User:Tim Starling (WMF)/Gerrit group membership policy changes

The draft policy is now at User:Tim Starling (WMF)/Draft Gerrit privilege policy.

Following is my earlier description of the proposed changes. These changes were not precisely implemented, since I took feedback on the talk page into account when I wrote the draft policy. The draft policy linked above is now the canonical version.

The current situation

There are policy pages for project ownership and +2. These are confusing terms. As defined by those pages, both are types of Gerrit group membership, except that "+2" discusses MediaWiki core and extensions, and "project ownership" discusses all projects, even though we don't normally think of MediaWiki core as having an ownership model.

Gerrit/Project ownership gives a procedure to follow to get any sort of Gerrit group access, specifically:

• Create a task in the Repository-Ownership-Requests project on Phabricator.
• If the group requested is mediawiki, additionally send an email to wikitech-l.
• Wait for the consensus of "existing project owners";
• Any Gerrit administrator may then act on the request.

WMF staff members are added to the LDAP wmf group, which causes them to be members of the Gerrit mediawiki group, having +2 access to MediaWiki core and extensions.

WMF SRE team members are added to the LDAP ops group, which is the sole way to get access to the operations/puppet project. This LDAP group also grants Gerrit administrator access.

The LDAP wmde group also exists, which causes WMDE staff members to be added to the Gerrit wmde group, but that only grants access to WMDE-maintained extensions, so some WMDE developers have also been manually added to the Gerrit mediawiki group.

The full list of LDAP group inclusions is:

ciadmin

integration

ops

Administrators, labs-toollabs, operations-software-certcentral, wmf-deployment, opssoftware, mediawiki

wmde

wmde, extension-AdvancedSearch, extension-MoveToCommonsClient, extension-MoveToCommons

wmf

Analytics, glam, mediawiki, qa, Translatewiki.net, webplatform.org, wikidata-query-blazegraph

The current list of Gerrit administrators is:

• 20after4
• Aaron Schulz
• Brian Wolff
• Catrope
• Chad
• Dduvall
• EBernhardson
• Hashar
• Krinkle
• Lars Wirzenius
• Legoktm
• QChris
• Thcipriani
• Tim Starling

Proposed changes

• Add the LDAP wmde group to the Gerrit mediawiki group, so that WMDE staff members will have full rights on mediawiki/* projects after on-boarding.
• Introduce a concept of expedited requests for employees of a list of trusted/allied organisations. Gerrit admins will be empowered to grant access to certain staff members without filing a task in Phabricator or waiting for consensus. This intended as a generalisation of LDAP group membership, providing a path for other chapters to be given special status in a future version of the policy.
• Deprecate the term "project ownership" to refer to Gerrit groups. Rename Gerrit/Project ownership to Gerrit/Merge privileges or similar. Use a similarly named Phabricator project for requests. Gerrit uses the term "ownership" in some places, but I'm uncomfortable with it since it doesn't reflect the reality of how most projects are maintained. The current list of extension maintainers should be documented somewhere, perhaps just in the infoboxes on the extension pages, but that should be separate from Gerrit group membership, since WMF staff members may be maintainers without having Gerrit group membership.
• Access requests to the mediawiki group require special consideration. These requests should be made in a separate Phabricator project, for example "MediaWiki merge privileges", so that those requests can more easily be found and triaged.
• Merge Gerrit/+2 into Gerrit/Merge privileges. The sections on granting and revocation definitely belong on the same page as the documentation of the procedure used to do granting and revocation. The tutorial on what it means to have +2 access can probably be there too, since agreeing to the social contract should really be a prerequisite for applying for +2, and thus part of the procedure for getting merge privileges. A bit of reformatting will make it look less bulky.
• The current +2 policy says that rights may be revoked if "you've had an employee agreement / contract which has come to an end, and you have no intent to continue contributing." The second half of this sentence has caused problems in the past and should be removed. For security reasons, it is normal practice to revoke all privileges regardless of whether the former employee plans to continue contributing.
• The current policy says that emergency revocation can be directed by WMF. I think this should be changed to say that emergency revocation may be done by any Gerrit admin at their discretion. Such decisions can be reviewed after the fact. It should not be necessary to ask anyone to approve revocation if an account is compromised and starts merging malicious changes.
• The current policy says that revocation may be directed by "anyone authorized by Wikimedia Foundation's Board of Trustees". This is vague. I would change this to state that an employee's Gerrit group membership may be revoked by that employee's manager. According to the WMF employee handbook, disciplinary action enacted by the manager in consultation with HR may include revocation of +2 access, so allowing the manager to revoke +2 access brings +2 policy into line with the handbook.
• Also, the CTO would be allowed to direct granting or revocation of any group from any person. It's implied, and doesn't need to be stated, that the CTO might be acting on a request from further up the hierarchy.

There is the question of what role TechCom should have in the +2 process. In the revocation section of the existing Gerrit/+2, TechCom or the WMF chain of command may authorise revocation. This implies that if TechCom or WMF is opposed to granting elevated permissions, those permissions should not be granted; that implication could be made explicit. The existing policy provides for a minimum period of one week, which is just about long enough to allow TechCom to veto requests. I don't think it is necessary for TechCom to positively approve every request.

On the conditions for granting: Gerrit/Project ownership currently states that a consensus of project owners is required, whereas Gerrit/+2 makes no mention of consensus, implying that a Gerrit admin may personally judge an applicant on the stated criteria. I think the conditions for granting should be either the unanimous consent of trusted participants, or a direction from TechCom or the CTO. A "trusted participant" could be anyone with +2 rights on any project. So if any such trusted person gives a formal objection and refuses to withdraw it, the request would need to be referred to TechCom or WMF to proceed.

One criticism of the current policy is that it doesn't say who the Gerrit admins are or how they are chosen. I think Gerrit admins can continue to add and remove people from the admin list, without requiring consultation. But we could also add that TechCom or WMF may direct a change to the Gerrit admin list. For example, if a Gerrit admin left WMF's employment, WMF presumably would direct that all their privileges be revoked, including Gerrit admin access.

If WMF is delegating the establishment and maintenance of this policy to TechCom, then the policy should state that TechCom is required to approve future changes to the policy. If WMF is merely asking for TechCom's advice on the issue, then the policy should state that the CTO must approve future changes. I think we need a clause of this kind, it's confusing to imply that anyone able to edit mediawiki.org can change the +2 policy.