operations/docs
operations/docs
3
1
Fork 9
Code Issues 4 Pull requests Activity Actions

Document the history and rationale of the Changes process

Browse source
This commit is contained in:
Ben Cotton 2021-05-11 16:08:02 -04:00
commit 70b31b6b4f
2 changed files with 32 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

1
modules/ROOT/nav.adoc
View file

@ -4,6 +4,7 @@
*** xref:changes_policy.adoc#_change_process_milestones[Change Process Milestones]
** xref:changes_guide.adoc[Change submission guidance]
*** xref:changes_guide.adoc#_section_by_section_guidance[Section-by-section guidance]
** xref:changes_rationale.adoc[Changes process rationale and history]
* xref:elections.adoc[Elections]
** xref:elections.adoc#_upcoming_elections[Upcoming elections]
** xref:elections.adoc#_elections_process[Elections process]

31
modules/ROOT/pages/changes_rationale.adoc Normal file
View file

@ -0,0 +1,31 @@
= Changes process rationale and history
The reason we have a Changes process is to coordinate work across the project.
We want to make sure everyone is aware of what's going on in order to get community feedback and ensure we're working in the same direction.
The Changes process is ultimately about _communication_, not _gatekeeping_.
== History
Prior to Fedora 20, Fedora used a process called the “Features” process.
This involved determining if a change was a “feature” or an “enhancement”.
Enhancements were considered not worth tracking, but features were highly user-visible or marketing-worthy and got extra attention.
This was done in the form of manually specifying completion percentage in the wiki and other fun tasks.
FESCo identified several key problems with this process:
* The definition of a “feature” was ambiguous which led to people submitting features unnecessarily, leading to extra administrative overhead.
* The wiki page had duplicated data input
* The process didn’t account for different types or scopes of features
* Features weren’t visible to the community until after the feature proposals were approved
For Fedora 20, we introduced a new process called the “Changes” process.
In some ways, it looks very similar to the previous Features process, but it had a few key differences.
First, Changes are broken out into “System-Wide” and “Self-Contained” changes.
System-Wide changes involve system-wide defaults, critical path components, or other changes that have a broad impact.
Self-Contained changes have limited scope and impact on the rest of the project.
They may be the changes to leaf packages or changes that occur within the responsibility of a single team.
Notably, Changes aren’t necessarily things that get shipped in the distribution—they may also include changes in how packages are built or other sorts of meta-work.
Both System-Wide and Self-Contained Changes go through the same process.
The main differences are the standard of scrutiny and the required input.
System-Wide Changes must list the impact on other developers, a listing of policy changes required, upgrade impact, a test plan, a contingency plan, and documentation.