The proposal states "For security reasons, it is normal practice to revoke all privileges regardless of whether the former employee plans to continue contributing."
I think it should be made clear whether this also applies if they had the access before joining the WMF (people have argued in the past that they should keep any access they had before). Also, it should be made clear that people are free to re-apply for any access they lost when leaving the WMF.
+1
Was going to mention this. I think it should say they may be revoked "If the rights were given because you've had an employee agreement / contract which has now come to an end."
Platonides' suggestion is to only revoke rights that were granted as part of hiring, while I think it's ok to revoke all rights when a person leaves, with the option to immediately re-apply to get them back. This may be a bit of a hassle, but should protect us against disgruntled ex-employees. It's not always easy to see who really leaves happily and voluntarily. There certainly are situations in which we would want to revoke rights, and I don't think it would be a good idea to only allow this when e.g. a formal complain is filed.
I don't think it makes sense to revoke more things than were granted. If I was a local CheckUser, and then were granted CheckUser rights accross the whole cluster as part of a staff work, leaving that should not remove more permissions than were given,¹ as the other rights were provided through a different process.
Of course, if there were additional points to be taken into account (eg. I was fired and got escorted out of the building yelling I would take revenge ☺), makes sense to revoke everything (that would be a different epigraph, though).
¹ with the option to keep them.
One problem with having special rules for when people are fired is that enforcing them is potentially defamatory.
I think there are broadly two cases of someone leaving WMF (or WMDE, for that matter, since their staffers are being proposed to have similar rights)
There are probably some grey areas or exceptions, but most cases I'd think would be reasonably clear to the managers of the person involved which applies. In case #1 it seems reasonable that retention of pre-employment rights without "revoke and reapply" should be an option.
FWIW it seems we already do this, and possibly more.
The problem with making this distinction is that we'd leak the circumstances of the person leaving the WMF to the outside. And while I'm all for transparency, I think it should be up to the person leaving to decide how much about that gets communicated, and how.
We should avoid speculations of the kind "hey, person X left the WMF and got their gerrit rights revoked, they must have done something terribly wrong". Better to just revoke them per default, and have people re-apply.
This also avoid people retaining rights they no longer use, because perhaps they are fed up with the wiki world, or just busy with other things. Stale accounts with elevated rights can be a security issue.
I'm not saying that someone who doesn't want rights anymore has to retain them. But let's not chase away people who want to remain volunteers by making them re-apply for access to everything.
I think people should keep by default the access that the person had gained on their own merits if their employment circumstances change. Specially given that it may include functions that were appointed by their community, with the wiki drama it may ensue (not to mention if that temporary removal of rights also affects two more users).
However, you make a very good point that actions taken should not indirectly leak if they left in good standing with the WMF or not.
How about leaving the rights not given due to his job by default, but mentioning that in their exit interview, the employee will be asked if, in addition to that, they are interested in keeping any extra access he may have as he is interested in contributing in the future, or even if they prefer that earlier ones are also revoked.
This way, mentioning in their offboarding that all rights are to be revoked does not leak whether that's being forced on them or simply because they are fed up with wikis and stated in the interview that they prefer to have everything removed (at least temporarily). It also makes things more efficient by leaving the final rights in one step.
Hi, will we allow longterm and trusted users who request new repos to be owners of the repo still?
I'm planning on changing the draft to clarify what is meant by WMF directing an action, as follows:
Bullet #1, sure. Also the part of the proposal not mentioned here allowing Gerrit admins to take emergency action (with later review) sounds fine to me.
Bullets #2 and #3 I find concerning, although I can't clearly articulate why. Is there really a need for a "benevolent dictator" model rather than allowing the more community-based processes to handle things?
Particularly regarding bullet #2, it seems to me the main difference between that and a Gerrit admin using their emergency power is that it doesn't provide for review of the action. Although given past history I'd expect there would be informal review on wikitech-l anyway. ;)
After reading Anomie's comment, I agree that the "benevolent dictator" powers of the CTO should be somewhat checked:
I think the CTO should at least be required to document and justify any granting or revoking access that bypasses the usual process.
I also think that while the CTO should be the one to enact alteration of the policy, and be able to veto such alterations, they should only be able to change the policy after consulting with the community (perhaps via a drafting process run by TechCom, but that need not be prescribed by the policy).
Mostly just for context...the current Gerrit administrators were mostly chosen by Chad (the defacto owner of Gerrit). If you had a reasonable need and were well trusted, he'd make you an admin.
In addition to that it looks like all of the release engineering team were also added.
Do you think the list of admins should be cleaned up or expanded? Is the list as it stands ok in your view?
We should establish a clear process and set of criteria for becoming a Gerrit admin. Cleaning up the process for getting +2 on MediaWiki does not have to be blocked on that, though.
For the record: the ops team (or better, whoever is in the ldap/ops group) is a gerrit administrator.
This makes sense for various reasons, the main being probably we have privileged access to the servers anyways.
I don't see a big issue with opsen automatically being gerrit admins, but I don't see much of a reason for it either. The technical ability of opsen to directly access and manipulate data is not equivalent to them being allowed to, and expected to, make changes to the data (such as granting gerrit access). In my mind, being a gerrit admin is not just a permission, it's a role. And the question is if opsen should and want to fill this role per default.
I think what you're asking for already exists? We have groups for ShoutWiki, BlueSpice, and Brickipedia, which are set as owners of extensions that those groups maintain. When someone new joins the group, an admin just needs to add them to that one group and they have +2 across all of their relevant extensions.
It's definitely good if the list can be non-empty to start with. ShoutWiki and BlueSpice definitely fit into the model I'm imagining, in that there is a company and the group members appear to be employees. For Brickimedia it is a bit more murky, it seems to be the ShoutWiki staff plus some volunteers. I guess the Brickimedia group would be administered by ShoutWiki? The question is whether allied organisations should be allowed to appoint non-employees to the Gerrit groups they manage, without going through the normal process.
I definitely think that "allied organisations should be allowed to appoint non-employees to the Gerrit groups they manage". That's what managing the group means, right?
The question is whether they can also appoint people to be added to the wikimedia-and-all-extensions group. I think that should be the case for organizations who's hiring process and internal review/oversight WMF has sufficient trust in. WMDE is the prime example, BlueSpice/HalloWelt is probably also a good candidate. Don't know about the rest.
This raises the question - how does an org gain (and lose) this "trusted" status? What shall be the process for this?
I'll second this point. The proposed changes state both "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." and "Access requests to the mediawiki group require special consideration."
I don't have any reason to think we can't trust WMDE in this, but we should consider the actual criteria for when a non-WMF group is trusted enough to appoint mediawiki mergers without that extra consideration to be prepared for the next group that might want that trust.
When discussing this during the TechCom meeting, we found that we should not use "included groups" to automatically make members of the wmde group members of the mediawiki group, for one reason: if we did that, it would become impossible to revoke or deny mediawiki rights from a wmde staff member. And while WMDE staff in general is presumably trusted, there have been cases in the past were individual WMDE staff have been denied +2 access to mediawiki.
So instead, membership to the mediawiki group should be granted to WMDE hires upon request per default, without a lengthy review process, with the WMF reserving the right to revoke that membership.
The organisations would be listed in the policy. So modification would be done in the same as any revision to the policy. I believe we are leaning towards CTO approval for this.
The proposal states "The existing policy provides for a minimum period of one week, which is just about long enough to allow TechCom to veto requests."
I'd like to suggest to extend the minimum period to two weeks, to provide for times around holidays or conferences when most people are out.
I would personally keep at one week. Two weeks as a general rule seem too long to me. We can extend the policy to say "except in predefined periods of holidays and conferences that can be found on page X". We can then link to the deployments page on wikitech which states the deployment freezes which coincide with holidays, AllHands et al.
I think one week is fine. In my experience, conferences and holiday periods are when *more* people are engaged. For all of people who's first/main priority isn't the wikis (the majority of our community members), myself included, holidays are the main time I get to spend on wiki related stuff. Conferences are the same, because wikis take up 100% of the time :-)
One of the highest periods of engagement I saw was at the beginning of Wikimania, when I posted five +2 nominations (intentionally timed that way).
I suppose one week is ok as a minimum. The person who evaluates the discussion should however consider waiting for more than a week if there was little feedback.
I don't think re-introducing the veto process ("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.") is a good idea. It used to be there, and only caused unnecessary drama (e.g. [1], [2]). Chad (IMO) correctly changed the policy and was backed up by others on the talk page.
That said, all of our recent nominees have passed through unanimously except one, and in that case after the nominee responded to the objection from an existing +2 member, the objector withdrew it, satisfied with the response.
I don't have a good idea on how to codify it, but I would rather see a softer "veto" process. The nominee should respond to any concerns that are brought up by people, and opposes from +2'ers are given more weight, but it shouldn't be a hard veto in which one person can obstruct the entire process.
I would note that this really only applies to the mediawiki group, if it's a smaller extension that only has one or two maintainers, if those people object, then those should be considered vetos.
The proposal states "I think the conditions for granting should be either the unanimous consent of trusted participants, or a direction from TechCom or WMF."
Perhaps that should be changed to "rough consensus", giving the gerrit admins the power to overrule an objection. There should perhaps be a well defined group of people who have definite veto powers, probably including TechCom and Trust+Safety.
Perhaps the right way to go about this is to state that gerrit admins can decide to grant or not to grant the rights based on the objections raised. This seems like a good balance that employs admins' common sense.
I'd like to know if User:Timo Tijhof (WMF) has anything to say about this, since he was among the dissenters in the two cases Legoktm cited. In the second, feedback was especially mixed, it's hard to see how you could interpret that even as rough consensus. I'm not proposing to reintroduce a veto, I'm saying that if there is no consensus on Phabricator, the case can be referred to TechCom. TechCom only needs a simple majority to pass a resolution.
I'm fine with "judgement of the acting admin" (like on an AFD) or "let TechCom decide (by single majority) if there are objections", or even "judgement of the acting admin, who can ask TechCom if they don't want to make the call". To me, it's important that that support and opposition are documented, the rationale for the decision is documented, and no single person alone can block. At least not just anyone. I'd be fine with giving veto power to some people, like the CTO, or techcom members, or Trust+Safety, or Ops.
