[mylyn-dev] proposal to update planning process

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

I would like to suggest a small change to our process for triaging of bugs with the goal of increasing transparency and predictability of release planning. I have illustrated the updated process in this graph: http://wiki.eclipse.org/Mylyn/Bug_Triage

The picture looks complicated but it's only a small change to our current process which is documented in the contributor reference: http://wiki.eclipse.org/Mylyn/Contributor_Reference#Triage. 

I am proposing to add a prioritized release backlog in addition to maintaining a backlog of all open requests and to limit tasks that are in progress.

Currently, we set the milestone for proposed bugs for a release which usually leads to a large number of unresovled bugs getting rescheduled shortly before releases. Some bugs get rescheduled several releases in a row which causes confusion and disappointment for integrator and users watching those bugs. Also, with the restructuring we now have to plan across several Bugzilla products with different milestones (e.g. Mylyn 3.7 includes Mylyn Reviews 0.9) making it diffcult to report over the plan.

To communicate the release plan more clearly I suggest that we mark all proposed bug with the plan keyword and prioritize them in Bugzilla. Once a committer or contributor commits to resolving a particular task for a release the milestone is set accordingly and the bug is assigned. Optionally, the status is set to Assigned to communicate that work is now in progress.

The nice thing about the plan keyword and assignment is that it spans across products allowing to query for those tasks.

Every Thursday we review recently resovled and assigned bugs during the regular meeting and schedule additional bugs based on the available people. 

My expectation is that we will have better control over the bugs that end up on a milestone and will be able to resolve a larger proportion making the plan more reliable. It also allows us to react to contributions that we generally can't plan for more easily since committers will be less overloaded. Hopefully the release backlog will be reasonably small (<100 bugs) to do meaningful prioritization which hasn't been feasible with the overall backlog which has surpassed 1500 unresolved bugs.

I would at least like to try this for one release cycle and then review results and decide to revert or make adjustements.

Any thoughts or comments? 

Steffen

-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com