Talk:Global rename policy/Archives/2014

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
Warning! Please do not post any new comments on this page. This is a discussion archive first created on 01 January 2014, although the comments contained were likely posted before and after this date. See current discussion or the archives index.


  • Might be related: bugzilla:14862. --dferg ☎ talk 19:35, 19 July 2010 (UTC)
    • Definitely seems related. I cross-referenced from a Bugzilla comment. --MZMcBride (talk) 04:54, 4 September 2012 (UTC)
  • It makes complete sense to make this process straightforward and easy, without taking up a lot of the time of people that have volunteered as stewards and bureaucrats. The sooner this is in place, the better! Thanks. Mike Peel (talk) 23:41, 8 August 2012 (UTC)
    • In an ideal world, user renames would be possible in Special:Preferences (think of Facebook or Twitter). But until that can be implemented, I suppose this policy is better than the current situation. I'd really like to see less bureaucracy in the rename process, though. --MZMcBride (talk) 04:54, 4 September 2012 (UTC)

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)

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)


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)
  • Oppose Oppose If a user asks to be renamed to '利用者:男性器' (User:Penis), then who will be around to reject the request? --Stefan2 (talk) 14:25, 17 August 2014 (UTC)
    The same 39 stewards and global renamers that will be answering the request in the first place. We are the ones who catch 99% of the issues with requests anyhow. Ajraddatz (talk) 14:26, 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)
  • SUL finalisation doesn't have anything to do with non-forced renaming of users (the purpose of this policy), so why did you ask your question on this page? Also, reading Global bans#Implementing a global ban, it doesn't matter if the globally banned user is using a global account or not, so the problem additionally seems to be unrelated to SUL finalisation. --Stefan2 (talk) 16:42, 29 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)