User:Pfrields/Features/Policy

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:

1. Less documented improvements to a Fedora release which do follow the feature process and do not fit the feature definition below.
2. Added to the release summary by anyone under heading of Other Enhancements. The release summary for the current release lives in the following namespace: http://fedoraproject.org/wiki/Releases/41/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:

1. highly user visible changes
2. improvements or changes that require non-trivial cross-package integration
3. exciting new capabilities we can trumpet fedora having--some of this is good public relations. Some examples might include:
   • work Fedora contributors are doing upstream as part of their work for Fedora
   • new features from upstream that we are making available in the Fedora for the first time
   • improvements that are Fedora specific. Example from past releases include the Core and Extras Merge and smolt
4. significant enough that if not completed properly or without a proper backup plan could delay the release
5. noteworthy enough to call out in the release notes

Feature Process

Individual features are tracked on separate wiki pages in the Features/ namespace. Individual features are organized using categories.

Source: File:Features Policy feature-process-flow.odg

---

1. New feature ideas may be added at any time to the wiki
   • Features/FeatureName (CategoryProposedFeature)
2. New feature desired for a particular release are designated as such
   • Features/FeatureName (CategoryProposedFedora42)
3. Proposed feature is presented to FESCo for acceptance
   1. Accepted features move to CategoryAcceptedFedora42
   2. Denied features remain in CategoryProposedFedora42 for rework or future resubmission
   3. After Feature Freeze all features in CategoryProposedFedora42 move to CategoryProposedFeature where they can be proposed for the next Fedora release.
4. Periodic status
5. Important milestones

While allowed by the wiki, a feature should only be assigned to one category.

New Feature Ideas

Community members are encouraged to create new pages for features that enhance or improve Fedora. Anyone can propose new features for Fedora by following these steps:

1. Add a new wiki page to http://fedoraproject.org/wiki/Features/<YourFeatureName>
2. Add details for each of the sections using the template at Template as a guide.
3. Add [[Category:ProposedFeature]] 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:

1. Summary of the feature
2. A designated owner (with a link to contact information http://fedoraproject.org/wiki/<YourName> --including a valid email address). The owner is responsible for:
   1. Making sure the feature is completed according to the schedule
   2. Communicating periodic status
   3. Attending feature status meetings
3. Current status
   1. last updated
   2. Estimated percentage of completion
4. Description of the new feature
5. Detailed explanation of what the new feature will do and how it will be implemented
6. Benefit to Fedora
7. Scope
8. Test Plan
9. Dependencies--on other packages or features
10. Contingency plan
11. Link to documentation
12. 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 Features/EmptyTemplate and a completed example is at Features/Template

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)
2. supported by the Fedora leadership
3. suitable for listing as an Official Feature of the next release of Fedora
4. important to track prior to feature freeze and could affect timeliness of release

Process

1. The Feature Owner adds the feature page to CategoryProposedFedora42
2. The Feature Wrangler reviews page for completeness and raises for review at next FESCo meeting
3. . FESCo reviews individual feature pages and votes to approve or deny the feature.
   1. More than 50% of voting FESCo members must be in agreement to approve or deny.
   2. The feature owner or proxy should be in attendance at this FESCo meeting to answer questions or provide clarification.
4. After a FESCo vote the Feature Wrangler:
5. Adds accepted features to the accepted category (CategoryAcceptedFedora42)
6. Moves the feature to CategoryProposedFeature unless they so violate the practices of Fedora that they should be removed. We would expect an event like this to be highly unusual)

Periodic Status

1. Feature pages should be updated to reflect the current status of the feature by the following milestones on the Release Engineering schedule:
   • Alpha freeze
   • Beta freeze
   • For features not 100% complete--every two weeks after 'beta freeze until final development freeze
2. At final development freeze all feature pages should be at 100% completion, and if necessary, the feature page adjusted to reflect everything completed (so as to reflect 100% completion).
3. Feature Wrangler will send individual reminders and announcements to fedora-devel-announce list as necessary
4. 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
5. Reminders to developers about upcoming feature deadlines will be sent to fedora-devel-announce@redhat.com
6. 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:

• Feature is incomplete or not testable at Feature Freeze
• Feature owner fails to consistently provide status or attend IRC meetings (if held).

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