Skip to content
Snippets Groups Projects
Commit 940c059e authored by Jérôme Charaoui's avatar Jérôme Charaoui :telescope:
Browse files

add tpa-rfc-24-extend-merge-permissions-web (tpo/web/team#37)

parent 24745b24
No related branches found
No related tags found
No related merge requests found
---
title: TPA-RFC-24: Extend merge permissions for web projects
---
[[_TOC_]]
# Background
Currently, when members of other teams such as comms or applications want to
publish a blog post or a new software release, they need someone from the web
team (who have Maintainer permissions in tpo/web projects) to accept (merge)
their Merge Request and also to push the latest CI build to production.
This process puts extra load on the web team, as their intervention is required
on all web changes, even though some changes are quite trivial and should not
require any manual review of MRs. Furthermore, it also puts extra load on the
other teams as they need to follow-up at different moments of the publishing
process to ensure someone from the web team steps in, otherwise the process is
blocked.
# Proposal
I would like to propose to grant the members of projects under
[tpo/web](/tpo/web) with **Developper** permission, the power to accept Merge
requests. This change would also allow them to trigger manual deployments to
production. This way, we will avoid blocking on the web team for small, common
and regular website updates. Of course, the web team will remain available to
review all the other, more substantial or unusual website updates.
To make this change, under each project's `Settings -> Repository -> Protected
branches`, for the `main` branch, the **Allowed to merge** option would change
from `Maintainers` to `Maintainers + Developpers`. **Allowed to push** would
remain set to `Maintainers` (so Developpers would still always need to submit
MRs).
In order to ensure no one is granted permissions they should not have, we
should, at the same time, verify that only core contributors of the Tor Project
are assigned Developper permissions on these projects.
## Scope
Web projects under [tpo/web](/tpo/web):
* [tpo/web/blog](/tpo/web/blog)
* [tpo/web/donate-static](/tpo/web/donate-static)
* [tpo/web/gettor-web](/tpo/web/gettor-web)
* [tpo/web/manual](/tpo/web/manual)
* [tpo/web/newsletter](/tpo/web/newsletter)
* [tpo/web/research](/tpo/web/research)
* [tpo/web/styleguide](/tpo/web/styleguide)
* [tpo/web/support](/tpo/web/support)
* [tpo/web/tpo](/tpo/web/tpo)
## Affected users
Members of the web team and of other teams who publish changes to websites on a
regular basis.
# Alternatives considered
An alternative approach would be to instead grant the **Maintainer** role to
members of other teams on the web projects.
There are some inconveniences to this aproach, however:
* The **Maintainer** role grants several additional [permissions][] that we
should not or might not want to grant to members of other teams, such as the
permission to manage Protected Branches settings
* We will end up in a situation where a number of users with the **Maintainer**
role in these web projects will not be true maintainers, in the sense that
they will not become responsible for the repository/website in any sense. It
will be a little more complicated to figure out who are the true maintainers
of some key web projects.
[permissions]: https://docs.gitlab.com/ee/user/permissions.html
# Approval
The decision should be made by project managers, in concert with web and TPA
teams.
# Deadline
There is no specific timeline for this decision.
# Status
This proposal is currently in the `proposed` state.
# References
* [issue tpo/web/team#37][]: ongoing discussion
[issue tpo/web/team#37]: https://gitlab.torproject.org/tpo/web/team/-/issues/37
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment