From 70b31b6b4f866a1edf0facddcd1c7f6fbcdc9782 Mon Sep 17 00:00:00 2001 From: Ben Cotton Date: May 11 2021 20:10:19 +0000 Subject: Document the history and rationale of the Changes process --- diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 75d8343..e57942d 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -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] diff --git a/modules/ROOT/pages/changes_rationale.adoc b/modules/ROOT/pages/changes_rationale.adoc new file mode 100644 index 0000000..9106b19 --- /dev/null +++ b/modules/ROOT/pages/changes_rationale.adoc @@ -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.