Re: Process, Tracker and Bugzilla

OK, that sounds more like an Action Item or Task management category, yes?
That can cut across the functional components?


On Fri, Jun 14, 2013 at 9:20 PM, Sean Hayes <Sean.Hayes@microsoft.com>wrote:

>  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>
> 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.****
>
>  ****
>
> ** **
>