Wikidata:Requests for comment/Bureaucrats' role in removal of permissions
An editor has requested the community to provide input on "Bureaucrats' role in removal of permissions" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
At the moment, Wikidata bureaucrats do not have the technical capability to desysop or decrat when need be. Such actions are done by stewards which presents two problems:
- Logs are split
- Actions may not be done in a timely manner
This currently proves to be successful with other wikis and with the technical abilities available to local bureaucrats, such actions will be local in the logs and such actions will be able to be help accountable to local policies.
Also note this is a nice list of wikis that currently allow bureaucrats to desysop and decrat.
Inhalt
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- I didn't expect this to be an easy close, and I don't expect that this close is going to go over smoothly, but here goes: Bureaucrats will not be able to desysop at this time. Ultimately, major user rights changes require a clear consensus and, in the absence of such a consensus, the status quo is not changed. Even if we discount entirely the comments made by the stewards and others that have not spent any significant amount of time on the project, support for the change is still only around 66%. However, while there has been significant push-back on this project, on Meta, and over IRC against what is seen as meddling by a small number of Stewards, and even more significant push-back at the perceived messages behind some of those comments, I am not about to entirely disregard the opinions of people who, active on this project or not, have the authorization of the broader WMF project community to act on this project, not just because of their community derived authority, but also because of the experience, and hopefully wisdom, that comes from having reached that point. Finally, when looking at the arguments made on either side of the debate, the arguments on the opposing side are generally better laid out and stronger, while many supporters aren't giving rationales at all.
In summary:
- A raw vote count gives the support at a meager 56%. A vote count that discounts the votes of 'drive-by commenters' does't bring it any higher than the mid 60s.
- The strength of argument is stronger for the opposition than for the supporters.
- A clear consensus is needed to enact user right changes. Even if this was left open for another month, I doubt that we'd see a consensus develop, and certainly not one in support.
Therefore I am closing this as no change/unsuccessful. If you want to discuss this further, you know where to find me. Sven Manguard Wha? 03:27, 15 May 2013 (UTC)[reply]
Allowing bureaucrats to remove the sysop permission per local policies.
Yes
[edit]Don't see why not. --Rschen7754 19:30, 9 May 2013 (UTC)[reply]
- There is no problem with this really. John F. Lewis (talk) 19:38, 9 May 2013 (UTC)[reply]
- I don't see any harm in this. --Stryn (talk) 19:38, 9 May 2013 (UTC)[reply]
- Of course. --Ricordisamoa 20:01, 9 May 2013 (UTC)[reply]
- Courcelles (talk) 20:50, 9 May 2013 (UTC)[reply]
- Strong support Wikidata's community is large enough to prevent abuse of bureaucratship. Regards --Iste (D) 20:52, 9 May 2013 (UTC)[reply]
- Support Regards, — Moe Epsilon 21:10, 9 May 2013 (UTC)[reply]
- Convenient. — Bill william comptonTalk 21:23, 9 May 2013 (UTC)[reply]
This is what bureaucrats are supposed to be able to do. The Anonymouse (talk | contribs) 06:41, 10 May 2013 (UTC)Moved to oppose. The Anonymouse (talk | contribs) 05:48, 14 May 2013 (UTC)[reply]
- Support No big deal, Stewards are still free to act when it's urgent! -- Lavallen (block) 16:01, 10 May 2013 (UTC)[reply]
- Support Raymond (talk) 16:39, 10 May 2013 (UTC)[reply]
- Support This makes having the sysop bit in the first place less dangerous, if you will. --FastLizard4 (talk) 19:52, 10 May 2013 (UTC)[reply]
- Support ·Add§hore· Talk To Me! 20:50, 10 May 2013 (UTC)[reply]
- Support why not? AutomaticStrikeout 02:13, 11 May 2013 (UTC)[reply]
- Support It just makes sense. If you can be trusted to add the right responsibly, why couldn't you be trusted to remove it responsibly? —Scott5114↗ [EXACT CHANGE ONLY] 09:36, 11 May 2013 (UTC)[reply]
- Support Of course. --Pyfisch (talk) 10:45, 11 May 2013 (UTC)[reply]
- Support TCN7JM 03:29, 12 May 2013 (UTC)[reply]
- Support Crats are trusted user --DangSunM (talk) 21:15, 13 May 2013 (UTC)[reply]
- LlamaAl (talk) 00:10, 14 May 2013 (UTC)[reply]
No
[edit]- Useless, btw Actions may not be done in a timely manner is not simply false (there are ~14 times more stewards, in a large variety of timezones, than local 'crats), it's also a perspective error. Setting apart emergency requests (usually carried out by stewards) there shouldn't be any rush to remove rights, for instance self-requests are often ragequits which can be solved by a reasonable waiting time. Flags' management is not a race to get highest logcounts, but it's, simply, a task whose aim is to maximize project's efficiency. --Vituzzu (talk) 11:32, 10 May 2013 (UTC)[reply]
- I supported such stuff in the past, however, I think removal of such rights should only happen on meta. -Barras (talk) 11:33, 10 May 2013 (UTC)[reply]
- I have raised a concern about this vote and some of the ones below at Wikidata talk:Requests for comment/Bureaucrats' role in removal of permissions#Steward votes. --Rschen7754 22:57, 10 May 2013 (UTC)[reply]
- This project is way too small with only 4 recently elected crats to give bureaucrats that power. Besides, I don't see the need. We are active... (and per Vituzzu - I mean "Actions may not be done in a timely manner"?? It's not that removal requests are open for days on meta, + it shouldn't be a race of who "wins" in removing rights.) Trijnstel (talk) 14:02, 10 May 2013 (UTC)[reply]
- see #1 to #3, -jkb- (talk) 15:30, 10 May 2013 (UTC)[reply]
- DerHexer (talk) 18:17, 10 May 2013 (UTC)[reply]
- — MarcoAurelio (talk) 18:56, 10 May 2013 (UTC) Per above. Sigh. In less than a year, with this, it is the third time this issue is discussed. The first one in January 2013 when even bureaucrats didn't existed; and recently in this RfC in April 2013 & I do not know if in some Project Chat threads the same issue has been raised too. Why this determination in seeking flags, rights and "powah"? The arguments presented do not convice me: the logs will be much more split if this passes and it is an undeniable fact that requests at Meta have always been managed in a timely manner -primary per Vituzzu-; not to talk about emergency requests which are always answered an actioned on wiki or via IRC. Instead, a trivial possition like bureaucrat is being changed to local godkings.[reply]
- I have been a crat and I did not feel like I had a lot of "powah". My wife is impressed if I make dinner at home, not if I promote a sysop on Wikipedia. -- Lavallen (block) 19:23, 10 May 2013 (UTC)[reply]
- Glad to know you're maried. Welcome to the club. Now, how that is relevant for this discussion? :-) The main point is that this was discussed in the past and rejected twice, and that the "new reasons" given for this change are not accurate and still doesn't convince me as I've said in my comment above (or tried to do). — MarcoAurelio (talk) 19:51, 10 May 2013 (UTC)[reply]
- Really twice? I only see a discussion in January (not that relevant, though). Regards, Vogone talk 21:00, 10 May 2013 (UTC)[reply]
- That's a bit of a red herring, because the entire bureaucrat right was rejected twice over the last several months before we finally got bureaucrats about a month ago. --Rschen7754 20:36, 10 May 2013 (UTC)[reply]
- Really twice? I only see a discussion in January (not that relevant, though). Regards, Vogone talk 21:00, 10 May 2013 (UTC)[reply]
- Glad to know you're maried. Welcome to the club. Now, how that is relevant for this discussion? :-) The main point is that this was discussed in the past and rejected twice, and that the "new reasons" given for this change are not accurate and still doesn't convince me as I've said in my comment above (or tried to do). — MarcoAurelio (talk) 19:51, 10 May 2013 (UTC)[reply]
- I have been a crat and I did not feel like I had a lot of "powah". My wife is impressed if I make dinner at home, not if I promote a sysop on Wikipedia. -- Lavallen (block) 19:23, 10 May 2013 (UTC)[reply]
- Pr. #1 and #3. --Byrial (talk) 20:01, 10 May 2013 (UTC)[reply]
- Fairly strong oppose We've never had anything requiring an urgent desysop, and, in fact, we've never had anything requiring an RfRemoval of admin rights. This strikes me as rather premature. Any concerns about the risks of rogue admins applies to rogue 'crats doubly. Timeliness of actions doesn't matter, since ragequitting sucks, and adding 4 more people to the group of users who can carry out emergency desysops doesn't significantly increase the likelihood that you call one in quickly. As for logs being split... that's solveable simply by assigning all stewards local UserRights access and requesting that they use the interface here instead of the one at meta. — PinkAmpers&(Je vous invite à me parler) 23:53, 10 May 2013 (UTC)[reply]
- Erm, why? Legoktm (talk) 12:01, 12 May 2013 (UTC)[reply]
- Strong oppose These removals should be handled by stewards, as it is done even in projects which are much bigger and longer established than Wikidata. Premature proposal, trying to solve a problem that doesn't exist.--Snow Blizzard 16:05, 13 May 2013 (UTC)[reply]
- Oppose without prejudice. While "in the end" this is where I'd hope things wind up, I think it's a bit too soon. We've had a number of disagreements so far over the expectation of admins / resysopping etc. as indicated in the discussion below, and I don't think we should give the crats the responsibility to rule in these controversial cases when the community doesn't know what it wants yet. --Rschen7754 02:45, 14 May 2013 (UTC)[reply]
- As an addendum, I think these disagreements when handled appropriately are a sign of a healthy community, but it would be easier to not have someone's desysop hanging in the balance for a particular dispute. --Rschen7754 12:38, 14 May 2013 (UTC)[reply]
- I think eventually we can allow desysoping by 'crats, but I and the community (locally and overall) do not seem to think we're ready quite yet. There aren't enough desysopings yet, and we shouldn't force the local bureaucrats to do it. The Anonymouse (talk | contribs) 05:48, 14 May 2013 (UTC)[reply]
- Oppose Politics.--Snaevar (talk) 21:23, 14 May 2013 (UTC)[reply]
Kommentare
[edit]- Suggest Waiting until desysoppings are needed at WD. ...Jakob Megaphone, Telescope 20:38, 9 May 2013 (UTC)[reply]
- We have already had 2-3 (all resignations). --Rschen7754 21:16, 9 May 2013 (UTC)[reply]
- Here's a proposal, but it's a pretty crazy one and I'm not sure how hard it would be technically--we allow admins to desysop themselves but not other admins and crats to decrat themselves but not other crats, which should deal with the issue of resignation....Jakob Megaphone, Telescope 14:20, 10 May 2013 (UTC)[reply]
- Actually, I like this proposal. — ΛΧΣ21 15:38, 10 May 2013 (UTC)[reply]
- I don't because it just supports rage quitting. Regards, Vogone talk 15:42, 10 May 2013 (UTC)[reply]
- If someone desysops or decrats themselves in a rage, that's their problem. They'll just have to do another RFA/RFB, preferably after some time has passed (3 months, maybe more). ...Jakob Megaphone, Telescope 19:32, 10 May 2013 (UTC)[reply]
- Not under current policy. --Rschen7754 20:28, 10 May 2013 (UTC)[reply]
- Storming off in a huff and desyssopping oneself could be counted as a "under-a-cloud removal" (in which case it is within policy to do what I suggested), but obviously discretion would be required in determining "cloudy" self-desyssops from non-cloudy ones....Jakob Megaphone, Telescope 21:33, 10 May 2013 (UTC)[reply]
- Uh, that's not the definition of "under a cloud." "Under a cloud" means that the admin/crat resigned because the community was likely to file a successful request for desysop and the admin/crat would have lost the flag anyway. In other words, the admin/crat resigned because they were trying to avoid having the flag forcibly removed. --Rschen7754 21:44, 10 May 2013 (UTC)[reply]
- Perhaps not. My point was simply that if my idea goes through then there should be some way do deter the drama caused by admins and crats removing their rights and asking for them back every three days.--Jakob Scream about the things I've broken 23:15, 14 May 2013 (UTC)[reply]
- Uh, that's not the definition of "under a cloud." "Under a cloud" means that the admin/crat resigned because the community was likely to file a successful request for desysop and the admin/crat would have lost the flag anyway. In other words, the admin/crat resigned because they were trying to avoid having the flag forcibly removed. --Rschen7754 21:44, 10 May 2013 (UTC)[reply]
- Storming off in a huff and desyssopping oneself could be counted as a "under-a-cloud removal" (in which case it is within policy to do what I suggested), but obviously discretion would be required in determining "cloudy" self-desyssops from non-cloudy ones....Jakob Megaphone, Telescope 21:33, 10 May 2013 (UTC)[reply]
- Not under current policy. --Rschen7754 20:28, 10 May 2013 (UTC)[reply]
- If someone desysops or decrats themselves in a rage, that's their problem. They'll just have to do another RFA/RFB, preferably after some time has passed (3 months, maybe more). ...Jakob Megaphone, Telescope 19:32, 10 May 2013 (UTC)[reply]
- I don't because it just supports rage quitting. Regards, Vogone talk 15:42, 10 May 2013 (UTC)[reply]
- Actually, I like this proposal. — ΛΧΣ21 15:38, 10 May 2013 (UTC)[reply]
- Here's a proposal, but it's a pretty crazy one and I'm not sure how hard it would be technically--we allow admins to desysop themselves but not other admins and crats to decrat themselves but not other crats, which should deal with the issue of resignation....Jakob Megaphone, Telescope 14:20, 10 May 2013 (UTC)[reply]
- We have already had 2-3 (all resignations). --Rschen7754 21:16, 9 May 2013 (UTC)[reply]
- "Actions may not be done in a timely manner" — Just wanted to point out that if you're looking for timely responses, this proposal is not the way to get it. There are more stewards to handle such requests and the delay is likely to be longer if left to a group of bureaucrats. Hey-ho. PeterSymonds (talk) 11:40, 10 May 2013 (UTC)[reply]
- Agree, but we are rarely in a hurry! -- Lavallen (block) 16:04, 10 May 2013 (UTC)[reply]
- Then why do you want bureaucrats handle requests because "actions may not be done in a timely manner" while you are "rarely in a hurry"? Trijnstel (talk) 18:12, 10 May 2013 (UTC)[reply]
- There are other advantages, the split logs is one, but less involvment from the outside is maybe my favorite. 12 hours or 72 is no big deal, there is no hurry. This will not fill our crats with to much work, and since the crats most sensitive tool (the rename of users according to me) is soon removed, the risks are very very small. -- Lavallen (block) 19:05, 10 May 2013 (UTC)[reply]
- In fact logs will be much more split. And regarding the "outside" let me quote:
The idea that every different project is "the outside" is not accurate. This very project, Meta and Commons; their processes and their content is the example on how much interconnection do exist between the projects. — MarcoAurelio (talk) 20:04, 10 May 2013 (UTC)[reply]«I do not think we (the stewards) are the outside really..., but by being a bit separated from the community, we ensure our feelings do not impact our decisions. A sysop is normally a trusted person, who do not need to be desysoped in urgency (or, your election system is likely broken ?). The stewards are only tools for you to use, just as you ask help from developers if needed. It was on purpose, to avoid flames in a community that unsysoping was not a tool given to bureaucrats»
- Yes, the interconnections are endless, even with such projects as Gutenberg, but the local wiki-culture can be very different. Where I come from, it is not costume to have a
{{Oppose}}
/{{Support}}
-vote for anything than Request for Sysop etc. Once when we wanted a change in local settings, they wanted us to vote of how our alphabet should look like. The response to that was a big laughter. And we do not even has the costume of letting crats close any such discussions. They have a set of tools and a set of rules, and it's their thing to interpret them when they are asked to use them. Anybody has the ability to interpret the consensus of a discussion. Another time on meta, I saw a proposal for a global policy, that local sysops never should block/protect when they are involved in the subject. The idea is good for large projects, but since an average project has three sysop, where one is inactive, it is not a practical global policy. Therefor I prefer to let local users interpret local talks. And I believe our crats can handle a rage-quit. -- Lavallen (block) 06:56, 11 May 2013 (UTC)[reply]
- Yes, the interconnections are endless, even with such projects as Gutenberg, but the local wiki-culture can be very different. Where I come from, it is not costume to have a
- In fact logs will be much more split. And regarding the "outside" let me quote:
- There are other advantages, the split logs is one, but less involvment from the outside is maybe my favorite. 12 hours or 72 is no big deal, there is no hurry. This will not fill our crats with to much work, and since the crats most sensitive tool (the rename of users according to me) is soon removed, the risks are very very small. -- Lavallen (block) 19:05, 10 May 2013 (UTC)[reply]
- Then why do you want bureaucrats handle requests because "actions may not be done in a timely manner" while you are "rarely in a hurry"? Trijnstel (talk) 18:12, 10 May 2013 (UTC)[reply]
- Agree, but we are rarely in a hurry! -- Lavallen (block) 16:04, 10 May 2013 (UTC)[reply]
- Not voting, but not without comment. I am certain that I have not seen a more feeble argument presented, with the sole rationale presented above is about features, not benefits. Logs together?!? That is a justifiable reason? No solely a comment, and not one with which other wikis are having demonstrable issues. The time frame? Oh for goodness sake, the stewards themselves see that "rage quit" is a clear reason to actually be slower, rather than quicker. Personally I think that the giving of this right in earlier times has not beneficial for communities and would prefer to see such a right only given where the community has their own ArbCom. — billinghurst sDrewth 23:36, 10 May 2013 (UTC)[reply]
Second problem is just false. First problem doesn't seem to be enough. I still can't understand why this change would be necessary as this need was not shown.—Teles «Talk to me˱M @ C S˲» 01:55, 12 May 2013 (UTC)[reply]
- The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Unlike the proposal above, there's a very clear consensus for this one. Bureaucrats will not be allowed to decrat at this time. Sven Manguard Wha? 02:05, 15 May 2013 (UTC)[reply]
Allowing bureaucrats to remove the bureaucrat permission per local policies.
Yes
[edit]- Though a risk does exist and we are currently small in regards to bureaucrats, this can be a positive thing in the future. At the moment we trust our Crats and abusing this ability regardless of reason will quick result in a revert of the action and the removal of the crat themselves. John F. Lewis (talk) 19:40, 9 May 2013 (UTC)[reply]
- The problem is that if a crat's account is compromised, all admins can be desysopped with a script. If we allow removal of the crat flag too, then we're left at the mercy of the stewards. --Rschen7754 19:48, 9 May 2013 (UTC)[reply]
- I'm neither for nor against the change but I don't see why decrating is more abusive than desysoping all accounts. Stewards will surely take care of it, if abuse happens. As we saw in Riley's case (where no abuse happened), it's even likely that the WMFOffice gets notified if an admin/'crat account gets compromised. Regards, Vogone talk 20:00, 9 May 2013 (UTC)[reply]
- Yes, but there are periods of the day when no stewards are around, and the WMF office will be even slower to respond. --Rschen7754 21:25, 9 May 2013 (UTC)[reply]
- We currently have far more stewards than bureaucrats, to be honest. Regards, Vogone talk 21:34, 9 May 2013 (UTC)[reply]
- Yes, but there are periods of the day when no stewards are around, and the WMF office will be even slower to respond. --Rschen7754 21:25, 9 May 2013 (UTC)[reply]
- I'm neither for nor against the change but I don't see why decrating is more abusive than desysoping all accounts. Stewards will surely take care of it, if abuse happens. As we saw in Riley's case (where no abuse happened), it's even likely that the WMFOffice gets notified if an admin/'crat account gets compromised. Regards, Vogone talk 20:00, 9 May 2013 (UTC)[reply]
- The problem is that if a crat's account is compromised, all admins can be desysopped with a script. If we allow removal of the crat flag too, then we're left at the mercy of the stewards. --Rschen7754 19:48, 9 May 2013 (UTC)[reply]
- Support A user who can be trusted to add the crat flag can also be trusted to remove it. Regards --Iste (D) 20:53, 9 May 2013 (UTC)[reply]
No
[edit]- Too much of a security risk in terms of compromised accounts. We don't have that many of these, so the stewards can handle this. --Rschen7754 19:29, 9 May 2013 (UTC)[reply]
- Decrattings are rare enough that letting the stewards do them is best, IMO. Courcelles (talk) 20:51, 9 May 2013 (UTC)[reply]
- Too rare of an occurrence to lend this permission to a tiny fraction of the community that provides unnecessary risk. Regards, — Moe Epsilon 21:12, 9 May 2013 (UTC)[reply]
- As per everyone above, it should be rare enough that the stewards can do it. The Anonymouse (talk | contribs) 06:44, 10 May 2013 (UTC)[reply]
- --Vituzzu (talk) 11:32, 10 May 2013 (UTC)[reply]
- Better not. That gives like absolute power to very very few people. -Barras (talk) 11:34, 10 May 2013 (UTC)[reply]
- No. Not even the English Wikipedia has that "power" so I don't see why Wikidata should have it either. Trijnstel (talk) 14:02, 10 May 2013 (UTC)[reply]
- But this is not EN-WP. ...Jakob Megaphone, Telescope 14:20, 10 May 2013 (UTC)[reply]
- Exactly! Trijnstel (talk) 14:26, 10 May 2013 (UTC)[reply]
- But this is not EN-WP. ...Jakob Megaphone, Telescope 14:20, 10 May 2013 (UTC)[reply]
- see #1 to #7, -jkb- (talk) 15:31, 10 May 2013 (UTC)[reply]
- Ugh no. — ΛΧΣ21 15:39, 10 May 2013 (UTC)[reply]
- Raymond (talk) 16:39, 10 May 2013 (UTC)[reply]
- DerHexer (talk) 18:17, 10 May 2013 (UTC)[reply]
- — MarcoAurelio (talk) 18:58, 10 May 2013 (UTC) Per my !vote above.[reply]
- Per reasons already mentioned. --FastLizard4 (talk) 19:52, 10 May 2013 (UTC)[reply]
- --Byrial (talk) 20:02, 10 May 2013 (UTC)[reply]
- no valid reasoning presented for this change. — billinghurst sDrewth 23:38, 10 May 2013 (UTC)[reply]
- Too risky. FunPika 17:34, 11 May 2013 (UTC)[reply]
- Nope. Stewards can do this. TCN7JM 03:31, 12 May 2013 (UTC)[reply]
- Idrc. Legoktm (talk) 12:02, 12 May 2013 (UTC)[reply]
- Per Legoktm. (International Development Research Centre?) --Ricordisamoa 01:38, 13 May 2013 (UTC)[reply]
- Stewards can do this. As Vogone says, currently we have more stewards than bureaucrats. LlamaAl (talk) 00:11, 14 May 2013 (UTC)[reply]
- Not necessary at this time. AutomaticStrikeout 00:12, 14 May 2013 (UTC)[reply]
- I cannot find necessity.. Some stewards participate in Wikidata community. Sotiale (talk) 01:57, 14 May 2013 (UTC)[reply]
Kommentare
[edit]- See my above statements in the comments section. ...Jakob Megaphone, Telescope 20:38, 9 May 2013 (UTC)[reply]
- Neutral ·Add§hore· Talk To Me! 20:51, 10 May 2013 (UTC)[reply]
- Support per self decrat. --Pyfisch (talk)
- neutral i'm not sure for now--DangSunM (talk) 21:12, 13 May 2013 (UTC)[reply]