Features/Policy/Background

From FedoraProject

< Features | Policy(Difference between revisions)
Jump to: navigation, search
(New page: == Background == The Feature process was created because in previous releases of Fedora, the status and handling of new features was not completely defined. This resulted in last minute s...)
 
 

Latest revision as of 17:19, 15 July 2008

[edit] Background

The Feature process was created because in previous releases of Fedora, the status and handling of new features was not completely defined. This resulted in last minute surprises when a particular feature that had been advertised as being an important part of the next release was not ready or its status was unclear. The Fedora Board wants Fedora releases to have a predictable release schedule. Proactively monitoring features on a periodic basis should help to add predictability to the release schedule and clearly communicate which new features should be expected in the next release of Fedora.

If everyone working on the next release of Fedora acts independently without communication or coordination between themselves we end up with simply a pile of bits at the end. The value of having features defined up front is many-fold:

  1. Everyone has an idea of what everyone else is working on. This provides the opportunity for feedback and suggestions for improvement.
  2. You get people interested--perhaps even helping out
  3. You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area
  4. You generate excitement around what's being worked on
  5. You avoid surprises at the end
  6. Public accountability to do what we say we are going to do
  7. Easier Release Notes creation for new features--everything needed is on the individual feature pages.
  8. Ability to list out a set of features to be picked up or when talking to the media/press. Fedora ambassadors and any promotional efforts would find a feature list useful.

All of these are important. And yes, some things that are planned will not make it. That is fine. By tracking them, we should be able to know sooner that a feature is in trouble so that others can either jump in to help out or to begin setting expectations that it will not happen.