Re: RFC: Feature process improvements

[John Dulaney]

I would suggest that we create a clear SOP for fall back planning in case
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."

John.

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

[Matthew Miller]

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.

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-tutoria...
has a decent Google Docs template, but we wouldn't want to make that
requirement for our process.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

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

[Jaroslav Reznik]

----- 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-tutoria...
>  has a decent Google Docs template, but we wouldn't want to make that
>  requirement for our process.
>  
>  
>  
>  --
>  Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁
>   <mattdm(a)fedoraproject.org&gt;
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Matthew Miller]

On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote:
>  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. 
The reason I like Bugzilla over Trac for this is that it's easy to link the
actual work (in the form of bugzilla entries against packages), which
reduces the overhead by making it almost automatic once the tracking bug is
set up. By contrast, a Trac instance would need to be manually updated and
maintained, wouldn't it?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

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

[Josh Boyer]

On Thu, Dec 6, 2012 at 1:04 PM, Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>  On Thu, Dec 06, 2012 at 08:11:01AM -0500, Jaroslav Reznik wrote:
> > 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.
>
>  The reason I like Bugzilla over Trac for this is that it's easy to link the
>  actual work (in the form of bugzilla entries against packages), which
>  reduces the overhead by making it almost automatic once the tracking bug is
>  set up. By contrast, a Trac instance would need to be manually updated and
>  maintained, wouldn't it? 
Trac is also horrible to work in.  Bugzilla isn't leaps and bounds better
but at least it sends reasonable plain-text emails that don't have
horrible wiki syntax in them.

Thank you for avoiding new suggested uses of trac.

josh