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>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]
> *Sent:* 14 June 2013 07:09
> *To:* Sean Hayes
> *Cc:* 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>
> 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 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.****
>
> ** **
>