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.

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.

Creating a new ticket

Click on the [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:

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.

Other properties and functionality

Related fields

Any check-ins and 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.


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.


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

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.

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.