GitHub Issue Labels

We try to use the same issue labels across all TestCentric projects as much as possible. Please consult with the rest of the team before adding any more. The labels are described below in groups according to the purpose they serve.

Type of Issue

There should be only one of these labels on a given issue because they are used in creating release notes automatically.

The following types of issues may appear on milestones and cause the issue to be added to the release notes automatically. Only one such label should be used on any issue.

• Bug Something that isn't working as designed.
• Documentation Solely pertaining to documentation or sample code.
• Enhancement An addition or improvement to an existing feature.
• Feature An entirely new feature.
• Build Something to do with how we build the software, scripts, etc. Includes packaging releases.
• Refactor What it says: refactoring that is needed.

The following types of issues are not added to milestones and do not appear in our release notes.

• Question Just a question. Generally closed when answered. May be changed to something actionable in some cases.
• 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 is not static, what was low may later become more important, for example.

• Critical A Critical issue is one, which must be fixed immediately for an emergency release. This should be rare.
• High Priority Implement as soon as possible.
• Normal Priority Implement when we can.
• Low Priority Implement later or not at all.

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.

• 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.

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, because that's the usual reason for closing.

• 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.

Area Affected

By default, we assume issues pertain to the standard GUI or test model. These optional labels help identify other areas needing attention.

• Experimental GUI Issue pertains to the Experimental GUI
• TestCentric Engine Issue pertains to our test Engine.
• NUnit Compatibility An issue identifying an area of compatibility between the TestCentric and NUnit engines.
• TestCentric 2.0 An issue pertaining to the next major release of the TestCentric GUI.

Miscellaneous and Special Labels

• Easy Fix The issue appears suitable for newcomers to work on.
• Hacktoberfest Used in October each year, when we participate in the Hacktoberfest event.
• Linux Issue only appears under Linux. Use this to attract contributors with Linux machines.
• Resolved Applies only to NUnit Compatibility issues and indicates that we have resolved what to do about a particular compatibility. The issue remains open until that action is carried out by this project, the NUnit project or both.