Team members: Difference between revisions
Add information on device maintainers and community members |
|||
Line 61: | Line 61: | ||
The community plays a big role in the project. Device maintainers and active community members are able to get [https://docs.gitlab.com/ee/user/permissions.html 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. | The community plays a big role in the project. Device maintainers and active community members are able to get [https://docs.gitlab.com/ee/user/permissions.html 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. | ||
=== 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 practises as they evolve. | |||
== See also == | == See also == |
Revision as of 00:36, 2 May 2024
The postmarketOS team consists of Core Team and Trusted Contributors. This page lists related permissions and responsibilities, mostly with a focus on the git repositories.
Core Team
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, ...)
Members
- @calebccff (Caleb Connolly)
- @craftyguy (Clayton Craft)
- @dylanvanassche (Dylan Van Assche)
- @Newbyte (Stefan Hansson)
- @pabloyoyoista (Pablo Correa Gómez)
- @PureTryOut (Bart Ribbers)
- @ollieparanoid (Oliver Smith)
- @z3ntu (Luca Weiss)
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
See also: How to become a Trusted Contributor, Part 2
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
Members
- @jenneron
- @minecrell (Minecrell)
- @minlexx (Alexey Min)
- @travmurav (Nikita Travkin)
- @funderscore (Ferass El Hafidi)
- @arnavion (Arnav Singh)
- @longnoserob (Robert Eckelmann)
- @Grimler (Henrik Grimler)
- @wonderfulShrineMaidenOfParadise (Raymond Hackley)
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).
Active device maintainers and community members
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.
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 practises as they evolve.