Version 1 (modified by Jari Häkkinen, 16 years ago) (diff)

Added ticket usage information.

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 developer 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 know dependencies in the ticket desciption 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.