-***CVSTrac Tickets***
+***HTCondor Tickets***
-A ticket is an object describing and tracking a bug, feature request, project,
-action item, or any other type of thing that you might want to track within a
-software development team.
+A ticket is an object describing and tracking a bug, new feature, project, incident, or action item related to the software development of HTCondor.
-Unlike some issue tracking systems, CVSTrac doesn't associate significant
-amounts of process overhead with tickets. There aren't any constraints on who
-can change specific fields, what states can lead to other states, who can
-assign tickets, etc.
-**Ticket Features**
+{subsection: Ticket life cycle and status attribute}
-*Properties*
+A newly created ticket has a _status_ attribute of =New=. Once a developer is actively working on this ticket, it should be marked as =Active=. For anything but the most trivial of enhancements or bug fixes, the first step is to write a design document. Once a design document has been attached to this ticket, the ticket should go to =ReviewDesign= state until approved - often times this results in a new/edited version of the design document. After design approval, the ticket will go back to =Active= while being implemented. If the developer has permission to push directly to the HTCondor git repository, this implementation may happen on a topic branch; if not, the implementation may be attached to the ticket as a patch file or a github fork URL can be placed in the remarks. Once the implementation is complete, the ticket should go to =ReviewCode= and be re-assigned to another developer for a code review. The result of this code review will appear in the ticket Remarks and be clearly labeled in bold-face with *CODE REVIEW*. After review, this ticket is assigned back to the original developer to address any issues identified in the review. After implementation is complete, the ticket should go into =DocPending= state until the HTCondor Manual has been updated appropriately, after which the ticket may go to =Resolved=. Other less common ticket status values include =stalled= for a ticket that was active in the past, but is no longer being worked on), =pending= for a ticket that is awaiting additional input from a third-party (typically more information related to reproducing a bug), and =abandoned= for a ticket that we will never work on or for a ticket that is a duplicate of a previously existing ticket.
+
+{subsection: Creating a new ticket}
+
+It is very important the the fields of the ticket are assigned proper values, and that the formatting for the fields is strictly followed. When creating a new ticket, most of the fields should be obvious from the desciptions, just be careful about following the formatting conventions as described. A couple comments on a few fields:
+
+*: *Title / One-line summary* should be as descriptive as possible since it appears in
+various cross-references, reports, ticket link titles, etc.
+
+*: *Type* should be set to =Code Defect= for a software bug, =Code Enhacement= for adding new capabilities or enhancing existing capabilities, =Action Item= for activities not related to the code (e.g. updating the web site), and finally =Support Incident= for describing suspicious observed behavior when you are not (yet) sure if the problem is due to a bug. Do not use type =Documentation= for new tickets.
+
+*: *Priority* describes how quickly the ticket should be resolved, and have special meaning to the HTCondor developers. Priority 1 is do ahead of everything / fire priority. Priority 2 means very important, must get done within the next couple releases. Priority 3 means we should make every effort to get it done in the current development series. Priority 4 means nobody has thought yet about the priority of this ticket (essentially, this ticket has not yet been triaged). Priority 5 means "idea network" - it is a worthy idea but unknown when (or ever) anything will happen.
+
+*: *Assigned To* identifies the developer responsible for this ticket. This person will automatically get an email whenever this ticket changes. If you do not know who should get the ticket, assign to =tannenba= and he will re-assign and/or re-prioritize.
+
+
+*: *Notify* should be a comma separated list of email addresses. Every time the ticket is updated, the list of addresses in this field will be sent an email summarizing what changed. Note that the person to who the ticket is _Assigned To_ automatically gets email notifications.
-Tickets have the following fields available:
*: *Ticket Number* is unique to each ticket and can be referenced in
{wiki: FormattingWikiPages wiki markup} using the
{quote: #n} syntax.
-*: *Title* should be as descriptive as possible since it appears in
-various cross-references, reports, ticket link titles, etc.
-*: *Notify* should be a comma separated list of email addresses. Every time the ticket is updated, the list of addresses in this field will be sent an email summarizing what changed. Note that the person to who the ticket is _Assigned To_ automatically gets email notifications.
-*: *Type* describes the kind of ticket, such as _bug_, _action item_, etc.
-Ticket types are configurable.
-*: *Status* describes the current state of the ticket. Possible states
-are also configurable.
-*: *Fixed Version* is the earliest released version that has (or will have) the new code. A new, open, or stalled ticket uses this field to indicate the release we would like to include the fix for. A resolved ticket should indicate which release actually included the fix. Format released versions as "vXXYYZZ" - note starting 'v' and zero-padding. So 7.4.1 would represented as v070401. If this field contains a single digit, it's an old Severity value; feel free to reset it as appropriate.
-*: *Priority* decribes how quickly the ticket should be resolved. This isn't
-necessarily related to *Severity* (i.e. a serious bug in a non-operational
-product isn't always high priority).
-*: *Assigned To* identifies which CVSTrac user should be handling the ticket.
-*: *Creator* identifies which CVSTrac user created the ticket (including,
-possible, *anonymous*)
-*: *Broken Version* is the earliest known version that exhibits the problem. Format released versions as "vXXYYZZ" - note starting 'v' and zero-padding. So 7.4.1 would represented as v070401.
-*: *Created* shows when the ticket was created.
-*: *Last Changed* shows when the ticket was last changed.
-*: *Subsystem* is intended to identify which component/area has a problem.
-This list _must_ be configured by the administrator.
-*: *Derived From* lists a parent ticket, if any.
-*: *Contact* lists a way to get hold of the problem reporter. Typically, this
-is an e-mail address. Contact information is _not_ made available to
-*anonymous* CVSTrac users.
-*: *Description* is a {wiki: FormattingWikiPages wiki} field providing
-information about the nature of the ticket.
-
-Additional custom ticket fields may be
-defined by the administrator. This could include things like billing
-information, due dates, completion percentages, resolutions, reporting
-organizations, etc.
-
-*Remarks*
-
-The *Remarks* property is a special {wiki: FormattingWikiPages wiki}
-field which can be editted directly, but also has a special _append_ option
-where users can add comments and discussion to a ticket. When appending, a
-timestamp and user name is automatically added into the remarks.
-*Related Objects*
+{subsection: Changing ticket status and other updates}
+
+Ticket properties including status can be edited by following the _Edit_ link in the ticket
+view. Remarks can be added by following the _Add remarks_ link in the *Remarks*
+area of a ticket view.
+
+{subsection: Other properties and functionality}
+
+{subsubsection: Related fields}
Any {wiki: CvstracCheckin check-ins} and
{wiki: CvstracMilestone milestones} related to the ticket are listed in
@@ -66,7 +46,7 @@
properties. These child tickets will be listed in a separate section, allowing
a certain amount of hierarchical project task management.
-*History*
+{subsubsection: History }
A separate page containing a full ticket history provides a chronologically
ordered list of _all_ events associated with a ticket. Property changes,
@@ -75,45 +55,15 @@
Changes to certain fields, such as *Description* and *Remarks* are shown in
_diff_ style.
-*Attachments*
+{subsubsection: Attachments}
Arbitrary files may be
{wiki: CvstracAttachment attached} to tickets. This could include things
-like screenshots, specifications, standards documents, etc. Attachments are of
+like screenshots, design documents, etc. Attachments are of
limited size.
-**Creating New Tickets**
-
-A new ticket is created by clicking on the *Ticket* link available in the
-navigation bar. A new ticket form will be opened and the user would then enter
-all appropriate information.
-
-The ticket form is a combination of text fields and dropdown menus. Dropdown
-menus provide a fixed set of items to choose from and are often populated with
-reasonable defaults.
-
-A large text area is provided for the problem description. As with most
-components of CVSTrac, this text area allows (and encourages) the use of
-{wiki: FormattingWikiPages wiki formatting}.
-
-As with any such system, detailed and complete information is encouraged.
-
-**Changing Tickets**
-
-Ticket properties can be editted by following the _Edit_ link in the ticket
-view. Remarks can be added by following the _Add remarks_ link in the *Remarks*
-area of a ticket view.
-
-A ticket can be automatically associated with a
-{wiki: CvstracMilestone milestone} or
-{wiki: CvstracCheckin check-in} simply by mentioning the ticket in the
-appropriate message using the {quote: #n} wiki markup.
-
-In some cases, ticket changes may result in
-notifications being triggered, if the
-administrator has configured this.
-**Undoing Changes**
+{subsubsection: Undoing Changes}
When in the _history_ view, it's possible to undo changes. A user with *delete*
permissions or the user responsible
@@ -121,7 +71,7 @@
permissions can do so at any time. An _undo_
link is included at the last item of the history page in this case.
-**Deleting Tickets**
+{subsubsection: Deleting Tickets}
Users with *setup* permissions can always delete
tickets. Tickets should only be deleted as a last resort. If
