Talk:Global sysops/2012

Speedy Deletion on Japanese Wikipedia

Hello, global sysops and others. Now Japanese Wikipedia enable {{Delete}} template to make speedy deletion candidates which has global issues like cross-wiki spam or vandalism. When you find such global problems on Japanese Wikipedia, use {{delete|1=reasons}}.

If you know anywhere suites to notify this message, please reproduce/move.

thanks,--aokomoriuta 05:53, 17 January 2012 (UTC)

De-Log from Global account

I want to de-log from global account (I want only the account at my base account, the german wikipedia). I see no advantages of the global account and I want to delete it, if possible.

Can I do this or anybody here for me?

--Ohrnwuzler (talk) 09:46, 21 March 2012 (UTC)

The advantage of global (SUL) account is that your username will be unique to you across all the wikis, so you can edit under the one name, with just the one login. Your account itself will only be created where you wish to use it, ie. you access those wikis while logged in. So if you don't access more broadly, then it will only exist at dewiki. Breaking apart of a SUL account is not recommended. billinghurst sDrewth 09:56, 21 March 2012 (UTC)

We're not allowed to perform global account deletions for reasons such as "I don't want it". We're not going to overturn the hard work of our developers unless the global account creates problems (such as it prevents a rename, etc.). Thanks for your understanding. Regards. —Marco Aurelio (Nihil Prius Fide) 20:22, 21 March 2012 (UTC)

Rename Main Page on Tsétsêhéstâhese Wikipedia

Good day, the Tsétsêhéstâhese Main Page needs to be move to Va'ohtama. See the discussion for that decision. Thank you, Amqui (talk) 18:55, 12 April 2012 (UTC)

P.S. I have been suggested to ask here after trying to find a place for that type of request. There is none according to the Crosswiki requests' pages list. Maybe it would be a good idea to have a clear designated place for general contributors to request global sysop action on a Wiki without any sysop. Especially when we consider Wikis without sysops are generally the ones without experienced contributors as well, we should make it easier for them rather than harder and confusing. Amqui (talk) 19:01, 12 April 2012 (UTC)

Done by Ruslik0 on 12 April. Trijnstel_talk 13:35, 15 April 2012 (UTC)

Wiki cleanup log

I created Global sysops/Wiki cleanup to mark coordinated efforts to review individual wikis. -- とある白い猫 ^chi? 14:43, 13 May 2012 (UTC)

Global sysops lose scope in rollback?

Since this group is not active on all wikis, but Global Rollback is, do global rollbackers lose this ability on wikis opted out of the global sysops if they become global sysops? That seems to be the case - no global sysop at Special:GlobalUsers has global rollback.--Jasper Deng (talk) 22:09, 13 May 2012 (UTC)

No, global rollbackers that also become global sysops retain their GR rights. That special page is merely unable to show multiple global groups of one person. For example, I am both a GR + GS. --MF-W 22:24, 13 May 2012 (UTC)

Strange... on my own CentralAuth instance, multiple groups are shown.--Jasper Deng (talk) 22:48, 13 May 2012 (UTC)

OK, I looked up your name in particular on that page, and it shows GR. However, I had tried this, expecting other user rights too, as with the local Special:ListUsers.--Jasper Deng (talk) 22:50, 13 May 2012 (UTC)

Yeah, you have discovered a long-known issue with Wikimedia's central auth (one of many) that has yet to be fixed :-D Ajraddatz (Talk) 04:31, 22 May 2012 (UTC)

Inactivity policy

I know I have "views" on holding rights when inactive but with this right the policy seems pretty clear. A quick check of some of the earlier holders of these rights show that the rights have been unused for a year or more - what is the system for dealing with this. Given the nature of these rights across so many wikis I think this is one we should keep an eye on. --Herby ^{talk thyme} 16:20, 14 June 2012 (UTC)

As the result of an earlier discussion, if you find an inactive GS you should inform them that their tools will be removed if they don't either become active again or request that they keep the rights. If they do feel that they would still benefit from them, then they can keep those rights indefinitely. If they don't respond after a while or don't want to keep them, then they are removed. Ajraddatz (Talk) 16:24, 14 June 2012 (UTC)

There wasn't consensus about that. @Herbythyme: Effeietsanders wanted to keep the GS rights to watch deleted contributions, though at that time he didn't use it according to the logs since 2009 (and this discussion was in 2011). As a result those rights were removed and I supported that. So no, there wasn't any consensus. Trijnstel_talk 16:32, 14 June 2012 (UTC)

Looks like some sort of consensus to me. Ajraddatz (Talk) 16:37, 14 June 2012 (UTC)

Then that change was wrong since it wasn't any formal "vote" or something like that. And I still disagree with it, so did Jafeluv and apparantly Herbythyme. Trijnstel_talk 16:42, 14 June 2012 (UTC)

I'll never understand why we give people a choice when we have a formal policy about such things... --Herby ^{talk thyme} 16:47, 14 June 2012 (UTC)

Me neither. Then why the policy, right? Plus these are quite important buttons; I mean, sysop rights on all small projects. Trijnstel_talk 16:50, 14 June 2012 (UTC)

I also have to agree with Trijnstel here. We can't keep such a status without being active, and one year is even too long to me. Anyway, the policy clearly states that stewards can remove the status if they judge it's necessary, and this clearly fall under this scope. Regards, -- Quentinv57 ^(talk) 16:54, 14 June 2012 (UTC)

Actually the two with nothing for over a year seem to have had reasons for keeping the rights... --Herby ^{talk thyme} 17:03, 14 June 2012 (UTC)

...Hence why I support a policy which allows these trusted users to judge whether or not they should keep the tools, rather than just removing them if they haven't made a log action in six months. Ajraddatz (Talk) 17:10, 14 June 2012 (UTC)

Changing the policy: removal of global sysops per community vote

Vote of confidence:

Any steward may remove a global sysop's rights at any time if they feel the tools have been misused, or if a request for comment has shown that a significant minority does not trust the global sysop. If this occurs and the global sysop wants the tools back, a vote of confidence shall occur, where the global sysop must retain the consensus of the community in order to return their access.

• What is a significant minority? - I think we all have different views on what is "significant" for us.
• What is the consensus of the community? - Similar to above.

Those subjective, imprecise and unclear terms will give us problems in the future. To avoid this, I propose to change the whole section by adding clear rules not subject to any personal appreciation. Numbers please.

I sincerely have no idea what is a significant minority: 2, 5, 10 users? - I'm really tired to see this kind of unclearness spread all over Meta policies. Those just encourage unfairness, wikilawyering and drama.

Thankfully the only one issue we had was this where the 100% of users opposed the retention of global rights so in that particular case it was quite easy. But it might not be the same in the future. I feel it's better to fix this now than to wait for the problem.

As such I propose that:

• Any global sysop be removed if the user does not achieve a 70% support in the RFC. Before any voting, a period of comments shall occurr.
• The vote of confidence will be removed. If the user wants the tools back the user should run again for Global Sysop with the same requirements as if it were a first candidacy. If you're removed from the position you shouldn't really have any special treatment for that.

-- MarcoAurelio (talk) 09:17, 14 August 2012 (UTC)

Needs clarifying for sure - thanks --Herby ^{talk thyme} 10:28, 14 August 2012 (UTC)

I agree. It's not even clear what a "vote of confidence" should be in this context.--Jasper Deng (talk) 14:37, 14 August 2012 (UTC)

Actually I think this section is not as strange as it appears on a first glance: A steward may "simply" take away the GS rights from a user if they feel the tools have been misused or if there was an RFC where at least a significant minority (ok, that is indeed not defined clearly) did not trust the GS anymore. Then afterwards the user can say "But I do think I still have the trust of the community (even if steward X/users A, B, C, D found me abusive)" and undergo a "vote of confidence", which I think is intented to mean a vote whether the user should get GS tools back or not. Of course, what is missing here is the definition which percentage would be necessary to succceed in the vote (the association of vote of confidence from politics would suggest an absolute majority?!). — So in effect, my perception is that the proposed change still is very much like the current policy, just that the undefined "vote of confidence" is replaced by a mandatory voting that requires 70% in favour of the user (I guess some like to call it !vote) at the conclusion of an RFC; which is good. However, I'd propose to keep the possibility for "any steward" to remove GS rights if they were misused: If some GS is suddenly going rogue, it can't harm to have allowed in the policy what is inevitable anyway. Of course, such a removal would almost automatically entail an RFC. --MF-W 16:30, 14 August 2012 (UTC)

Hello MF-W: I didn't planned to remove the ability from stewards to remove GS rights as defined in the current policy. Just ammending the part of the policy that comes after that :) Regards, -- MarcoAurelio (talk) 17:27, 14 August 2012 (UTC)

Ah, OK. Maybe you could put up the exact wording change you propose? :-) --MF-W 18:35, 14 August 2012 (UTC)

I need a bit of help, because many texts passes in my head but I can't find one of my liking to propose; except what I proposed to change. Regards. -- MarcoAurelio (talk) 15:38, 16 August 2012 (UTC)

I guess the following comes close to your proposal:

The current "Vote of confidence" section will be removed, instead the following new text is added: "Any steward may remove a global sysop's rights at any time if they feel the tools have been misused. A global sysop also loses the rights if the user does not achieve a 70% support ratio in an RFC about their status as a global sysop. Before any voting, a period of comments (of at least 2 weeks, ...) shall occurr." --MF-W 19:00, 19 August 2012 (UTC)

Inactivity

Maybe it's a good idea to rewrite the inactivity section (including numbers etc) as well. I still don't like this sentence which was added earlier: "... and if they feel that they could still use the tools then they will retain them." We shouldn't give them the choice as it's all about activity, not about trust because all global sysops are certainly trusted. Trijnstel_talk 15:10, 14 August 2012 (UTC)

+1! --Herby ^{talk thyme} 15:23, 14 August 2012 (UTC)

• Agree. Savh^ñ 20:50, 15 August 2012 (UTC)
• Agreed. I should point out that inactive users easily can dilute active users in stat tools (maybe not for GS but definitely for projects with lots of inactive local sysops).--Jasper Deng (talk) 21:57, 15 August 2012 (UTC)

GS / Steward and GS / GR

Hello,

Some times ago (I think in april 2011) all the GS received the global rollbacker bit. But I see that it's not dond anymore. Has the consensus change about this automatic attribution ?

I also see that 2 stewards are still GS. I don't understand the reason for this double rights because all the rights of GS are included in the steward flag.

regards

--90.12.0.4 22:42, 14 August 2012 (UTC)

the discussion about GS/GR was here --90.12.0.4 22:48, 14 August 2012 (UTC)

The consensus has not changed. A person who gets global sysop and does not have global rollback will be given it when they get GS. If this has not happened in a particular case let one of the stewards know and we'll fix it. :) fr33k]man 14:54, 15 August 2012 (UTC)

The following users are global sysop but are not global rollbacker:

• Axpde (is also steward)
• Fr33kman (is also steward)
• Jon Harald Søby
• Liliana-60
• SPQRobin
• Zscout370

As every global sysop is supposed to be global rollbacker, the sentence

Some global sysops also have global rollback. Unlike the global sysop group itself, global rollback is truly global.

should be change to

Global sysops also have global rollback. Unlike the global sysop group itself, global rollback is truly global.

or because some are also stewards but it will stay a minority

Most global sysops also have global rollback. Unlike the global sysop group itself, global rollback is truly global.

.

I was reverted yesterday, so I won't make this change but I think it must be done.

--90.59.118.250 19:49, 15 August 2012 (UTC)

Global rollback links to the list of global rollbackers saying "(including Global sysops on request)". So, let us just write "Global sysops may also obtain global rollback, if they don't have it already. Unlike (etc.)". --MF-W 20:47, 15 August 2012 (UTC)

I received GR flag without requesting it, just because I was GS. And the response of Fr33kman is that the GR flag should be automaticly given to the new GS, without request.

If a GS don't want GR flag, then the first sentence could be considered as false, but the second one will still be true.

--Hercule (talk) 21:03, 15 August 2012 (UTC)

Big projects like en and de may not like that, because global rollback applies to them too. -- Liliana • 09:33, 16 August 2012 (UTC)

I don't understand why they may not like that. It's not a new group, it's just that the GS are also GR. The GS rights don't apply to these projects.

If a member of a big project don't want that a GS is also GR (I can't imagine why) he can say it on the request for GS of the person. It can be considered as a double request for flags (GS and GR)

--Hercule (talk) 15:24, 16 August 2012 (UTC)

GR to GS is suposed to be on request. If a user passes a RFGS without being first a GR, the GS may request GR and it'll be granted; because the consensus there seemed to be that if the user is trusted enough for GS it was also enough for GR.

GR is a right that exists since the very existance of global groups. The policy is at meta and wikis do allow it if used carefully so I don't see any problems.

-- MarcoAurelio (talk) 15:41, 16 August 2012 (UTC)

As Fr33kman said : "A person who gets global sysop and does not have global rollback will be given it when they get GS." There is no need for the GS to ask it. So every GS are supposed to be GR.

--Hercule (talk) 09:03, 7 September 2012 (UTC)

Potential sysop abuse

Good day, I wasn't sure where to send them, so I suggested them to open an RfC: Requests for comment/Sysop abuse on the Zazaki Wikipedia. Amqui (talk) 23:36, 28 September 2012 (UTC)

Translations

Sorry, I just figured out that the translation box to the right is from the same template as the Need help line that I have problems with. I left a message on the template talk page there Template talk:Translation2#Need help line. That being said, I don't understand why you don't use the Translation extension for the translation of this page. Amqui (talk) 23:55, 24 November 2012 (UTC)

Maybe because this page was created years before the introduction of Translate? ;-)

As I said you on the template talk, I can mark this page for translation if you're willing to import all old translations to the new system. Thanks, Nemo 01:53, 25 November 2012 (UTC)

Now Mathonius marked the page for translation in some way, so we urgently need someone to import the old translations, because as a result we currently have no translations at all. For each page, look at the last revision before FuzzyBot came and manually copy the translations in the new translation interface. --Nemo 07:53, 25 November 2012 (UTC)

Done. I'm very sorry for the trouble I've caused and I hope it has been solved now, although I couldn't figure out where to 'translate' Global sysops/zh-classical. Mathonius (talk) 11:33, 25 November 2012 (UTC)

Thank you for fixing, and for the hard work. --Nemo 12:45, 25 November 2012 (UTC)

Sorry everybody. It's my fault that translations were down, I didn't realize they would be overwritten. On the other hand, the new translations look great! BTW "‎Classical Chinese" is "lzh" language code according to ISO. πr² (t • c) 13:22, 25 November 2012 (UTC)

Or should it be "zh-hant"? There are already translations to zh-hant, but they are different from the "Classical Chinese" ones. πr² (t • c) 13:32, 25 November 2012 (UTC)

Please include {{List of global sysops}} into translatable strings for ability translation of table header. Template {{user groups}} also should be translatable (now are exist some translations, see link to template). --Kaganer (talk) 09:59, 25 November 2012 (UTC)

I've done {{user groups}}. {{List of global sysops}} has no subpages and creating them would probably create problems elsewhere; I also don't like this way to pass parameters much, especially to translate just the header, because it's not super-robust; is there a way to make it language-neutral (I've migrated two columns to automatic translation, should work well enough for those)? Thank you, Nemo 12:45, 25 November 2012 (UTC)

{{List of global sysops}} - will be these same way, as for {{Global sysops/Permissions}} (calls base template with filling addition parameters). Example of code:

{{List of global sysops
<!-- FOR TRANSLATORS
|Last update=
|Name=
|IRC nick=
|Languages spoken=
|Active from=
-->
}}

This are used in the past version of translated page.--Kaganer (talk)

Request to global sysops' page

With the above being said, I don't see a clear page where an user can request an action from a global sysop. The request page for stewards is pretty clear, but there's nothing for global sysops. And over that, some requests that could be performed by global sysops are listed on the Steward requests' page which add to the overall confusion. I think we should look at the processes for requests on Meta from a global point of view and try to consolidate things so it's less 'all over the place'. Maybe a separate page isn't necessary, but it would be useful, especially for new contributors, to make it clear on the Global sysops page where to go to request help. Maybe a simple solution would be for the template on top, to say if somebody wants help from a global sysop it needs to go on the Stewards request page and that that page is only for guidlines about the rights themselves. The whole idea here is to look at this from the point of view of a new editor, I, myself, almost get lost between those pages on Meta for global sysop/steward/bureaucrat actions and I'm quite experienced, I can't imagine the burden for a new contributor, we loose him 10 times before he finds where to ask something (assuming that he finds Meta in the first place). If acquiring and retaining new contributors is a strategic goal for the movement, I think we should re-think that and transform those strategies into actions. Thanks, Amqui (talk) 06:59, 21 November 2012 (UTC)

The fact that you found so many place to link to this discussion that my watchlist is now full of them proves that that's true :P

Maybe we can re-label SRSD, where speedy deletion requests (on GS wikis) are already done by global sysops, a bit ("Requests for privileged actions"?), so that it is also open for other administrative requests from GS wikis. --MF-W 10:52, 21 November 2012 (UTC)

I was thinking along those lines. Another possibility is Steward requests/Miscellaneous for any GS/steward action not covered by the other pages (protection, abusefilter, etc.) πr² (t • c) 15:34, 21 November 2012 (UTC)

I think that PiRSquared's proposal is perfect. :-) Restu²⁰ 18:39, 21 November 2012 (UTC)

There is still the fact that it's unclear if we come on that page first. I understand that page here is for guidelines on the global sysops rights, but it should be clear for the top where to go for requests. Amqui (talk) 19:16, 21 November 2012 (UTC)

I added the information in the box at the top of the page. Amqui (talk) 23:56, 24 November 2012 (UTC)

I've changed the scope for the Requests for speedy deletions to include all Miscellaneous admin actions. Amqui (talk) 19:46, 25 November 2012 (UTC)