Wikidata

Wikidata:Requests for comment/Opting out of Global sysops

< Wikidata:Requests for comment


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

In a recent discussion at the project chat, we were not able to reach a consensus on whether to, or not to opt out of the global sysops. I closed the discussion as no consensus, given that only 70% of the participants stated their support. Therefore, I start this request for comment to gather a wider community participation in this matter.

Regards. — ΛΧΣ21 05:19, 8 March 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.
Okay. More than 15 days have passed, and we have a result. As I stated when I opened the RFC, I have no side here, since I'm fine with either of the results.
Result
  • With 66.6% of the community voting No, Wikidata remains opted in to Global sysops.
  • No more discussions about a possible opt out should be held within the next three months.

I deeply thank all participants of this RFC, and issue a sincere apology to those that considered it as an unnecessary extension to the previous discussion at the project chat, although the results showcased that it was necessary. Regards. — ΛΧΣ21 21:30, 24 March 2013 (UTC)[reply]

Opting out

edit
Should we opt out of the global sysops list of wikis?

Yes

edit
  1.  Support --Sk!d (talk) 15:02, 8 March 2013 (UTC)[reply]
  2.  Support Wiki13 talk 15:05, 8 March 2013 (UTC)[reply]
  3.  Support --Stryn (talk) 15:14, 8 March 2013 (UTC)[reply]
  4.  Support per my initial proposal rationale.--Jasper Deng (talk) 20:16, 8 March 2013 (UTC)[reply]
  5.  Support we're well out of the scope of the global sysop policy with over 10 active admins. --Rschen7754 22:04, 8 March 2013 (UTC)[reply]
  6.  Support --LlamaAl (talk) 00:29, 9 March 2013 (UTC)[reply]
  7.  Support per Rschen7754. Lukas²³ talk in German Contribs 15:29, 9 March 2013 (UTC)[reply]
  8.  Support -- Cheers, Riley Huntley 19:44, 9 March 2013 (UTC)[reply]
  9.  Support we are clearly out of the GS policy and scope. I do agree however that we should make it easy for a GS who is reasonably active over here to obtain local adminship. --Mark91it's my world 15:59, 10 March 2013 (UTC)[reply]
  10.  Support --Iste (D) 13:15, 13 March 2013 (UTC)[reply]
  11.  Support-- Bserin (talk) 15:19, 23 March 2013 (UTC)[reply]
  12.  Support GSes who are no local sysops do not use their permissions anyway (very little exeptions). In my opinion, there is no need for them to have the rights and keeping GSes would make them locally undesysopable, which would be a kind of overriding community consensus in the case that a locally elected admin gets desysopped. The community is strong enough to manage spam at their own and we have many globally experienced GSes and Stewards who have also sysop rights locally. Regards, Vogone talk 21:27, 23 March 2013 (UTC)[reply]
  13.  Support --Mateuszek045 (talk) 13:04, 24 March 2013 (UTC)[reply]

No

edit
  1.  Oppose I don't see why we're stopping them from helping us when they are willing to do so and trusted to do so by the global community. Legoktm (talk) 15:06, 8 March 2013 (UTC)[reply]
  2.  Oppose, largely per Lego's reasoning. --Izno (talk) 15:19, 8 March 2013 (UTC)[reply]
  3.  Oppose (somewhat) but only due to what I consider flawed proposal that smells of possessiveness "because we can". Global sysops basically respond to spam locally (from my light observations), generally by blocking, and would like to see evidence that they are doing more than that and really requiring to be stopped. If we had global sysops in deleting duplicates, etc. or breaching local policy, then it becomes a no brainer. None of that evidence has been presented. Apart from that, my gut says that a proposal should be standalone, not obliquely refer to a previous attempt and make people dig through the parts of the proposal. If you are going to do this, doing it properly seems appropriate.  — billinghurst sDrewth 04:32, 9 March 2013 (UTC)[reply]
    As a comment, if you remove GS, as a steward you are also saying to me that when I CU (at your request/insistence) and find problems, then you are restricting me not to further act.  — billinghurst sDrewth 04:38, 9 March 2013 (UTC)[reply]
  4.  Oppose No need to remove helping hands. Ajraddatz (Talk) 05:16, 9 March 2013 (UTC)[reply]
  5.  Oppose One of the strengths of GS is spam-fighting. We need all the help we can get to fight spam and vandalism. Also, they're really nice people :) This, that and the other (talk) 06:19, 9 March 2013 (UTC)[reply]
  6.  Oppose And I think Wikidata may need a rule about not reproposing [straw] polls on a topic before some months passed from the last... --Nemo 16:15, 13 March 2013 (UTC)[reply]
  7.  Oppose They're good helpers and no need to remove them TBloemink talk 15:02, 16 March 2013 (UTC)[reply]
  8.  Oppose per above. Multichill (talk) 17:54, 16 March 2013 (UTC)[reply]
  9.  Oppose per above. As I said in a previous thread on this issue though, Wikidata has an exceedingly low threshold for adminship, so Global Sysops that find themselves spending a lot of time here should consider running for local adminship as well. Sven Manguard Wha? 19:21, 16 March 2013 (UTC)[reply]
  10.  Weak oppose given I've not seen any problem with GS' actions so far and their help is welcome. That being said, I wouldn't mind if every GS active on Wikidata was granted local adminship first, and we opted out after that.… or maybe I do. I don't know. — Arkanosis ✉ 22:46, 16 March 2013 (UTC)[reply]
  11.  Oppose imho every help should always be welcome. --Vituzzu (talk) 13:19, 17 March 2013 (UTC)[reply]
  12.  Oppose. — mantis [religiosa] — 14:39, 17 March 2013 (UTC)[reply]
  13.  Oppose Liam987 19:42, 17 March 2013 (UTC)[reply]
  14.  Oppose as a global sysop doing cross wiki vandalism moving from one version to another often I'd be happy to keep helping out when problems arise. Wikidata is an important axe in the middle. MoiraMoira (talk) 13:57, 18 March 2013 (UTC)[reply]
  15.  Oppose Wait six months and then discuss it again. —Tom Morris (talk) 15:27, 18 March 2013 (UTC)[reply]
  16.  Oppose They are helpful. -- Daniel Mietchen - WiR/OS (talk) 21:51, 18 March 2013 (UTC)[reply]
  17.  Oppose per above. --David1010 (talk) 10:40, 19 March 2013 (UTC)[reply]
  18.  Oppose They are, indeed very helpful. --Rsrikanth05 (talk) 20:23, 20 March 2013 (UTC)[reply]
  19.  Oppose --Kolega2357 (talk) 20:34, 20 March 2013 (UTC)[reply]
  20.  Oppose, why are we turning down help? Tazerdadog (talk) 15:52, 21 March 2013 (UTC)[reply]
  21.  Oppose -- Per Legoktm. Wutsje 03:11, 22 March 2013 (UTC)[reply]
  22.  Oppose Per Legoktm; in the future, we could opt-out if there would be serious disadvantages. --Ricordisamoa 07:28, 22 March 2013 (UTC)[reply]
  23.  Oppose Per Legoktm and Ricordisamoa above. -- The Anome (talk) 20:45, 22 March 2013 (UTC)[reply]
  24.  Oppose As Lego stated above.--Nickanc (talk) 10:23, 23 March 2013 (UTC)[reply]
  25.  Oppose --LZ6387 (talk) 21:03, 23 March 2013 (UTC) They help and don't harm, so why?[reply]
  26.  Oppose Global sysops only step in if there are no local sysops. Carsrac (talk) 20:13, 24 March 2013 (UTC)[reply]

Discussion

edit
  • Note: Given that I have no personal opinion in the matter (I'm fine with one option or the other), I will recuse myself from voting so that I can be able to close this request for comment if necessary. — ΛΧΣ21 15:06, 8 March 2013 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ ✓ Done by Bene* (talk • contribs • logs). --LlamaAl (talk) 14:27, 16 March 2013 (UTC)[reply]

  • Just to make sure that the main arguments are summarized here. The argument for opting out is that we are big enough and have enough sysops at the moment, whereas global sysops may be unfamiliar with our policies, and if they really intend to work here, they can easily pass RfA. The argument for not opting out is that the amount of administrative work so far grows, we even started to have backlogs on Requests for Deletion, and if there are globally trusted people out there who could help we should not really refuse.--Ymblanter (talk) 15:45, 8 March 2013 (UTC)[reply]
  • I see arguments for both sides. As I am a GS I won't vote due to a COI. But I am a bit sceptical about the fact that local decisions (e. g. removal of adminship) can be overridden by being a GS. Kind regards, Vogone talk 15:26, 9 March 2013 (UTC)[reply]
  • According to the global sysops policy, this wiki is opted-out by default, so wouldn't we need consensus to opt-in rather than consensus to opt-out? Regards --Iste (D) 15:37, 9 March 2013 (UTC)[reply]
  •  Comment As far as I can see the issue, I can comprehend if the community wants to opt out of Global Sysops. That's absolutely fine with me. By monitoring #cvn-wikidata though, I just would like to add that GSs would limit themselves to operate with (cross-wiki) spammers, if necessary. --Frigotoni ...i'm here; 20:54, 13 March 2013 (UTC)[reply]
  •  Comment This is unrealistic and is not at all good. We do not want a bureaucrat and, to be disable by the administrator of the global options administrators here. Where is the logic here? --Kolega2357 (talk) 20:40, 20 March 2013 (UTC)[reply]

Middle ground

edit

I'd just like to start a discussion here about a middle ground to talk abou (see e.g. Hazard's comment). If we choose to disallow GSs from acting here, then there's no middle ground to be had. If we don't disallow action here, what should GSs be allowed to do? Anything and everything? Most things? Only a few things? Ideas? --Izno (talk) 21:34, 16 March 2013 (UTC)[reply]

My understanding is that GSes to countervandalism and cross-wiki countervandalism. A global sysop isn't going to go into an established project and start closing deletion requests or granting user rights; they're going to go in and block spambots and revert vandalism. That doesn't really take much knowledge of local site policy, it just takes a good eye and practice. Sven Manguard Wha? 22:59, 16 March 2013 (UTC)[reply]
They also do housekeeping on abandoned/semi-abandoned projects like speedy deletion. I would be fine with blocks of cross-wiki vandals and creating attack pages but indeed probably not with granting user rights and closing discussions without getting the local flag first.--Ymblanter (talk) 23:10, 16 March 2013 (UTC)[reply]
Global sysops cannot technically edit user rights. --Rschen7754 23:50, 16 March 2013 (UTC)[reply]
Then it is even easier. Should we leave them anti-vandalism and anti-spam blocks, and uncontroversial deletions?--Ymblanter (talk) 07:31, 17 March 2013 (UTC)[reply]
I'd also be fine with allwoing them to do uncontroversial edits to the MediaWiki namespace. Regards --Iste (D) 11:27, 17 March 2013 (UTC)[reply]
Perfectly fine with me. Should we may be make a list of possible tasks and discuss them separately? There could be also smth else we might overlook.--Ymblanter (talk) 11:56, 17 March 2013 (UTC)[reply]
Undent: I started a list. That might be too heavy (un-agile) for this discussion, so people are free to change the format accordingly. --Izno (talk) 14:20, 17 March 2013 (UTC)[reply]

Problems?

edit

As a sysop on a minor project which currently are within the SWMT and GS, I see some problem with this group of users. The problems are related to their very limited knowledge of the local language, and automatic translate-tools isn't (yet) something you can trust. Some SWMT- and GS-actions has been very clumpsy, therefor we have talked about opting out. But since the local admins are active daily nowdays, the problems has been small in recent years. They are still active on "my" project hunting X-wiki-vandals and spammers. They do nothing else than that today, if we don't request their actions of course. Nobody here has told about any local problems relating to them, and I cannot see any language-related problem other than can exist for any local admin on a multi-lang-project like this. They are not authorised to interpret consensus in a RfP, not more than any average user are, so I see no problem. If they use their tools to delete in their own namespace and revert their own mistakes, I see no problems as long as they know what they are doing. -- Lavallen (block) 12:08, 17 March 2013 (UTC)[reply]

Comment about the language issue: I wouldn't say that all global sysops have "very limited knowledge of the local language", or that we always use "automatic translate-tools". For example, I was able to communicate and understand text written in an African language. It's even easier in Indo-European languages, especially Germanic and Romance languages (for me). Since your native language is Swedish, I'll show you a better example. My grammar wasn't perfect, but I started to translate the mainpage in Danish to get a native speaker to do so. If you look at my talk page, a lot of the messages aren't in English (many are in Italian, French, Europanto). Also, global sysops can't technically grant rights, and closing RfPs is clearly out of the GS scope. πr2 (t • c) 14:09, 20 March 2013 (UTC)[reply]

Eventual opt-out?

edit

The fundamental concern that I have here is when this project will opt out of GS. Will it be when we have bureaucrats? CheckUsers? 200 admins? A project of that size is fundamentally out of the scope of the GS program. --Rschen7754 18:40, 17 March 2013 (UTC)[reply]

I believe that the fact that we don't opt out doesn't mean that they are bound to work here. They can just ignore us and appear just when we need them, if we ever do. — ΛΧΣ21 19:51, 17 March 2013 (UTC)[reply]

List

edit
Extended content
* Be bold when editing this list. I may have added too much depth in places, not enough in others, to talk about the edges that we're exploring for limits on what the GSs can do. --Izno (talk) 14:18, 17 March 2013 (UTC)[reply]

Blocking

Obvious bad-faith

  • What makes an editor a bad-faith editor for the purposes of GS? Crosswiki editors spamming? Local editors spamming? Local editors being uncivil but are productive otherwise (can of worms!)? Local editors having trouble making changes and so screw things up (see en:WP:BRD)? The same definition as the rest of the wiki? --Izno (talk) 14:18, 17 March 2013 (UTC)[reply]
IP editors
Non-confirmed users
Confirmed users

Non obvious bad-faith

IP editors
Non-confirmed users
Confirmed users

Obvious good-faith

Unblocking

Obvious bad-faith

Not obvious bad-faith

IP editors
Non-confirmed users
Confirmed users

Obvious good-faith

IP editors
Non-confirmed users
Confirmed users

Deletion

Spam

Attack pages

RfD

  • How does a GS know whether an RfD is controversial? Should we set limits on the type of page by namespace, or by number of editors commenting, or that they must check to see whether a deletion is valid? --Izno (talk) 14:18, 17 March 2013 (UTC)[reply]

Undeletion

Rollback

Miscellaneous

Changing interface pages

Handing out user rights

Non-bureaucratic proposal

edit

Global sysops and stewards are allowed to use their admin tools for

  • blocking accounts and IP addresses in cases of vandalism, spam or long-term abuse
  • performing rollbacks according to Wikidata's rollback guideline and marking edits as patrolled
  • deletions of vandalism or spam
  • non-controversial housekeeping within the MediaWiki namespace

They are not allowed to revert or overrule any actions that are performed by a local administrator. If a global sysop misuses their rights, any local user in good standing may ask them to stop.

In my opinion there is no need to go into further detail here, as global rollbackers/global sysops generally know what they're doing, so I think they're very unlikely to abuse their tools. Any feedback or improvements are welcome. Regards --Iste (D) 20:27, 17 March 2013 (UTC)[reply]

I do not believe they should engage in the deletion of duplicate items, which can be more subtle than one might think. Before deletion, it must be verified that what's going to be deleted is a duplicate.--Jasper Deng (talk) 20:33, 17 March 2013 (UTC)[reply]
I agree with Jasper. Let's strike the "[…] or duplicated items" part, if they are reported on e. g. WD:RFD. But I do not mind if a GS deletes some by himself merged items (e. g. like SPQRobin does). Regards, Vogone talk 22:28, 17 March 2013 (UTC)[reply]
They shouldn't perform routine deletions, since local administrators are always on hand, and surely more skilled for those tasks (except for special cases). --Ricordisamoa 00:15, 18 March 2013 (UTC)[reply]
Their purpose is handling spam and vandalism. I see no reason why that would be taken from them. Do you consider those routine? --Izno (talk) 00:19, 18 March 2013 (UTC)[reply]
Chanced to remove duplicate items per consensus above. Sven Manguard Wha? 03:03, 18 March 2013 (UTC)[reply]
I could support this. --Stryn (talk) 08:40, 18 March 2013 (UTC)[reply]
What about stewards who have just done a CU and need to do some blocks? --Rschen7754 09:09, 18 March 2013 (UTC)[reply]
I am afraid for this case we need a policy to be discussed separately.--Ymblanter (talk) 09:17, 18 March 2013 (UTC)[reply]
This is probably a good place to start talking about it anyway. --Izno (talk) 21:57, 18 March 2013 (UTC)[reply]
I've added long-term abuse to the cases where stewards or GS should be allowed to perform blocks, as I think this is one of the major issues they often deal with and are experienced with. This would also include CU blocks. Regards --Iste (D) 12:38, 19 March 2013 (UTC)[reply]
Should we allow them to perform CUs here, IAW either our local policy or the global policy? --Izno (talk) 13:19, 19 March 2013 (UTC)[reply]
From what I know GS can not CU, only stewards can.--Ymblanter (talk) 14:20, 19 March 2013 (UTC)[reply]
As long as we don't have local checkusers, I don't see any other possibility than allowing stewards to perform CU. Of course global sysops don't have the technical ability to do so. Regards --Iste (D) 17:03, 19 March 2013 (UTC)[reply]
"Any local admin may ask them to stop" -- Shouldn't this be anyone excepting bad-faith editors (who may be asking for it because they don't want to be reverted)? --Izno (talk) 13:19, 19 March 2013 (UTC)[reply]
I don't see any problems if non-admins in good standing are allowed to ask them to stop. I just wrote "any local admin" in my proposal because in some other projects which have policies about global rights usage only admins are allowed to do so. Regards --Iste (D) 17:03, 19 March 2013 (UTC)[reply]
Ah, okay. --Izno (talk) 17:14, 19 March 2013 (UTC)[reply]

Note

edit

Even if we do not achieve consensus in favor of opting out, I believe that if there's no consensus to stay opted in (i.e. the previous consensus no longer holds), then we fallback to the GS policy default, which would opt us out.--Jasper Deng (talk) 22:22, 18 March 2013 (UTC)[reply]

Errm… no. The community is the key and if the community does not want an opt-out there also will not be an opt-out. The stewards would never opt-out a project whose community is against that. This would be against their "never override community consensus" guideline. Regards, Vogone talk 11:27, 19 March 2013 (UTC)[reply]
When previous discussions about this topic took place, there was a clear consensus to stay opted-in although we already didn't meet the default requirements at that time, so I agree that opting-out would need explicit consensus (see also the "Discussion" section where I raised the same concern 10 days ago). Regards --Iste (D) 12:24, 19 March 2013 (UTC)[reply]
But it could go either way here. That previous consensus no longer exists if this discussion ends up as being no consensus, unless the No side receives a heavy majority, in which case it continues to exist.--Jasper Deng (talk) 19:40, 19 March 2013 (UTC)[reply]
From what I'm accustomed to, consensus is needed to make any changes to user rights or groups. I think if there is no consensus to perform a change, then it should be not done. It's the same principle as in the de-adminship policy we are planning to adopt from commons: A majority of users must support de-adminship. Otherwise the respective admin will keep his rights, even if he receives less than 75% of support. Regards --Iste (D) 20:53, 19 March 2013 (UTC)[reply]
I understand what Jasper is saying, but in general on a wiki consensus is required to change the status quo. In this case, since the status quo is to keep global sysops, a "no consensus" result would maintain that. Ajraddatz (Talk) 12:10, 21 March 2013 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Opting_out_of_Global_sysops&oldid=598954651"