Requests for comment/Global rename policy

Add links
From Meta, a Wikimedia project coordination wiki

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]

Global rename policy[edit]

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)[reply]

Please could you confirm what this solution is? The Helpful One 01:14, 4 September 2012 (UTC)[reply]
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)[reply]
  • 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)[reply]
    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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

┌─────────────────────────────────┘
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)[reply]

Done. Please take a look at Requests for comment/Global usurpation policy. Thanks, — Hex (❝?!❞) 09:48, 11 October 2012 (UTC)[reply]
  • 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)[reply]

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)[reply]

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)[reply]

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)[reply]

This just got a whole lot more relevant[edit]

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)[reply]

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)[reply]

Update?[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Motion to close[edit]

This RfC was premature in 2011, and is still premature. Discussion of the "draft Global rename policy" stalled; until there is a clear proposed policy draft, an RfC, which would assess global consensus on that proposed policy, is premature. This RfC could only serve to direct attention to the proposed policy page, and it's not working for that any more. It's time to close it without prejudice. The last comment in this RfC was a suggestion that the RfC name was inappropriate. When the ducks are in a row, a new RfC can be filed with an optimal name. Given that the policy will affect the present prerogatives of bureaucrats, it is possible that bureaucrats should be notified, specifically, of the discussion., when the community is ready. There can then be a more focused discussion and a poll assessing consensus. --Abd (talk) 23:42, 12 February 2014 (UTC)[reply]

Restored comment from revision 7471264, based on input from revision 7486105. Please continue the discussion here Abd, and not on the RFC's talkpage, for transparency. TeleComNasSprVen (talk) 03:21, 14 February 2014 (UTC)[reply]

The above was a close comment, the close was reverted with:

(Undo revision 7471264 by Abd (talk) don't see how this is premature; c.f. Global bans was a draft which was discussed and voted into policy, this page ought to receive the same treatment)

This page is not the draft Global rename policy, and this page was started when that page was quite different than it became. Changes from date of RfC opening to now. So early comments in the RfC, to what version of the draft policy do they apply?

Having two places where the same issue is being discussed, Bad Idea. Ideas here may not have been incorporated there, etc.

While the draft is being formed, it is discussed on the attached Talk page. When the proposers are ready, sometimes a policy is then formally approved right there on that Talk page, a site notice may be used to announce it. This proposed policy affects every bureaucrat in the WMF, I'm not convinced that a simple meta RfC is adequate, but maybe. When the draft is deemed ready to go -- then such an RfC may be appropriate.

Reading the page more carefully and reviewing the history, I found that this RfC became inactive in 2011 (though not actually closed). It was "reopened" a year later to propose a script solution.[1]. This was new wine in an old bottle and a good example of why not to do that. The proposal was an implementation detail, and discussed difficulties, not policy per se. The policy draft did not reflect the discussion here.

This should be closed and all effort focused on the draft policy page. The draft policy allows stewards to do global renaming. It is not necessary that they have a specific means of doing that. (But they may not wish to do it if it would be an onerous burden.) If they have the authority to do it, and if the policy clarifies what they can and cannot do, providing procedure (such as local notice of names before final implementation, to cover the possibility of locally offensive names), what was proposed here in the reopening back in September of 2012 would not even need an RfC. It is entirely possible that splitting the discussion into two places impeded the process of approval. --Abd (talk) 04:01, 14 February 2014 (UTC)[reply]

That could be done, but should not be done while this is open. Otherwise the discussion remains forked. This could be closed, and content transcluded to a section on the Talk page.
(An RfC may be indicated, when those participating on the policy page believe the policy is ready for that, but it's far cleaner for it to be a new RfC. Otherwise people attracted to it will need to read through a lot of largely irrelevant, obsolete discussion.)
I have edited the policy talk page, permanent link, showing how I would make the transclusion look after closure here, and self-reverted.[2] If this RfC is closed, my edit there could be reverted back in, and this would be done. The collapse could be removed, but I'd advise against it. --Abd (talk) 16:39, 15 February 2014 (UTC)[reply]
I hadn't thought of transclusion, because we never seem to do that over at en.wp... good idea. I imagine there would need to be some notice on the RfC itself (in a noinclude?) advising people of the RfC's transcluded status? — Scott • talk 17:51, 18 February 2014 (UTC)[reply]
I suggested the RfC be closed first. Yes, a notice can be placed, it might be part of the closing statement, or it could be added later with noinclude.
The problem was created here by having two discussions open at the same time on the same topic. That should preferably be avoided; I'm working on proposed RfC process that would discourage that. Transclusion is better than copying the comments, for sure. Where there is one discussion, then another, simply referencing earlier discussions is fine; that's standard. I'm adding to this a suggestion that where there are such sequential discussions, the new one be referenced on Talk for the old, with explanation in the edit summary, so that everyone who commented in the old discussion gets routine watchlist notification of the issue being reopened. I never thought of that one on Wikipedia, it would have handled the problem of notifying commentors in old AfDs of the new AfDs for the same article. --Abd (talk) 18:31, 18 February 2014 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Requests_for_comment/Global_rename_policy&oldid=24933029"