Process, Tracker and Bugzilla

All.

I am considering how we can better manage, and hopefully accelerate, our process a little in the run-up to TPAC when we may have to take on additional workloads incurred by a revised charter and WebVTT work..

I have been finding of late that the tracker software, while good for keeping track of action assignments, is not so good for actually maintaining our various specifications. I note that many groups have transitioned to using Bugzilla. In particular the WebVTT CG is doing so, and in anticipation of a smooth transition of their work items into our group, I therefore propose that we transition to Bugzilla, sooner rather than later to get used to the workflow.

In preparation for this, and to estimate a burn-down rate between now and November, I have been analyzing the open issues and I believe they fall into about a dozen major classes, which I'll call for want of a better term work packages.  I'll be following up later with this breakdown.

I propose with the groups consent to do the following:


1.      Have Philippe set us up with a bugzilla repository.

2.      Consolidate all of the existing issues into the broad work packages identified.

3.      Create a new straw-man change proposal/placeholder on the wiki for each work package which summarizes all of the issues related to that package.

4.      Have each work package be identified as a component for bug tracking purposes, as well as components for SDP, SE and 1.1

5.      Identify an owner for each work package (don't all volunteer at once J)

6.      Close out all of the existing issues

7.      Register all new issues going forward as bugs in bugzilla.

Then as an ongoing process I would like to run each work package effectively as its own mini project using an Agile/Scrum like methodology, where the identified owner keeps up to date with the backlog for that work package, prioritizes the backlog; and defines iterations for the package of about 2 weeks with specific actions for the top work items from the backlog for that iteration, and at the end of each iteration we'll transfer whatever we have at that point for each work package into the edit queue(s) for Glenn to process.

We will close out work packages as and when their backlog is cleared.

I'm opening this up for debate now, with a view to adopting this plan this at next week's call. Silence will be deemed consent, however you are encouraged to actively voice approval if you agree.

I do not plan to debate this during the meeting, it will be a simple Go/No go decision. So if you have questions, or an issue with this plan please raise it in response to this email in advance of the meeting.

Thanks

Sean.