Page MenuHomePhabricator

Allow bureaucrats to remove sysop permissions on Commons
Closed, ResolvedPublic

Event Timeline

Change 623119 had a related patch set uploaded (by Mdaniels5757; owner: Mdaniels5757):
[operations/mediawiki-config@master] Allow bureaucrats to remove sysop permissions on Commons

https://gerrit.wikimedia.org/r/623119

I'm not sure if 76 % can be considered clear consensus, especially since Commons policy requires 75 % for a RFA to pass.

To be fair, 76% is more consensus than 75%.

For ruwiki, the change was implemented with a !vote of 20 to 5 (80.0%). Here, the !vote was 20 to 6 (76.9%). I think that that 1-!vote difference is not material (disclosure: I was with the majority here).

Per @Urbanecm. If a commons bureaucrat could sign-off they're okay with the closure and with having the requested ability it'd be good. Thanks.

Per @Urbanecm. If a commons bureaucrat could sign-off they're okay with the closure and with having the requested ability it'd be good. Thanks.

That's not required. There's no policy on Commons nor global one that requires sign off of bureaucrats for consensus to be achieved. A clear project discussion should not be subjected to re-discussion here.

Despite from what @Ammarpad said, Probably all crats are aware of this proposal, I had posted a note on BN when I opened the proposal and it was there for all the time.

In fact, @CptViraj had explicitly called for a non-bureaucrat to close the discussion, to avoid the appearance of impropriety of deciding something that would give them more permissions.

To be fair, 76% is more consensus than 75%.

With all respect to you, one percent is nothing in this size of a voting. If it was only 20:7, it would be significantly below 75 %. Is it fair to leave the voting outcome on a _single vote_? I don't think so.

Per @Urbanecm. If a commons bureaucrat could sign-off they're okay with the closure and with having the requested ability it'd be good. Thanks.

That's not required. There's no policy on Commons nor global one that requires sign off of bureaucrats for consensus to be achieved. A clear project discussion should not be subjected to re-discussion here.

Well, I don't think it's being re-discussed - I consider this discussion to be about evaluation of the discussion/consensus rather than continuation of the discussion. I do think a discussion about evaluation of discussion/consensus should take a place here; usually, consensus is determined by whoever implements the change (cf. consensus determination in a DR/RFA). In this case, I raised a concern about validity of consensus, and Marco seconded it.

Well, I don't think it's being re-discussed -

If it's not being "re-discussed", then what's name of the discussion going on here?

I consider this discussion to be about evaluation of the discussion/consensus rather than continuation of the discussion.

Phabricator is not the right place to "evaluate" consensus that has already been evaluated by the community. If you disagree with the close, you should take it to Commons and challenge it, per the normal procedures of challenging discussion close.

I do think a discussion about evaluation of discussion/consensus should take a place here

This does not make sense, if combined with your first sentence. You said it's not "being being re-discussed" and you here you said a "discussion/evaluation of discussion should take a place here".

Phabricator is not the right place to "evaluate" consensus that has already been evaluated by the community.

This is done all the time; proper community consensus is required to handle all site requests on Phabricator. See https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes and https://meta.wikimedia.org/wiki/Limits_to_configuration_changes. (As a disclosure, I did oppose this proposal.)

I don't know that what was done in 2011 anywhere on any wiki should have any bearing nine years later.

For the size of the Commons userbase, a relatively low number of editors (26) have taken part in the discussion. The number of supports is below what is expected for CU/OS candidates.

For the size of the Commons userbase, a relatively low number of editors (26) have taken part in the discussion.

Well, the discussion was open for almost 3 months.

There's a consensus to do take this action, it would not be appropriate to re-visit the discussion here. That opportunity was had and it was open for three months...

I did not personally participate in the discussion, so I don't have a stake in it aside from being a member of both the commons admin and steward groups.

The way I see it, the only place we could question the legitimacy of a discussion is there was apparent socking or insufficient notification/discussion time (e.g. it took place on some obscure page with a small timeframe). Neither of which appear to be the case here, so we should proceed accordingly.

To clarify, I am also not taking any side here nor have any stake aside from being a steward who also happens to be active in this corner of Phabricator. The ultimate authority whether to deploy a config change resides in the system administrators, and I am not one of them. However I agree with @Rschen7754 that (and it seems logical; and have always understood that way) that if they have doubts as to whether a config change is to be deployed or not, they're entitled to ask for further details and eventually reject any proposed change. Like I said, I have no stake here and no power to decide.

As a point of order, if this request came from a wiki that only had 10 admins and 2 bureaucrats, I don't think it would be taken seriously even if there was consensus. Especially after https://meta.wikimedia.org/wiki/Requests_for_comment/Userrights_on_Hindi_Wikipedia.

Local community consensus is a prerequisite but the ultimate decision is made by the sysadmins.

I still believe that there is consensus to proceed, 76% isn't low. Surely number of participating editors was low but as I said earlier the discussion was open for 3 months, we can't force people to join the discussion. And I really don't see why this right shouldn't be granted to our local crats, Commons is a large project, we have multiple active bureaucrats. If one misuses it then they'll be decrated, if one's account gets comprised then we have stewards/WMF available all the time to take emergency actions.

I still believe that there is consensus to proceed, 76% isn't low. Surely number of participating editors was low but as I said earlier the discussion was open for 3 months, we can't force people to join the discussion. And I really don't see why this right shouldn't be granted to our local crats, Commons is a large project, we have multiple active bureaucrats. If one misuses it then they'll be decrated, if one's account gets comprised then we have stewards/WMF available all the time to take emergency actions.

Well, it didn't change my opinion (that it is a really weak consensus, one that would be be broken by ONE VOTE) through. Anyway, now that I got involved, I'm not going to decide about this task - positively or negatively.

My main concern was that 76 % is barely enough for a RFA to pass, while this is much more longer time (and impactful) policy.

Why should 75% be used as the threshold anyways? RfAs explicitly require a supermajority consensus because the presence of a significant minority means that the candidate is not sufficiently trusted. For community policy decisions, we've always used the standard of "some vague amount greater than 50% depending on the rate of participation and strength of the arguments". In practice, the threshold is often closer to 60-65% for a discussion of this size, or 55-60% for a discussion with hundreds of !voters (assuming that the strength of the arguments on both sides are average).

Also see the last succesful RFC on Commons closed by a crat with a 71% consensus: https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Partial_blocks
As a Commons admin, I think any percentage greater than 2/3 means the proposal is most probably accepted. The German Wikipedia uses the same 2/3 threshold for its RFAs, as far as I know.

Why should 75% be used as the threshold anyways? RfAs explicitly require a supermajority consensus because the presence of a significant minority means that the candidate is not sufficiently trusted. For community policy decisions, we've always used the standard of "some vague amount greater than 50% depending on the rate of participation and strength of the arguments". In practice, the threshold is often closer to 60-65% for a discussion of this size, or 55-60% for a discussion with hundreds of !voters (assuming that the strength of the arguments on both sides are average).

Well I used that only because I thought "well this is about admins, and 3/4 is used in RFA matters", and I didn't find a policy on RFC consensus conditions at Commons :-). If there is any, I can surely revisit my position

FWIW, my personal opinion is we should more evaluate whether the decision has legitimacy in context of the community that made the decision, rather than be a slave to a specific percentage (After all, consensus is not a vote ;). Have any of the oppose people in that discussion or any other prominent contributors to commons expressed a view that the closure was illegitimate? If not, I think we should do this, if they did, then we should re-evaluate the situation. As far as I can tell, this close was not controversial at commons, so I think we should follow it.

I was asked to give my opinion as a sysadmin. My general note is that if the wiki has active 'crat and if they deemed this as doable, I would have implement it regardless that it's borderline or not (but it's not too crazy, I would have been against it if it was 60% or something). My only problem with this is that it was closed by an admin and not a 'crat. Is any of the commonswiki's 'crat can approve the closure? Also since I'm 'crat in my homewiki, If I were a 'crat in commonswiki, I would have extended it for two weeks but with a sorta big announcement asking for more contributions, people can do this to move it out of a deadlock.

I still don't understand this. Why should a crat close the proposal when the proposal is about granting crats an additional permission? I think our crats have the same thinking that's why none of them participated in the discussion. Why confirmation of crats is required? They are chosen by the community and for community, they should accept what community wants. But since sysadmins have the power to make the final decision and they want crats confirmation, I have posted a message on BN.

Disclosure: I did not participate in the vote, but it is know that I'm supportive of the idea for years.

As a Commons crat I second that the discussion was held in an acceptable manner and the result represents community consensus.

Change 623119 merged by jenkins-bot:
[operations/mediawiki-config@master] Allow bureaucrats to remove sysop permissions on Commons

https://gerrit.wikimedia.org/r/623119

Mentioned in SAL (#wikimedia-operations) [2020-10-06T11:15:45Z] <urbanecm@deploy1001> Synchronized wmf-config/InitialiseSettings.php: 5cc7027ba8d0ddee5c9898b80afe850603bf870e: Allow bureaucrats to remove sysop permissions on Commons (T261481) (duration: 00m 58s)

Urbanecm claimed this task.

Per Ladsgroup's comment and Krd's confirmation, I went forward, and deployed the change.