Tickets

(Draft)

Thoughts on how to manage tickets

This document is a work-in-progress.

Triage

When tickets are created, they are automatically placed into a "NEW" state. Such tickets should be triaged by a maintainer. Once triaged, their state will be changed to "triaged" or "lookedat". Maybe we want a better name for this. The process of triage includes:

• setting the priority (see below);
• checking that the title and description make sense;
• possibly assigning the ticket to a person (see below).

How do we avoid multiple maintainers triaging tickets at the same time? Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.

Ticket metadata

Tickets have certain metadata, and more can be configured by the admin. We should decide what each of these means, and how we are going to use them.

Priority

Value	Meaning
Optional	Very low priority
Minor	Not important enough to look at before a release
Major	Needs to be fixed before release or documented in release notes
Critical	At least one thorn always fails to run
Blocker	The ET does not build, or another problem which means development cannot continue.

Type

Value	Meaning
Defect	Something does not do what it is supposed to do
Enhancement	A new feature proposal
Task	Something that needs to be done that does not make any change to the code

State

Value	Meaning
New	The ticket has been newly-created, and no decision has been made on what to do about it or who will do it
Accepted/Assigned	The user will oversee the ticket, usually doing the work themselves
Reopened	The ticket was closed before, but the problem came back, or was not fully fixed
Closed	(fixed, invalid, duplicate, wontfix, worksforme)
Review	A patch has been created which is ready to apply, and approval and/or comments are needed because that is the ET process
reviewed_ok	The patch has been approved and can be committed