~sircmpwn/todo.sr.ht#183: Ticket states

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.

Status: REPORTED
Submitter: ~mjacob
Assigned to: No-one
Submitted: 5 years ago
Updated: 3 years ago
Labels: No labels applied.

~sircmpwn 5 years ago

This is actually already in the database, we just need a UI for it.

~mjacob 5 years ago

Nice! Is this effort tracked somewhere? What additional features were implemented?

~sircmpwn 5 years ago

It's not being tracked anywhere, this ticket will do. The original design of todo.sr.ht included these fields in the database.

~rwa closed duplicate ticket #220 4 years ago

~c-alpha 3 years ago

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.