Add initial template and expand on the README file on the process

0000-template.md

+## REPLACE-ME: Title
+
+* Date proposed: yyyy-mm-dd
+* RFC ID: https://gitlab.postmarketos.org/postmarketOS/rfcs/-/merge_requests/ID
+  **update this number after RFC merge request has been filed!**
+
+## Summary
+
+REPLACE-ME: Short description, 1-2 sentences, in case the title needs to be
+extended
+
+## Motivation
+
+REPLACE-ME: Explain the rationale that has motivated the creation of this RFC. If applies,
+also provide use-cases.
+
+## Consequences
+
+REPLACE-ME: Think about who and how will this change affect. Both positive and
+negative impacts can be described. It does not need to be wordy, but show which
+are the benefits and disadvantages. For example, requiring every postmarketOS
+user to re-install might need to come coupled to great leap in functionality.
+Think about:
+
+* Users
+* Relationship with other projects, upstreams (Alpine, KDE, GNOME, SXMO), and
+  downstreams (if ever applies)
+* Maintainer habits' changes
+* Projects which might need updates, e.g: does this mostly affect pmbootstrap,
+  mkinitfs, or none?
+
+## Draft implementation plan
+
+REPLACE-ME: Most RFCs require of some implementation. It could be a technical
+implementation, like the coding and packaging work needed to get systemd into
+postmarketOS. But it could also be things like documenting a new process on the
+website, or changing permissions to certain users.
+
+REPLACE-ME: This section aims to make the proposer *think* about how the
+proposal can be implemented. It does not require a complete or detailed
+plan of every task that needs to be executed. An example in the context of the
+gitlab migration:
+
+1. Identify every place in gitlab.com/postmarketOS where gitlab.com is
+  hard-coded
+2. Open MRs to updating URLs to point to gitlab.postmarketos.org
+3. Do the migration!
+4. Merge all the MRs
+
+REPLACE-ME: If the proposer has considered different alternatives, and settled
+for one, a rationale of the reasons will be greatly appreciated. Possibly also
+by your future self, since you will avoid having to answer "why not alternative
+X?" repeteadly.
+
+### The proposer
+
+REPLACE-ME: Explain which is your role in this process. Are you just proposing
+a well-developed  idea, and looking for people interested in executing it? Are
+you able to completely execute it yourself, or maybe instead act as project
+manager?
+
+If deemed appropriate, you might request funding from postmarketOS to execute
+it. postmarketOS can either approve it, reject it, or work with you on a grant
+application for the implementation team
+
+### Blocking issues
+
+Sometimes plans require further work. Either other RFCs, or implementations
+in other parts of the ecosystem, like Alpine.
+
+If deemed appropriate, you might also request funding for this.

README.md

@@ -8,7 +8,7 @@ features and changes in project direction in a focused environment.
 RFCs start as merge requests in:
 https://gitlab.postmarketos.org/postmarketOS/rfc/-/merge_requests
 
-### What does an RFC do?
+## What does an RFC do?
 
 The RFC process is intended to bring focus and structure to discussions of
 important changes and new features. It provides a space for sharing and
@@ -22,18 +22,13 @@ An RFC is only a design document, and not a single line of code needs to be
 written for the discussion to be approved, although prototyping can be a good
 idea.
 
-### When should I file an RFC?
+## When should I file an RFC?
 
 If you have an idea for something and are unsure if it needs an RFC, the best
 way to find out is to just ask (e.g. by opening
 [an issue](https://gitlab.postmarketos.org/postmarketOS/rfc/-/issues/new) and filling out
 the "idea" template.
 
-An RFC is much more likely to succeed if it begins life as a discussion, and
-collaborators are encouraged to start off by talking to other project members
-before submitting an RFC. This can also help gauge early support for the
-feature and work out any obvious issues or design decisions.
-
 RFCs are used for proposing "substantial" changes. The meaning of "substantial"
 is subjective, but a good start would be anything that benefits from design
 discussion. Put a different way, it is recommended to file an RFC if the design
@@ -44,14 +39,79 @@ can benefit from such processes:
 - Moving to a new git forge, or gitlab instance
 - Big pmbootstrap or pmaports refactorings that have the potential to break
   devices
+- Changing the permission structure of the project, to give more people rights
 - Adding systemd
 - Working on an immutable version of postmarketOS
-- Organizational or governance changes, e.g: adding the Trusted Contributor
-  program, or remarkable changes to the RFC process itself
+- Adding the Trusted Contributor program
+- Other remarkable organizational or governance changes, like big changes to
+  the RFC process itself
 
-### Who can file an RFC?
+## Who can file an RFC?
 
 Anyone can file an RFC. Please make sure that you have discussed it with some
-member of the team before doing so.
+people, or opened an issue to discuss before doing so. This will greatly
+increase the changes for it to succeed. This can also help gauge early support
+for the feature and work out any obvious issues or design decisions.
+
+We encourage everybody that has big ideas for changes to postmarketOS to open
+RFCs. Even if you have not figured out all the details on how to fill an RFC,
+it is welcomed. RFCs are specifically designed for feedback to be gathered, and
+we expect changes to happen between proposal and approval. People interested
+can help you get an RFC to the finish line. We will rather have some RFCs
+opened and waiting for being developed, or politely closed due to requiring
+more work, than leave great ideas in the drawer because people not feeling
+entitled to propose changes.
+
+## Proposing an RFC
+
+### Step 0: Check previously proposed RFCs and issues
+
+It might be that the idea has already been proposed in the form of an issue,
+or there is a previous RFC that is being worked on or was closed. Give those
+previous attempts a read. Contribute to them if they are being worked on,
+or take feedback with you if you are doing a new attempt
+
+### Step 1: Prepare the RFC
+
+For this repository, and copy `0000-template.md` to
+`0000-<my-proposal-title>.md` and fill in as many details as you can. Do not
+hesitate to talk with other postmarketOS users and community members about it,
+show it to them and integrate feedback.
+
+### Step 2: File the RFC
+
+Once everything is ready, and you want to announce it and official feedback,
+check the
+[list of MRs](https://gitlab.postmarketos.org/postmarketOS/rfc/-/merge_requests?scope=all&state=all)
+and get the last number in there. Move the `0000-<my-proposal-title>.md` to
+`<last-mr-number-+1>-<my-proposal-title>.md`. Push an open an MR! Ping any
+community members that might be interested or have collaborated with you
+in the ellaboration of the RFC. If the RFC might have some remarkable impact,
+please also queue a comment to add it to the monthly blog posts, by commenting
+on the
+[corresponding issue](https://gitlab.postmarketos.org/postmarketOS/postmarketos.org/-/issues/?label_name%5B%5D=monthly-blog-post).
+
+## Discussing an RFC
+
+Discussion about the RFC should happen on the RFC merge request. Any discussions
+that happen outside it should be summarized or linked to by the authors.
+The RFC will likely undergo numerous revisions in the discussion process, and
+some might take time for it gain traction. Often big changes require some time
+for people to make up their minds and nicely collaborate.
+
+We encourage everybody taking part in the RFC discussion process to work towards
+reaching a conclusion in a constructive manner. When you make a post to the RFC
+thread, focus on the contents and implications of the RFC only. While
+disagreeing, please always keep in mind the examples of
+[positive behavior](https://postmarketos.org/coc/#our-standards) in the Code of
+Conduct, and try to work towards them.
+
+## Finalizing an RFC
+
+The author(s) or the postmarketOS team might come to the conclusion that the RFC
+is in no need of more discussion. If the RFC has no blocking issues, or those
+are deemed to be short-term resolvable, either the authors or any member of the
+postmarketOS team may request a vote to take place.
 
-### Proposing an RFC
+The ???? will vote by approving the MR during a 1-week period. Once a majority
+of the members is reached, the RFC will be passed and merged.