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

Jaroslav Reznik jreznik at redhat.com
Thu Dec 6 13:11:01 UTC 2012


----- Original Message -----
> On Wed, Nov 28, 2012 at 09:39:03PM -0500, John Dulaney wrote:
> > a feature, especially a crit path feature, is not ready for prime
> > time.
> > Obviously, if a feature is not %100 by feature freeze, then it
> > needs to be
> > dropped.  I would even venture to suggest that we include in the
> > SOP
> > something along the lines of "If feature is not 80% by point X (X
> > being two
> > weeks prior to freeze), then FESCo should at that point evaluate
> > enacting
> > the fall back."
> 
> I don't think percent-complete is very helpful. The numbers are often
> completely arbitrary, and even if they are actually accurate to that
> project
> hard to compare in a relative sense. 80% of a small feature may be
> far
> closer to complete than 99% of a major one.

That's the reason why I tried to ask feature owners to provide a comment,
not only percentage update as what's important for us is - what's needed to
get feature completed not how far do we think we are. As even that last
1% could be a show stopper and also it's not easily comparable as you
said.

For Feature tracking on wiki - it's really very suboptimal, hard to 
update manually (especially the Feature List), it has to be in sync with
Feature page Status Section... Using Categories often leads to 
disappearing of Feature due to errors (FeatureReadFESCo and you have a
problem).

At FUDCon Milan, we discussed using Trac to manage Spin process - it's
actually very similar process. And for tracking stuff I think it's more 
suitable than Bugzilla - custom states, better overviews + use Wiki just
for feature description/overview as it's easier editable than Trac ticket.

I already added Feature Process component to Project Schedule trac - I
can try to draft it (and set it up there). Also FESCo voting on Features
could be moved from theirs Trac as it's quite polluting it (but it really
depends - another Trac instance, you're kidding...).

For F19 we try the smaller steps as the process should be running right
now and submission deadline is in month and half. But I'd like to call
FUDCon session on making features/development/scheduling "better" - as
it's very closely tight together...

Jaroslav

> 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.
> 
> 
> 
> --
> Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
>  <mattdm at fedoraproject.org>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list