Tickets

From Einstein Toolkit Documentation
Jump to: navigation, search

This draft document is a work-in-progress.

The Einstein Toolkit uses bitbucket's issue tracker to keep track of current problems and new features. This page describes how this system is used.

Processes

Triage

When tickets are created, they are automatically placed into a "new" state. Such tickets should be triaged by a maintainer. Once triaged, their state will be changed to "open". The process of triage includes:

  • checking that the title and description make sense;
  • setting the priority and other metadata (see below);
  • possibly assigning the ticket to a person (see below).

Review

When a patch or branch is available for review, then the pull request URL should be added to the ticket and a reviewer suggested on the pull request. Reviewers should be contacted as well since being suggested to be a reviewer does not trigger a notification. If the review is passed, the pull request should be "approved", and once the pull request has been merged the ticket should be set tot the "resolved" state ideally mentioning the commit that resulted from the merge of the pull request. RH: should it then be "closed" as well?


Ticket metadata

The following sections describe how the bitbucket ticket metadata is used in the Einstein Toolkit.

Type

Value Meaning
bug Something does not do what it is supposed to do
enhancement A new feature proposal
task Something that needs to be done that does not make any change to the code

State

Value Meaning
new The ticket has been newly-created, and not yet triaged by a maintainer
open The user will oversee the ticket, usually doing the work themselves.
closed no more work will be done on the ticket and the ticket can be archived
resolved the ticket has been acted on and the proposed change applied
duplicate the ticket is a duplicate of another ticket, which has been linked in
invalid RH: should this be used for incorrect tickets, issues that cannot (anymore) be reproduced?
wontfix the observed behaviour is intentional or has already been fixed
on hold currently not being used

Priority

Value Meaning
blocker The ET does not build, or another problem which means development cannot continue. This requires immediate attention. Must the build failure affect all machines, or just a subset? Is it a blocker if just one of the supported machine cannot be used?
critical At least one important thorn cannot be used, or something else is severely broken. If this is not addressed quickly, the respective change should be reverted.
major Needs to be fixed before release, or documented as broken in release notes
minor Not important enough to necessarily look at before a release
trivial Very low priority, though maybe not trivial to implement

Assignee

This is the bitbucket user who is expected to perform the next work on the ticket, and who will do so soon (on a timescale of a week). Feel free to assign ownership to other people. This should be interpreted as a polite request to do something if possible. If you are assigned a ticket, feel free to reject the assignment if you don't have time or inclination to work on it. Ticket can be "Reassigned to" an empty field, which removes ownership. If a ticket sees no progress after about a week or so, consider removing the ownership, unless the owner plans to work on it soon.

Milestone

Tickets can be assigned a release milestone. This means that we want to have these tickets looked at for the upcoming release. It is normal that not all of these will be addressed in time. Note that it doesn't make sense to add a milestone to a ticket unless someone is likely to work on it, and ideally that should be the person who assigned the milestone. We should make a clear distinction between tickets which are "major", i.e. important enough to be considered for the release, and those which have the milestone. What is the difference? Essentially, "priority=major" indicates that the ticket is important enough to be considered for the release, whereas unimportant tickets may also be tracked in relation to a release, if someone has an intention to work on them. Is this right/useful? eschnett thinks this may not be useful</span.>

Component

Which area of the code (or infrastructure) is affected. This is useful for people who are experts in a particular area to see all the problems in that component.

Keywords

Keywords should be added to the ticket description as needed using a line of the form: ``` keyword: SOMEKEYWORD ``` to simplify searching for them. Currently used keywords are:

Value Meaning
backport to request that a change be backported to the release branch

Version

The version of the code that the problem is reported against. This will either be the development version or a particular release.