> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
