From 940c059e35f9756afdce98ee506991e0276caef6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= <jerome@riseup.net>
Date: Tue, 19 Apr 2022 09:45:25 -0400
Subject: [PATCH] add tpa-rfc-24-extend-merge-permissions-web (tpo/web/team#37)

---
 ...tpa-rfc-24-extend-merge-permissions-web.md | 96 +++++++++++++++++++
 1 file changed, 96 insertions(+)
 create mode 100644 policy/tpa-rfc-24-extend-merge-permissions-web.md

diff --git a/policy/tpa-rfc-24-extend-merge-permissions-web.md b/policy/tpa-rfc-24-extend-merge-permissions-web.md
new file mode 100644
index 00000000..38c7d979
--- /dev/null
+++ b/policy/tpa-rfc-24-extend-merge-permissions-web.md
@@ -0,0 +1,96 @@
+---
+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
-- 
GitLab