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.

For an opinionated view on the Changes process, see Ben Cotton’s Opensource.com article or DevConf.CZ 2019 talk.

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.

Want to help? Learn how to contribute to Fedora Docs ›