Talk:Global rename policy/Archives/2014

From Meta, a Wikimedia project coordination wiki

Untitled

Please see also Requests for comment/Global usurpation policy for a special-case application of this policy. — Hex (❝?!❞) 19:12, 14 October 2012 (UTC)

Home-wiki notification

Should the home-wiki be notified before the rename? The stewards might not know what the new name means, thus breaking some renaming rules. ...Aurora... (talk) 10:49, 4 May 2013 (UTC)

The issue is that there won't necessarily be a home-wiki with newly registered users. Also language alone won't be sufficient to address those concerns (which project would be notified regarding a Chinese name? what if someone's name was an insult in Urdu that was written in English?). I think the better choice would be to freely grant renames if they look alright, but leave it to local projects to block the user for disruption or flag down a steward to undo the rename if the user has become disruptive. MBisanz talk 15:57, 4 May 2013 (UTC)
I tend to agree, I can't think of any way to reconcile username policies from such a diverse group of projects and languages. The possible unfortunate side effect could be users who go to meta to be renamed, only to get blocked again because they have failed again to chose an acceptable username, but I suppose we can worry about that if and when it becomes a significant issue. Beeblebrox (talk) 06:24, 5 May 2013 (UTC)
In that case, perhaps users should declare which wiki is their main wiki, or what language are the names in. Oh well, the chances of this happening are pretty low I suppose. ...Aurora... (talk) 06:48, 5 May 2013 (UTC)
Just check their contributions and decide that the name should comply with all projects where they are frequently contributing. Conflicting user name policies are going to be a problem. English Wikipedia doesn't allow corporate accounts, but I think that there were a couple of cases where archives were allowed to get corporate accounts for uploading images from the archive to Commons, although I don't remember which archives or which user names. --Stefan2 (talk) 23:54, 5 May 2013 (UTC)

┌─────────────────────────────────┘
Another issue is the provision that the user not be blocked on any wiki. En.wp generally uses a "soft" block approach with spammer usernames if their spamming has not been too obnoxious. The idea is to give them the message that we absolutely do not tolerate spamming, but if they pick a new name they can try again to edit in a neutral manner. I don't think the idea of SUL was to force us to change our local policies, so I would suggest that this provision be removed.

It doesn't make sense on its face anyway, I don't know why it was ever put in there in the first place. Why should we refuse to rename a user if they are blocked on one of the many WMF wikis, possibly for issues completely unrelated to their username? Seems like a sort of assumption-of-bad-faith rule. Beeblebrox (talk) 21:57, 6 May 2013 (UTC)

That wasn't the intent, so I've gone ahead and reworded it. MBisanz talk 23:11, 6 May 2013 (UTC)
That's much better. In fact I tried to propose something like that at en.wp a while back but it never got off the ground. A certain user (who you may recall), had done something like six rename and when they got in some trouble nobody put it together at first that between the various names he had been blocked more than thirty times and so people were still talking about giving them another chance, not realizing they had already squandered several dozen second chances. Beeblebrox (talk) 23:54, 7 May 2013 (UTC)

Username blacklists

Hi. There are some wikimedia projects that have migrated from using titleblacklist to an abuse filter (for example pl.wikipedia). Is this also taken into account when creating a tool for verifying compliance with local user name policies? Beau (talk) 08:56, 5 May 2013 (UTC)

It has not. If you know of other wikis that use a similar system, it would help to let us know. MBisanz talk 01:14, 6 May 2013 (UTC)

Hello, let me confirm the procedure

  • Either manually or automatically maintained, there will be a global blacklist which will contain individual unfavorable names (in regex?) which will be rejected to rename.
  • Each local wikis may retain their own local naming rules which may be written in general way: if an account renamed by steward is against a given wiki rule, admin there may block this account and they resolve the issue locally.

Besides that, will the new scheme abolishes local bureaucrats? I understand so, since all accounts will be managed globally. Let me know if I misunderstand something. Cheers, --Aphaia (talk) 22:33, 7 May 2013 (UTC)

  • It won't "abolish" local crats, just remove their technical ability to rename users. They will still retain whatever other abilities the local rules grant them, for example at en.Wikipedia they also perform the technical implementation of granting bot and admin permissions. If there are any projects where renaming was their only function then I suppose they would be obsolete after this month. Local projects will still be able to make their own rules about acceptable usernames but only stewards will be able to rename accounts. Although the idea of a global username policy has come up in some recent discussions there is not one at this time and personally I do not believe it is really feasible or desirable. Beeblebrox (talk) 23:48, 7 May 2013 (UTC)
Ah I see ... just user ability set of b'crat will be changed after changing. Thanks for clarification. --Aphaia (talk) 00:38, 8 May 2013 (UTC)
  • English Wikiquote uses an abuse filter for this purpose: Filter#13 (log). ~ Ningauble (talk) 14:20, 26 August 2014 (UTC)
    @Ningauble: Do you, or you community, have some suggestion or comment that helps guide this policy, or the actions undertaken? Is your filter prevention creation, or editing? If a global rename ignores a local filter, what do you see as the impact? How do you see that your community would view such an action? Is some of your local filter able to be generically reflected in a global naming policy to guide renamers?  — billinghurst sDrewth 01:41, 27 August 2014 (UTC)
    billinghurst, I posted this point of information in response to MBisanz's request above ("If you know of other wikis that use a similar system").

    As a steward you can see for yourself that the above linked filter prevents the action "createaccount" when the account name contains the name of a local administrator, known vandal, or harassed contributor. In the context of renaming, most names appearing in the above linked filter log would be covered by the general policy that frivolous or inappropriate requests will be declined.

    In response to your hypothetical question, if a renamer granted names like "Ningauble, leave me alone." or "Kalki is a quack" (examples from the above linked log) I would take a very dim view of it, and would log a Steward request if it came to my attention. On the other hand, I would be more sanguine if someone unfamiliar with local conditions did not recognize names like "Zarbonosaurus" or "InvisibleDennys" (also from the above linked log) as belonging to patterns of harassment, and might only log a Steward request if we experienced a flood of them.

    Frankly, I would not expect people to use the renaming process for this sort of harassment. Looking farther down the road, as "single unified login" evolves toward "single account, period", if account creation were to become decoupled from the local wiki there it was initiated then this sort of filter might be rendered ineffectual. (As it is now, a vandal can bypass the filter by creating an account name on one wiki for use on another, but the childish or impulsive behavior caught by the filter is not that sophisticated.)

    (Pardon the lateness of my reply. For some reason, your {{ping}} did not generate an Echo notification – probably a passing bug.) ~ Ningauble (talk) 17:42, 15 September 2014 (UTC)

    @Ningauble and Keegan (WMF): So can we summarise these components with global rename as … we need:
    • to prevent too similar a name to existing users (which systematically, I know is being suggested through bugzilla:70380)
    • avoid terms that can suggest harassment (as you suggested covered by naming policy, though we need to d/b check)
    Otherwise, we have a situation if someone did get their name changed, and doesn't work at enWQ, then it isn't problematoc to enWQ, and if their name is really problematic and does sneak through, then they will have to seek a rename, as it won't work. Most users won't fall into these spaces, and we can deal with the problematic accounts if/as they arise. Re the SUL globalisation, they can do that silliness now though now sure how it will work differently later with local wiki MW: config file interplay, and maybe Keegan can answer that, or see how we can have that technically addressed in the respective bugzilla(s).  — billinghurst sDrewth 03:39, 16 September 2014 (UTC)
    I do think the harassment would be covered in the naming policy. As for names that could be construed as too similar, I'm not sure about putting that into the engineering of SUL finalisation. That seems like it needs a human judgement call, but I'll loop in @Deskana (WMF): to be sure since I don't make those decisions, ultimately :) Keegan (WMF) (talk) 17:04, 16 September 2014 (UTC)
    @Keegan (WMF): Just so I'm clear, is the ask here "Make the global rename tool respect both local and global username blacklists"? I want to be sure before I respond. --Dan Garry, Wikimedia Foundation (talk) 21:09, 18 September 2014 (UTC)
    @DGarry (WMF): Ideally I would say all. Hmm, I think that there needs to be an element of determination, and an element of override, though I am also aware of the coding challenges. As stewards already have an override function on certain creation events, might it be worthwhile considering global renames can do if it doesn't hit a blacklist (local or global), and stewards can do if they click an override.

    The issue that I see is identifying which wiki's blacklist is the stumbling block, and investigating, with the blacklist identification being outside of the rename tool (which may just stop and say NO). User:COIBot in IRC has a "findrules" function that interrogates all the spamblacklists, so it may be able to be tweaked or the code provided within stewardbot.

Slightly off-topic because this is not about renaming per se:  In engineering SUL finalization for interplay with local wiki configuration, will there still be a hook to abort account creation in Special:UserLogin that calls the AbuseFilter of the local wiki where login was invoked, or will filters that check action "createaccount" become unsupported? If there is any practical way to continue support for this, I think it would be a good idea. ~ Ningauble (talk) 19:24, 16 September 2014 (UTC)

@Ningauble: To be clear, the SUL finalisation is mainly concerned with resolve any clashing accounts and preventing clashes from ever occurring again. We're not altering the login and account creation process in any significant way (with the notable exception of users who were forcibly renamed to resolve the clashes). So, if I understand what you're asking, there's no reason why anything should function differently after the SUL finalisation in the case you gave. --Dan Garry, Wikimedia Foundation (talk) 21:15, 18 September 2014 (UTC)

Requests for comment discussion

For historical interest. TeleComNasSprVen (talk) 22:03, 18 February 2014 (UTC)

Archived requests for comment discussion that led to the creation of this proposed policy page.

Global rename policy: For the time being, it's only a draft, but since the creation of SUL we do not have an effective global renaming tool (there's an old request on bugzilla about it). This policy will not be the solution, but would really help in bulk requests. --Lucas Nunes 22:23, 12 September 2011 (UTC)

Agree we need the policy, disagree with the opt-in basis. Let's get something here that satisfies everyone, rather than make a solution which doesn't actually solve the problem. Ajraddatz (Talk) 22:26, 12 September 2011 (UTC)
I agree with Ajr. Global means global. We need a tool that works at all wikis that stewards have access to, to help the increasing number of users looking for global renames and such. -- Marco Aurelio 15:23, 16 September 2011 (UTC)
And as for myself I agree with the proposed requirements too. If we want to avoid problems those should be firm and clear, and more strict. -- Marco Aurelio 15:38, 16 September 2011 (UTC)

Global rename policy

The following request for comments is closed. The request was eventually archived as inactive.

We have a solution that can rename users across the wikis. Reopening the RfC. --Jyothis (talk) 19:46, 3 September 2012 (UTC)

Please could you confirm what this solution is? The Helpful One 01:14, 4 September 2012 (UTC)
It is a javascript based solution that perform rename action on every wiki the user has an account on. --Jyothis (talk) 01:55, 4 September 2012 (UTC)
  • Local crats on projects that have them and will be effected by a the global name change should be notified and given an opportunity to weigh in on the change prior to it occurring. The notification would be automated messages to the relevant crat noticeboards. 7 days should be given to respond, if there are objections from regular editors (or crats acting in an unofficial capacity) it should be left to the steward whether the rename should occur. In the event there is an official objection from a crat, the rename should not occur on that project (though may proceed on other projects at steward discretion), and it should be up to the requesting editor to appeal locally. Monty845 (talk) 20:21, 10 September 2012 (UTC)
    And could you please explain us why this bureaucratic overkill should happen? Global accounts should be treated as global entities and hence renamed on a global base. In other webpages accounts are even able to change their names on their own just having to respect law and special policies. Local crats will of course still be able to review these actions and decide whether to disallow editing under this given name. Cheers, —DerHexer (Talk) 18:14, 11 September 2012 (UTC)
Because I think it is important to respect local autonomy. Suppose the editor has an extensive editing history and the new name does clearly violate local policy, perhaps it is highly offensive in the local language, and no one noticed here. Now you have an offensive name plastered all over editing histories, simply blocking locally wont undo that. Its not bureaucratic overkill, its just a notice so that there is a chance for local crats to way in. If they have no objection it doesn't cause much extra work, and if they do have an objection, its important that it be considered. Monty845 (talk) 20:22, 12 September 2012 (UTC)
Your explanation is reasonable but a global name should not cause local problems, imo. Hence, all badwords from all languages should be moved to the global blacklist which should prevent stewards from renaming these accounts (while I still think that if e. g. “love”, “Peter”, etc. would be offensive in only one language we shouldn't disallow the global usage of this word—we are indeed a global movement). So if a renaming caused problems in one wiki, the problem would be addressed on meta, the word either added or rejected and the renaming be made undone. Regarding the bureaucratic overkill I have to make you aware of the current procedure: If one user with hundreds of local accounts requests a global renaming here on metawiki, stewards must tell them to ask hundreds of bureaucrats for renaming these local accounts while these bureaucrats often do not respond, don't care or don't even know how to rename a user (no joke). Not all projects are as well developed as the English Wikipedia (your homewiki) concerning bureacrat work, but all of them, including the larger projects, are part of the global Wikimedia world. Further, developers are working on a global rename tool so that it'd be just a matter of time before this procedure would be implemented anyway. We now could set up this slowly and thoughtful (e. g. with creating such global blacklist) using the JavaScript renaming tool and, hence, would be prepared for the official tool without having to face similar problems to these we had to face when SingleUserLogin was enabled. Isn't that reasonable? Cheers, —DerHexer (Talk) 09:24, 13 September 2012 (UTC)
Shouldn't it be possible to create a bot to automatically notify every Crat noticeboard (or the local equivalent)? In my suggestion, once notified the onus would be on the local crats to come here and object. Other then a waiting period to give them a chance to do so, there should be additional burden on the requesting editor unless there are objections. Monty845 (talk) 15:10, 16 September 2012 (UTC)
Crats on smaller projects do not respond for ages. Not even if you use their user talk pages. Cheers, —DerHexer (Talk) 13:09, 13 October 2012 (UTC)
  • Having a global policy, and tool, is an excellent idea. Following a recent rename on en.wp I've needed to hoover up disused accounts called "Hex" from over a dozen different language Wikipedias; the initial process of finding everywhere I needed to go, and translating my requests into the appropriate languages via Google (which only seemed polite) took several hours to accomplish. Nearly three weeks later, I'm still waiting for the process to complete in some places! Also relevant here is Requests for comment/Usurpation policy on commons, which relates to an extremely unusual rule - unlike on any other Wikimedia wiki I've encountered - being enforced by Commons bureaucrats regarding usurping user names. — Hex (❝?!❞) 10:30, 9 October 2012 (UTC)

┌─────────────────────────────────┘
Ah, okay; I suppose I got the wrong impression from your comment. Well, I think that having a global SUL policy could be a good thing. When I've had a chance for some coffee and a think this morning I'll open an RfC on it. — Hex (❝?!❞) 07:54, 11 October 2012 (UTC)

Done. Please take a look at Requests for comment/Global usurpation policy. Thanks, — Hex (❝?!❞) 09:48, 11 October 2012 (UTC)
  • I personally feel that it makes much more sense for first to fully implement fully the Global account system, that is, switch to a one-global account system and handle the name conflict resolution related to that. Then this policy would no longer be needed as local renames would never exist anymore. Snowolf How can I help? 10:50, 18 October 2012 (UTC)

There's now documentation on the plans for future work on CentralAuth. The short version is that eventually only global accounts will exist; merges will happen at various stages, and owners of left-over unattached accounts whose name conflicts with an existing global account holder will have to rename, either to an existing global account or to a new name. — Hex (❝?!❞) 22:49, 4 January 2013 (UTC)

If you look at the history for that file, you will see that the documentation is from 2006 and that not much has happened since then, so I'm not sure if this still is planned. --Stefan2 (talk) 13:42, 11 March 2013 (UTC)

Update: This process is now planned to begin May 27. See Single User Login finalisation announcement and associated discussion. — Scott • talk 12:24, 1 May 2013 (UTC)

This just got a whole lot more relevant

It seems likely this may heat up a bit soon given that the scenario mentioned above where all renaming for all WMF sites would take place here is actually going to happen less than a month from today.

Right off the top I see a potential problem with the draft policy: that the user not be currently blocked on any WMF site. To begin with I don not know why that should be in the policy at all. Different sites have different policies and behavior that might get you kicked off of one site might be just what they are looking for at another, for example Wikivoyage welcomes and encourages original research and an informal tone, both things that will get you on trouble on Wikipedia. And, at en. Wikipedia anyway, we regularly do "soft" blocks for username issues, giving the user the option to either create an account with a new, non-infringing name or to post an appeal with their suggested new name if they want to keep attribution for their existing edits. This approach has fairly strong support from out local community and i do not believe that meta can or should tell any of the other projects what their username policy is. Clearly, this is a mess made by the WMF, not meta, but it is going to be meta's job to clean up the mess, and I am beginning to suspect it will be a big one as there are so many sites with so many different local username policies. We can't reasonably expect the stewards to be familiar with every single one of them, so what are we going to do? Beeblebrox (talk) 00:41, 1 May 2013 (UTC)

I agree with Beeblebrox's comments above. Also, will there be appointed a lot more stewards representing many more languages, or are you going to request assistance from the various "language communities" in order to e.g. weed out inappropriate names (as mentioned in the proposal), which often requires a near-native language fluency plus cultural knowledge/background? If a rename violates local policy, how will it be revoked? Another worry is that some people are not comfortable with languages other than their native one. I know that these problems must already exist to some degree, but with many large wikis being added to the mix, I fear that difficult renames, and the workload in general, will multiply for the poor stewards. - Kaare (talk) 14:06, 3 May 2013 (UTC)

Update?

So, the new SUL system is now enabled. What is going on with global renames now? Through my own research, I've found that locally renaming a global account just breaks the SUL on the particular wiki. Obviously, this isn't something that we want to have happen, since all of the recent SUL changes were initiated to fix things like this.

I suspect that if we want accounts to become truly global, we need to defer all renaming to stewards and establish a single global account renaming policy. Like Beeblebrox said above, there is the potential for lots of local policies to conflict with global renaming otherwise. While local project sovereignty is important, I think that the benefits of having a functional SUL system should win in this case.

I'd like to hear some input from other people about this. If it is agreed that this is the best way to move forward, I'll draft some sort of global rename policy after researching the policies of the largest wikis, and we'll see how to go from there.

Looks like a draft has already been made, though it lacks a bit of substance. I'll try to add some more onto it.

This discussion probably should have been started prior to the SUL changes being rolled out, but we should try to get this sorted out now at least. Ajraddatz (Talk) 19:08, 17 August 2013 (UTC)

Well, as far as I know, it is planned to remove the renameuser right from bureaucrats and to give stewards the global rename tool (+ keeping the local rename tool to sort out any SUL difficulties!), isn't it?
About the SUL-breaking by renaming, that is certainly true, and has always been like that (there are even warnings when renaming an account that is part of a SUL account etc.). That's why we need the SUL finalization to bring us global rename, in order to stop these problems ;)
The draft at Global rename policy seems good enough to me, except that it was created not with SUL finalization in mind, but with allowing stewards to rename users locally also on projects which have active bureaucrats (as an attempt at getting renamed globally, i.e. on every wiki where your account exists, is currently a very time-consuming task). It seems to me that the main concern is that users could request to be renamed to names which are not allowed on any individual wiki, for whatever reason (swearwords, company names, ...). The solution should be simple: Single projects can still block users with abusive usernames also in the future, so they should just do so and tell the user in question to get a (global) rename. Of course stewards would also not grant rename requests to names they recognize as outright abusive.
Of related interest might be my draft for the re-organization of the global rename request page, which was written in preparation to the initially scheduled SUL finalization date of 27 May, and pretty much abandoned after the finalization got unfortunately postponed. --MF-W 00:57, 19 August 2013 (UTC)
If a user with lots of contributions is renamed to a bad word, then the bad word appears in "action=history" for old edits, even if the user is prevented to make new edits. Reusers can still choose to attribute old posts to the old user name, but it's harder to identify that name after the renaming. I think that it is better to ask the local projects where the user predominantly is active whether the chosen name would be acceptable or not. This also prevents having an unpleasant surprise if the account suddenly is blocked on a project because of the user name. --Stefan2 (talk) 15:23, 19 August 2013 (UTC)
Thanks for the clarification, MF-W! I agree that, with hundreds of languages, stewards can't know all of them... but that is the same with the situation we have now, with stewards doing renames on smaller wikis. Who would know if some username is offensive in an obscure dialect somewhere? If a user has any history of abuse, stewards should consult with local 'crats before doing the rename, but other than that it shouldn't block the moving forward of this. Ajraddatz (Talk) 15:16, 22 August 2013 (UTC)

Technical note: I think this page should be "renamed" (no pun intended) to "Global account rename policy", as we have multiple cases and definitions of "rename" so far presented on this wiki and elsewhere, to contrast with say "renaming" a page or "renaming" a wiki or some other definition of "rename". TeleComNasSprVen (talk) 06:18, 7 February 2014 (UTC)

What bogus is this to transclude an RFC on some talk page? I get pings from it all the time. --MF-W 22:08, 18 February 2014 (UTC)
I'm really sorry. As I explained to Stefan on my talkpage, I had no idea transclusions would cause notifications to be sent out to people in the discussion. It was suggested by Abd, see this diff and this discussion at the bottom of Requests for comment/Global rename policy. I'm wondering if that's a bug? TeleComNasSprVen (talk) 22:13, 18 February 2014 (UTC)
I don't know there is any bug here. The comments have not been specific on just what notifications were seen. The transclusion would produce a notification for everyone who has this page watchlisted. Would it produce a notification from user names transcluded? ("... mentioned you...." If so, that's a tad extreme.... There were other edits to both pages, and transclusion was mentioned, so I'm not certain that this was actually due to transclusion, per se. The page is still transcluded above. It could be replaced with a simple link, one click, just as it is one click to open the collapse... --Abd (talk) 22:44, 18 February 2014 (UTC)
"The transclusion would produce a notification for everyone who has this page watchlisted." Again, you have no idea what you're talking about, because it does not affect everyone who has this page watchlisted. That's different, I do not know why you would reference a feature everyone knows about. Because of the links in the transclusions to certain userpages, the transclusion effect on this talkpage sent out a Special:Notifications to everyone who signed in the RFC discussion. Also bugzilla:50082. TeleComNasSprVen (talk) 22:50, 18 February 2014 (UTC)
I was speculating on a possible cause. "This page" was This page. Placing the transcluded material here would indeed produce such a notification. However, I have now verified that this was not the cause, but it was specifically the behavior that TCNSV has now described, which is not described in the echo documentation, AFAIK, and was not anticipated. It was due to transclusion, the software treats all user names linked in the transcluded discussion as if they were new mentions. Definitely a nuisance. As mentioned, we have other options.
My self-reverted demonstration edit here would have produced all those same notifications, as well. So people got two of them, each. TCNSV got dinged because he repeated it. My apologies, TCNSV. --Abd (talk) 23:09, 18 February 2014 (UTC)
Yes, I got two notifications.[1] --Stefan2 (talk) 23:16, 18 February 2014 (UTC)
I don't see why one would transclude a whole RFC somewhere. Why isn't a link sufficient? (esp. when the RFC had no outcome) --MF-W 23:37, 18 February 2014 (UTC)
I was thinking that if we ever were to have another discussion on 'promoting' this page to policy status for stewards, we could revisit the RFC on this talkpage. There were also some concerns about splitting the location of these discussions, so a merge was suggested (by way of transclusion). I could, however, convert it back into a regular link if you want. TeleComNasSprVen (talk) 23:48, 18 February 2014 (UTC)

Examples

Perhaps setting up a policy would be easier if we had some example requests? They could also be used to test gerrit:92468, see SN. Ideas on how to find users interested in pioneering? --Nemo 11:12, 15 June 2014 (UTC)

To be honest the current draft says nothing but "you can get renamed if you don't want a new name that is super-absurd". I don't know what else such a policy could contain... There are some technical restrictions (like lowercase first letters), but such things can rather be explained on the request page as technical restrictions. --MF-W 11:22, 15 June 2014 (UTC)
I take that as a "yes" :) : if the policy, as simple as it is, is probably already good enough, we can just advertise this possibility and start doing the first renames, then remove the draft and "Outdated!" warnings when dust settles. No? --Nemo 12:51, 15 June 2014 (UTC)
Hmm.. yes? :P --MF-W 15:53, 15 June 2014 (UTC)
I have some comments and suggestions:
  • If one or more accounts need to be usurped before the renaming can take place, the request for renaming should be declined or put on hold until the account(s) have been usurped. If an usurpation policy allows the steward to execute the usurpation, then the steward may choose to do so.
  • Ideally, stewards should confirm that the new user name doesn't violate a user name policy on a project where the user is active. For example, if the user is active on the English-language edition of Wikipedia, then the name should ideally not violate w:WP:U. It may be a good idea to ask users on the project for guidelines before carrying out the rename if the steward is unsure if a name is compliant with policy. If the new name nevertheless violates policy, the project will probably just block the user, but it can be irritating if you for example have to attribute lots of articles to a profane user name.
  • This update only seems to have been mentioned on some obscure pages on Meta, Wikitech, Mediawikiwiki and Gerrit. It should be made more visible, at least to bureaucrats. Someone, for example User:MediaWiki message delivery, should quickly place a note on all bureaucrat noticeboards. --Stefan2 (talk) 20:26, 15 June 2014 (UTC)
About local policies: I wonder if it's worth trying to rationalize some of the odder policies so that projects aren't producing unnecessary problems? Polish Wikiquote, for example, indefs anyone whose username is more than 20 characters long, which would catch some people using their real names, e.g., Hillary Rodham Clinton (22 characters). There are a few surnames in the world that contain more than 20 characters, even without a personal name. Most other wikis reject "too long", but don't define what "too long" means. WhatamIdoing (talk) 21:20, 9 July 2014 (UTC)

Benefit of having a public request

If I understand correctly, requests are not going to be public and will be done in a special page only visible by users with permission of renaming. There won't be help anymore from "non-renamers" users, like is usual in public pages, for instance [2], [3].

In case a name is abusive in a certain language, renamers won't be warned by other users before renaming. Is there a way to reduce this problem?—Teles «Talk to me ˱C L @ S˲» 22:43, 16 August 2014 (UTC)

Perhaps the page could be view-able by all, but ofc only stewards/global renamers could action requests. I certainly would not want to continue using the SRUC page if we didn't need to... the benefits that come with being able to easily request a rename from anywhere instead of needing to go to one confusing page are more than enough (in my mind) to outweigh the cost of not being able to give feedback. Ajraddatz (talk) 22:46, 16 August 2014 (UTC)
I still believe the special page is just for the victims of forced renames after the finalisation? For everything else, using a normal page seems much better as it allows better discussion, e.g. if someone wants an abusive username, or should for some other reason be told to choose a different username. --MF-W 01:37, 17 August 2014 (UTC)
It is a bit confusing, but the email chain suggested that they would initially design the interface for finalization, and then after that re-purpose it to a queue for stewards (and global renamers). Ajraddatz (talk) 02:27, 17 August 2014 (UTC)
In a public request, anyone can warn the steward about the problem with the name or even revert the request. Renamers and stewards will not cover most of the languages and may not be aware of issues related with that.—Teles «Talk to me ˱C L @ S˲» 01:56, 17 September 2014 (UTC)

Technical question

> The new name is not registered on any wiki. (A global rename is not technically possible if there are attached or unattached accounts associated with the target username.)

Is it possible to pick an arbitrary time frame (2 years, for instance) after which, where Y wants to rename to X, if local sufficiently inactive X accounts exist, stewards rename them to X~project by hand, and then let this policy fire for a global rename or Y to X? --Gryllida 14:18, 19 August 2014 (UTC)

When SUL finalization is completed sometime in the next year (hopefully I didn't just jinx it) then there will no longer be conflicting local accounts. Additionally, we can already perform local usurpations to free up usernames for global renaming. I'll add a section about that to the policy; thanks for bringing it up. Ajraddatz (talk) 15:14, 19 August 2014 (UTC)
SUL finalization will most likely take at least 6 months for completion. But we will have it done by early to mid-2015, I'm sure. Cheers, —DerHexer (Talk) 22:53, 19 August 2014 (UTC)

Ready for translation?

PiRSquared17 said this was outdated last year, [4] but now is it ready for translation? whym (talk) 13:48, 26 August 2014 (UTC)

More or less yes, but there are currently discussions whether we should add a section about usurpations. But adding a new section shouldn't prevent us from translating the rest. Cheers, —DerHexer (Talk) 14:05, 26 August 2014 (UTC)
Then could someone please mark it for translation? Otherwise people may start to translate the older version, as this document was publicized crosswiki. (I was about to do that.) whym (talk) 14:29, 26 August 2014 (UTC)
Done. —DerHexer (Talk) 15:05, 26 August 2014 (UTC)
  • Is this policy yet? The page claims it is not.
  • Or should it be translated, reviewed and approved before it becomes policy. But there is a scheduled removal of local crat rename rights September 15. If this is not policy by then, wasn't that a premature announcement? How will local-only accounts be handled? So many questions, so little time. --Abd (talk) 18:27, 26 August 2014 (UTC)
Someone must just name it policy. We can flip coins who'll do that but it should be done asap and will be done before Sept 15 at the latest. Currently, this page contains actual procedures on m:SRUC which will not change soon but might be added by a usurpation clause. Local-only accounts will be globalized during SUL finalisation, and most of them are already. Anyway, until all accounts are global stewards will keep renameuser rights on each wiki so that they can solve local issues if they arise. But usually, a global rename is more appropriate. Cheers, —DerHexer (Talk) 21:04, 26 August 2014 (UTC)

The loss of local autonomy

It's rare, but it does occur, perhaps as often as a few times a year, that a steward enforces a defacto "ban" without a ban process, per global ban policy, and not only for spam and vandalism, and the ability of users to register a local account has been a defense, where, if there is a reaching into the local wiki to block, it may be undone by local administrators, should there be a problem.

As it is, global locks create no local log, and local users may be completely unaware of it, except for the user who no longer can log in or change settings, email, etc.

SUL finalization, requiring all accounts to be global, if that's what is happening, has this been discussed? Until there is a local whitelist for global locks, as there is for global blocks, this change is dangerous. In spite of many requests for it, this feature has had no priority.

The problem is only the automatic globalization, which then makes the account lockable. There is no problem from requiring that a local account not have a globally conflicting name. I think there must be near-complete consensus on that, if not complete. But the fix for that seems to have neglected local autonomy. Is that the case? --Abd (talk) 13:33, 27 August 2014 (UTC)

Globalisation is taking place as per WMF's information to users about how and why, if you don't like that please take the discussion to where it is relevant. Locks should be made according to the respective policy, and where they are made contrary to the policy, or wish to be appealed, then they should be addressed to stewards via the corresponding page, or email address. Your question has nothing to do with the global rename policy, so seems out of place on this page.  — billinghurst sDrewth 23:12, 27 August 2014 (UTC)
Great. I will. What is relevant here is a mention, on this discussion page, of an impact of the change on local autonomy, something that has been very important in the past, which I am not seeing has been discussed. If the WMF is imposing the change, the WMF can legally do that. However, it's like superprotection. Legal, but possibly foolish. This is not for here. I asked if there had been discussion, and I'm not getting an answer. Thanks. --Abd (talk) 23:39, 27 August 2014 (UTC)
There is no relationship between global rename policy, and the issue that you raised. You also know that the place to ask is Wikimedia Forum, and none of us are naive enough to believe that you didn't know that. Your editing behaviour with your little pieces of discord have been addressed to you before, and the innocence act doesn't work.  — billinghurst sDrewth 00:49, 28 August 2014 (UTC)

Talk:Global renamers#Discussion as to length of candidacies

I have started a discussion as to the length of certain global renamer candidacies. --Rschen7754 19:43, 1 September 2014 (UTC)

Local request pages

I have removed the text ...

Requests can also be placed through applicable local request pages, so long as sufficient information is given to process the request.

... which was recently added. I do not see that this is part of the "policy" and is more about operational instruction for GRN. Once someone is at the _policy_ (here on meta), it seems weird to send them back to their home wiki, especially as there may be no global renamers at that wiki, so a request will not be seen to be actioned. The purpose of the approach is more to reflect that if a local request has been made, that we do not need to delete it and send them onto meta to remake the request. If we need to say anything, then it would be a statement that any request that is processed needs to be documented with a permanent link.  — billinghurst sDrewth 23:46, 2 September 2014 (UTC)

The removal doesn't change anything however, because the text says "should be requested through Steward requests/Username changes" (italic added) so local requests are still allowed. (No opinion yet on whether that's a good thing.) --Nemo 10:52, 4 September 2014 (UTC)
I purposefully left it at should. It is a direction to where they should be made, though it gives GRNs the ability to action in other places, and also allows requests to be made and actioned by email.  — billinghurst sDrewth 16:11, 4 September 2014 (UTC)

We should decide what is this policy and what is it for. In case, if it is only for users who would like to request rename on Meta, the global rename policy is only a local policy and the removal was correct. In case if it would like to be a global, general policy, I would keep this or a similar sentence in it for the next months based on this discussion. Samat (talk) 15:03, 4 September 2014 (UTC)

So long as you weren't trying to force everyone to use the basically monolingual and very confusing SRUC page then I'm happy. Your reason for removal makes sense. Ajraddatz (talk) 15:07, 4 September 2014 (UTC)

There is no compelling reason for SRUC to be monolingual. It could have a translatable header and use a translatable request template (where the argument names are translated as well). --Nemo 15:10, 4 September 2014 (UTC)
The header is even already translatable. --MF-W 16:08, 4 September 2014 (UTC)
And depending on how many requests are made, I don't see any issues with having language sections, even if that just makes things easier for managing queues. The SRUC needs to be a functional and usable page for users predominantly, and GRNs secondarily.  — billinghurst sDrewth 16:13, 4 September 2014 (UTC)
Yes it's translatable but not fully, because the boilerplate {{SRUC}} text is forced to English: that's not too hard to fix though. --Nemo 17:50, 4 September 2014 (UTC)
Until the point where we use only support/oppose templates, nobody would like to ask anything, there is no comment or request to the applicant and you (we) can understand the additional explanation of the applicant in any language, it can work. Language barrier is stronger than many of you can imagine, specially in countries where English isn't generally spoken. Samat (talk) 16:04, 4 September 2014 (UTC)
I disagree that we don't understand how important the language barrier is. I've been a global sysop and steward for a combined four years, and have seen the issues that it can cause in action. The language issue is only one problem with the SRUC page; it is generally bulky and not user friendly, and I don't think that much can be done to make it more so while still serving its purpose. But I would very much like this to be a common sense process where we are willing to action any requested rename rather than forcing users to apply from one centralized location. Ajraddatz (talk) 16:09, 4 September 2014 (UTC)
It doesn't matter at all where requests are made. It is just helpful for users who read the policy to know where they can request renames. Therefore, it is helpful to at least include a link to SRUC. We can also add a link to the Index of pages where renaming can be requested (best title ever), once that page is updated to exclude pages nobody able to rename will look at anymore. --MF-W 16:08, 4 September 2014 (UTC)
The text that I have to send out on Monday refers future local renames to SRUC. Please modify the text to a better place, if there is going to be one :) If not I'll stick with SRUC. Thanks! Keegan (WMF) (talk) 22:00, 4 September 2014 (UTC)
@Keegan (WMF): please review this suggested edit and revert or modify as appropriate. –xeno 20:58, 5 September 2014 (UTC)
  • On enwiki, rename requests very often require clerk or bureacrat intervention to ensure the requested name is appropriate. Since it is our local username policy and somewhat zealous enforcement of same that often causes these users to arrive at our local pages for renames, I expect enwiki will continue to process requests at the existing local venues. (Not to mention all the existing pointers in various template, help, and project pages.) –xeno 23:21, 4 September 2014 (UTC)
I removed the part about bureaucrats as the message only will be sent to projects with bureaucrats according to the text at the top of the page. --Stefan2 (talk) 21:19, 5 September 2014 (UTC)
Thanks Stefan2, but xeno was correct in his edit. There may be projects that have bureaucrats that are not/do not become global renamers. If this is the case, they cannot readily continue their local process page. Keegan (WMF) (talk) 21:32, 5 September 2014 (UTC)
In theory projects (especially non-English) might still maintain a localized page to allow users more familiar with English to proxy requests to m:SRUC (as some projects already do now) - at the very least during these transitional stages where not all the translations, etc., are in place. –xeno 22:55, 5 September 2014 (UTC)

@Keegan (WMF): Keep it simple and manage expectations, so to me it is just the mention of SRUC, and that enables good multiple language translations. Xeno has indicated that at least one wiki is looking to add their own local value, which is okay, as long as their approach is aligned with the global goals, and hopefully not forcing their agenda on all wikis. If we advertise too many diverse places, then we get isolated pockets and risk culture shifts, rather than an uniformity of approach.  — billinghurst sDrewth

I would like to request to use the local page on the Hungarian Wikipedia too, as many (most?) of the users can not speak English and not comfortable with a foreign language environment. The process will be align with the global guidelines. I think, it is only a temporary (one year?) solution until the central surface and process will be comfortable for everybody. Honestly, it is not the case even on Commons where we already worked a lot on it. Samat (talk) 07:25, 5 September 2014 (UTC)
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Global_rename_policy/Archives/2014&oldid=15195385"