| | 1 | = The Life of a Ticket = |
| | 2 | |
| | 3 | One of the central parts of Haiku Development is [http://dev.haiku-os.org/ this website]. It is a place for users to report problems, for (new) contributors to upload and propose patches, and for developers to discuss future features. |
| | 4 | |
| | 5 | The main resource through which these are done are called tickets. A ticket contains a bug report or feature requests, and it is a means for the ticket reporter and the developer to track the state of that ticket. |
| | 6 | |
| | 7 | This document is intended for ticket triagers, (new) contributors and developers. If you are an end user and you want to report a bug, have a look at ReportingBugs. |
| | 8 | |
| | 9 | == Different Roles during the Life of a Ticket == |
| | 10 | |
| | 11 | There are different people involved with a ticket. While every logged in user can add a comment to a ticket, and add themselves to the CC list to stay notified, there are some special users that are involved with a ticket. These users can be grouped into four categories. |
| | 12 | |
| | 13 | * The '''reporter''' is the person that creates the ticket. It is the duty of the reporter to be as concise as possible when describing a bug. The reporter also has to be available to provide additional info and testing until the ticket is closed. |
| | 14 | * The '''triager''' is someone that goes through all the tickets in the __new__ state and that checks whether the bug report is clear enough and provides all the information. If so, the ticket is passed on. |
| | 15 | * The '''owner''' is the person that owns a ticket. All components have a default ticket owner, but sometimes the owner is also set to another developer that is working on the ticket. The owner is responsible for all tickets assigned to him/her that have the __assigned__ or __in-progres__ state. |
| | 16 | * The '''developer''' is the person that is working on the ticket in order to fix it. When the developer is a Haiku core developer, he will usually be the '''owner'''. If a new contributor is tackling the ticket, the '''owner''' is the person that will work with the contributor to get the patch ready for the [/browser repository]. |
| | 17 | |
| | 18 | == The States of a Ticket == |
| | 19 | |
| | 20 | A ticket has several 'life' phases. Each life phase is associated with a 'state'. In every state the details of a ticket can be edited, comments can be added and people can add themselves to the CC list. There are five different states. |
| | 21 | |
| | 22 | === __new__ === |
| | 23 | |
| | 24 | Tickets that are created start with this status. What should happen is that a '''triager''' can look at the ticket and see whether it is complete. If not, the '''reporter''' should be available to give further information. If the bug report contains the required information, the '''triager''' ''reassigns'' the ticket to someone. The ticket will then have the __assigned__ status. Sometimes, the default component owner sees the ticket and picks it up right away. He/she can ''accept'' the ticket (so it will become __in-progress__) or ''reassign'' it to someone else. |
| | 25 | |
| | 26 | === __assigned__ === |
| | 27 | |
| | 28 | When a ticket has passed triaging, it will be __assigned__ to another '''owner'''. The owner should then decide whether to keep the ticket, or whether it belongs to someone else. In case the ticket belongs to the '''owner''', he can either ''accept'' it if he has the intention of working on it (the status will then be __in-progres__), or he can just add a comment that the ticket does belong to him/her, but that it will not be worked on right away. |
| | 29 | |
| | 30 | A '''developer''' can at any point 'intercept' a ticket when it is __assigned__ and ask the '''owner''' whether he can work on it. In case a core developer wants to do the ticket, he can ''accept'' it. If a contributor wants to work on the ticket, the ''owner'' should accept it. |
| | 31 | |
| | 32 | === __in-progres__ === |
| | 33 | |
| | 34 | These are tickets that have been ''''accepted'''' and that are being worked on. In case an interested contributor comes across a ticket with the status __in-progres__ and it seems to be inactive, that contributor can ask the '''owner''' through a comment what the status of the ticket is. Do not start to work on it right away, as you might be doing duplicate work. |
| | 35 | |
| | 36 | The '''reporter''' should stick around to help out testing patches (if needed). |
| | 37 | |
| | 38 | If a patch is accepted, and committed to the [/browser repository], then the ticket will be ''resolved''. If the ticket is resolved, its status will be ''closed''. |
| | 39 | |
| | 40 | === __closed__ === |
| | 41 | |
| | 42 | There are four reasons why a ticket is closed. |
| | 43 | |
| | 44 | * It is marked as 'fixed'. This means that a patch has been submitted to the [/browser repository]. |
| | 45 | * It is marked as 'invalid'. This means the '''triager''' or the '''owner''' could not reproduce the issue. |
| | 46 | * It is marked as 'junk'. This ticket is spam. |
| | 47 | * It is marked as 'duplicate'. There is already a ticket that describes the same problem. The comments should mention which ticket. |
| | 48 | |
| | 49 | If the issue still seems to occur, or there is a regression, the ticket can be ''reopened''. This is also the case for an 'invalid' ticket that is supplied with new information. |
| | 50 | |
| | 51 | === __reopened__ === |
| | 52 | |
| | 53 | If a previously closed issue has been ''reopened'', this means: |
| | 54 | |
| | 55 | * The ticket was not properly 'fixed' or due to new changes the old issue appears again. The ''owner'' is responsible for looking into it. |
| | 56 | * The ticket was 'invalid' but the '''reporter''' has new information that might make the problem reproducible. A '''triager''' should look into it. |
