Trac Usage Guidelines

  1. Trac Usage Guidelines
  2. Wiki
  3. Ticket Management
    1. Versions
    2. Ticket Types
    3. Milestones
    4. Priorities
    5. Components
With a small lack of effort, this trac can become something akin to the wild west.

If you follow this guide we can (hopefully) reduce the amount of time taken in periodically tidying up the trac.

Wiki

Trac wiki doesn't automatically support "child pages" so please add doco under the relevant parent:

For example Watcher/UserGuide.

Ticket Management

Guidelines:

  1. Make sure you put as much info into the ticket as possible
  2. Update your ticket as you work on it
  3. If you want to work on a ticket assigned to someone else, speak to them about where they've got to
    • If they just haven't got round to looking at it they are probably happy just to assign it to you!
  4. If 1 ticket is taking more than a few hours, break it down into smaller tasks
  5. Close completed tickets

Versions

We are working hard to create a stable release procedure. This will assist developers and users to know what the next version will and won't do. To assist us, please note that:

  • Tickets that need to be completed for the current version must be placed into that version (easy!)
  • As we start planning for the next version, we'll start assigning tickets to it.
    • Try to complete tickets for the current version
  • Any tickets not relating to the current of next version are put into the bucket

IN GENERAL: This means that each system should have a bucket and NO MORE than 2 versions - the version being worked on and the next version.

BUT: If there's a major bug in a previous version we may bring that version back up for defect tickets

Guidelines:

  1. When you submit/review a ticket, make sure you check Report {10} to make sure it's in the right spot

Ticket Types

  • defect: Existing software does not appear to work or is incorrect in some way
  • task: A general ticket, mainly for new code/documentation
  • enhancement: For the enhancement of existing software

Milestones

We basically treat 1 week as a milestone. So the trick is to work out what needs to be done week by week and allocate the appropriate tickets to the milestone.

It's a good way to indicate what you're working on this week and can be check in the Roadmap

Priorities

These will generally be determined by the project officers. You can suggest a priority level.

Guidelines:

  1. If it's a "nice to have" please put it down as a Feature Request

Components

We've tried to make sure these match the various aspects of the systems but please let us know if something's missing