Nothing Special   »   [go: up one dir, main page]

Page MenuHomePhabricator

Allow bureaucrats to remove sysop rights on fr.wikipedia
Closed, ResolvedPublic

Description

Please allow bureaucrats the ability to remove sysop rights on fr.wikipedia, per this community discussion : https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Prise_de_d%C3%A9cision/Droit_de_retrait_du_statut_d%27administrateur_par_les_bureaucrates with 82 % approval.

We need something like $wgRemoveGroups['bureaucrat'][] = 'sysop';


Version: unspecified
Severity: enhancement
URL: http://fr.wikipedia.org

Details

Reference
bz35258

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:11 AM
bzimport set Reference to bz35258.
bzimport added a subscriber: Unknown Object (MLST).

Actually,

'+frwiki' => array(
    'bureaucrat' => array(  'bot', 'abusefilter' ),
),

should be changed to :

'+frwiki' => array(
    'bureaucrat' => array(  'bot', 'abusefilter', 'sysop' ),
),

in the wgRemoveGroups section of InitialiseSettings.php

Best regards,

Currently, there isn't any policy as regards the criteria to allow wikis to assign or remove flags reserved to stewards requests. Until a consensus on such criteria (if any) is reached, please keep this request on hold.
https://meta.wikimedia.org/wiki/Talk:Limits_to_configuration_changes#Disconnection_from_stewards_overseeing

Cf. this RfC on how shell requests not following any policy are problematic and dangerous. https://meta.wikimedia.org/wiki/Requests_for_comment/Userrights_on_hi.wiki

(In reply to comment #2)

Currently, there isn't any policy as regards the criteria to allow wikis to
assign or remove flags reserved to stewards requests. Until a consensus on such
criteria (if any) is reached, please keep this request on hold.
https://meta.wikimedia.org/wiki/Talk:Limits_to_configuration_changes#Disconnection_from_stewards_overseeing

Cf. this RfC on how shell requests not following any policy are problematic and
dangerous.
https://meta.wikimedia.org/wiki/Requests_for_comment/Userrights_on_hi.wiki

It is the same request as several other wikis, including en.wikipedia :
https://meta.wikimedia.org/wiki/Bureaucrat#Removing_access
A few users should not be able to block a large community consensus, if you want to forbid this kind of changes you should make a RfC before.

(In reply to comment #3)

It is the same request as several other wikis, including en.wikipedia :
https://meta.wikimedia.org/wiki/Bureaucrat#Removing_access

Yes, they shouldn't have been done, as several mistakes and problems have shown (some listed on that page as well).

A few users should not be able to block a large community consensus, if you
want to forbid this kind of changes you should make a RfC before.

The "large consensus" is the default option which applies to hundreds of wikis, not what a tiny minority of wikimedians of some projects think. Also, I know for sure that several supporters of the change didn't like it or feel strongly about it, or didn't know about the context.
I agree that an RfC should be created and one will be opened very soon; it's probably better if people wanting to remove sysops locally open it, explaining why they want to change the status quo and what criteria they'd apply.

(In reply to comment #4)

The "large consensus" is the default option which applies to hundreds of wikis,
not what a tiny minority of wikimedians of some projects think.

That's a strange argument, so any changes to the default configuration is against "the large consensus" ? and any local RfC which change something could be discarded ?

Our RfC show 82% approval for 106 users in total and it lasted more than 3 months for discussing and voting.

(In reply to comment #5)

That's a strange argument, so any changes to the default configuration is
against "the large consensus" ? and any local RfC which change something could
be discarded ?

No, but there must be some criteria about what can be accepted and what can't. It's obvious that not all wikis can be allowed to remove sysops locally, but developers can't be expected to cherry-pick what requests to accept and what to reject, so the global community has to create some guidelines/criteria, if we want to change the long-standing practice.

Our RfC show 82% approval for 106 users in total and it lasted more than 3
months for discussing and voting.

Good, so you'll have a lot of knowledge to share with the global community on the topic. Please do open an RfC on Meta.

(In reply to comment #6)

Please do open an RfC on Meta.

I think our RfC is enough to make the change, like all other configurations changes we have requested. There is no need for a second one, it is up to you to create the RfC you wish.

I agree with Nemo_bis.

An efficient debate pattern should be offered to the whole Wikimedia community, and not kept only on fr.

The RfC isn't needed to validate the fr.wikipedia PdD but to create the Wikimedia-wide guidelines.

EN.WP.ST47 wrote:

Marking later: requires community-wide review. Once there is consensus (on meta or elsewhere) to allow wikis to give out rights currently reserved for stewards, please reopen this with a link to that consensus.

esprit.fugace wrote:

I disagree : Dereckson is here trying to block a decision he couldn't oppose on fr.wp. I find it deeply unfair that a purely technical right on fr.wp, that was given with no difficulty on en.wp, should need a consensus on meta ! It would furthermore disadvantage the french users, not all of which are fluent enough in english to participate.

Since such changes have always been easily granted before, I think the charge of proving the community oppose it should be on Nemo_bis and Dereckson. If there is a discussion on meta that propose a clear policy for all wikis, and disallow this bug, so be it : but here, what you propose (putting this bug request on hold) is a reversal of usage, that's usually what needs a consensus to be approved.

Further on meta : http://meta.wikimedia.org/w/index.php?title=Talk:Limits_to_configuration_changes&diff=prev&oldid=3573777

Er... there is a misunderstanding, nobody is trying to block anything. Personally, I respect the decision on fr. and of course a 82% decision should be applied!

I'm only saying it's a good idea we put our experience of this debate and this situation to the benefits to other wikis to help implement a projects-wide policy.

koneko wrote:

this is a bit irritating. The current situation looks like this to me :

frwiki's community (support side)
-as the 3rd biggest Wikipedia, frwiki possesses thousands of active editors + a number of sysops and bureaucrats that ensures that no lone dictator may emerge [1]
-the same request was previously accepted for the similar enwiki (bug 18390) mid-2011. No adverse effects have been reported about it.
-the maturation process had an adequate duration (a month, not counting the various discussion on the village pump forehand), was followed by a community vote of adequate duration (3 weeks), and finally rated by a very comfortable majority (82%) of an adequate number of voters (over a hundred)

Nemo_bis (oppose side)
-claims it's against consensus (silent majority, the things people tries to make you say...)
-require consensus from meta (...)
-main example of potential abuse : hiwiki

  • hiwiki might have over 100k articles, but most have been created by bots. Its community consist of barely a few dozen editors [2]. This wiki's situation cannot and must NOT be compared to wikis like frwiki or enwiki.

-while attempting to block everything, refuse to open the RfC process and instead require its opponents do the work.


now then :
-Nemo_bis, I am painfully aware you're doing this in good faith
-I too agree that, following hiwiki's incident, guidelines will have to be discussed to avoid similar issues
-But this is no reason to block a no-brainer request like the current one

if you want that RfC to happen, take the matter into your own hand and open it yourself.

[1] http://stats.wikimedia.org/EN/SummaryFR.htm
[2] http://stats.wikimedia.org/EN/SummaryHI.htm

While in principle I too would like the desysop (and decrat) rights to stay with the Stewards, who are very active and generally manage to cover almost all times of the day and are by definition not-connected to the local community, I see no basis in policy or practice to say that it's not within frwiki's right to ask for this.

Should Wikimedia-wide guideline be developed on the matter at some point, as it's certainly auspicable, then this matter and all related ones at other wikis should be revisited.

Until then however, I see no reason for this request to be declined. Frwiki's not Hiwiki, let's be serious :)

I would ask that the bug be re-opened and the request fullfilled, as there is no basis in policy or practice not to do so.

Reopening the bug, as I don't see how it a right currently available to 'crats on dozens of projects can be described as "currently reserved for
stewards".

Despite having voted against it, I don't see any objective reason for the request to be declined. If frwiki wants to be totally self-reliant, so be it.

EN.WP.ST47 wrote:

Greetings:

Please remember that this is a shell action request and nothing else. The only discussion that belongs here is whether or not the community authorizes this request and how it is to be implemented. I'm looking at a list of shell users and none of them have commented here yet, so until they decide either to fulfill this request or require movement-wide consensus, and because requests of this nature have in the past been fulfilled and there is no movement-wide consensus saying that they should /not/ be fulfilled, I'm going to set the tag back to shell. If you want to have a discussion on the merits, please go to http://meta.wikimedia.org/wiki/Talk:Limits_to_configuration_changes#Disconnection_from_stewards_overseeing , as any discussion here is related solely to this particular request and it would be nice to have the discussion before a wider audience.

(In reply to comment #15)

Despite having voted against it, I don't see any objective reason for the
request to be declined. If frwiki wants to be totally self-reliant, so be it.

^ seems fair to me.

Done