F9 Feature Process

[Matthias Clasen]

On Wed, 2007-10-31 at 19:41 -0700, John Poelstra wrote:

> ~~~~~~~~~~~~~~ Quick Overview if you don't want to visit the wiki ~~~~~~~~~~~~~~~~~~~~
> 
> Here are some of the big issues from my perspectiveones:
> 
> 1) What is a FEATURE and how should the policy be clarified http://fedoraproject.org/wiki/Features/Policy#definition
>   -considering that anyone can commit new code and packages to Fedora what is unique about a feature?
>   -it is waste of everyone's time to have someone create a feature page and then for FESCo to say "denied--that isn't a feature

I think it is worth making it more explicit that there are different
kinds of features. Something like "replace program a with program b" or
"rewrite program c" (examples are esd -> pulseaudio, or NM) is very
different from "gradually improve fedora wrt. to foo" (examples are
better laptop support, less power consumption). For the former, it makes
sense to have a contingency plan, which will usually be "stay with the
old version". For the latter, it is fine to just do as much as you get
done for this release, and continue improving the situation afterwards.
For the gradual improvement type features, the main question at feature
freeze time is if we have achieved enough of an improvement to make a
big splash about it.


> 2) Do we have common agreement on the purpose of creating a feature page?
>   -marketing?
>   -testing?
>   -release notes?
>   -other
>   -all of the above?

Pretty much all of the above, I'd say, plus some more
    - developer synchronization if several people work on a feature
    - cross-distro and upstream communication; I find it e.g. a big 
      help to look at Ubuntu blueprints occasionally to see how their
      plans line up with ours


> To someone not familiar with Fedora wouldn't they expect http://fedoraproject.org/wiki/Releases/8/FeatureList
> and http://fedoraproject.org/wiki/Releases/8/ReleaseSummary to contain the same information or for there to only 
> be one page? The ReleaseSummary page is really good by the way!

I would expect FeatureList to be the starting point, and ReleaseSummary
the end result of turning it into a shiny and attractive document.


> 6) What if a feature is not ''complete'' at Feature Freeze?  
>   -How do we decide to drop it versus give it more time?

This really depends on the type of feature; for the gradual features discussed about, dropping them is not very 
meaningful. For "replace existing functionality" or "new stuff" features, dropping could be a possibility, but 
looking at this at feature freeze time is really too late; if we want to be serious about dropping features, we 
need to do closer monitoring of features before the freeze, and ensure that the contingency plans are in place
and that people are aware of the approaching freeze, and don't miss it by accident. 

Out of interest, I didn't see any information about how we did in terms of features that made it in vs features 
that were dropped or deferred in your F8 recap. Did we drop anything, and if so, have you looked at why ?


Matthias