Requests for comment/Improve quality of renames

The following request for comments is closed. There is a clear consensus to introduce a waiting period before handling rename and vanish requests that require local knowledge or language familiarity. – DreamRimmer ■ 14:18, 13 November 2025 (UTC)[reply]

Hi all!

While most of readers are not able to see the private renamers queue, I have some concerns about the trend of renames in recent times.

If it's true that until a few years ago the queue was clogged up and a certain backlog was created (even weeks long), today we are at an optimal point from this perspective, the queue is mostly always empty and generally there are always fewer than 15/20 requests waiting (and they remain in this state for a few hours/days).

The renamer's work is however a job that imho must be done with a certain judgment and quality. Speedy renames are often performed by renamers who are not active on the projects in which the user is active, or by renamers who do not speak the language of the user who made the request, and after a very quick check of the user. This leads to a decrease in quality and I opened several threads over the last few years in the renamer ML about this, and each time the problem was solved for a few days, after which the renames were again too quickly processed at the same rate as before (to the point that it's practically impossible to carry out a check on previous renames).

Since renames must not obscure bad behavior, and this does not only include active blocks (even if these are considered as a matter of practice), it's clear that only a user active on the project in which the request is active or who speaks the same language can be aware of such a situation (remember that rename requests arrive in any language), even if renamers and rename are "global".

Personally, therefore, given some situations (I point out this discussion which is public, even if there are several renames that have gone unnoticed - see Special:CentralAuth/딸기바, since in this case the rename was accepted less that 5 minutes after the request, and I can confirm that the original request for vanish was made in Korean) that would have been avoided by waiting for a locally active renamer, I'd like to propose to add this rule for global renamers:

Each request for a rename/vanish can be processed by a renamer who does not speak natively the user's main language and/or is not active on the project in which the requester is most active or has the home wiki, only after 24 hours from the request.

Imho 24 hours is not a huge amount of time, and the backlog will not increase. We must also consider the timezones of the renamers (which may not be active at the time of the request made by a user who speaks the same language) and the fact that we are all volunteers, so I would say that even 48 hours could be fine, but it is certainly necessary that at least 24 hours are waited.

Thanks for your consideration. --Superpes15 (talk) 08:05, 9 October 2025 (UTC)[reply]

Support the 24 hours hold time, also 48 hours would be fine since we are all volunteers. Even though renamers from a project may be active on a Wiki within 24 hours, they might not check the rename queue here in that time.🪶-TΛNBIRUZZΛMΛN (💬) 08:33, 9 October 2025 (UTC)[reply]
Support - long overdue. - -- XXBlackburnXx (talk) 08:49, 9 October 2025 (UTC)[reply]
Support Looks fair. aqurs 🍧 09:49, 9 October 2025 (UTC)[reply]
Support 24 hours. Ternera (talk) 14:17, 9 October 2025 (UTC)[reply]
~~Oppose~~ Neutral Did an SQL check. ~~Users with more than two renames are 3 in 2024, 1 in 2025 and 4 in 2008.~~ There are 6 renamed users that are locked, all from 2015 and 2016.--Snævar (talk) 01:59, 10 October 2025 (UTC) Updated.--Snævar (talk) 15:23, 10 October 2025 (UTC)[reply]
Then your SQL query must be faulty, because I had to unvanish 19 users back in April and re-lock them in the process - not to mention that users who request vanishing and have 0 edits get locked automatically. -- XXBlackburnXx (talk) 05:59, 10 October 2025 (UTC)[reply]
@Snævar: Renames aren't easily reverted, and this happens as a last resort, so regardless, this data has nothing to do with the quality of the renames. Also, your data isn't clear to me. I myself have reversed at least five renames in the last few years (but there are surely more), and I don't understand what kind of research you did about it (to revert a rename, only two renames are enough, and we don't need more than 2). This doesn't change the fact that many renames remain incorrect or are performed without knowledge of local policies. On itwiki, to cite just the example closest to me, there are several renames of users with inappropriate usernames who haven't been unblocked after the rename because they still violated the policy and had to ask another remain (or, worse, remained blocked). Superpes15 (talk) 06:02, 10 October 2025 (UTC)[reply]
I looked only at the user that was renamed from. So, in order to get on my list user A would be moved to user B, back to user A and then to user B or C. We all know what an edit war is, this would be a log war or an action war, because these are actions, not edits. There not being many of those incidents indicates that the original renamer is fine with the new rename. But sure, the need to revert renames of several users, once per renamed user, does also indicate an issue, so struck the first bit of my comment.

While I do agree that superpes15's situation is an issue, I think it is being made into a bigger deal than it is. I find it unlikely that a renamer that does a wrong rename would do one again after being told off on it. Snævar (talk) 15:22, 10 October 2025 (UTC)[reply]

From my own rename log, back when I had the bit: logid 34476629, logid 34253911, logid 33779991, logid 32360589, logid 29725864, logid 26641140. Only two of them are NOT locked as of now, and all of the logs above are after 2017-01-01. So yeah, your 'updated' statement on renamed/locked users are still not accurate. — regards, Revi 12:22, 14 October 2025 (UTC)[reply]

As a ko-N global renamer, I was the first to raise this concern. I've also processed many requests in the queue recently, but after the LTA's vanish request was approved, I've been much more cautious. While I agree that renaming must be handled carefully, It's a bit unfortunate that with the proposed 24-hour rule, there would be fewer situations where I could help.

GRNs are trusted users, and most ordinary requests have been processed without issue. Based on my experience, this restriction would likely cause a backlog of requests, which doesn't seem like an efficient approach.

Here's my alternative suggestion:

For rename requests from users who are blocked on one or more wikis, and
For vanish requests (because they are related to lock),

a renamer who is not active on the user's main wiki may process the request only after 48 hours.

In contrast, ordinary rename requests are rarely approved incorrectly, and even if such a case occurs (of course, renaming is more complex than it appears indeed but) it can be reverted at the renamer's discretion. Regards, 𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 12:25, 10 October 2025 (UTC)[reply]

I suggest replacing the "native" word with "sufficiently proficient". You do not need a native-level understanding of a language to be able to rename users. And more broadly, is this something that happens with all global renamers? If a few users are most responsible for these issues, they should be removed. Leaderboard (talk) 07:02, 12 October 2025 (UTC)[reply]
This issue is not about understanding the language itself. Actually, using machine translation is usually sufficient to grasp the general meaning of a request. The problem here is not a misinterpretation of the request, but rather a lack of awareness of the specific behavioral patterns of a certain LTA.
In the case of Special:CentralAuth/딸기바, the request stated "no longer in use", and since the account had a fair number of edits, the renamer likely believed the vanish request was legitimate and approved it accordingly. However, this should have been handled by someone who was actively involved in that local project. For example, while I understand and (though often awkwardly;;) write in English, I have no knowledge of the behavioral patterns of LTAs on enwiki.
Therefore, my point is that for sensitive cases (like rename requests from blocked users or vanish requests) requests should be handled preferably by a renamer who is active in the relevant project.
And imo, setting "native speaker”" as the practical criterion for defining an "active renamer" in this context is the least error-prone approach. 𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 12:02, 14 October 2025 (UTC)[reply]
@기나ㅏㄴ What I don't like about "native speaker" is that it does not handle cases where a global renamer is not a native speaker but is fluent regardless, and sounds unnecessarily heavy-handed as a result. In other words, this would mean that most global renamers cannot handle English Wikipedia requests without waiting for 24 hours, which I find unnecessary.
Sounds like what might help instead is to make it easier for global renamers to check the relevant pages instead (such as wikipedia:en:WP:LTA)? Leaderboard (talk) 12:41, 14 October 2025 (UTC)[reply]
Not every project have it, and some project (namely the kowiki as the relevant case here) refuse to have it. (kowiki rejected it because community consensus saw it as 'feeding'.) — regards, Revi 14:27, 14 October 2025 (UTC)[reply]
@Revi C. So how does the community know about LTAs? Is it just hearsay, (as I've seen in some wikis) individual users putting subpages of LTAs, or ...? Leaderboard (talk) 15:07, 14 October 2025 (UTC)[reply]
Mostly hearsay and dealing with them with your ~~fist~~ hand. — regards, Revi 15:18, 14 October 2025 (UTC)[reply]

I understand your point. Tbh, I also agree that this limitation might seem inefficient, and I initially intended to express a similar opinion to yours.
However, I think replacing it with "sufficiently proficient" would make the boundary too vague and practically meaningless.
In my view, a rule should be written in a way that leaves as little room for interpretation or dispute as possible.
That's why I suggested keeping the restriction to "native speakers", but applying it only to the specific cases where this issue has been problematic. 𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 16:45, 14 October 2025 (UTC)[reply]
I don't see the problem that you're trying to raise. Yes it leaves the onus to the global renamer and there's always some room for interpretation, but so is arguably the case with "native" speaker. One does not need to be a native speaker (i.e, at CEFR C2) to be able to rename usernames, sorry.

Eg would I meet the requirement for a language like Korean or Chinese or Kannada? Not at all. Will I meet the requirement for English? Yes even if I'm not a "native" speaker. For Dutch? As someone currently between CEFR A2 and B1 (and preparing for the B1 exams), that's where there's some room for interpretation when it comes to "sufficiently proficient". (Also, as I realised, "native speakers" doesn't address whether someone is active on a certain wiki, which seems to be the point you're trying to make anyway?)

The point being most renamers should either easily pass the bar for a certain language, or won't come anywhere close to it. Only in rare cases would one need to formally think about "do I meet it?". Leaderboard (talk) 19:20, 14 October 2025 (UTC)[reply]
I would say A2-B1 is nowhere close to "sufficiently proficient." I'd expect at least B2, and preferably C1-C2 users to ensure they'll be able to have a good understanding of local rename policies. Renamers should ideally refrain renames in communities they are not familiar with (at least for 24 hours as implied) to minimize damage. If they can't wait 24 hours, they should held accountable by local communities when necessary and not rely on translations or expect someone to explain it to them in English. Takipoint123 (talk) 21:00, 15 October 2025 (UTC)[reply]
I agree that I didn't formulate it perfectly, clearly the intention is to limit those who are not active in the projects mainly frequented by the requester, logically I'd expect any user who speaks, for example, Italian natively to be first of all active on an Italian-speaking project, but obviously this does not always happen, so it is certainly very important that the involved renamer should be part, or at least very expert, of that project in which the requester is active to avoid issues. However, I understand the problem of those who come from an external project and want to contribute globally, at the moment I can't find a solution, at least different from the one proposed. I too made a couple of wrong renames and surely if I waited 24 hours this would not have happened... Superpes15 (talk) 19:15, 17 October 2025 (UTC)[reply]
@Superpes15 in that case I think it should read "For the first 24 hours after the request has been placed, the request should only be processed by a renamer who:
has sufficient language proficiency in the requester's home/most active wiki, AND

is active in the requester's home or most active wiki"

This ensures that 1. The person handling the request can understand local norms and policies and 2. Actually is active in that wiki. Clears up a bit of confusion imo Takipoint123 (talk) 20:01, 18 October 2025 (UTC)[reply]
This looks better. I still have some reservations about point 2, and that is because of "the problem of those who come from an external project and want to contribute globally" part (as "active" is undefined). Which is me - my home wiki is not a Wikipedia. Leaderboard (talk) 20:08, 18 October 2025 (UTC)[reply]
Regarding how "active" or "familiar" one is, I believe, should be self-assessed like most other things on Wikimedia projects. Renamers are never required to perform a particular rename, just like administrative tasks. If a renamer does choose to perform a rename, it should be inferred that they know what they are doing and is willing to take accountability for any consequences. Takipoint123 (talk) 19:37, 19 October 2025 (UTC)[reply]
OK that makes sense. Leaderboard (talk) 04:51, 20 October 2025 (UTC)[reply]
Support * Pppery * _{it has begun} 19:51, 14 October 2025 (UTC)[reply]
Support There's 104 global renamers for the work to be spread across. There is no reason why these issues should be happening if the request is properly reviewed, so support. Ferien (talk) 14:36, 15 October 2025 (UTC)[reply]
Support per nom.--Takipoint123 (talk) 21:03, 15 October 2025 (UTC)[reply]
Yet another one, Special:GoToComment/c-Revi_C.-20251019214500-Unlock_Renamed_user_5de0a4e8f3cf9340d1cb8e49c94c2379. Fully support either Superpes15's original proposal or Takipoint123's revised proposal. — regards, Revi 21:52, 19 October 2025 (UTC)[reply]
Support The same situation keeps repeating. 𝓰𝓲𝓷𝓪𝓪𝓷기나ㅏㄴ(T/C) 18:06, 24 October 2025 (UTC)[reply]
Support there's no need to rush renames. Jianhui67^{talk★contribs} 04:33, 25 October 2025 (UTC)[reply]
Thanks for bring this up. —*Youngjin (talk) 11:45, 11 November 2025 (UTC)[reply]