The Life of a Ticket

One of the central parts of Haiku Development is ​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.

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.

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.

Different Roles during the Life of a Ticket

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.

• 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.
• 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.
• 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.
• 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 repository.

The States of a Ticket

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.

new

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.

assigned

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.

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.

in-progres

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.

The reporter should stick around to help out testing patches (if needed).

If a patch is accepted, and committed to the repository, then the ticket will be resolved. If the ticket is resolved, its status will be closed.

closed

There are four reasons why a ticket is closed.

• It is marked as 'fixed'. This means that a patch has been submitted to the repository.
• It is marked as 'invalid'. This means the triager or the owner could not reproduce the issue.
• It is marked as 'junk'. This ticket is spam.
• It is marked as 'duplicate'. There is already a ticket that describes the same problem. The comments should mention which ticket.

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.

reopened

If a previously closed issue has been reopened, this means:

• The ticket was not properly 'fixed' or due to new changes the old issue appears again. The owner is responsible for looking into it.
• The ticket was 'invalid' but the reporter has new information that might make the problem reproducible. A triager should look into it.