Changes/Policy

From FedoraProject

< Changes(Difference between revisions)
Jump to: navigation, search
(This is really well written. Made only minor English style changes. There are a couple spots that need clarification, who is responsible for certain actions in the process (see '''boldface''' notes))
(I think Alpha change deadline is what's meant here -- unless there is a new milestone for "Change freeze" that means something else?)
Line 44: Line 44:
 
== HOWTOs ==
 
== HOWTOs ==
 
=== For developers ===
 
=== For developers ===
{{hidden|header=How to propose a new change?|content=
+
{{hidden|header=How do I propose a new change?|content=
 
In order to be considered an official change proposal accepted for the next Fedora release, the change proposal must be formally documented on a separate wiki page.
 
In order to be considered an official change proposal accepted for the next Fedora release, the change proposal must be formally documented on a separate wiki page.
 
# Read the policies for self contained changes and complex system wide changes mentioned above.
 
# Read the policies for self contained changes and complex system wide changes mentioned above.
Line 55: Line 55:
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
  
{{hidden|header=How does a change get accepted?|content=
+
{{hidden|header=How is a change accepted?|content=
 
Self contained changes that pass community review (the announcement) are accepted by FESCo without further investigation in a batch, no sooner than one week after the announcement. Complex system wide changes must be accepted by FESCo individually in the weekly meeting. The scope and dependencies are thoroughly reviewed to determine influence on the other parts of Fedora. It's beneficial for the change proposal owner to be available in the FESCo ticket for the change proposal, and in the relevant FESCo meeting (announced in advance). The change proposal owner is notified when the change is accepted for inclusion in the planned release.
 
Self contained changes that pass community review (the announcement) are accepted by FESCo without further investigation in a batch, no sooner than one week after the announcement. Complex system wide changes must be accepted by FESCo individually in the weekly meeting. The scope and dependencies are thoroughly reviewed to determine influence on the other parts of Fedora. It's beneficial for the change proposal owner to be available in the FESCo ticket for the change proposal, and in the relevant FESCo meeting (announced in advance). The change proposal owner is notified when the change is accepted for inclusion in the planned release.
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
Line 65: Line 65:
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
  
{{hidden|header= What are the changes deadlines?|content=
+
{{hidden|header= What are the change deadlines?|content=
 
For specific dates refer to the [[Schedule]].
 
For specific dates refer to the [[Schedule]].
  
Line 71: Line 71:
 
New change proposals may be submitted using the guidelines described elsewhere and accepted by [[FESCo]] until the ''change proposals submission deadline''.
 
New change proposals may be submitted using the guidelines described elsewhere and accepted by [[FESCo]] until the ''change proposals submission deadline''.
  
==== Changes Freeze ====
+
==== Change freeze ====
* New changes must be feature complete or close enough to completion by the [[Schedule|change deadline]] so that a majority of its functionality can be tested during the Alpha and Beta releases.
+
* New changes must be feature complete or close enough to completion by the [[Schedule|Alpha change deadline]] so that a majority of its functionality can be tested during the Alpha and Beta releases.
* If a change proposal page specifies a change will be enabled by default, it must be so at the change deadline.
+
* If a change proposal page specifies a change will be enabled by default, it must be so at the Alpha change deadline.
 
* Changes meeting the preceding bullets are considered ''testable.''
 
* Changes meeting the preceding bullets are considered ''testable.''
 
* Use the MODIFIED status in the tracker bug to show the change made the change deadline and is ''testable''.
 
* Use the MODIFIED status in the tracker bug to show the change made the change deadline and is ''testable''.

Revision as of 13:22, 2 July 2013

Idea.png
Quick Links
If you know the process already, you can jump immediately to an empty Change Proposal form.

Contents

Fedora Release Planning Process

The motivation for the planning process is to raise the visibility of planned changes and make coordination and planning effort easier. Otherwise it is nearly impossible to follow all changes happening in a big project such as Fedora. It must be easy to submit the change proposal as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review.

The list of accepted changes, or change set, is used by different teams across the project. For example, the change set may be used to prepare external facing materials like release notes and release announcements.

The planning process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes.

Change categories

Fedora Engineering and Steering Committee (FESCo) defined two Change categories:

  1. Self contained changes
  2. Complex system wide changes

Self contained changes

A self contained change is a change to isolated package(s), or a general changes with limited scope and impact on the rest of distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a SIG with limited impact outside the SIG's functional area. Self contained changes could be used for early idea state proposals for wider and complex changes.

Public announcement of a new self contained change promotes cooperation on the change, and extends its visibility. Change owners may find help from the community or useful comments. These changes don't have to be thoroughly reviewed by FESCo. Based on the community review, the self contained change can be updated to the complex system wide change category, and the owner may be asked to provide more details and extend the change proposal page.

Complex system wide changes

Complex system wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self contained changes.

HOWTOs

For developers

FAQs

Feel free to ask the Wrangler for help. Currently this position is held by Jaroslav Reznik.