RE: Process, Tracker and Bugzilla

I’d be happy for that to be the general structure of the BZ repository, however in order to make forward progress on the work packages I don’t think they canl be so neatly categorized.

What I might suggest is “Work Package” to be an additional component at the same level as your list, possibly with versions for specific work packages.

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 14 June 2013 14:05
To: Sean Hayes
Cc: public-tt@w3.org
Subject: Re: Process, Tracker and Bugzilla

I would like a courser grained partition, as it is often confusing for folks to determine which bucket applies. We also need to account for possible addition of VTT work.

BZ divides the world into Product and Component. So I'd suggest we have a small number of Products, such as:

TTML
WebVTT

For components for the TTML product, I would suggest the following:

Animation
Layout
Metadata
Other
Parameters
Processing
Profiles
Schemas
Specification
Styling

There is also a third sub-division, Version, so for the TTML/Specification component, we could have:

1.0
1.0SE
Next

I think this should be adequate to start, then we can sub-divide further if needed.



On Fri, Jun 14, 2013 at 2:41 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
Yes. I’m working on them right now. I’ll hopefully have them all up on the Wiki by EOD
The existing packages are:

HTML5 mapping (reference rendering)
TTML DOM API

Roughly the new ones are (not in any specific order):

3D extensions

Animation beyond set

Complexity model

Editorial cleanup

Metadata vocab

Profile fixes

Schema fixes

Audio rendering

Style.CSS additions

Style.Defaults

Style.Image additions

Style.Syntax fixes

Typography.Advanced

Typography.General

Typography.I18n

UX

XML fixes


Details to follow.

From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: 14 June 2013 07:09
To: Sean Hayes
Cc: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: Re: Process, Tracker and Bugzilla

Can you propose the initial set of components (work packages)?

On Fri, Jun 14, 2013 at 2:01 PM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
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 ☺)

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.