Tickets in Github

We use Github tickets (“issues” in Github terminology) to define and track issues and potential issues at the repository level.

Tickets should generally be created:

Any code change pushed to a repository should be associated with a ticket, with only rare exceptions.

Any person in STG/LIT may create a ticket in an STG/LIT project repository. Often our projects include partners outside STG/LIT, and those project team members may also create tickets in the appropriate repository.

Anatomy of a Ticket

####Title:

####Description: The description should concisely, yet sufficiently describe the scope of work and desired result. It should be specific enough that a pull request addressing this ticket can be tested to determine whether it accurately implements the change.

Descriptions should include #references to other tickets where appropriate. This helps to navigate between cross-connected issues. When mentioning other github users, use @mentions, as this will trigger Github to notify each user mentioned. (See Github’s guide to notifications, references, mentions, etc..)

Defects (“bugs”) should include the following:

Adding comments

In general, do comment liberally in the Description section. Github doesn’t charge us per word.

If a discussion about a ticket occurs in real life (and we encourage real-life discussions here), go ahead and add some notes into the ticket to capture the important points of the discussion. Adding this into the ticket is helpful for many reasons, including:

####Tags (Labels): Tagging tickets is optional, but can be very useful. These tags should be used when applicable:

Multiple tags may certainly be applied to a ticket.

Ad-hoc tags may be created and used as appropriate per project.

A useful feature of Github is the ability to filter issues by label.

####Assignee:

####Milestone:

Pull Requests Are Github Issues (Tickets) Too

As far as Github is concerned, a Pull Request (“PR”) is just another type of Issue. We like the creator of a Pull Request to include: