Page MenuHomePhabricator

Amendments to the Gerrit Privilege policy
Open, MediumPublic

Description

Background

On 2019-02-27 TechCom approved T216295: RFC: Update to Gerrit privilege policy , giving birth to the unified and consolidated Gerrit Privilege policy as part of the official Wikimedia development policies. The policy outlines the rights and responsibilities of developers holding the C+2 right and describes the processes for requesting and revoking these rights.

Problem

The current policy, as stated, has some holes that need to be covered, as illustrated by a recent example (T234124). TechCom has identified the following areas needing further clarifications:

  1. Process to follow in case there are no comments from relevant parties to a given request
    • As per the current policy, when there is no consensus, the request should be escalated to TechCom. However, TechCom feels that no comments does not equate to no consensus, and therefore this explicit case should be covered.
  2. Involvement of current extension maintainers
    • The privilege request section of the policy deals with the general case. Alas, most requests are for extension repositories, so this particular case should be addressed.
  3. Process to follow when privilege is being requested for an unmaintained repository
    • The policy addresses existing and new extensions, and assumes they have active maintainers, but that's not always the case: there is a number of repositories without active maintainers. The policy should be amended to clarify the process in this case.
  4. Which developers are deemed as trusted
    • The Requesting Gerrit privileges section mentions trusted developers, but it is not clear from this or any other policy who they are. It should be clarified.

Proposed Amendments

The proposal is to amend the Requesting Gerrit privileges section to address all of the aforementioned drawbacks. The following changes are proposed:

  • Add a new paragraph after Paragraph 3 with the following contents: Upon the task's creation, a Gerrit administrator must ensure all relevant parties are notified, always involving at least some trusted developers. Additionally, for repositories other than mediawiki-core (and specifically all extensions and services deployed in the WMF cluster) the repository's maintainer(s) must also be notified and their explicit consent on the ticket is needed for the request to be granted. Should the request be made for a repository without an active maintainer, the request is to be rejected and the requester instructed to create a new repository based on the one they are asking access to.
  • Paragraph 6: Add at the beginning If there are no comments from relevant parties after the grace period, the request should be rejected.

Furthermore, the Definitions section should be amended to include the definition of trusted developers:

  • Trusted developers: The group of developers that were granted the +2 right at least two years prior to the request and have actively contributed to either the repository in question or to mediawiki-core since.

For clarity, a draft containing the full version of the policy amended per the above proposal can be found here (the amendments can also be seen in wikitext form by looking at this diff).

Event Timeline

mobrovac created this task.
@mobrovac proposed in the task description

Upon the task's creation, a Gerrit administrator must ensure all relevant parties are notified, always involving at least some trusted developers. Additionally, for repositories other than mediawiki-core (and specifically all extensions and services deployed in the WMF cluster) the repository's maintainer(s) must also be notified and their explicit consent on the ticket is needed for the request to be granted. Should the request be made for a repository without an active maintainer, the request is to be rejected and the requester instructed to create a new repository based on the one they are asking access to.

(Emphasis mine.)

Two parts that I think are worth clarifying:

  • Does "some" mean "at least one", "at least two", or something else?
  • Does "the maintainers / their" mean, "all maintainers", "at least two", "a majority of", or something else?

Could you clarify this part?

Should the request be made for a repository without an active maintainer, the request is to be rejected and the requester instructed to create a new repository based on the one they are asking access to.

Why should a new repository be created in this case? I don't really understand the logic behind this.

Why should a new repository be created in this case? I don't really understand the logic behind this.

I suppose the idea is this:
there should a a chain of trust among the maintainers of a repo, which consumers of the repo can rely on. If that chain is broken because the maintainer of the original repo has vanished, a new repo (a fork) should be created, to force consumers to make an explict choice to trust the new maintainer.

I strongly disagree with the idea of forking an extension just because the sole maintainer went away. That's not how open source projects are meant to work. The open source license grants the rights to continue to work on a project. I think the MediaWiki community in general owns MediaWiki extensions and should not need permission from the original author to continue work. The idea of a "chain of trust" is the exact thing I was arguing against when I made the new Gerrit privilege policy, since I don't trust existing maintainers to properly review the bona fide status of proposed new developers.

Trusted developers: The group of developers that were granted the +2 right at least two years prior to the request and have actively contributed to either the repository in question or to mediawiki-core since.

I'd probably rephrase this to exclude developers who don't have +2 anymore.

Additionally, for repositories other than mediawiki-core (and specifically all extensions and services deployed in the WMF cluster)

This says that extensions and services deployed in production must always be forked when the maintainer leaves; I imagine the opposite was meant.

More to the point, I think this is a bad idea, both pragmatically and on a value alignment level, and we should have opt-out instead of opt in (similarly to the Toolforge usurpation policy).

Milimetric added a subscriber: Milimetric.

@tstarling we wanted to assign this to you in today's techcom meeting, but not in absentia, so just pinging you. Are you ok with driving this forward? We only had four people today but we generally agreed with you and Gergo that forking when maintainers leave is a bad idea.

I am not working on this right now.