Team members
 |
Who the Core Contributors, Trusted Contributors, etc. are is now listed at https://postmarketos.org/team/. Here is some remaining information that we probably want to move other to the other page eventually. |
Core Contributors
Responsibilities / Permissions
GitLab
Have approval and merge rights for all branches and repositories.
("Force push" is disabled for "master" and stable branches, even for the Core Team.)
Other
- Steering of the project
- Taking part in Core Team Meetings
- Creating Releases and Service Packs
- Making releases of pmOS projects (pmbootstrap, tinydm, ...)
Voting
- An existing core team member needs to vouch for new core team members.
- Voting in new team members requires unanimous votes from existing members.
Trusted Contributors
Responsibilities / Permissions
GitLab
Have approval and merge rights for all branches and repositories, with the following exceptions:
- stable branches of pmaports (v21.06 etc.)
- master branch of pmbootstrap
- homepage
- apkbrowser.git
- cast.postmarketos.org.git
- postmarketos.org.git
- bpo
Voting
- Two people from the Trusted Contributors or Core Team need to endorse the potential new trusted contributor.
- Everybody from the Core Team needs to approve / gets a chance to veto the new contributor (exception: if somebody is on holiday, time limit 1 week).
Application
Apply by creating a new confidential issue at https://gitlab.postmarketos.org/postmarketOS/apply-for-trusted-contributor/-/issues/new
Active Contributors
The community plays a big role in the project. Device maintainers and active community members are able to get Reporter access on repositories relevant to their work. This is managed in a case-by-case basis, and requires having worked in postmarketOS for at least several months.
You can find the complete list in gitlab.
Expectations
Reporter access on GitLab includes a bunch of "project manager" type permissions, like assigning issues, setting (and editing) milestones, creating new labels, etc. This is a case of "just because you can doesn't mean you should". In general, we expect folks to assign issues/MRs, set labels, and approve MRs that affect packages they maintain. It will take some time for us to find a good balance here, so this isn't to say that folks should never use the other permissions, just that it's worth checking if you aren't sure.
This section will be updated to document our common practices as they evolve.