features and percentages [was Re: RFC: Feature process improvements]

[Fabian Deutsch]

> On Wed, Dec 05, 2012 at 08:19:15PM +0100, Fabian Deutsch wrote:
> > > I like burndown charts. Low overhead, easily read, and generally more
> > > concrete than guesses at percentage done. I wonder if there's a way we can
> > > easily provide a widget in the wiki for keeping them up to date. This:
> > > http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
> > > has a decent Google Docs template, but we wouldn't want to make that
> > > requirement for our process.
> > 
> > I must say that the Ubuntu folks are distilling their bugzilla
> > informations quite well on http://status.ubuntu.com/ubuntu-raring/ . The
> > good thing about this solution is, that bugzilla is (AFAIK) used to track
> > the progress of a feature - and using bugzilla could be also a doable to
> > track our features.
> 
> Well, it's their launchpad bug tracker, not bugzilla. It's a great idea,
> though. Anyone want to volunteer to write something that extracts data from
> our bugzilla and presents it in this format? 

Ah yes, it's launchpad ...

> One approach: a convention where each feature gets a tracking bug, and then
> various tasks can be marked as blocking that. *Then*, each release can have
> a tracking bug for accepted features themselves, and the tool to produce the
> chart can simply be pointed at that and follow the tree downward.

Yes - I think that's a good convention in general, to have tracker bugs for all features
requested for a new release.
And this convention can be independent from the tool visualizing the resulting bug tree.
We could even start with a blocker bug for a release itself.

- fabian