User Tools

Site Tools


Bug & Feature Tracker

For all newly detected bugs a ticket should be created, even if a bug is already fixed by current work related to another work package. Analogously, a new feature request should be created for each new feature that is implemented. This helps to track changes over different versions of Scaffold Hunter (e.g., for creating the changelog of a release). The associated commits and branches should contain a reference to the bug / feature request, such that it can be associated with the respective ticket (see Commit & Branch Conventions).

Tracker Fields

Open States

  • open: The default state for new bugs/feature requests
  • re-opened: A bug/feature that was in a closed state or review-state, but needs to be re-opened because the bug/ was not fixed (correctly), the bug/feature implementation caused some side-effect or the feature was incomplete.
  • needs-info: The bug/feature is stalled, because further information are needed from the reporter to fix it.
  • in-progress: Someone is currently working on this bug/feature (the responsible developer should be assigned as owner of this bug). In this state nobody else should grab the bug without contacting its owner! We can save some mails like “on which features/bugs are you currently working” with this state.
  • needs-review: If you have fixed a bug or implemented a feature, but you want somebody else to review it before closing the bug, this is the right state. You should go for this if you have changed a larger part and want to be sure you have not introduced new bugs. This is also a good way to tell the reporter of a bug, that he should test, if the bug is also resolved for him. In the latter case you should also write a comment with the request to retest and specify the version/branch he should use. For a general review you might want to add a hint, what parts should be reviewed more precisely than others.
  • needs-merge: If a bug/feature in a feature branch has been fixed/implemented and is reviewed but cannot be merged immediately this state should indicate, that the associated code/work still needs to be merged. A typical example is a fix/feature, that breaks some backward compatibility and therefore needs to be hold back until the next major release.
  • on-hold: If a bug/feature has been partially fixed/implemented, but some kind of dependency prevents further work until the dependency is fulfilled, a bug should be marked as on-hold. The dependency may be another bug or a general organization issue.

Closed States

  • closed: The bug (feature) has been fixed (implemented).
  • wont-fix: We decided not to fix this bug or not to implement the feature, respectively.
  • invalid: The bug report does not follow some minimal conditions (e.g., the bug reported is not a bug, but a feature ;-), spam, unclear description). May be used after a needs-info request is not responded for a longer time.
  • duplicate: The bug was already reported. Please add a reference to the duplicate bug in this case.


  • any future version: Used for all new bugs and feature requests
  • next release: The bug should be fixed in the next release
  • no milestone: Bug will not be fixed, is invalid, a duplicate or not related to a release
  • closed: x.x.x: Bug has been fixed with release version x.x.x

Also see Organization of the release process.


  • blocks: This is a list of bug / feature request ids. This bug / feature request must be fixed / implemented before any of the listed blocked bugs can be fixed / implemented.
  • depends on: This is a list of bug / feature request ids. This bug / feature request depends of the fix / implementation of another bug and can only be completed afterwards.
  • related to: This is a list of bug / feature request ids.. This bug is somehow related to another bug, but it does not depend on or blocks the other bug. E.g., this is a good place to reference other bugs that may have the same cause.

Usually, a block entry “B” in a bug / feature request A implies a “depends on” entry “A” in bug / feature request B. Please ensure, that the dependency is always listed in both bugs (A and B).

Referencing commits

To reference the respective commits, which fix a bug / implement a feature, the 6-digit-hash of the commit should be used in squared brackets, e.g., [abcdef]. The system will automatically create a link to the associated commit.

tracker.txt · Last modified: 2017/04/10 15:26 by till