Stewards' noticeboard/Archives/2014-07
Please do not post any new comments on this page. This is a discussion archive first created in July 2014, although the comments contained were likely posted before and after this date. See current discussion or the archives index. |
Viquipedia
Hello, I want to inform the Stewards of a serious lack of neutrality in catalan Wikipedia. In the Wikipedia there is a clear discrimination between Spaniards born in regions where Catalan Spaniards born in regions where Catalan is spoken is not spoken, and. You can see discrimination in these two articles: https://ca.wikipedia.org/wiki/Ricardo_Zamora https://ca.wikipedia.org/wiki/Andr%C3%A9s_Iniesta In the first article only mentions that Zamora was catalan, and nowhere in the article mentioned it was Spanish. In the second article mentions if Spain. Catalonia and Spain Albacete belong to, so the policy of neutrality requires that the treatment for the two items is the same. But that Wikipedia administrators raised a vote: https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:Presa_de_decisions/2009/Q%C3%BCesti%C3%B3_de_banderes#Resultat where proposals that did not fulfill the policy of neutrality were chosen. The Interpreting is clear, the policy of neutrality requires that all options are visible on the items, ie, which is clearly visible on all items, the legal nationality, Spain, but administrators of Wikipedia, violate neutrality in based on a "catalan linguistic area", but there is no policy which would give more value to the language of each Wikipedia. I want to raise a petition to the Stewards consider the problem, and make a binding resolution. --Emperador312 (talk) 10:35, 1 July 2014 (UTC)
- ... and? Stewards are not a global Arbitration Committee; we cannot impose our own decisions on a community. --Rschen7754 10:37, 1 July 2014 (UTC)
- The stewards are to guarantee that the 5 pillars of Wikipedia are met. And in the Wikipedia in Catalan not met --Emperador312 (talk) 10:40, 1 July 2014 (UTC)
- Perhaps you should read Stewards then - that is not anywhere on the page. --Rschen7754 10:42, 1 July 2014 (UTC)
- Five pillars are a wikipedia issue, not one for stewards. If you believe that there is an issue within caWP, then the discussion belongs there. caWP is a self-governing wiki, stewards certainly cannot intervene on content issues. — billinghurst sDrewth 15:40, 1 July 2014 (UTC)
- Perhaps you should read Stewards then - that is not anywhere on the page. --Rschen7754 10:42, 1 July 2014 (UTC)
- The stewards are to guarantee that the 5 pillars of Wikipedia are met. And in the Wikipedia in Catalan not met --Emperador312 (talk) 10:40, 1 July 2014 (UTC)
Admin activity review for JAWN
Japanese Wikinews can now be carried out in its own Admin activity review. This is the result of discussions by ja:n:ウィキニュース:赤提灯#重要: 管理者活動の点検について. Please look at ja:n:ウィキニュース:管理者/2014管理活動点検による確認.--アルトクール(Home in JAWN) 07:28, 4 July 2014 (UTC)
- @アルトクール: Please add it to the relevant section on Talk:Requests for comment/Activity levels of advanced administrative rights holders (and we need to get that list into a better place). — billinghurst sDrewth 14:14, 4 July 2014 (UTC)
- Addendum. Also please thank your community for taking up this challenge. The stewards appreciate where communities have that review process, it gives you control, and it saves us some time. — billinghurst sDrewth 14:21, 4 July 2014 (UTC)
- I've added to list. Thank you.--アルトクール(Home in JAWN) 05:17, 5 July 2014 (UTC)
- Addendum. Also please thank your community for taking up this challenge. The stewards appreciate where communities have that review process, it gives you control, and it saves us some time. — billinghurst sDrewth 14:21, 4 July 2014 (UTC)
Global bots on uk.wikinews
In the topic "Global Bot wikis" which is now in archive was abuse. The link to ukwn in there is to ukwn's village pump's archive - the user notified community directly in there instead of village pump itself - stews should check the links they are provided with. I noticed the message then and moved it to proper page (and asked the user how he get to the archive so links may be fixed but he never responded) but I noticed the corresponding topic and actions on meta just recently. In the discussion nobody supported and nobody objected. I myself rather support the proposal but I had some business irl and in other wikimedia projects to respond in there. Even if it's considered successful discussion - why the community wasn't notified about the conclusion? There is a bot in the wiki blocked for running without a bot flag and botmaster ignoring my asks to request the bot flag. After approving SBP such blocks should be reviewed and IMHO stews are not the last people to check it's proceeded. --Base (talk) 10:36, 5 July 2014 (UTC)
- So, the discussion was eventually moved to the village pump and still nobody responded? Ruslik (talk) 17:26, 5 July 2014 (UTC)
- Aye, the community's now being not in the peak of activity unfortunately. But a stew has changed the wiki-set per discussion in Village Pump's archive and haven't left a notice in wiki in question which I consider rather bad practice. --Base (talk) 13:03, 11 July 2014 (UTC)
- There are some edits that stewards are requested to perform once the wikis are added, under Bot_policy/Implementation#Implementation. --Rschen7754 01:16, 12 July 2014 (UTC)
- Aye, the community's now being not in the peak of activity unfortunately. But a stew has changed the wiki-set per discussion in Village Pump's archive and haven't left a notice in wiki in question which I consider rather bad practice. --Base (talk) 13:03, 11 July 2014 (UTC)
Vietnamese spammer in process of sending millions of emails to people who can't even read them
Hi, it appears a bot on the Vietnamese Wikipedia is going to be setting up talk pages and sending out "welcome" emails to everyone who has ever had a Wikipedia account in any language. I got mine today. Going over there, I found an area for English speakers where there was already some discussion of this, and it seems clear the bot operator has no intention of stopping. Just so we're clear, both the talk page message and the email are in Vietnamese, but the bot owner appears to understand English as well. Since this is a cross-wiki issue and involves potentially spamming millions of users with emails they can't even read using the WMF's email system I would like for the stewards to look into it and take whatever action they deem appropriate. See thread at [1]. The bot's name is "AlphamBot2". Thanks. Beeblebrox (talk) 22:17, 4 July 2014 (UTC)
- If Google has translated it correctly, the email that I got also seems to imply that it is some sort of official communication from the WMF itself. Can forward if that would be helpful. Beeblebrox (talk) 22:25, 4 July 2014 (UTC)
- If they edit locally they can only write to local users (currently less than 400 thousands), so you need to have visited the site before (assuming you have SUL). This is hardly unprecedented, I regularly receive such messages (for instance in ml and ar if I remember correctly). --Nemo 22:27, 4 July 2014 (UTC) P.s.: Appears to be resolved, isn't it?
- I took that remark to mean what they had said before, that they were only sending one email to each user so if you had a problem with it it was already too late. Not sure, but I am pretty darn sure I have never made an edit there. It's possible I looked at it at some point for some reason. Beeblebrox (talk) 23:08, 4 July 2014 (UTC)
- They have now clarified that they have in fact stopped doing this, so no action is needed. Beeblebrox (talk) 20:05, 5 July 2014 (UTC)
pms wiki
Hi! I would like to point out that pms.wiki has its own rules for sysop activities (http://pms.wikipedia.org/wiki/Wikipedia:Deuit_p%C3%ABr_j%27aministrator). So it should not undergo the general revised rules approved on meta. Borichèt (talk) 06:24, 25 July 2014 (UTC)
- @Borichèt: Are you sure about this? [2] shows no desysops performed by stewards. What are the inactivity rules for pms.wikipedia? --Rschen7754 06:30, 25 July 2014 (UTC)
Specific rules about removing advanced rights are numbers 6 and 16. Essentially, rights - for inactivity or other reasons - are removed upon request of some member of the community. Borichèt (talk) 07:05, 25 July 2014 (UTC)
- Okay, we will not conduct the global process on your wiki. However, please be aware that bureaucrats on your wiki cannot remove the administrator permission, and you will need to make a request on SRP. --Rschen7754 07:10, 25 July 2014 (UTC)
adding translation admin to the stewards global group
Hello, Due to a bug in the translate extension, the translate admin right is needed to delete / revert (mass delete/revet) is needed in order to handle more that one action at a time for pages created with this extension. I suggest we add this right to the group at least until this bug is solved. Matanya (talk) 14:55, 11 June 2014 (UTC)
- Note: There are 15 wikis where this would have an impact as they use Extension:Translate, such that it is those where the 'wmgUseTranslate' configuration is set to true [3] — billinghurst sDrewth
- I support this addition, at least until the bug is fixed. Ajraddatz (talk) 14:59, 11 June 2014 (UTC)
- Please procede with adding this. The steward toolset has to cover delete and revert. Snowolf How can I help? 15:04, 11 June 2014 (UTC)
- I second this request, the translation extension poses some difficulties when dealing with vandalism, test and nonsense... --M/ (talk) 15:23, 11 June 2014 (UTC)
- Support - QuiteUnusual (talk) 16:08, 11 June 2014 (UTC)
- (non-steward comment) Are there even small wikis with that extension enabled? As far as I know, the communities which have that extension enabled for their wiki are big enough for dealing with vandalism at their own (i.e. without steward help). Wouldn't such a change circumvent local procedures for getting access to this right which can be easily (and accidentally) abused if one doesn't know well enough about the extension? Regards, Vogone (talk) 20:01, 11 June 2014 (UTC)
- I can suppose that if a Steward accidentally does any mistake when deleting / reverting those pages created by the translation extension, they would indeed help in reverting themselves. It makes less sense that pages containing grossly insulting vandalism could not be immediately be dealt by a group defined as users with complete access to the wiki interface on all Wikimedia wikis. --M/ (talk) 20:09, 11 June 2014 (UTC)
- This is not about a gs right but a steward right. Stewards are required to have enough rights to make up for local sysops even on non-gs wikis in cases of emergency or cross-wiki issues. Snowolf How can I help? 20:35, 11 June 2014 (UTC)
- Local sysops do not have this right either and normally it is only assigned to local users after the extension's documentation was read and sufficiently understood. I personally would not ad-hoc grant this right to any steward on Wikidata, which would be one of the very few wikis being affected by such a change (besides Commons, Meta, MediaWiki.org, Outreach and maybe a few chapter wikis), without them fulfillig these criteria defined by the local policy. Unfortunately, this not always easy-to-use extension can cause damage if used wrongly and sometimes issues aren't fixed with a single self-revert. I wonder why this step is needed especially since stewards are unlikely to act on big wikis and do not even seem to consider themselves trusted enough to hold other (active) rights like the "patrol" right (mentioning this as stewards would suddenly be able to mark pages for translation, possibly even without them realising that not every user can do this). Kind regards, Vogone (talk) 20:50, 11 June 2014 (UTC)
- As I raised this issue with stewards, there was consideration for not undertaking any rights changes at this time due to the expected low use. One of our discussion points was around the requirement for delete and oversight case, and having to get a third party to delete something and then get a steward to oversight was not seen as an attractive proposition. It is not an extension of our abilities, just the use of a tool that exists. This is a reserve power, and aligns with all use of our reserve powers. Nothing has changed in that regard. — billinghurst sDrewth 13:19, 13 June 2014 (UTC)
- Local sysops do not have this right either and normally it is only assigned to local users after the extension's documentation was read and sufficiently understood. I personally would not ad-hoc grant this right to any steward on Wikidata, which would be one of the very few wikis being affected by such a change (besides Commons, Meta, MediaWiki.org, Outreach and maybe a few chapter wikis), without them fulfillig these criteria defined by the local policy. Unfortunately, this not always easy-to-use extension can cause damage if used wrongly and sometimes issues aren't fixed with a single self-revert. I wonder why this step is needed especially since stewards are unlikely to act on big wikis and do not even seem to consider themselves trusted enough to hold other (active) rights like the "patrol" right (mentioning this as stewards would suddenly be able to mark pages for translation, possibly even without them realising that not every user can do this). Kind regards, Vogone (talk) 20:50, 11 June 2014 (UTC)
- No objections from me (as someone who has considerable experience with the user right). Thehelpfulone 20:50, 11 June 2014 (UTC)
- You say there's a bug. I would like to see the report on Bugzilla. PiRSquared17 (talk) 20:52, 11 June 2014 (UTC)
- Support Support PiRSquared17 idea. --Kolega2357 (talk) 20:57, 11 June 2014 (UTC)
- this bug is for delete should be extended to mass delete/revert. Matanya (talk) 21:06, 11 June 2014 (UTC)
- What does "mass delete/revert" mean? Are you referring to Special:PageTranslationDeletePage? That special page requires two rights: "delete" and "pagetranslation". PiRSquared17 (talk) 20:24, 12 June 2014 (UTC)
- I'd assume it means mass delete (or rollback all scripts). Ajraddatz (talk) 06:18, 13 June 2014 (UTC)
- @Matanya: btw I fixed the bug you linked, which was actually just for TUX. PiRSquared17 (talk) 04:52, 25 June 2014 (UTC)
- What does "mass delete/revert" mean? Are you referring to Special:PageTranslationDeletePage? That special page requires two rights: "delete" and "pagetranslation". PiRSquared17 (talk) 20:24, 12 June 2014 (UTC)
- I Support the idea that if it's a but then it's to be fixed as a bug. I would support giving stews TA tool only if everyone of them will now and new ones in election sign that they have carefully read the docs and perfectly if they also would show practically that they understood it right (it's quite boring thing to fix wrong tagging after somebody). If they would not then I Oppose it. In many wikis with Translate admins can grant themselves with the flag and usually how they use the tool is too awful to persuade me that stews would use it better unless they all promise it. --Base (talk) 18:10, 16 July 2014 (UTC)
- Support per above. Jianhui67 talk★contribs 12:29, 25 July 2014 (UTC)
Ja.Wikiversity has now its own Admin Review Policy
Today we, ja.wikiversity community, have introduced our own Admin Review Policy, over our Village-Pump discussion and the Talk page of the draft. And I've just updated the list. Thank you very much, dear Stewards! --Kanjy (talk) 12:26, 25 July 2014 (UTC)
- Thanks Kanjy. I have terminated the review process that stewards had started, and wish you luck in your managing these matters. It is appreciated that your community has progressed this matter, please thank them from us. — billinghurst sDrewth 16:18, 25 July 2014 (UTC)
Preparing for global renames
Soon it will be possible to rename accounts globally per gerrit:92468. I believe the relevant steward request pages should be updated in preparation. For more information, see the commit message on gerrit. PiRSquared17 (talk) 02:14, 15 June 2014 (UTC)
- The required right to use Special:GlobalRenameUser is 'centralauth-rename'. PiRSquared17 (talk) 02:17, 15 June 2014 (UTC)
- Docs: mw:Help:Extension:CentralAuth/Global_rename. PiRSquared17 (talk) 04:33, 15 June 2014 (UTC)
Proposal
- This proposal would be effective
18 June1 July 2014 with the deployment of SUL renaming. - Stewards will handle all global renames; i.e. a user with an SUL requesting a change of username. The new user right 'centralauth-rename' will be added to the local steward group on meta.
- Local bureaucrats will handle non-SUL renames and usurpations; i.e. users without an SUL or users trying to take over an account name to complete their SUL.
- (Not part of the proposal) When SUL finalization is complete, stewards will take over all renaming functions, and the 'renameuser' right will be removed from the local bureaucrat user group. This is not part of the proposal, but rather a statement of fact of what will happen at the completion of SUL finalization.
We don't have much time before this is deployed, and although we don't need to use it right away), I think that this is an area where we could prevent quite a bit of the pain of global renaming. Thoughts? Ajraddatz (talk) 02:39, 15 June 2014 (UTC)
- It is typical that WMF is still failing to give us SUL finalisation, which, when first announced more than a year ago, was claimed to be super-imminent. Now (thankfully) a volunteer wrote the code for a part of the finalisation, i.e. renaming, and it's deployment is even more super-imminent, while the rest of the implementation of WMF's glorious plan (taking away the rename right from bureaucrats) does not look like it will happen. This is bad, because we will have the situation described in the "proposal" above: Stewards will do global renaming, because stewards do global stuff; and bureaucrats do the remaining renaming of local accounts. That is the only possible implementation we can get within 2 days. It means that while a "simple, complete" global renaming is then easily possible, nothing changes for any other SUL situations, where you still need to run after bureaucrats on several wikis.
- Last year I created User:MF-Warburg/New SRUC in the panic ahead of the alleged date of SUL finalization. My opinion back then (I think I even wrote it somewhere on Meta, but I don't remember where) was to not panic. That is still my opinion. If we use this opportunity to fusion SRUC and SRSUL, it will be much clearer to people where to request stuff, and easier for stewards and other interested users to see all the requests for global renaming in one page. When the feature is there, it will of course be handled with care, but as long as it works, there should be no problem.
- The only thing which could be a problem is (again) the fact that bureaucrats still are able to rename. If they continue to handle local renaming requests in cases where the user probably wants a global rename, just doesn't know enough about MediaWiki accounts on WMF wikis (and probably doesn't care much about other wikis except maybe Commons), that will break a lot of SUL accounts. --MF-W 09:34, 15 June 2014 (UTC)
- I do think that the opposite will happen. We will now be enabled to test the global rename tool which is good, afterwards SUL will be finalized and in the end the renameuser right removed from local bureaucrats so that only stewards can rename accounts anymore on both global and local area. That was the plan of the WMF and don't see any changes in the current deployment process. Btw., Legoktm is a WMF contractor who first had to work on Flow and now on SUL finalisation. Cheers, —DerHexer (Talk) 10:35, 15 June 2014 (UTC)
- Of course that is good, but the "afterwards" will probably be in August 2015 or so. --MF-W 11:17, 15 June 2014 (UTC)
- DerHexer is correct. Legoktm wrote this in his role as a contractor for the WMF, not as a volunteer. --Dan Garry, Wikimedia Foundation (talk) 21:34, 10 July 2014 (UTC)
- I do think that the opposite will happen. We will now be enabled to test the global rename tool which is good, afterwards SUL will be finalized and in the end the renameuser right removed from local bureaucrats so that only stewards can rename accounts anymore on both global and local area. That was the plan of the WMF and don't see any changes in the current deployment process. Btw., Legoktm is a WMF contractor who first had to work on Flow and now on SUL finalisation. Cheers, —DerHexer (Talk) 10:35, 15 June 2014 (UTC)
- Quick note: Global rename policy and talk page. —DerHexer (Talk) 10:13, 15 June 2014 (UTC)
- Elfix points me on the necessity of a Global account naming policy. —DerHexer (Talk) 16:36, 15 June 2014 (UTC)
- I agree. If we need to abide by every individual wiki policy it would be a nightmare. Better to establish a global policy with the global community so that problem does not exist. Ajraddatz (talk) 19:31, 15 June 2014 (UTC)
- What could be the content? Different languages all have different words that they consider too abusive to be part of a username. --MF-W 22:45, 16 June 2014 (UTC)
- I agree. If we need to abide by every individual wiki policy it would be a nightmare. Better to establish a global policy with the global community so that problem does not exist. Ajraddatz (talk) 19:31, 15 June 2014 (UTC)
- Will it be required that we log entries on a page at Meta? I handle a lot of the en.wiki requests as a local crat and it would be easier for users during the transition if I could
{{done}}
their request an en.wiki page and only use meta for the actual rename. MBisanz talk 14:12, 16 June 2014 (UTC)- I'd think that we would want to transition requests for renames to meta as much as possible (i.e. putting big notices on local CHU pages). That said, during a transition period, it would probably be acceptable to not log every request here. That's something we should work towards though. Ajraddatz (talk) 15:24, 16 June 2014 (UTC)
- As long as it is archived, and referenced appropriately with a fully linkable permalink, what does it matter that the request sit on a different wiki? At a point in time we will stop at a local wiki, and you can call that a transition or a change at some point of time. — billinghurst sDrewth 15:49, 16 June 2014 (UTC)
- In my opinion, requests can be accepted in any way that is reasonable. From users identified by WMF cloaks I even accept requests on IRC sometimes [for the currently existing local renaming]. Just a note about your case of planning to accept requests on a local rename request page: We must handle this transition in an intelligent way, otherwise - as I wrote above - continued local renaming by bureaucrats will result in unnecessary breaking of SUL accounts. And certainly there shouldn't be the possibility for unknowing users to run into "first and second class renames" on one page, depending on who will execute the request. --MF-W 22:45, 16 June 2014 (UTC)
- But nothing has changed in this regard, we just have a new tool. At this point in time the primary responsibility for renames remains with those communities where bureaucrats exist; with stewards undertaking unfulfilled requests or where there is no crats in the community. If they receive second-hand service, they take it up with their community, not our business. — billinghurst sDrewth 11:59, 17 June 2014 (UTC)
- And how do you expect this tool to work? I guess there'll two fields “old name”, “new name” and one button “global rename now” plus maybe some checkboxes for confirmation, collision warnings or the like (as it is now with Special:Renameuser). I doubt that we can choose not to rename on enwiki, dewiki, or any other specific wiki. As most (global) accounts will have a local account on at least one wiki with bureaucrats, the global rename tool would become completely useless. That wouldn't be the tool I'm waiting for since 2008 or even longer. Or alternatively, the user would still have to tramp to each project with local crats before they can request global renames which would neither simplify nor shorten the process for the requesting user but we were also waiting for. Hence, either one group will be allowed to rename accounts on each and every wiki (let it be stewards, stewards and global renamers, stewards and all crats, or anyone else) what a global rename tool is designed for, or we abandon it completely which would suck. Cheers, —DerHexer (Talk) 13:04, 17 June 2014 (UTC)
- If primary responsibility rests with the communities on this, then let's change that. With global accounts, the current system of every local wiki with active bureaucrats handling renames is a ridiculous one. Let's get the WMF to do this all at once - make global renaming truly global, and in so doing fix this issue which should have been resolved when centralauth was turned on in the first place. The current system for renaming is ridiculous and patently unfair for those who need to go through it. We can fix it, and I think we should. In fact, I was already drafting an email to Philippe specifically about this. Ajraddatz (talk) 16:46, 17 June 2014 (UTC)
- Not certain that it is in WMF's bailiwick, this is the community's rule. You might be better trying to have the community allow stewards to rename after a period when the local wikis have not undertaken a rename, eg. allow local wikis nn many days to fulfil local moves, and if not undertaken, then a steward will undertake all remaining actions. — billinghurst sDrewth 15:51, 21 June 2014 (UTC)
- You're right, they are unwilling to take action. But you do realize that what you mentioned is already done, right? On projects where the crats are inactive or don't respond to rename requests we do that for them after a while. See a request handled today on SRSUL for an example. Ajraddatz (talk) 22:12, 21 June 2014 (UTC)
- Not certain that it is in WMF's bailiwick, this is the community's rule. You might be better trying to have the community allow stewards to rename after a period when the local wikis have not undertaken a rename, eg. allow local wikis nn many days to fulfil local moves, and if not undertaken, then a steward will undertake all remaining actions. — billinghurst sDrewth 15:51, 21 June 2014 (UTC)
- But nothing has changed in this regard, we just have a new tool. At this point in time the primary responsibility for renames remains with those communities where bureaucrats exist; with stewards undertaking unfulfilled requests or where there is no crats in the community. If they receive second-hand service, they take it up with their community, not our business. — billinghurst sDrewth 11:59, 17 June 2014 (UTC)
- Alright, that makes sense then. Thanks. MBisanz talk 01:47, 17 June 2014 (UTC)
- I'd think that we would want to transition requests for renames to meta as much as possible (i.e. putting big notices on local CHU pages). That said, during a transition period, it would probably be acceptable to not log every request here. That's something we should work towards though. Ajraddatz (talk) 15:24, 16 June 2014 (UTC)
- I've gone ahead and will be leaving notifications for local bureaucrats, informing them of the above plan but also saying that they are not required to participate (since we have no authority to actually enforce it). As such, we should probably update the SRUC page to both 1) be easier to use and 2) reflect global renaming on 1 July. Thoughts? Ajraddatz (talk) 03:25, 19 June 2014 (UTC)
- Some of the feedback I've been getting involves concern that there is no global guidelines for account naming. Personally, I don't think that there should be one, however I would certainly support expanding Global rename policy to include a list of commonly-disallowed usernames by local policies. Examples include promotional usernames, usernames with offensive language, etc. Obviously this will require some case-by-case analysis by stewards. I'll add this to the policy page if nobody objects; we'll also probably need to vote that into official policy status at some point. Ajraddatz (talk) 21:28, 20 June 2014 (UTC)
If anyone wants to test the tool before it is rolled out for real, they can use Beta Labs. Any Beta Labs steward (including myself) can grant the right there to anyone who wants to test it. PiRSquared17 (talk) 01:16, 7 July 2014 (UTC)
Global renamers
Something which could help keep us in line with local policies would be expanding the number of users who could rename users globally from just stewards to stewards and some trusted bureaucrats in a global renamers group. I know that there are arguments on both sides for this from past discussions, but I think the benefit would be maximized if global renamers stuck to requests centred around their home projects. They do know a lot about local policies, and that knowledge could be helpful, especially during the transition period. Please let me know what you think, to see if it's worth proposing it on an RfC or some similar means. Ajraddatz (talk) 21:28, 20 June 2014 (UTC)
- That seems very reasonable. PiRSquared17 (talk) 21:58, 20 June 2014 (UTC)
- As long as this is done similar to the GR/GS processes, that sounds fine. --Rschen7754 22:03, 20 June 2014 (UTC)
- I don't think this thought should be pursued at the moment, as I already said in past discussions. We should first see how stewards will be able to handle the new workload & tools. I fear there might be chaos if too many people can start using global rename when it might not yet be perfect. --MF-W 11:41, 21 June 2014 (UTC)
- Also just as there is now a tool, it has been expressed by WMF that there is no change in global rules, and the local wikis maintain their local rules, so it is still a catch-up tool, not first use tool. — billinghurst sDrewth 15:45, 21 June 2014 (UTC)
- What does that mean? When it comes to global actions surrounding global matters, steward tools take precedence. Or are global blocks and locks also catch-up tools? (Apologies if I've misunderstood here)
- Also, please note that this propose has nothing to do with workload, but rather preventing policy issues. I do agree though, no need to implement it right away; I'm trying to see if there would be significant opposition or problems with a proposal for that group. Ajraddatz (talk) 17:54, 21 June 2014 (UTC)
- Instead, WMF expressed that crats will lose their renameuser right as soon as global rename will be enabled and local renames handled by stewards if necessary at all (which will less happen when SUL is finalized). Cheers, —DerHexer (Talk) 20:58, 21 June 2014 (UTC)
- Also just as there is now a tool, it has been expressed by WMF that there is no change in global rules, and the local wikis maintain their local rules, so it is still a catch-up tool, not first use tool. — billinghurst sDrewth 15:45, 21 June 2014 (UTC)
I registered some BEANSy qualms about the main proposal by email to Ajraddatz, after he promoted the change at en:'s Bureaucrat noticeboard. I think this additional idea would allay many of my fears. However, it does beg the question: why restrict this new tool to Stewards, instead of local Crats, rather than just rolling the tool out to local Crats? --Dweller (talk) 23:46, 24 June 2014 (UTC)
- Giving local crats the access to rename accounts across the system (who may not be aware of global issues) would be problematic (not to mention that many crat rights were handed out like candy in the 2000s without any community review, etc.). --Rschen7754 23:48, 24 June 2014 (UTC)
- It should be possible to train interested local 'crats on the intricacies and implications of global renames, no? 28bytes (talk) 23:53, 24 June 2014 (UTC)
- Well, the problem is that people would try and use the tool without being trained on that sort of thing. According to [4] there's hundreds of crats out there and the dissemination of that information is just not possible (don't forget language barriers!). Sure, there's plenty of crats that are inactive for 2+ years, and per AAR we're trying to address that, but it's a lengthy process. Not to mention crats who may be blocked in other wikis but are now able to rename people on those wikis, differences in username policies (Wikivoyage allows corporate accounts!), crats on testwikis and some small wikis (where this is still given out like candy), who would now be able to rename everywhere, etc. And that levels of trust for the bureaucrat right vary quite widely (on some wikis like most Spanish-language wikis, all admins are crats, whereas on enwiki it's much harder than RFA!) That just opens up a can of worms, quite frankly. --Rschen7754 23:57, 24 June 2014 (UTC)
- That makes sense. In that case, offering interested local 'crats a review process for a global rename right along the lines of what Ajraddatz suggested above would seem to be a better way to handle the likely increase in rename requests here. 28bytes (talk) 00:10, 25 June 2014 (UTC)
- FWIW it's also not technically possible to let local crats rename globally. That tool will require local renameuser rights on all wikis, so even if 'crats are granted access through a global renamers group, there will be the extra step of adding them to that group (hopefully without too much of a process). I'll be looking at expanding the global renaming policy and ratifying it soon, but unfortunately I'm working full time right now and don't have much internet access. Ajraddatz (talk) 00:29, 25 June 2014 (UTC)
- Technical note: nope, that's not an issue. The tool assumes that anyone with the global rename userright is trusted with local renames, and doesn't check for a local renameuser right. Legoktm (talk) 01:13, 25 June 2014 (UTC)
- Thanks for clarifying, must have read the docs wrong/not remembered it correctly. Ajraddatz (talk) 01:26, 25 June 2014 (UTC)
- Technical note: nope, that's not an issue. The tool assumes that anyone with the global rename userright is trusted with local renames, and doesn't check for a local renameuser right. Legoktm (talk) 01:13, 25 June 2014 (UTC)
- FWIW it's also not technically possible to let local crats rename globally. That tool will require local renameuser rights on all wikis, so even if 'crats are granted access through a global renamers group, there will be the extra step of adding them to that group (hopefully without too much of a process). I'll be looking at expanding the global renaming policy and ratifying it soon, but unfortunately I'm working full time right now and don't have much internet access. Ajraddatz (talk) 00:29, 25 June 2014 (UTC)
- That makes sense. In that case, offering interested local 'crats a review process for a global rename right along the lines of what Ajraddatz suggested above would seem to be a better way to handle the likely increase in rename requests here. 28bytes (talk) 00:10, 25 June 2014 (UTC)
- Well, the problem is that people would try and use the tool without being trained on that sort of thing. According to [4] there's hundreds of crats out there and the dissemination of that information is just not possible (don't forget language barriers!). Sure, there's plenty of crats that are inactive for 2+ years, and per AAR we're trying to address that, but it's a lengthy process. Not to mention crats who may be blocked in other wikis but are now able to rename people on those wikis, differences in username policies (Wikivoyage allows corporate accounts!), crats on testwikis and some small wikis (where this is still given out like candy), who would now be able to rename everywhere, etc. And that levels of trust for the bureaucrat right vary quite widely (on some wikis like most Spanish-language wikis, all admins are crats, whereas on enwiki it's much harder than RFA!) That just opens up a can of worms, quite frankly. --Rschen7754 23:57, 24 June 2014 (UTC)
- It should be possible to train interested local 'crats on the intricacies and implications of global renames, no? 28bytes (talk) 23:53, 24 June 2014 (UTC)
I'm fairly worried about the main proposal. Apart from the BEANS issues that worry me, there's the workload. How many active Stewards are there? en: alone did about 350 renames last month. --Dweller (talk) 00:00, 25 June 2014 (UTC) (update: based on my subjective and imprecise [lack of] definition of "active", it looks like roughly 20... which ain't many) --Dweller (talk) 00:06, 25 June 2014 (UTC)
- Well, though some stewards are bureaucrats and will have to shift their renaming activity over here. I personally think that we will have to have global renamers of some sort (and that is how things will probably wind up should we become overwhelmed with the workload), though not everyone is behind the idea. --Rschen7754 00:18, 25 June 2014 (UTC)
- "steward", like any other user right name, is not capitalized My main concern about stewards is their lack of timezone coverage, not their overall activity. If stewards can't handle it, we can start an RfC on creating a user group like this one.--Jasper Deng (talk) 00:25, 25 June 2014 (UTC)
- Most people I've talked to are behind the idea. Ultimately, if there are major workload issues then we can very rapidly get help through the global renamers group. I can understand the concerns with local 'crats not having a global perspective, but these are also generally intelligent and trusted people who bring a wealth of experience. That they can't rename globally but I can (as someone who isn't a crat anywhere here) is pretty silly, so I'll definitely be proposing this group for policy (and workload potentially) reasons. Ajraddatz (talk) 00:29, 25 June 2014 (UTC)
- Hello stewards, I am Bene*, a bureaucrat from wikidata. I recently saw that global rename has been introduced and one user already has been renamed. In my opinion this is a great tool which makes renaming with SUL much easier. As a bureaucrat I'm quite experienced in renaming and know the tools as well as I understand the global context of SUL. Thus if my help is appreciated I'd be glad to assist. Best regards --Bene* (talk) 21:16, 10 July 2014 (UTC)
- Hi stewards, I am a crat from dewiki. I saw the rename of the user .js. A realy good tool, because a rename is for some user quite a lot of work. Like Bene* I would like to help, if help is needed. Best --Itti (talk) 15:50, 14 July 2014 (UTC)
- I'm also bureaucrat from dewiki and would like to help too. Regards, IW 16:34, 14 July 2014 (UTC)
- Like Itti, I support Ajraddatz' proposal, and if it's accepted would apply for the global renaming right, restricting myself to renaming users with homewiki .de. Greetings, --MBq (talk) 16:22, 14 July 2014 (UTC)
- I'm bureaucrat at dewiki for serveral years now and I renamed hundreds of users there. I would like to help renaming globally. --APPER 16:17, 16 July 2014 (UTC)
- Hello stewards, I am Bene*, a bureaucrat from wikidata. I recently saw that global rename has been introduced and one user already has been renamed. In my opinion this is a great tool which makes renaming with SUL much easier. As a bureaucrat I'm quite experienced in renaming and know the tools as well as I understand the global context of SUL. Thus if my help is appreciated I'd be glad to assist. Best regards --Bene* (talk) 21:16, 10 July 2014 (UTC)
Hi, I am regular user (not a crat or steward or anything else) that wants his SUL to be gloablly renamed, but I havent found a request page for that. We just got the message through tech wiki news that it will be possible to rename a user globally but our crats dont know yet where to request such a rename. Can you help me or we will get the instructions in some other way soon? Thanks.--Hypothalamus (talk) 16:10, 3 July 2014 (UTC)
- SRUC but it will not be possible until (at the earliest) July 9. Also, there is currently no global rename policy. PiRSquared17 (talk) 22:10, 3 July 2014 (UTC)
See the proposal for the group at Global renamers. Ajraddatz (talk) 17:36, 27 July 2014 (UTC)
Deploy and initial testing
Hello everybody, we've just deployed global rename and I've done two test renames (one dummy account and "Jan S..." to ".js"). Both renames went totally fine! I would recommend you to abstain from doing global renames for the next 24 hours, to let things settle and make sure there aren't any subtle breakages we're not aware of yet. If you want to test global rename, you can still do that on beta wikimedia. Cheers, Hoo man (talk) 17:30, 9 July 2014 (UTC)
- Thank you, hoo and lego, for creating this tool! I'm really looking forward to fulfilling user rename requests much easier now. I'm confident that most local crats will agree here. Cheers, —DerHexer (Talk) 23:12, 9 July 2014 (UTC)
Notes from the product manager for SUL
Hello everyone.
For those that don't know me, I'm Dan, the product manager responsible for the SUL finalisation. Some of you might know me as Deskana.
I asked Legoktm to start working on GlobalRenameUser as it's a prerequisite to the SUL finalisation; RenameUser detaches local accounts from global ones, and that can't keep happening after we've performed the finalisation. This extension will, post-finalisation, totally replace RenameUser.
As we developed the tool to work primarily post-finalisation, I realise this tool isn't really that useful right now. We're only deploying it in case you want to use it. If you don't want to use it yet for whatever reason, that's totally fine.
Our current plan for the SUL finalisation is to have all of the engineering work finished by the end of September 2014. The actual finalisation will happen after that at some point yet to be determined. The community engagement aspect is as important as the engineering work; if I set the date for the finalisation too close to the present, then there will be floods of rename requests that overwhelm the stewards. We need to be mindful of every community member involved in this, and that includes both those being forcibly renamed and the stewards that will have to answer lots of questions about it. I want to set a realistic date, and I can't do that just yet.
I'll keep in touch as things develop. Thanks!
--Dan Garry, Wikimedia Foundation (talk) 18:29, 10 July 2014 (UTC)
- Dear Dan, I really can't believe you want to delay the use of this great tool, now that it's ready. I'm sooo thankful for it and that I was honoured to be "tested" with. It had been a horror for me since weeks, knowing that when I want to change my name that I will have to:
- visit all sister projects I edited
- look for all the different bureaucrats/user rename pages there
- try to figure out all the local rules & languages
- post my requests one-by-one
- post a global request on meta for the rest
- post a local request on meta, too
- be prepared for a lot of questions in return
- keep track of all those requests for days or weeks
- dealing with a high risk of login conflicts, distracting me from editing during all that time
- keep checking for SUL finalisation every couple hours/days on multiple sister projects
- ... 12. ... 13. ... ...
- The community really needs this tool to be unleashed asap. I can't be thankful enough to Hexer, Hoo and Lego for establishing it! (Sorry if my words should sound unpolite? I'm no native speaker and intend no offense nor personal attack.)--.js (talk) 01:25, 13 July 2014 (UTC)
- Don't worry .js, we're still going to be using it. We just need to finalize some of the policy elements and adjust the appropriate pages (which sounds like a simple task and really should be). Ajraddatz (talk) 01:29, 13 July 2014 (UTC)
- Hi .js. I'm glad your global rename went well! I don't want to delay the usage of GlobalRenameUser at all; my point was that it is up to the stewards to decide whether they want to use it or not. I'm glad they decided to. They will take a little bit of time to establish the policy for its usage, then I'm sure it'll see a lot of use. :-) --Dan Garry, Wikimedia Foundation (talk) 06:50, 13 July 2014 (UTC)
- I created a list on dewiki with local-only active accounts. I and the other local bureaucrats will try to help people on that list to get a sul accounts.
- Why is it still allowed to create local only accounts? On dewiki half of the active (=edit last 30 day) local only accounts have been created within the last five month. Not stopping the creation of new local-only accounts contrasts the goal of having only sul accounts. Merlissimo (talk) 18:34, 14 July 2014 (UTC)
- We're working on that too, see bugzilla:67901. Legoktm (talk) 19:36, 14 July 2014 (UTC)
Ping User:DGarry (WMF) and User:Legoktm: I just realized that there are private wikis... And since they are detached from SUL it's important that accounts can be renamed there. I assume the RenameUser extension will be kept activated on those wikis? Trijnsteltalk 17:43, 16 July 2014 (UTC)
- @Trijnstel: That's correct. We're just going to remove RenameUser from wikis hooked up to CentralAuth so that it can't be used to detatch local accounts from global ones; if a wiki isn't hooked up to CentralAuth, there's no reason for us to remove the RenameUser extension from it. --Dan Garry, Wikimedia Foundation (talk) 19:29, 16 July 2014 (UTC)
- Until now I was under the impression that first, only the renameuser right would be taken away from bureaucrats (at a yet-unknown point of time), so that stewards could still use it for fixing problems with detached accounts that might come up from failed rename attempts of the past, or any other problems (up to, maybe, a yet-unknown point of time when the RenameUser extension would be disabled completely). Is that still correct? --MF-W 21:51, 16 July 2014 (UTC)
- @MF-Warburg: After the finalisation, RenameUser will be removed from all wikis that are hooked up to CentralAuth; given that it can detach local accounts from global accounts, leaving it in place will just mean a second finalisation further will have to be performed further down the line. The SUL team are instead designing tools (such as a global account merger, and global rename) to serve the same use cases after the finalisation (i.e. "The finalisation means I now have six separate global accounts. Can I get them merged into one?"). In the interim period, our current plan is for RenameUser to remain enabled so that it can be used as it is presently. If the SUL team does decide to remove RenameUser in the interim period, we would be sure to inform the stewards well before we did so. --Dan Garry, Wikimedia Foundation (talk) 03:48, 17 July 2014 (UTC)
- That's not entirely true, it's not planned to remove the RenameUser extension, it was just planned to remove the rights from all (local) groups. Even CentralAuth's global rename relies on the RenameUser extension locally to do the "hard work" so removing the extension would also break that. But as we will get global account merge functionality, it wont be necessary to use the local rename user functionality after the SUL finalization has been completed (and I guess the global group holders that in theory could assign themselves the rights to use the local functionality wont do so). Cheers, Hoo man (talk) 11:36, 20 July 2014 (UTC)
- Indeed, Legoktm informed me of this afterwards. The user-facing effect is the same; as it breaks unification nobody should be performing local renames, and since all the use cases are met by other tools nobody should really have the ability to do it either. --Dan Garry, Wikimedia Foundation (talk) 05:38, 22 July 2014 (UTC)
- That's not entirely true, it's not planned to remove the RenameUser extension, it was just planned to remove the rights from all (local) groups. Even CentralAuth's global rename relies on the RenameUser extension locally to do the "hard work" so removing the extension would also break that. But as we will get global account merge functionality, it wont be necessary to use the local rename user functionality after the SUL finalization has been completed (and I guess the global group holders that in theory could assign themselves the rights to use the local functionality wont do so). Cheers, Hoo man (talk) 11:36, 20 July 2014 (UTC)
- @MF-Warburg: After the finalisation, RenameUser will be removed from all wikis that are hooked up to CentralAuth; given that it can detach local accounts from global accounts, leaving it in place will just mean a second finalisation further will have to be performed further down the line. The SUL team are instead designing tools (such as a global account merger, and global rename) to serve the same use cases after the finalisation (i.e. "The finalisation means I now have six separate global accounts. Can I get them merged into one?"). In the interim period, our current plan is for RenameUser to remain enabled so that it can be used as it is presently. If the SUL team does decide to remove RenameUser in the interim period, we would be sure to inform the stewards well before we did so. --Dan Garry, Wikimedia Foundation (talk) 03:48, 17 July 2014 (UTC)
- Until now I was under the impression that first, only the renameuser right would be taken away from bureaucrats (at a yet-unknown point of time), so that stewards could still use it for fixing problems with detached accounts that might come up from failed rename attempts of the past, or any other problems (up to, maybe, a yet-unknown point of time when the RenameUser extension would be disabled completely). Is that still correct? --MF-W 21:51, 16 July 2014 (UTC)
"Ghost" admins on a "ghost wiki"
This wiki has long been redirected to the new wiki at Wikimedia UK's own servers (notice the URL redirect when you click the first link). But apparently, the admins and bureaucrats weren't removed and are still there, which isn't that big of a deal, but does pollute Special:CentralAuth. I did in fact request removal of my own rights at SRP#Jasper Deng@ukwikimedia, and it was done, so it shows that removal can still be done.
However, I knew there were more such admins and thanks to User:Legoktm's SQL query here, there are 42 other such admins, which probably should be removed too. I was going to post this at SRP but it would've been very cumbersome to do so.--Jasper Deng (talk) 04:07, 28 July 2014 (UTC)
- It is a chapter wiki, where stewards do as requested, it is not stewards' role to pre-emptively take any additions or removals without requests. I would suggest that this should be addressed to WMUK, and they will make the requests to us that they wish for us to do. — billinghurst sDrewth 04:57, 28 July 2014 (UTC)
- @Billinghurst: Except, they have no more control over this wiki - it is for all intents and purposes closed. I'm talking about their vestigial wiki on the production cluster, not their current site.--Jasper Deng (talk) 05:37, 28 July 2014 (UTC)
- I understand to which wiki you refer. They have full control over it in the ownership sense, and they can fall back to it at any point of time they choose to do so. WMUK can submit a bugzilla to have all the admins/crats removed as it is simply theirs to control, or they can come to stewards and ask for them to be cleansed one by one. It is not stewards' role to determine what WMUK does with their chapter wiki. — billinghurst sDrewth 06:03, 28 July 2014 (UTC)
- Thank you Jasper for raising this and leaving a note on the UK chapter's water cooler. Please feel free to remove the admin and crat rights from the accounts on the ghost wiki. Would you like a request filed through bugzilla or is this post enough? Richard Nevell (WMUK) (talk) 10:06, 28 July 2014 (UTC)
- @Richard Nevell (WMUK): I think that bugzilla is best, as they have a script that does this when they close wikis. Otherwise we have to rely on external tools to query the data. — billinghurst sDrewth 11:07, 28 July 2014 (UTC)
- Is there a particular product and component I should add the bug to? Richard Nevell (WMUK) (talk) 12:13, 28 July 2014 (UTC)
- Bugzilla Component: Site request. --Steinsplitter (talk) 12:16, 28 July 2014 (UTC)
- Request done bugzilla:68737 — billinghurst sDrewth 14:11, 28 July 2014 (UTC)
- You beat me to it :-) Thank you for the help everyone. Richard Nevell (WMUK) (talk) 14:17, 28 July 2014 (UTC)
- Request done bugzilla:68737 — billinghurst sDrewth 14:11, 28 July 2014 (UTC)
- Bugzilla Component: Site request. --Steinsplitter (talk) 12:16, 28 July 2014 (UTC)
- Is there a particular product and component I should add the bug to? Richard Nevell (WMUK) (talk) 12:13, 28 July 2014 (UTC)
- @Richard Nevell (WMUK): I think that bugzilla is best, as they have a script that does this when they close wikis. Otherwise we have to rely on external tools to query the data. — billinghurst sDrewth 11:07, 28 July 2014 (UTC)
- Thank you Jasper for raising this and leaving a note on the UK chapter's water cooler. Please feel free to remove the admin and crat rights from the accounts on the ghost wiki. Would you like a request filed through bugzilla or is this post enough? Richard Nevell (WMUK) (talk) 10:06, 28 July 2014 (UTC)
- I understand to which wiki you refer. They have full control over it in the ownership sense, and they can fall back to it at any point of time they choose to do so. WMUK can submit a bugzilla to have all the admins/crats removed as it is simply theirs to control, or they can come to stewards and ask for them to be cleansed one by one. It is not stewards' role to determine what WMUK does with their chapter wiki. — billinghurst sDrewth 06:03, 28 July 2014 (UTC)
- @Billinghurst: Except, they have no more control over this wiki - it is for all intents and purposes closed. I'm talking about their vestigial wiki on the production cluster, not their current site.--Jasper Deng (talk) 05:37, 28 July 2014 (UTC)
This is not something which should have a bug, as that's an issue which can and should be solely resolved by stewards. No need to involve shell users (sysadmins) or anything here. I've closed the bug. Hoo man (talk) 14:18, 28 July 2014 (UTC)
- sDrewth talked me into doing this server side using my shell access, so... Done. The list of all removed rights can be found here. Cheers, Hoo man (talk) 15:46, 28 July 2014 (UTC)
- Just a FYI, we do remove rights on all closed wikis per CPP. --Rschen7754 16:52, 28 July 2014 (UTC)
- To note: CPP would not seem to apply to chapter wikis, the lead introductory scope would seem to explicitly exclude it, presumably they are not projects. So I would agree that we should do this as following good practice, but we cannot require this as a policy. — billinghurst sDrewth 23:59, 28 July 2014 (UTC)
- The CPP definitely applies to chapter wikis. Some of them were closed using the standard closure process (see this). The CPP itself says that 'This policy defines the process to close (...) a wiki hosted by the Wikimedia Foundation'. Ruslik (talk) 12:07, 29 July 2014 (UTC)
- I beg to differ. None of the process mentioned there was followed, anyway the moving of the wiki to an offsite wiki by a UK registered body has nothing to do with the language committee, and I would love to see them have tried. So it would clearly fall outside of that policy. Chapters are not projects. — billinghurst sDrewth 12:55, 29 July 2014 (UTC)
- The policy is about wikis, not projects by the way (see the part quoted by Ruslik0). And the language committee was merely the group which introduced that policy. Vogone (talk) 16:15, 29 July 2014 (UTC)
- I beg to differ. None of the process mentioned there was followed, anyway the moving of the wiki to an offsite wiki by a UK registered body has nothing to do with the language committee, and I would love to see them have tried. So it would clearly fall outside of that policy. Chapters are not projects. — billinghurst sDrewth 12:55, 29 July 2014 (UTC)
- The CPP definitely applies to chapter wikis. Some of them were closed using the standard closure process (see this). The CPP itself says that 'This policy defines the process to close (...) a wiki hosted by the Wikimedia Foundation'. Ruslik (talk) 12:07, 29 July 2014 (UTC)
- To note: CPP would not seem to apply to chapter wikis, the lead introductory scope would seem to explicitly exclude it, presumably they are not projects. So I would agree that we should do this as following good practice, but we cannot require this as a policy. — billinghurst sDrewth 23:59, 28 July 2014 (UTC)
- Just a FYI, we do remove rights on all closed wikis per CPP. --Rschen7754 16:52, 28 July 2014 (UTC)
Inactive admin on oc.wikibooks
Hello, Just found your notice to Cedric31 on oc.wikipedia. I do not know what is the status of oc.wikibooks, but I'm ready to help keeping an eye on it. Just tell me through the oc.wp user discussion system. Thanks in advance, --Jfblanc (talk) 12:20, 28 June 2014 (UTC)
- We will check Cedric31's status in a month, which is the required duration, before removing the rights. --Rschen7754 07:52, 29 June 2014 (UTC)
- Hi, just found your answer here (seems you did not answer on the wp as asked, well, never mind). I'm trying to rock the Occitan users on wikipedia (and now on the other oc wikis) to have these properly followed up. I'll keep you updated. Regards. --Jfblanc (talk) 09:01, 30 July 2014 (UTC)