Tickets
(Draft)
Contents
Thoughts on how to manage tickets
This document is a work-in-progress.
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 | ? |
| Minor | ? |
| Major | ? |
| Critical | ? |
| Blocker | The component (or toolkit) cannot be used. We cannot release with a ticket in this state. |
Type
| Value | Meaning |
|---|---|
| Defect | A bug |
| An improvement suggestion | |
| Task | Something that needs to be done that does not make any change to the code |
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 |
