0001: Establish a Change Request process

Summary

Big changes to postmarketOS should not only be posted in an issue in https://gitlab.postmarketos.org/postmarketOS/postmarketOS, but actually follow a process that encourages the people proposing it to think about a plan and the consequences of the change.

Motivation

We have bumped into the problem that big changes in postmarketOS sometimes lack structure. Though there have been announcements for most of them, the timeline and consequences have not always been clear, leading to breakage for developers and users. There has also been sometimes problems with transparency and communication of decisions on big changes. This PMCR process aims to solve those issues by providing a structure for people to think about such changes, and share them with others.

Consequences

Establishing this PMCR can have the following advantages:

  • Provide a mental model around which people can think about consequences and planning for big changes, so that they are better planned, and cause less fallout

  • Ensure that big changes are discussed by the community and the members of the team, establishing an atmosphere of transparency and trust where decisions can be traced back in time.

  • Have a single source of truth for past decisions. This can avoid having to rationalize again and again. It will also help not having to fetch those rationales from old blog posts.

  • Allow people outside the postmarketOS team to propose breaking ideas that might improve postmarketOS overall. Those people are currently oftentimes left out of the decision-making process, or don’t have a proper way to express themselves.

  • Ensure that we have a place to point to people that want big changes to be incorporated.

Unfortunately, any process has its disadvantages too:

  • Potentially delay the implementation of big features.

  • Make the process of implementing big features more bureaucratic. One cannot anymore just think about something, do it, and push it. It needs to go through a process, which means it might at some point derail. It requires a non-zero amount of energy. Any ideas to reduce the bureaucratic impact of this PMCR process are welcomed.

  • It might take a while to get into this, and fine-tune rules of things that need an PMCR from things that don’t. It might cause some confusion.

Draft implementation plan

  1. Gather feedback on the documentation written in this repository, and bikeshed wording until people are satisfied.

  2. Approve it. Being the first PMCR, this will require consensus within the Core Contributors. This should be done via gitlab approvals once all discussion threads are resolved. As part of those discussion, a voting process is established and documented in the README of the project.

  3. Inform about the new PMCR process in the blog, amend documentation as needed, and start using it!

The proposer

Myself, a member of the postmarketOS Core Contributors. However, this can be considered a proposal from the whole team, as it was decided in the meeting 2024-11-11.

Blocking issues

None!