Tickets - Revision history

Rhaas: change NEW to new

2019-03-27T17:29:54Z

change NEW to new

Rhaas: updated to match bitbucket capabilities, removed discussion about naming of states, removed discussion about what to do if multiple persons work on ticket in parallel

2019-03-27T17:29:23Z

updated to match bitbucket capabilities, removed discussion about naming of states, removed discussion about what to do if multiple persons work on ticket in parallel

Gabella at 15:24, 14 March 2019

2019-03-14T15:24:21Z

Hinder: /* Priority */

2015-10-14T04:34:57Z

‎Priority

68.106.163.203: /* Priority */

2014-12-09T21:48:53Z

‎Priority

68.106.163.203: /* Triage */

2014-12-09T17:55:37Z

‎Triage

Eschnett: /* Milestone */

2014-12-08T15:57:10Z

‎Milestone

Eschnett: /* Priority */

2014-12-08T15:56:19Z

‎Priority

Eschnett: /* Priority */

2014-12-08T15:54:17Z

‎Priority

Eschnett at 15:52, 8 December 2014

2014-12-08T15:52:46Z

@@ Line 7: / Line 7: @@
 === 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:
+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;

@@ Line 1: / Line 1: @@
 <span style="background:yellow">This draft document is a work-in-progress.</span>
-The Einstein Toolkit uses the TRAC issue tracker to keep track of current problems and new features.  This page describes how this system is used.
+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==
@@ Line 9: / Line 7: @@
 === 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 "triaged" or "lookedat". <span style="background:yellow">Maybe we want a better name for this.</span>  <span style="background:lightblue">eschnett suggests "accepted".</span> <span style="background:lightgray">knarf thinks that "accepted" gives the wrong impression that this means "accepted" by that maintainer (in the sense that she/he will be working on it. This is one of the default states trac has, and accepting a ticket means exactly that: to be the new "owner" of the ticket.</span> The process of triage includes:
+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, the ticket state should be set to "review", and assigned to a reviewer (the reviewer can unaccept the assignment, or reassign it).  If the review is passed, the state should be set to "reviewed_ok".  This indicates that it is ready to commit or merge.  Once this has happened, the ticket can be closed as "fixed".
+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 TRAC ticket metadata is used in the Einstein Toolkit.
+The following sections describe how the bitbucket ticket metadata is used in the Einstein Toolkit.
 ===Type===
@@ Line 31: / Line 27: @@
 ! style="text-align:left;"|  Value || style="text-align:left;"| Meaning
 |-
-|Defect    || Something does not do what it is supposed to do
+|bug                 || Something does not do what it is supposed to do
 |-
-|Enhancement         ||   A new feature proposal
+|enhancement         || A new feature proposal
 |-
-|Task         || Something that needs to be done that does not make any change to the code
+|task                || Something that needs to be done that does not make any change to the code
 |}
@@ Line 43: / Line 39: @@
 ! style="text-align:left;"|  Value || style="text-align:left;"| Meaning
 |-
-|New    || The ticket has been newly-created, and not yet triaged by a maintainer
+|new                  || The ticket has been newly-created, and not yet triaged by a maintainer
 |-
-|Accepted/Assigned         || 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
 |-
-|Reopened         || The ticket was closed before, but the problem came back, or was not fully fixed
+|resolved             || the ticket has been acted on and the proposed change applied
 |-
-|Closed         || (fixed, invalid, duplicate, wontfix, worksforme) - self-explanatory
+|duplicate            || the ticket is a duplicate of another ticket, which has been linked in
 |-
-|Review         || A patch has been created which is ready to apply, and approval and/or comments are needed
+|invalid              || RH: should this be used for incorrect tickets, issues that cannot (anymore) be reproduced?
 |-
 |}
@@ Line 61: / Line 62: @@
 ! style="text-align:left;"|  Value || style="text-align:left;"| Meaning
 |-
-|Blocker  ||    The ET does not build, or another problem which means development cannot continue. This requires immediate attention.  <span style="background:yellow">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?</span>
+|blocker  ||    The ET does not build, or another problem which means development cannot continue. This requires immediate attention.  <span style="background:yellow">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?</span>
 |-
-|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.
+|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
+|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
+|minor         || Not important enough to necessarily look at before a release
 |-
-|Optional    || Very low priority
+|trivial       || Very low priority, though maybe not trivial to implement
 |}
-===Owner===
+===Assignee===
-This is the TRAC 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.
+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===
@@ Line 88: / Line 89: @@
 ===Keywords===
-We have a set of keywords and meanings which allow certain things to be searched for easily.  You can enter multiple keywords separated by spaces.  The following are currently defined
+Keywords should be added to the ticket description as needed using a line of the form:
 {|  {{PrettyTable}}
-! style="text-align:left;"|  Keyword || style="text-align:left;"| Meaning
+! style="text-align:left;"|  Value || style="text-align:left;"| Meaning
 |-
-|backport         || The fix needs to be applied to the latest release, as well as the current trunk
+| backport || to request that a change be backported to the release branch
 |-
 |}

←Older revision		Revision as of 15:24, 14 March 2019
Line 1:		Line 1:
		+	'''This document seems out-of-date, the new ticketing system is on Bitbucket.org and nolonger on Trac.'''
		+
	<span style="background:yellow">This draft document is a work-in-progress.</span>		<span style="background:yellow">This draft document is a work-in-progress.</span>

@@ Line 59: / Line 59: @@
 ! style="text-align:left;"|  Value || style="text-align:left;"| Meaning
 |-
-|Blocker  ||    The ET does not build, or another problem which means development cannot continue. This requires immediate attention.
+|Blocker  ||    The ET does not build, or another problem which means development cannot continue. This requires immediate attention.  <span style="background:yellow">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?</span>
 |-
 |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.

@@ Line 65: / Line 65: @@
 |Major         || Needs to be fixed before release, or documented as broken in release notes
 |-
-|Minor         || Not important enough to look at before a release
+|Minor         || Not important enough to necessarily look at before a release
 |-
 |Optional    || Very low priority

@@ Line 78: / Line 78: @@
 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.
 <span style="background:yellow">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?</span>
 ===Component===

@@ Line 61: / Line 61: @@
 |Blocker  ||    The ET does not build, or another problem which means development cannot continue.
 |-
-|Critical       || At least one thorn always fails to run, or something else which requires immediate attention
+|Critical       || At least one important thorn cannot be used, or something else which requires immediate attention
 |-
-|Major         || Needs to be fixed before release or documented in release notes
+|Major         || Needs to be fixed before release, or documented as broken in release notes
 |-
 |Minor         || Not important enough to look at before a release

@@ Line 9: / Line 9: @@
 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 "triaged" or "lookedat".   <span style="background:yellow">Maybe we want a better name for this.</span>  <span style="background:lightblue">eschnett suggests "accepted".</span> The process of triage includes:
 * checking that the title and description make sense;
 * possibly assigning the ticket to a person (see below).
-<span style="background:yellow">How do we avoid multiple maintainers triaging tickets at the same time?  Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.</span>
+<span style="background:yellow">How do we avoid multiple maintainers triaging tickets at the same time?  Each maintainer theoretically has an area of expertise (https://docs.einsteintoolkit.org/et-docs/Organization_and_Responsibilities), but these are not uniquely assigned.</span><span style="background:lightblue">eschnett does not think this will be a problem.</span>
 ===Review===