Release Management/Liberty Tracking
- 1 How release tracking worked in Kilo
- 2 Problems we are trying to solve
- 3 Proposed Liberty release tracking
- 4 Implementation
- 5 Future plans
How release tracking worked in Kilo
In Kilo and previous releases, release tracking was a double mission:
Communicate what is likely going to land in the cycle by maintaining our best attempt at a prediction
This was done by constantly refining the list of blueprints that are likely to land for each milestone. This is the work of release liaisons for each project, work that is reviewed almost every week during the 1:1 syncs.
Produce release pages that list the key features (and bugfixes) that were added during a given development milestone and cycle
On the bugfixes side, this was done using automated scripts that take FixCommitted Launchpad bugs and target them to the milestone they were fixed in. On the features side, this was done by taking the milestone objectives list, trusting that all completed work was actually targeted, and deferring incomplete work to the next milestone.
Problems we are trying to solve
- Current Release tracking takes a lot of time (3 hours per week) and doesn't scale
- Most of the time (80%) is spent achieving the first part of the mission
- The prediction we communicate is extremely unreliable
- Nobody actually seems to consume the prediction we communicate
- Product managers are actually more interested in seeing the list of things being worked on, and then the list of things that were actually implemented.
Proposed Liberty release tracking
The proposed change is to stop using Launchpad milestone pages before a milestone is actually completed (i.e. stop trying to predict). Release liaisons may use Launchpad series page instead, as a way to conveniently track release cycle main goals. The release status page would be reworked to communicate the completed work and the status of the in-progress work (without necessarily promising when it shall land).
Move away from per-milestone predicting to giving a general completion status of features being worked on
- Assignees should maintain the status of their blueprint (in particular, set it to "Started" when started and to "Implemented" when completed)
- Release liaison may opt to track their specific cycle goals by setting the series goal (not mandatory)
- Assignees may target their blueprint to a future milestone, as an indication of when they intend to land it (not mandatory)
- Stop running the autokick script to guard milestone pages and align series goal and milestone targets
- Reorganize release status page to show past milestones completed blueprints first, then series-targeted blueprints (then, maybe, other started stuff)
- No longer hold weekly 1:1 syncs, be available on-demand instead
Continue to produce release pages
- On milestone tags, automatically remove the milestone target from incomplete bugfixes and blueprints (or defer to next milestone ?)
- Automatically pick up recently-FixCommitted bugfixes and add the milestone target to them (as usual)
- Automatically pick up recently-Implemented blueprints and add the milestone target to them
- Release liaisons should make sure we don't miss a key feature (and retroactively file an implemented blueprint if that's the case)
- Hold a specific 1:1 sync point when a tag is due (milestone week) to make sure we are up to date and ready
- Disable autokick script for the Liberty cycle
- Create a Launchpad script to pick up recently-Implemented blueprints and add the milestone target to them, to use in milestone.sh release script
- Create a Launchpad script to clear up milestone target on incomplete stuff when milestone tag hits
- Rewrite releasestatus so that it generates a new page with past milestones completed blueprints first, then series-targeted blueprints
- Consider cleaning up all old (started) blueprints, so that we can list started blueprints in the release status page (and rename it development status page ?)
- Evolve spec2bp as a tool to help release liaisons set/maintain the series goal (instead of the milestone pages)
- Create new CLI tool to help assignee update blueprint completion status
The future plans include moving from Launchpad to StoryBoard. StoryBoard shall clearly distinguish between what was completed (tracking the milestone which contains the fix) from lists of in-progress tasks (promising a feature or bug for a certain sprint/milestone/cycle). Promises and cycle goals will therefore be tracked into specific task lists. The milestone field will only be usable on completed tasks. This should reduce the confusion introduced in Launchpad by using the same field(s) to track promises and achievements. The Liberty proposed changes actually prepare that future by emulating the StoryBoard future concepts within Launchpad (for example by using "Series goal" to build a cycle goals task list).