Last week FESCo approved the Fedora 11 schedule. The Fedora 11 milestones are posted.
I am still planning to create detailed schedules in TaskJuggler for some of the Fedora teams. A first look at the detailed schedule is here. I took my first crack at this a year ago. These schedules have been useful to a certain extent, but I would like to find a way to make them more valuable and used more often.
Each release I have tried to create better schedules that truly reflect each of the tasks that goes into completing a Fedora release. Improvements have come from understanding how to work with TaskJuggler better (structuring and optimizing the data file and refining the report generation) while also becoming more familiar with the tasks each team performs.
Why does creating detailed schedules matter? Besides giving project managers something to live for, detailed schedules offer several benefits:
- acknowledging how much estimated time a task takes
- identifying dependencies between tasks
- identifying and coordinating dependencies between teams
- providing more checkpoints to take corrective action and keep the release on time
- helping the uninitiated see all the steps necessary to create a release
- something to point at when someone asks “Why aren’t we done yet?”
If the word schedule makes you break out in hives, think detailed task list instead.
Three important parts of detailed schedules are:
1) building it
2) referencing or using it
3) comparing plan to actual
Building the schedules is challenging because I’m not always familiar with what a task entails or what it depends on. Figuring this out can be a tedious process of back and forth on mailing lists. Telephone and gobby has helped, but then time zones get in the way 
. Often we’ve found while discussing one team’s schedule, a missing or unaccounted for tasks becomes apparent in another team’s schedule. A good example of this happened while creating the Fedora 11 Translation schedule. Content was to be created by the Documentation team, translated by the Translation team, and posted by the Websites team. The documentation schedule had a vague reference to the task, it was missing from the translation schedule, and I realized maybe it would be a good idea to create a Website’s team schedule for the next release.
I’m hoping to meet with the artwork, documentation, translation, websites and any other interested team members at FUDCon in Boston (January 9-11, 2009) to make sure we are tracking the right tasks and better understand how maintaining these schedules can help.
I reference the schedules from time to time, particularly for the release readiness meetings, but on the whole since I’m not actively involved in all of the teams or capable of attending every team meeting, I don’t look at them that often. During the past few releases it has been easy to track the planned versus actual schedule because I’m on the Release Engineering team. For other teams like Artwork, Documentation, and Translation I’ve done a decent job collecting and plotting the tasks necessary to complete a release on the schedule, but have had less ability to track actual results. It might help if there was a designated person on each team that could relay schedule updates to me or send patches to the TaskJuggler source file. I’d like to think that the detailed schedules could also be useful for weekly team meetings, though maybe less useful for teams that track tasks using Trac tickets.
Historically we have not been very concerned about tracking or comparing actual results to the original plan. TaskJuggler makes tracking plan to actual data very easy. The hard part is remembering to collect the actual data along the way because after the fact it becomes much harder to remember. I’ve tried to gather some historical data by looking at old revisions of the wiki milestones, but the value there is limited because it is at such a high level. All you end up with is plan to actual for a particular milestone without any indications which of the underlying tasks caused the difference. Being able to track what we accomplished or didn’t in the desired time frame is important if we want to continue to increase the efficiency and predictability of our release processes.
I want Fedora to be a release that strives for excellence and is known for being on time. I also want Fedora to be known as a place that tries to make it easy for others to understand what all the teams do and to see all the moving parts that make a release come together.
