Tickets

From Einstein Toolkit Documentation
Revision as of 12:02, 8 December 2014 by Hinder (talk | contribs) (Milestone)
Jump to: navigation, search

(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

Owner

This is the TRAC user who is expected to perform the next work on the ticket, and who will do so soon (on a timescale of a week). Feel free to assign ownership to other people. This should be interpreted as a polite request to do something if possible. If you are assigned a ticket, feel free to reject the assignment if you don't have time or inclination to work on it. Ticket can be "Reassigned to" an empty field, which removes ownership.

Milestone

Tickets can be assigned a release milestone. This means that we want to have these tickets looked at for the upcoming release. It is normal that not all of these will be addressed in time. Note that it doesn't make sense to add a milestone to a ticket unless someone is likely to work on it, and ideally that should be the person who assigned the milestone.

Version

Component

Keywords

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