***HTCondor Tickets***

A ticket is an object describing and tracking a bug, new feature, project, incident, or action item related to the software development of HTCondor.


{subsection: Ticket life cycle and status attribute}

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}

Click on the {link: tktnew [Ticket]} link at the top of the page. 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.


*: *Ticket Number* is unique to each ticket and can be referenced in
{wiki: FormattingWikiPages wiki markup} using the
{quote: #n} syntax.

{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
their own sections.

Tickets may also have _children_ which reference them in their *Derived From*
properties. These child tickets will be listed in a separate section, allowing
a certain amount of hierarchical project task management.

{subsubsection: History }

A separate page containing a full ticket history provides a chronologically
ordered list of _all_ events associated with a ticket. Property changes,
remarks, check-ins, attachments, inspections, etc, are all listed here.

Changes to certain fields, such as *Description* and *Remarks* are shown in
_diff_ style.

{subsubsection: Attachments}

Arbitrary files may be
{wiki: CvstracAttachment attached} to tickets. This could include things
like screenshots, design documents, etc. Attachments are of
limited size.


{subsubsection: Undoing Changes}

When in the _history_ view, it's possible to undo changes. A user with *delete*
permissions or the user responsible
for the change can do this within 24 hours while a user with *admin*
permissions can do so at any time. An _undo_
link is included at the last item of the history page in this case.

{subsubsection: Deleting Tickets}

Users with *setup* permissions can always delete
tickets. Tickets should only be deleted as a last resort. If
a ticket contains valuable project history, it should instead be closed.

Users (except *anonymous*) with *delete* permissions
can delete tickets created by *anonymous* within 24 hours of ticket creation.