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

Candidate timetable

Weeks run from Tuesday through to Monday of the following week, to coincide with the regular Committers Meeting on Tuesday of each week, during which activites of the previous week can be reviewed, and activities for the coming week can be planned.