Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
  • 0003-name-change-plan
2 results
Compare
Pablo Correa Gómez's avatar
0003-name-change-plan
Pablo Correa Gomez authored
7ca2a1db
History
Pablo Correa Gómez's avatar 7ca2a1db
History
Name Last commit Last update
.ci
.gitlab/issue_templates
.gitlab-ci.yml
0000-template.md
0001-pmcr-process.md
0003-name-change-plan.md
README.md
README.md

postmarketOS Change Request (PMCR)

A postmarketOS Change Request (PMCR) is an RFC process for postmarketOS contributors to propose, design and discuss new features and changes in project direction in a focused environment.

PMCRs start as merge requests in: https://gitlab.postmarketos.org/postmarketOS/pmcr/-/merge_requests

What does a PMCR do?

The PMCR process is intended to bring focus and structure to discussions of important changes and new features. It provides a space for sharing and collaborating on ideas and design documents, keeping community discussion organized and focused on the goal of reaching a decision.

Visibility and inclusivity are important values for PMCRs. They are advertised in our monthly blog posts, and are followed by the team.

A PMCR 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 a PMCR?

If you have an idea for something and are unsure if it needs a PMCR, the best way to find out is to just ask (e.g. by opening an issue and filling out the "idea" template.

PMCRs are used for proposing "substantial" changes. The meaning of "substantial" is subjective and evolves based on community norms. However, there are some basic rules that can help understanding what needs a PMCR:

  • Big pmbootstrap or pmaports refactorings that require user action and will otherwise leave devices unbootable for multiple devices (5+) from different families (3+ SoCs).
  • Adding new flavors or ways to distribute postmarketOS. Examples include adding an immutable or a systemd version.
  • Changes in the Governance structure that have an impact on all members with rights in the project. Like adding the Trusted Contributor program, or splitting power across committees.
  • Remarkable changes to the PMCR process itself.
  • Infrastructure changes that require manual actions to be taken from everybody contributing to postmarketOS.

Most changes do not require a PMCR:

  • Adding new ways to install a small group of devices, or devices within the same SoC, even if requiring user action.
  • Changing supported kernels for some devices.
  • Massive rebuild of kernels or device packages in pmaports, due to a change in features or policy. Such as adding new options to kconfigcheck, or changing the location of deviceinfo.
  • Big pmbootstrap refactorings that are transparent to the developers.

Who can file a PMCR?

Anyone can file a PMCR.

We encourage everybody that has big ideas for changes to postmarketOS to open PMCRs. Even if you have not figured out all the details on how to fill a PMCR, it is welcomed. PMCRs are specifically designed for feedback to be gathered, and we expect changes to happen between proposal and approval. People interested can help you get a PMCR to the finish line. We will rather have some PMCRs 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.

It might help you shorten the process if you have shared and discussed your idea with more people. That can also help gauge early support for the feature and work out any obvious issues or design decisions. This is, however, not a requirement.

Proposing a PMCR

Step 0: Check previously proposed PMCRs and issues

It might be that the idea has already been proposed in the form of an issue, or there is a previous PMCR 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 PMCR

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 PMCR

Once everything is ready, and you want to announce it and official feedback, check the list of MRs and get the last number in there. Move the 0000-<my-proposal-title>.md to <last-mr-number-+1>-<my-proposal-title>.md. Create a new merge request! Ping any community members that might be interested or have collaborated with you in the ellaboration of the PMCR. If the PMCR might have some remarkable impact, please also queue a comment to add it to the monthly blog posts, by commenting on the corresponding issue.

Discussing a PMCR

Discussion about the PMCR should happen in the PMCR merge request. Any discussions that happen outside it should be summarized or linked to by the authors. The PMCR 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 PMCR discussion process to work towards reaching a conclusion in a constructive manner. When you make a post to the PMCR thread, focus on the contents and implications of the PMCR only. While disagreeing, please always keep in mind the examples of positive behavior in the Code of Conduct, and try to work towards them.

Finalizing a PMCR

The author(s) or the postmarketOS team might come to the conclusion that the PMCR needs no more discussion. If the PMCR 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.

At this point, and when the PMCR requires implementation, the PMCR must contain a draft implementation plan that can be translated into a high-level planning issue. It is also necessary to have a person responsible for the implementation towards the Core Contributors. This way there is some warranty that PMCRs will be executed.

During Core Contributors' Meetings, the Core Contributors will vote on approving or rejecting the PMCR. There will be one vote per contributor, and a majority of 60% is needed to either approve, or reject the PMCR. Decisions need a quorum of more than half of the members. If there is a tie, it might be indicative that the PMCR requires further discussion, and should be sent back to the author(s) to iterate based on feedback. The results and reasoning will be published on a comment in the Merge Request.