-
Notifications
You must be signed in to change notification settings - Fork 0
03 Terms and Labels
Issue reports are generally called Tickets.
The term "issue" implies something is wrong, or a bug. Bugs/Problems are reported in Bug Tickets.
A request for a new feature, or simple change request, implies a positive change. Such changes are reported in Enhancement Tickets.
Questions should go to one of the community forums, or in Discussions here. But some questions about anomalies result in change requests for enhanced documentation, or we may discover a question has been raied due to a bug. Therefore, starting a ticket as a Question is also acceptable.
Labels are provided in four categories: type-, component-, status-, resolved-. These labels make tickets easy to find and process.
As noted above, types are type-bug, type-enhancement, and type-question. Types may be changed based on discussion.
Two primary components are tracked here, component-app and component-docs.
- All tickets begin with no status label.
- When first found, the
status-01-newlabel may be applied to indicate "we know it's here but it has not been processed yet". - A ticket them moves to
status-02-discussion(or it may start in this status) if discussion if a ticket is created based on a forum report or other event. - From there they might be rejected or moved to
status-03-confirmed. This does not imply a commitment to make a change. The status only verifies understanding or acknowledgement of a concern. It may imply confirmation of an issue or verification of a documentation change request. Until moved to another status or resolution, tickets in this state should be considered pending, or waiting for scheduling or disposition. - When actually being worked on, tickets are moved to
status-04-in-progress. - When processing is complete a ticket moves to
status-05-changes-complete. At this point the change is awaiting peer verification, testing, beta or some other pre-production confirmation. - Prior to production, changes generally move to
status-06-beta. A filter/report can be used to see changes in this status. Testing is welcome for tickets in this status. - Finally, when in production tickets move to
resolved-completed. Changes in this status can be used to create a release change log. - At any time a ticket status may change to
status-needs-more-info. After discussion a ticket will usually move back to its prior status, but not always. After more information is obtained an issue might be deemed invalid, or might result in the creation of other tickets. - It may be common for tickets to skip a status or to be rolled back. The numbers in the status names are used to help identify where a ticket is in processing.
A ticket can be resolved and closed as being resolved-completed, resolved-duplicate, resolved-invalid, or resolved-will-not-change.
- Completed tickets are closed after a release goes production.
- Duplicates will be linked to other tickets. A later ticket should be linked as duplicate to an earlier ticket.
- Invalid tickets are usually based on a misunderstanding.
- The will-not-change resolution implies behaviour is intended, or that a change is out of scope, too difficult, or simply too complex to be supported at any time in the near future.