Proposed release timetable for Fedora 3.4

Principles

• Break down the release into milestones
• Schedule work items against milestone
• Work items should be prioritised
• When scheduling, concentrate on the next milestone, scheduling all uncompleted items in order of priority
• Ensure all scheduled items have a responsibility against them; review milestone schedule against developer's availability and adjust as necessary
• Review priorities of outstanding items when milestone is complete and schedule the next milestone

Milestone workflow

• Initially all candidate issues for Fedora 3.4 should have Fedora 3.4 as the "Fix version(s)"
• At the start of a milestone
  • Review any newly-submitted issues, and either
    • Assign to "Fix version(s)" Fedora 3.4 if appropriate, and open; or
    • Assign to a future fix version if appropriate, and open; or
    • Close/won't fix if appropriate; or
    • Leave as submitted if not possible to make a decision
  • Prioritise all issues in "Fedora 3.4"
  • Move highest-priority issues into next milestone
  • Ensure all issues in next milestone are assigned
  • Ensure all issues in next milestone have a tester assigned
  • Review workload, add more issues from "Fedora 3.4" or move issues back to "Fedora 3.4" until milestone looks do-able
• During the milestone
  • Work on issues, according to who's assigned
• At the end of the milestone
  • Ensure completed items have been tested
  • Ensure completed items are marked completed
  • Move any unstarted issues back to "Fedora 3.4"
  • Move any work-in-progress items to the next milestone

To do: can we have a hierarchical "Fix version(s)" structure, ie Fedora 3.4->Milestone 1; or should we use a separate custom "Milestone" field?

Candidate timetable