Trac usage guidelines

The yat project is using trac as described here.

Ticketing system

• Prefer smaller tickets. A ticket may cover many aspects early in the process going from an idea or a request to implementation. The goal is to split larger tickets into smaller that represent well defined tasks.

• A ticket must be well specified. This implies that the creator of a ticket must supply information such that another developer can perform the task. Too little information may disqualify other developers from resolving the issue.

• When a developer starts to fix a ticket the ticket must be accepted. This is important to make sure that no one else is working on the same issue. Until a ticket is assigned to someone it is free for anyone to claim, but one should only claim tickets that will be solved in reasonable time.

• Until trac supports ​ticket dependencies we must keep track of them ourselves. Add links to known dependencies in the ticket description field. The order of the dependecies should reflect the order in which the tickets should be resolved.

• The commits to the repository should be as small as possible, Commit often and do it minimalistic. If there is a need to make large changes before a proper commit can be made (remember, the code in the repository must always compile) a branch should be created.

• Use the ticketing system for discussions about tickets.

• Use post-commit-hooks. A fairly complicated example of what you can do is with a commit message of: "Fixes #3 and #11, and refs #14". This will close #3 and #11, and add a note to #14.

• Please change the milestone to one of the other active milestones when you resolve tickets assigned to the convenience milestone later. The later milestone should not have any resolved tickets.

Monitoring the roadmap

You can monitor your personal tickets and roadmap items through your favourite calendar if it supports the iCalendar format, more information in TracRoadmap