From da83c3aff2fb9e48c4becea24ad9a65fe4e1c3e3 Mon Sep 17 00:00:00 2001 From: Loic Dachary Date: Mon, 5 Feb 2018 10:25:08 +0100 Subject: [PATCH 1/5] docs: establish a light weight privilege elevation process https://forum.securedrop.club/t/adding-mickael-as-new-maintainer/375 was the first public discussion about elevating privileges for a SecureDrop contributor. Since we're a small community there probably is no need to estabish a complicated formal process. However, for the sake of transparency we have a three step process that allows everyone to discuss and possibly disagree with the privileges asked by a contributor. The contributor is to initiate the process because it would not make sense to grant privileges to someone who is unlikely to use them. For instance if a contributor has time to propose occasional pull requests but is not motivated by reviewing. --- docs/development/contributor_guidelines.rst | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/docs/development/contributor_guidelines.rst b/docs/development/contributor_guidelines.rst index a0ee5357ed..7a175df07e 100644 --- a/docs/development/contributor_guidelines.rst +++ b/docs/development/contributor_guidelines.rst @@ -122,12 +122,21 @@ Privileges ---------- Dedicated contributors to SecureDrop will be granted extra privileges -such as the right to push new branches or to merge pull -requests. There is no formal process at the moment but the general -idea is that any contributor with the right technical and social -skills is entitled to ask. The people who have the power to grant such -privileges are committed to do so in a transparent way to avoid any -disputes. +such as the right to push new branches or to merge pull requests. Any +contributor with the right technical and social skills is entitled to +ask. The people who have the power to grant such privileges are +committed to do so in a transparent way as follows: + +* Step 1: the contributor posts a message `in the forum + `__ asking for privileges (review or + merge, etc.). +* Step 2: after at least a week someone with permissions to grant such + privilege reviews the thread and either: + * grants the privilege if there are no objections from current + maintainers and adds a message to the thread + * explains what is expected from the contributor before they can + be granted the privilege +* Step 3: the thread is closed Other Tips ---------- From 7b7aa37de72ff2022a7bee4b3d8906c4c8deda2a Mon Sep 17 00:00:00 2001 From: Loic Dachary Date: Mon, 5 Feb 2018 10:26:07 +0100 Subject: [PATCH 2/5] docs: cross linking privilege for i18n and development --- docs/development/contributor_guidelines.rst | 7 +++++++ docs/development/i18n.rst | 7 +++++++ 2 files changed, 14 insertions(+) diff --git a/docs/development/contributor_guidelines.rst b/docs/development/contributor_guidelines.rst index 7a175df07e..f648b12f69 100644 --- a/docs/development/contributor_guidelines.rst +++ b/docs/development/contributor_guidelines.rst @@ -118,9 +118,16 @@ should be removed. If you are unfamiliar with how to squash commits with rebase, check out this `blog post `__. +.. _contributor-permissions: + Privileges ---------- +.. note:: the translation workflow is different from the code and + documentation development workflow, see the associated + :ref:`privilege escalation ` + documentation. + Dedicated contributors to SecureDrop will be granted extra privileges such as the right to push new branches or to merge pull requests. Any contributor with the right technical and social skills is entitled to diff --git a/docs/development/i18n.rst b/docs/development/i18n.rst index e16b6be58e..2aa85ef35b 100644 --- a/docs/development/i18n.rst +++ b/docs/development/i18n.rst @@ -297,9 +297,16 @@ We do not want to publish the translator emails so we strip them: git log --pretty='%aN' $previous_version..lab/i18n -- \ securedrop/translations install_files/ansible-base/roles/tails-config/templates | sort -u +.. _i18n-administrator-permissions: + Translations administrators --------------------------- +.. note:: the translation workflow is different from the code and + documentation development workflow, see the associated + :ref:`privilege escalation ` + documentation. + A translation administrator is a person who is actively performing administrative duties. They have special permissions on the repositories and the translation platform. When someone is willing to From ede36a3384616458ce133c169c45819aa4bfedb9 Mon Sep 17 00:00:00 2001 From: Loic Dachary Date: Mon, 5 Feb 2018 10:26:34 +0100 Subject: [PATCH 3/5] docs: increase the privilege expiration delay to six months There are a number of cases where a contributor with escalated privileges (for i18n or development) can be inactive for a few months. It does not necessarily mean they are no longer motivated or that they lost contact with SecureDrop for so long that they would not be comfortable using their privileges. However, if six months passed without activity we can safely assume it would not bother them to re-apply again. And establishing this revokation period is a non-controversial way to ensure all persons with privileges are currently active. This is also the period currently used by the tor project in a similar case. --- docs/development/contributor_guidelines.rst | 3 +++ docs/development/i18n.rst | 5 ++--- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/development/contributor_guidelines.rst b/docs/development/contributor_guidelines.rst index f648b12f69..b5afbdc184 100644 --- a/docs/development/contributor_guidelines.rst +++ b/docs/development/contributor_guidelines.rst @@ -145,6 +145,9 @@ committed to do so in a transparent way as follows: be granted the privilege * Step 3: the thread is closed +The privileges of a developer who has not been active for six months or +more are revoked. They can apply again at any time. + Other Tips ---------- diff --git a/docs/development/i18n.rst b/docs/development/i18n.rst index 2aa85ef35b..f8ad84174f 100644 --- a/docs/development/i18n.rst +++ b/docs/development/i18n.rst @@ -320,9 +320,8 @@ among the current administrators. All administrators are listed in the `forum introduction page `_ -An administrator who has not be active for two months or more is -removed from the list and their permissions revoked. They can apply -again at anytime. +The privileges of an administrator who has not been active for six months +or more are revoked. They can apply again at any time. The community of SecureDrop translators works very closely with the SecureDrop developers and some of them participate in both From b71b615ae7dde01b69e2e10072d35411fbd4324f Mon Sep 17 00:00:00 2001 From: Conor Schaefer Date: Mon, 5 Feb 2018 20:20:41 +0100 Subject: [PATCH 4/5] Reformats procedure for maintainer status grants Changes are strictly cosmetic: using an ordered list, rather than adding numbers inside an unordered list, and carefully matching capitalizing to make the documentation read more like a paragraph, even though it's broken up a bit. In the process, also resolving a linting error that was blocking merge. --- docs/development/contributor_guidelines.rst | 22 +++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/docs/development/contributor_guidelines.rst b/docs/development/contributor_guidelines.rst index b5afbdc184..2c98ae260b 100644 --- a/docs/development/contributor_guidelines.rst +++ b/docs/development/contributor_guidelines.rst @@ -134,16 +134,18 @@ contributor with the right technical and social skills is entitled to ask. The people who have the power to grant such privileges are committed to do so in a transparent way as follows: -* Step 1: the contributor posts a message `in the forum - `__ asking for privileges (review or - merge, etc.). -* Step 2: after at least a week someone with permissions to grant such - privilege reviews the thread and either: - * grants the privilege if there are no objections from current - maintainers and adds a message to the thread - * explains what is expected from the contributor before they can - be granted the privilege -* Step 3: the thread is closed +#. The contributor posts a message `in the forum + `__ asking for privileges (review or + merge, etc.). +#. After at least a week someone with permissions to grant such + privilege reviews the thread and either: + + * grants the privilege if there are no objections from current + maintainers and adds a message to the thread; or + * explains what is expected from the contributor before they can + be granted the privilege. + +#. The thread is closed. The privileges of a developer who has not been active for six months or more are revoked. They can apply again at any time. From 35a50e5cc9caa2664645d7cf9876843dcdd37156 Mon Sep 17 00:00:00 2001 From: Conor Schaefer Date: Mon, 5 Feb 2018 20:51:13 +0100 Subject: [PATCH 5/5] Clarifies distinction between maintainer workflows We use separate processes for determining "maintainer" status for contributors to the technical codebase (e.g. application logic, tests, configuration/deployment) and contributors to the translations. Fortunately we have clear docs on both already: this change merely amends the language cross-linking the relevant parts of the docs. --- docs/development/contributor_guidelines.rst | 7 +++---- docs/development/i18n.rst | 7 +++---- 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/docs/development/contributor_guidelines.rst b/docs/development/contributor_guidelines.rst index 2c98ae260b..d202256476 100644 --- a/docs/development/contributor_guidelines.rst +++ b/docs/development/contributor_guidelines.rst @@ -123,10 +123,9 @@ check out this Privileges ---------- -.. note:: the translation workflow is different from the code and - documentation development workflow, see the associated - :ref:`privilege escalation ` - documentation. +.. note:: The privilege escalation workflow is different for + :ref:`code maintainers ` and + :ref:`translation maintainers `. Dedicated contributors to SecureDrop will be granted extra privileges such as the right to push new branches or to merge pull requests. Any diff --git a/docs/development/i18n.rst b/docs/development/i18n.rst index f8ad84174f..f0d84bcc9e 100644 --- a/docs/development/i18n.rst +++ b/docs/development/i18n.rst @@ -302,10 +302,9 @@ We do not want to publish the translator emails so we strip them: Translations administrators --------------------------- -.. note:: the translation workflow is different from the code and - documentation development workflow, see the associated - :ref:`privilege escalation ` - documentation. +.. note:: The privilege escalation workflow is different for + :ref:`code maintainers ` and + :ref:`translation maintainers `. A translation administrator is a person who is actively performing administrative duties. They have special permissions on the