Jump to content

Team members: Difference between revisions

From postmarketOS Wiki
Members: add Pablo to TC \o/
Remove TC info, now in apply-for-tc repo
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
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.
{{note|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 Team ==
== Core Contributors ==
=== Responsibilities / Permissions ===
=== Responsibilities / Permissions ===
==== GitLab ====
==== GitLab ====
Line 13: Line 13:
* Creating Releases and Service Packs
* Creating Releases and Service Packs
* Making releases of pmOS projects (pmbootstrap, tinydm, ...)
* Making releases of pmOS projects (pmbootstrap, tinydm, ...)
=== Members ===
* @calebccff (Caleb Connolly)
* @craftyguy (Clayton Craft)
* @dylanvanassche (Dylan Van Assche)
* @MartijnBraam (Martijn Braam)
* @Newbyte (Stefan Hansson)
* @PureTryOut (Bart Ribbers)
* @ollieparanoid (Oliver Smith)
* @z3ntu (Luca Weiss)


=== Voting ===
=== Voting ===
Voting in new team members requires unanimous votes from existing members.
* 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 ==
== 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.)
* homepage
** apkbrowser.git
** cast.postmarketos.org.git
** postmarketos.org.git
* bpo
=== Members ===
* @jenneron
* @minecrell (Minecrell)
* @minlexx (Alexey Min)
* @pabloyoyoista (Pablo Correa Gómez)
== GitLab configuration ==
=== Group mapping ===
{| class="wikitable"
|-
! postmarketOS
! GitLab Group
|-
| Core Team
| Maintainer (or Owner)
|-
| Trusted Contributor
| Developer
|}


=== Settings per repository ===
All this information is now available in https://gitlab.postmarketos.org/postmarketOS/apply-for-trusted-contributor
<pre>
# Settings / General
## Merge Requests
Merge Method:
[x] Fast-forward merge


Merge options:
== Active Contributors ==
[ ] Automatically resolve merge request diff discussions when they become outdated
[x] Enable "Delete source branch" option by default


Squash commits when merging:
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.
[x] Do not allow


Merge checks:
You can find the complete list in [https://gitlab.postmarketos.org/groups/group/active-contributors/-/group_members gitlab].
[ ] Pipelines must succeed
[x] All discussions must be resolved


## Merge request approvals
=== Expectations ===
[ ] Remove all approvals when commits are added to the source branch.


# Settings / Repository
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.
## Protected Branches
master:
Allowed to merge: Developers + Maintainers
Allowed to push: Developers + Maintainers
Allowed to force push: False
Code owner approval: False (we only use it for notification)


(stable branches):
This section will be updated to document our common practices as they evolve.
Allowed to merge: Maintainers
Allowed to push: Maintainers
Allowed to force push: False
Code owner approval: False


## Protected tags
== See also ==
*:
* [[Gitlab project configuration]]
Allowed to create: Maintainers
</pre>


[[Category:Core Team]]
[[Category:Admin]]

Latest revision as of 22:13, 12 March 2025

Note 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

All this information is now available in https://gitlab.postmarketos.org/postmarketOS/apply-for-trusted-contributor

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.

See also