{{admon/tip | Quick Links | If you know the process already, you can jump immediately to [[Features/EmptyTemplate | an empty feature form]] or a [[Features/ExampleFeature | completed feature example]].}}

−

-->

+

−

<!-- page was renamed from JohnPoelstra/FeaturePolicyDraft

+

−

-->

+

−

<!-- Last reviewed by FESCo--November 2007

+

= I want to know... =

−

-->

+

* [[/Definitions | What is a feature? ]]

+

* [[/Definitions | What is an enhancement? ]]

+

* [[/Is_this_a_feature | Is ''<XXX>'' a feature? ]]

+

* [[/Process | What does the feature process ''look'' like? ]]

+

* [[/Process | Is there a diagram for the feature process? ]]

+

= Starting the process =

+

* [[/Ideas | How do I propose a feature idea, even if I can't build it myself? ]]

+

* [[/Proposals | How do I propose a feature I'm going to help build or own? ]]

+

* [[Features/Template | What does the feature form look like? ]]

+

* [[/Acceptance | How does a feature get accepted? ]]

+

* [[/Status | What do I need to do over the course of the release cycle? ]]

+

= During the process =

+

* [[/Status | How do I show the status of a feature I own? ]]

+

* [[/Milestones | What are the feature deadlines? ]]

+

* [[/Dropping | What is the process for dropping a feature? ]]

−

{{ Template:message/note | This page describes the process for officially adding new features to the next major Fedora release. Feature submissions and enhancements are welcome from anyone!

+

= Policy questions =

−

}}

+

* [[/Why | Why does this process matter or why should I care?]]

−

+

* [[/Background | Where did this process come from? ]]

−

{{Anchor|Enhancements}}

+

* [[/Exceptions | Is there a way to get an exception from this policy? ]]

−

= Enhancements =

+

* [[/Governance | Who is responsible for this process? ]]

−

+

−

''Enhancements'' are:

+

−

# Less documented improvements to a Fedora release which do follow the ''feature process'' and do not fit the [[Features/Policy#definition| 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 =

+

−

+

−

{{Anchor|Definition_of_a_Feature}}

+

−

{{Anchor|definition}}

+

−

== 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:

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

+

−

1. Benefit to Fedora

+

−

1. Scope

+

−

1. Test Plan

+

−

1. Dependencies--on other packages or features

+

−

1. Contingency plan

+

−

1. Link to documentation

+

−

1. Important information for release notes

+

−

+

−

{{ Template:message/notice | 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.

+

−

}}

+

−

+

−

{{ Template:message/note | A blank template is available at [[Features/EmptyTemplate| ]] and a completed example is at [[Features/Template| ]]

+

−

}}

+

−

+

−

{{Anchor|feature-accept}}

+

−

=== 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:

+

−

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

+

−

1. supported by the Fedora leadership.

+

−

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

+

−

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

+

−

+

−

==== Process ====

+

−

1. The Feature Owner adds the feature page to CategoryProposedFedoraX

+

−

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

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.

+

−

* The Feature Wrangler will maintain this page.

+

−

* 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

+

−

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

+

−

+

−

+

−

{{Anchor|freeze}}

+

−

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

+

−

+

−

{{ Template:message/notice | ''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''.

+

−

}}

+

−

+

−

+

−

{{Anchor|drop}}

+

−

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

+

−

+

−

== Governance ==

+

−

+

−

A person responsible for managing features, a ''Feature Manager'', is designated by the Fedora board and reports to FESCo as outlined here: https://www.redhat.com/archives/fedora-advisory-board/2007-June/msg00022.html

+

−

+

−

The Feature Manager is commonly known as the ''Feature Wrangler''.

+

−

+

−

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

+

−

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

+

−

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

+

−

1. You avoid surprises at the end

+

−

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

+

−

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.

+

−

+

−

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.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.