This is a design page for deciding which issue project-wide tags to have in GNOME's GitLab instance.
Goals / Requirements
- Avoid making issues a lot of work or very complicated.
- Ensure that tags can be easily understood by a range of audiences, including newcomers.
- Indicate the state of issues in a way that can be quickly recognised and viewed from issue lists/search results.
- Endorse particular reasons for closing issues, as a framework for decision making.
- Enable newcomers to find issues that they can easily work on.
- Provide a way for members of the accessibility, documentation and translation teams to find issues that are relevant to them (and potentially generate email notifications that they can receive)
- Enable maintainers and bug squad members to weed out issues that are no longer relevant.
- Enable developers to find bugs of a similar type, so they can find them and work on them as a set, for example.
- A way for the release team to mark release blockers - they can use milestones for this.
bug, confirmed, critical, discussion, documentation, enhancement, suggestion, support
Seems to be a fairly long random mix of labels, some of which are grouped by color.
- Random colors: bug, build error, documentation, duplicate, enhancement, feedback, help wanted, in progress, invalid, more information needed, needs reproduction, needs review, needs testing, performance, proposal, question, regression, transient, triaged, ui, under review, wontfix, work in progress
- Red: crash, data loss, deprecation-help, security, uncaught exception
- Status: Archived, Duplicated, Invalid, Open, Resolved
- Priorities: Confirmed, High, Incomplete, Low, Needs Triage, Normal, Unbreak Now!
- A - includes - unicode, testsuite, runtime, plugin, parser, security, stability
- C - bug, cleanup, enhancement, feature-accepted, feature-request, future-compatibility, tracking-issue
- E - easy, hard, help-wanted, medium, mentor, needs-mentor, needstest
- I - compilemem, compiletime, crash, ICE, needs-decision, nominated, slow, unsound
- O - android, ARM, freebisd, ios, linux, macos, openbsd...
- P - high, low, medium
- regression-from-stable-to-beta, regression-from-stable-to-nightly, regression-from-stable-to-stable
- S - inactive-closed, waiting-on-author, waiting-on-bors, waiting-on-crater, waiting-on-review, waiting-on-team
- T - cargo, compiler, core, dev-tools-rustdoc, dev-tools, doc, infra, lang, libs
- WG - compiler-const, compiler-errors, compiler-front, ...
Sane GitHub labels
- Status: Abandoned, Accepted, Available, Blocked, Completed, In Progress, On Hold, Pending, Review Needed, Revision Needed
- Type: Bug, Enhancement, Maintenance, Question
- Priority: High, Low, Medium
- Status: Declined, Duplicate, Invalid, Stalled
- Priorities: High, Low, Lowest, Needs Triage, Normal, Unbreak Now!
- Types: Administrative Request, Bug Report, Deadline, Feature Request, Goal, Release, Task
- How should tags interact with kanban boards? These imply having status tags which track the progression or priority of an issue.