English French
Changes policy
If you know the process already, you can jump immediately to https://fedoraproject.org/wiki/Changes/EmptyTemplate[an empty Change Proposal form]. For help with understanding the fields, see the xref:changes_guide.adoc[change submission guidance] page. Watch the https://www.youtube.com/watch?v=oERoxg-VYPo[Fedora Changes policy video] for a quick introduction to the process.
xref:_change_categories[Change Categories]
xref:_change_proposal_sections[Change Proposal Sections]
xref:_essential_communication[Essential Communication]
xref:_change_process[Change Process]
xref:_change_process_milestones[Change Process Milestones]
xref:_bugzilla_trackers[Bugzilla Trackers]
The motivation for the Changes process is to raise the visibility of planned changes and make coordination and planning effort easier. It is nearly impossible to follow all changes happening in a big project such as Fedora. By providing a mechanism for sharing changes, it is easier for contributors to know what is coming and to ensure that we can address impacts of changes well before the release date. Change proposals should be shared 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.
Change owners are trusted _and depended upon_ to highlight all relevant changes. Not noting important changes (whether due to oversight, different opinion of importance, or intentionally) breaks the Change process.
The Change 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) has defined two Change categories:
Self-contained changes
System-wide changes
Self-Contained Changes
A self-contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of the distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a Special Interest Group (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. xref:releases::spins/creating.adoc[Creating a new Solution] (e.g. a Spin/Lab) is a Self-Contained Change.