wiki:UsingTrac
Last modified 11 years ago Last modified on 07/11/06 15:39:33

Basic rules of using Trac in this project

This document describes the practices that are used with Trac in this project (Calibrate WP3).

Tickets

  • We have several types of tickets:
    • Story: User stories, describing the product from the user's point-of-view
    • Prototype: details of graphical layouts and user interactions that usually complement user stories
    • Enhancement: Programming task, describing one new feature.
    • Defect: Programming task, describing one bug.
    • Task: Generic task, describing one thing that should be done.

Work cycle

  • Design:
    1. Designers can create new user stories that is then discussed using comments and by editing the body of the story
      • new ticket type: story
      • summary: good short summary of the story
      • description: user story
      • milestone: n/a
      • accepted by: none
      • priority: n/a
    2. When designers have agreed upon a user story, it can be accepted by a product owner
      • accepted by: one of the product owners (Teemu, Hans, Tarmo); no-one else may accept stories
      • milestone: any future milestone, but not the one currently in implementation; or none, meaning the story isn't scheduled yet
      • priority: the importance of the story (in comparison with other stories in the same milestone)
  • Development:
    1. Developers estimate accepted user stories
      • time estimated: estimate of implementation effort using BCK (best current knowledge) in hours, preferrably done jointly with all developers
    2. When a new milestone is started, sprint planning takes place:
      1. An estimate of the total work that development can do during the sprint is calculated by Tarmo, based on the WeeklySchedule
      2. Product owner reprioritizes the stories for the imminent milestone
        • priority: corrected importance based on estimated cost
      3. Product owner needs to postpone stories if the total estimated effort of the stories exceeds the capacity of the team
        • milestone: changed to a later milestone for tickets that are postponed
      4. Developers split all remaining stories for the milestone into enhancement tickets
        • new ticket type: enhancement
        • summary: good short summary of the feature
        • description: starts with (story #123) where 123 is the number of the story; followed by enough details of the feature so it can be estimated and implemented (ask the product owners for details when necessary)
        • priority: same as the priority of the story
        • accepted by: none
        • milestone: the current milestone
      5. Developers estimate all new enhancement tickets together
        • time estimated: estimate of implementation effot using BCK in hours, preferrably done jointly with all developers
      6. If the total estimated effort of the enhancement tickets exceeds the capacity of the team, lowest priority stories (and enhancements) are postponed by the product owner until capacity is not exceeded
        • milestone: changed to a later milestone for tickets that are postponed
    3. Work on the milestone starts
      • No new enhancements or stories can be added to that milestone
      1. Individual developers accept enhancement and defect tickets they would like to work on
        1. unassigned defect tickets should be selected first, starting with the highest priority
        2. if no unassigned defect tickets remain, unassigned enhancement tickets for that milestone are selected, starting with the highest priority
        • assigned to: the developer who accepts the enhancement or defect ticket
      2. Developers do unit tests, implement the features or fix the bugs, test, and commit
        • time spent: cumulative amount of time spent working on the ticket
        • time remaining: current estimate of time remaining
      3. Developers close tickets when they are done
        • time spent: total amount of time spent working on the ticket
        • time remaining: 0
        • status: closed, fixed

Discussions and decisions

  • All decisions should be recorded into the Trac system so they're visible to everybody.
    • In general decisions are done by writing them into a wiki page of suitable topic.
    • If a decision is made about a certain ticket, then the decision is stored into that ticket.
  • Discussions may be held anywhere, but the results should be stored into Trac.
    • Face-to-face discussions
    • Discussions in the mailing list
    • Discussions in the wiki pages or tickets in Trac

Wiki pages

  • All wiki pages should have a link to them from the front page of Trac.
    • Place the link to the best matching section of the front page.
  • All wiki pages can be commented
    • You can just add comments to any section of a page, and append your own name. Use bold to highlight your name.
    • You can add the macro "AddComment?" to the end of a page, which will create a comment area for easy commenting (see end of this page's source).

Additional instructions

Downloading trac pages for offline browsing

You can download trac pages for offline browsing with a program called "wget".

Get all tickets for offline browsing:

wget -r -l 1 -k -p http://lemill.org/report/15

Get all wiki pages for offline browsing:

wget -r -l 1 -k -p http://lemill.org/wiki/TitleIndex

(meaning: Recurse, go down 1 Level, Konvert links for local viewing, get all page Prerequisites)

AddComment?