We use labels to help categorize and prioritize issues and to communicate their status to users. The labels we currently use are described below in groups according to the purpose they serve.
Type of Issue
When you create an issue, assign one of these labels to it, according to what best fits.
- Breaking Change This usually involves the removal or partial disabling of a feature. It requires a major version upgrade. See VERSIONING.md in the root of the project for more information.
- Feature An entirely new feature is being added.
- Enhancement An addition or improvement to an existing feature.
- Bug Something that isn't working as we intended.
- Refactor Changing how the code works without changing what it does. Includes reorganizing, internal name changes, etc.
- Documentation A change pertaining solely to documentation or sample code.
- Build Something to do with how we build the software, scripts, etc. Note that this may be a bug fix, enhancement or even a new feature of the build scripts. However, we use Build because that's how we want these changes to be listed in the release.
- Question Just a question. Generally closed when answered. May be changed to something actionable in some cases. Most questions come from users but we can also use this label for questions one of us is asking the other devs.
- Idea Just an idea we are considering. We either close these without action or change to a feature or enhancement.
Priority
As with issue type, there should only be one of these on an issue. Priority may change over time.
- Critical A Critical issue is one, which must be fixed immediately for an emergency release. This should be extremely rare.
- High Priority Implement as soon as possible.
- Normal Priority Implement when we can.
- Low Priority Implement later or not at all. If we decide not to implement the issue may eventually be closed.
Status
We don't maintain a systematic tracking of issue status because it would be too burdensome. Some status information, however, is important enough to warrant an optional label. When using any of these labels, it's important to remove them after the need is resolved.
- Needs Discussion We need to have some team discussion and possibly user input before proceeding.
- Needs Confirmation A bug has been reported and needs to be confirmed before we do anything more.
- Needs Design The issue is something (usually a new feature) we are willing to do but some up-front design is needed. There should always be a comment on the issue explaining what sort of design we're talking about, which may be anything from UI design to internal structure.
- Blocking The issue is keeping other issues from being worked on.
- Blocked The issue is blocked by another issue or some external factor. The reason should be specified.
Issues Closed Without Action
When an issue is closed without taking any action, we use one of these labels to indicate the reason. Note that there is no label for issues that were closed by completing the work required or answering a question. That's for two reasons: (1) because that's the usual reason for closing and (2) because it saves a step when issues are closed automatically upon merge.
- Duplicate The issue is a duplicate of another issue. A comment should indicate the issue number.
- Not a Bug The issue (generally a bug) is closed as not valid or the feature already exists. There should be an explanatory comment.
- Not Reproducible We are unable to reproduce the behavior described in a bug report.
- Won't Fix The issue is closed as something we don't intend to implement. It may be out of scope for the project or inconsistent with the values and priorities of the project. There should be an explanatory comment.
Miscellaneous and Special Labels
- good first issue The issue appears suitable for newcomers to work on. Used by GitHub to highlight projects seeking volunteers.
- Hacktoberfest Used in October each year, when we participate in the Hacktoberfest event.
- NetCoreRunner Being used at this time to highlight issue pertaining to NUnit.ConsoleRunner.NetCore, while we figure out what to do with it.
Creating Labels
All team members are authorized to create labels. Please don't go crazy and keep the labels in a similar style to the standard ones. Include a description of the label when you create it and update this page if the label is for general use. If the label is temporary, delete it when you don't need it any longer.