0001-pmcr-process

Let's get started!!

0001-rfc-process.md

+## Establish a Request for Comment process
+
+* Date proposed: 2024-11-21
+* RFC ID: https://gitlab.postmarketos.org/postmarketOS/rfcs/-/merge_requests/1
+
+## 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 RFC 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 RFC 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
+  rationales 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 left out of the
+  decision-making process, or don't have a proper way to express themselves.
+* Ensure that people not part of the team don't suddenly propose big changes in
+  an MR, causing a big amount of backslash from team members. This attitude can
+  drive people away, as has previously in the past. Instead, we can politely
+  point the people to file an RFC.
+
+Unfortunately, any process has its disadvantages too:
+
+* Potentially delay the implementation of big features. Personally, I believe
+  that if there's one thing we have in FOSS is *time*. We have no deadlines, no
+  investors. If things get delayed, they just get delayed.
+* 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 RFC
+  process are welcomed.
+* It might take a while to get into this, and learn how to differentiate things
+  that need an RFC 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, put this in the blog post, ammend documentation as needed, and start
+   using it!
+
+I volunteer for taking the second task. The first one needs general
+contributions.
+
+### The proposer
+
+Myself, a member of the postmarketOS Core Contributors. However, this can be
+considered as a proposal of the whole team, as it was decided in the meeting
+[2024-11-11](https://wiki.postmarketos.org/wiki/Core_Contributors_Meetings).
+
+### Blocking issues
+
+Decide on *who* should have the rights to vote and approve RFCs. This is a
+complicated situation, where everybody in the team has a conflict of interests.
+I would personally think that the natural way to do it would be having the
+Core Contributors be responsible for it. But we need a way (an RFC!) to propose
+rotation within that group. I'm happy to hear everybody's thoughts on this.