LilyPond Contributor's Guide: 8.4 Issue classification

## 8.4 Issue classification

The Bug Squad should classify issues according to the guidelines given by developers. Every issue should have a Status, Type, and Priority; the other fields are optional.

### Status (mandatory)

Open issues:

- New: the item was added by a non-member, despite numerous warnings not to do this. Should be reviewed by a member of the Bug Squad.
- Accepted: the Bug Squad added it, or reviewed the item.
- Started: a contributor is working on a fix. Owner should change to be this contributor.

Closed issues:

- Invalid: issue should not have been added in the current state.
- Duplicate: issue already exists in the tracker.
- Fixed: a contributor claims to have fixed the bug. The Bug Squad should check the fix with the next official binary release (not by compiling the source from git). Owner should be set to that contributor.
- Verified: Bug Squad has confirmed that the issue is closed. This means that nobody should ever need look at the report again – if there is any information in the issue that should be kept, open a new issue for that info.

### Owner (optional)

Newly-added issues should have no owner. When a contributor indicates that he has Started or Fixed an item, he should become the owner.

### Type (mandatory)

The issue’s Type should be the first relevant item in this list.

- Type-Collision: overlapping notation.
- Type-Defect: a problem in the core program. (the `lilypond` binary, scm files, fonts, etc).
- Type-Documentation: inaccurate, missing, confusing, or desired additional info. Must be fixable by editing a texinfo, ly, or scm file.
- Type-Build: problem or desired features in the build system. This includes the makefiles, stepmake, python scripts, and GUB.
- Type-Scripts: problem or desired feature in the non-build-system scripts. Mostly used for convert-ly, lilypond-book, etc.
- Type-Enhancement: a feature request for the core program. The distinction between enhancement and defect isn’t extremely clear; when in doubt, mark it as enhancement.
- Type-Other: anything else.

### Priority (mandatory)

Currently, only Critical items will block a stable release.

- Priority-Critical: LilyPond segfaults, a regression (see below) against a previous stable version or a regression against a fix developed for this version. This does not apply where the “regression” occurred because a feature was removed deliberately - this is not a bug.
- Priority-High: An issue which produces output which does not accurately reflect the input (e.g. where the user would expect an accidental, but none is shown) or which produces aesthetically poor output in a situation which could be expected to crop up frequently in real-world music. It should not be used where the problem can be avoided with a simple workaround. It can also be used to flag where new code in a development version is not functioning as it should. This level is also used for issues which produce no output and fail to give the user a clue about what’s wrong.
- Priority-Medium: Normal priority - use this as the default.
- Priority-Low: A minor problem which produces slightly undesirable output, or which will only occur in contrived examples, or which is very easily worked around.
- Priority-Postponed: no fix planned. Generally used for things which nobody wants to touch.

Note that these are initial classifications and can be subject to change by others in the development team. For example, a regression against an old stable version which hasn’t been noticed for a long time and which is unlikely to get fixed could be downgraded from Priority-Critical by one of the programmers.

### Opsys (optional)

Issues that only affect specific operating systems.

### Patch (optional)

Normal Bug Squad members should not add or modify Patch issues; leave them to the Patch Meister.

- Patch-new: the patch has not been checked for “obvious” mistakes. When in doubt, use this tag.
- Patch-review: the patch has no “obvious” mistakes (as checked by the Patch Meister), and is ready for review from main developers.

  Developers with git push ability can use this category, skipping over `patch-new`.

- Patch-needs_work: a developer has some concerns about the patch. This does not necessarily mean that the patch must be changed; in some cases, the developer’s concerns can be resolved simply by discussion the situation or providing notation examples.

  If the patch is updated, the category should be changed to `patch-new` (for normal contributors) or `patch-new` (for developers who are very confident about their patch).

- Patch-abandoned: the author has not responded to review comments for a few months.

### Other items (optional)

Other labels:

- Regression: it used to work intentionally in an earlier stable release. If the earlier output was accidental (i.e. we didn’t try to stop a collision, but it just so happened that two grobs didn’t collide), then breaking it does not count as a regression.

  To help decide whether the change is a regression, and therefore should be Priority-Critical, please adopt the following process:

  1. Are you certain the change is OK? If so, do nothing.
  2. Are you certain that the change is bad? Add it to the tracker as a Critical issue, regression.
  3. If you’re not certain either way, add it to the tracker as a Critical issue, regression but be aware that it may be recategorised or marked invalid.

  In particular, anything that breaks a regression test is a regression.

- Frog: the fix is believed to be suitable for a new contributor (does not require a great deal of knowledge about LilyPond). The issue should also have an estimated time in a comment.
- Maintainability: hinders development of LilyPond. For example, improvements to the build system, or “helper” python scripts.
- Bounty: somebody is willing to pay for the fix. Only add this tag if somebody has offered an exact figure in US dollars or euros.
- Warning: graphical output is fine, but lilypond prints a false/misleading warning message. Alternately, a warning should be printed (such as a bar line error), but was not. Also applies to warnings when compiling the source code or generating documentation.
- Security: might potentially be used.
- Performance: might potentially be used.

If you particularly want to add a label not in the list, go ahead, but this is not recommended.

#### LilyPond — Contributor’s Guide