1. A summary status for all the features targeted to a particular release will be collected on a summary page which references and briefly explains the feature.

+

# A summary status for all the features targeted to a particular release will be collected on a summary page which references and briefly explains the feature.

−

* The Feature Wrangler will maintain this page.

+

#* The Feature Wrangler will maintain this page.

−

* This page will be located at: http://fedoraproject.org/wiki/Releases/<release number>/FeatureList

+

#* This page will be located at: http://fedoraproject.org/wiki/Releases/<release number>/FeatureList

−

1. Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce@redhat.com

+

# Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce@redhat.com

−

1. Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on fedora-devel-list@redhat.com

+

# Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on fedora-devel-list@redhat.com

Line 184:

Line 184:

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:

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.

+

# Everyone has an idea of what everyone else is working on. This provides the opportunity for feedback and suggestions for improvement.

−

1. You get people interested--perhaps even helping out

+

# You get people interested--perhaps even helping out

−

1. You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area

+

# You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area

−

1. You generate excitement around what's being worked on

+

# You generate excitement around what's being worked on

−

1. You avoid surprises at the end

+

# You avoid surprises at the end

−

1. Public accountability to do what we say we are going to do

+

# Public accountability to do what we say we are going to do

−

1. Easier Release Notes creation for new features--everything needed is on the individual feature pages.

+

# Easier Release Notes creation for new features--everything needed is on the individual feature pages.

−

1. 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.

+

# 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.

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.

Revision as of 01:21, 28 May 2008

This page describes the process for officially adding new features to the next major Fedora release. Feature submissions and enhancements are welcome from anyone!

Enhancements

Enhancements are:

Less documented improvements to a Fedora release which do follow the feature process and do not fit the feature definition below.

Added to the release summary by anyone under heading of Other Enhancements. The release summary for each release lives in the following namespace: http://fedoraproject.org/wiki/Releases/<release number>/ReleaseSummary

Features

Definition of a Feature

A feature is defined as a significant change or enhancement to the version of Fedora currently under development that may or may not include new packages.

Features are usually considered to meet one or more of the following objectives:

Add details for each of the sections using the template at Template as a guide.

Add CategoryProposedFeature to the bottom of the wiki page.

These pages do not have to be complete and are useful for brainstorming or work in process

Proposing Official Features

In order to be considered an official feature accepted for the next Fedora release, the feature should be formally documented on a separate wiki page which includes the following information:

Summary of the feature

A designated owner (with a link to contact information http://fedoraproject.org/wiki/<YourName> --including a valid email address). The owner is responsible for:

Making sure the feature is completed according to the schedule

Communicating periodic status

Attending feature status meetings

Current status

last updated

Estimated percentage of completion

Description of the new feature

Detailed explanation of what the new feature will do and how it will be implemented

Benefit to Fedora

Scope

Test Plan

Dependencies--on other packages or features

Contingency plan

Link to documentation

Important information for release notes

All sections must be complete (or noted as not applicable with an explanation) before the Feature Wrangler will submit a feature to FESCo for acceptance.

A blank template is available at and a completed example is at

Feature Acceptance

Definition

Acceptance by FESCo is a sanity check, presumed in most cases to be a formality, to ensure that new features compliment Fedora's guidelines and is manageable, prior to publicizing as officially targeted for the next release.

Feature acceptance is agreement by FESCo that a particular feature is:

consistent with the goals and policies of Fedora while within the laws governing the corporate entity sponsoring Fedora--Red Hat.

supported by the Fedora leadership.

suitable for listing as an Official Feature of the next release of Fedora

important to track prior to feature freeze and could affect timeliness of release

Process

The Feature Owner adds the feature page to CategoryProposedFedoraX

The Feature Wrangler reviews page for completeness and raises for review at next FESCo meeting

Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce@redhat.com

Nag mail to developers with delinquent feature page updates will be emailed privately and shamed in a nice way on fedora-devel-list@redhat.com

Important Milestones

New features may be proposed (using the guidelines above) and accepted no later than the feature freeze milestone

New features must be feature complete or close enough to completion that a majority of its functionality can be suitably tested--the "feature is testable".

At feature freeze the Feature Wrangler will present a final feature status to FESCo which FESCo will review and comment on

After final review by FESCo at Feature Freeze the final accepted Feature list (Release Road Map) will be publicly announced by the Feature Wrangler.

Testable does not mean a small portion of the feature is complete and can be tested while a significant portion of the remaining functionality has not been completed and may not yet be tested. We are attempting to provide some flexibility here without completely losing the understood meaning of feature freeze.

Dropping Features

A feature will be proposed for a vote to be dropped from the Accepted Feature list by FESCo if one of the following occurs:

Partially completed features can still be listed as accepted for the upcoming release if the wiki page describing the feature is tailored to reflect the completed work. Dropped features can be proposed again for inclusion in the next release.

Exception Process

Features not meeting the guidelines above may be brought to a FESCo meeting for review.

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:

Everyone has an idea of what everyone else is working on. This provides the opportunity for feedback and suggestions for improvement.

You get people interested--perhaps even helping out

You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area

You generate excitement around what's being worked on

You avoid surprises at the end

Public accountability to do what we say we are going to do

Easier Release Notes creation for new features--everything needed is on the individual feature pages.

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.