It would be useful to have customizable ticket states. I had the experience that visualizing the ticket flow as much as possible is a good idea.
My main use case is the following: If someone starts working on a ticket, it should be set to in progress. This makes it easy to see whether someone started working on something. It also helps myself to limit in-progress work and focussing on finishing stuff.
Another possible use case (but I didn’t think about it too hard): If "outsiders" report a bug, it should be in a state which indicates that someone from the project should triage it. For features, it should be easy to see whether something is just a proposal or it was decided to implement it at some point. Similarly, for bugs should be easy to see whether it was already confirmed or not.
This is actually already in the database, we just need a UI for it.
Nice! Is this effort tracked somewhere? What additional features were implemented?
It's not being tracked anywhere, this ticket will do. The original design of todo.sr.ht included these fields in the database.
From a long standing FOSS bug tracker:
- open states:
- UNCONFIRMED
- NEW
- ASSIGNED
- REOPENED
- closed states:
- RESOLVED
- VERIFIED
- CLOSED
UNCONFIRMED is for untriaged bugs. After it's been confirmed to be a bug, it advances to NEW, and awaits to be picked up by someone (at which point it advances to ASSIGNED).
If and when an issue is in one of the closed states, there is an additional field called "Resolution", which can be set to one of:
- empty
- FIXED
- INVALID
- WONTFIX
- LATER
- REMIND
- DUPLICATE
- WORKSFORME
- MOVED
Additionally, when it is in the ASSIGNED state, the "Assignee" field gets activated, and must be filled in.
There is also a field labelled "QA Contact", which can be set to a user. Typically, the assignee fixes the bug, and advances it to RESOLVED, at the same time setting the Resolution field to an appropriate value. The QA Contact user (when set) automatically gets notified by email, and when done with verifying the fix works, he/she advances the bug to VERIFIED.
The verification process is optional, and if it's not a bug, but a pure task, it will simply stay there as RESOLVED.
CLOSED is typically used when it becomes clear early that no action is needed. Such a bug would be moved to CLOSED, and the Resolution field would typically be set to DUPLICATE, WORKSFORME, or MOVED.