Wikipedia talk:Requested moves/Archive 34

Archive 30

←

Archive 32

Archive 33

Archive 34

Archive 35

Archive 36

Receiving "current page title is invalid" warning

Sorry all, to do this here, but I am unable to place the following move on the main page for some reason. Is anybody able to (i) explain to me my mistake and (ii) carry out the move?

subst:RMassist| Nuala Níc Con Iomaire | Nuala Nic Con Iomaire | reason = incorrect spelling of name as verified by link to Irish Times obituary on page — Preceding unsigned comment added by Jmharve (talk • contribs) 12:18, 15 March 2022 (UTC)

Not sure where exactly you're trying to put this, but it looks like it should work fine, provided it all goes inside {{...}}. Primefac (talk) 12:47, 15 March 2022 (UTC)

Huh. It did work fine, yes. I haven't done anything different from what I tried first time round, but it's worked now! Jmharve (talk) 15:04, 16 March 2022 (UTC)

Request 16 march to backlog, why?

Fano (nationalist movement) → Fano (militia) this discussion went straight to backlog, why? The request to move via Requested moves was done today. Dawit S Gondaria (talk) 23:45, 16 March 2022 (UTC)

This is because the bot in charge of keeping things updated, doesn't understand the date of adding RM templates. It assumes the last date in the first paragraph under the template to be the RM start date, which in this case is was 3 March and thus shown as backlog. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 06:04, 17 March 2022 (UTC)

I've relisted it, the bot will now place it in the 17th March section. Cheers! ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 06:06, 17 March 2022 (UTC)

Backlog notice

I see the backlog notice at the top of the page constantly, and with how many page movers help out with the RM process, I feel like it would read better as This page has a backlog which requires the attention of one or more administrators or page movers. Thoughts? Skarmory (talk • contribs) 23:09, 17 March 2022 (UTC)

The notice is from {{backlog}} which I don't believe can be changed. Plus, as a page mover, I'm not sure it would make much of a difference. Generally speaking, we sign up for that user right because we like to close RMs. Calidum 18:34, 18 March 2022 (UTC)

It can be changed; right now the bot is setting the template to the admin version. I’ll look into this through a code change in the bot soon. 🐶 EpicPupper ^{(he/him | talk)} 22:12, 18 March 2022 (UTC)

Oh, and by the way, I plan on changing it to just “editors” as non-admins/page movers can close RMs. 🐶 EpicPupper ^{(he/him | talk)} 22:18, 18 March 2022 (UTC)

To editor 🐶 EpicPupper: gentle reminder: I would check with editor wbm1058 since that template is drawn by 400+ pages. P.I. Ellsworth - ed. ^put'r there 19:55, 21 March 2022 (UTC)

Hi @Paine Ellsworth! I was proposing a change to how the template is invoked through the bot, not the actual template code. Does this still apply? Thanks! Sorry for the delay, travelling right now and editing on the smart fridge in the hotel. Cheers! 🐶 EpicPupper ^{(he/him | talk)} 04:12, 22 March 2022 (UTC)

Yes, I would think it does apply, 🐶 EpicPupper. First, with respect, I think the admin version should be kept, because certain aspects of page moving are only possible if one has admin or page mover user rights, and for page movers they are actually unbundled admin user rights. While it's true that any editor can close RMs and in some situations can move pages, it is best that these chores be done by experienced editors regardless of their user rights. Secondly, editor wbm1058 is the custodian of the RMCD bot and very likely appreciates it when informed about anything that affects it or is affected by it. Imho, there is nothing broken here; therefore, there is nothing that needs to be "fixed". But that's just me; I could be wrong. P.I. Ellsworth - ed. ^put'r there 10:15, 22 March 2022 (UTC)

Thanks for the clarification. Your logic seems sound; I'll hold off on the changes. Cheers, 🐶 EpicPupper ^{(he/him | talk)} 16:20, 22 March 2022 (UTC)

Page link “move” to correct article title - “The Nymphs” to: “Nymphs (Band)”

Moved to Talk:The Nymphs § Requested move 27 February 2022

13:11, 27 February 2022 (UTC)

Is there an update on this? HandOfKwll (talk) 08:26, 27 March 2022 (UTC)

The RM is still open. Primefac (talk) 08:51, 27 March 2022 (UTC)

Please Rename a Page

Moved to Talk:Orange Romania Communications (diff)

16:34, 29 March 2022 (UTC)

Updating WP:THREEOUTCOMES

Is there any objection to changing "Consensus to not move" under WP:THREEOUTCOMES to "not moved?" The latter is the more commonly used phrasing nowadays and is less of a mouthful. Calidum 23:18, 15 February 2022 (UTC)

Sounds reasonable to me. Colin M (talk) 23:34, 15 February 2022 (UTC)

"Not moved" is ambiguous as it also accurately describes the effect of a "no consensus" closure. How about "consensus against move"? – Uanfala (talk) 23:41, 15 February 2022 (UTC)

I'm not seeing what problem this is solving. "Less of a mouthful" also can mean "less precise". Just plain not-moving-the-article can occur for two pretty different reasons, one being nobody much wanted to move it, the other being because after some vague milling around nobody could decide what to do so nothing was done. I'm not sure that just "not moved" by itself is a sufficiently detailed description for the bolded heading for either case. But maybe I'm wrong, and I'm willing to be convinced. But thanks for asking and bringing it up. It's a reasonable proposition. Herostratus (talk) 02:37, 16 February 2022 (UTC)

I think Calidum's point is that, in practice, when there's consensus against moving, 95% of the time closers summarize this with a bolded "Not moved". It's all well and good to say that what they really should be writing is X, but how are you going to get closers to actually modify their behaviour? It looks like RMCI was edited in 2018 to try to establish "Consensus not to move" as the preferred verbiage over "Not moved", but 4 years later it still doesn't seem to have taken hold. Colin M (talk) 03:30, 16 February 2022 (UTC)

Yes, I would prefer the closing instructions follow what actually happens in practice rather than some theoretically superior wording. Not only is "not moved" the more commonly used term, it's unambiguous in the vast majority of cases. I would also note "not moved" was listed as an alternative to "consensus not to move" until November when it was removed by the one user who seems to raise a stink about this issue [1]. Calidum 16:28, 16 February 2022 (UTC)

• Support. That way it will match the script User:TheTVExpert/rmCloser, which also uses "not moved" to indicate consensus against the move. Vpab15 (talk) 09:59, 16 February 2022 (UTC)
• Also support a revert back to "Not moved". "Consensus to not move" in boldface type is overkill imho, so let's go back to what most closers use anyway. Since there is some ambiguity between "not moved" and "no consensus", I usually close with "Not moved per consensus garnered below," or similar. Maybe we should find a better way to get the correct info about "not moved" out to those editors who close RMs. WP:RMCI is considered by some to be a rather obscure, unvetted page, and yet closers should have a deep understanding of its content and why all those closure requirements should be done. Also, just as an important side note, NONE of the three outcomes need to be in italics. That's just more overkill – imho of course. P.I. Ellsworth - ed. ^put'r there 13:49, 16 February 2022 (UTC)

Support (with caveat) "Not moved" has been used for a while, and is mostly used to indicate with consensus but can be ambiguous I'd suggest that a some advice be added to strongly suggesting the that closing statement impart if their was a consensus or not. Perhaps adding "The close should make clear if there was a firm consensus or not." before the list of options. Ambiguities in closes for "not moved" have regularly ended up at MR. PaleAqua (talk) 17:58, 16 February 2022 (UTC)

• Support. "Not moved" has basically become the de facto standard way of saying "Consensus to not move" in closing a RM discussion for quite some time. It can and should be explicitly stated at WP:THREEOUTCOMES that when a RM is closed as "not moved" that that means there was consensus to not move the article. Rreagan007 (talk) 01:54, 17 February 2022 (UTC)
• Oppose entrenching jargonesque practices. It is a bad practice by RM closers, and makes for poor closing statements for main audience, being non-RM regular editors who edit articles and occasionally browse talk pages. Documenting "what closers use" is not justified if their practice increases barriers. User talk:Paine Ellsworth's points about bold and italics are unimportant, or at least I don't have an opinion. The important point is clarity to a casual, non-RM regular, editor.

Example good close opening sentences are:

* "The result of the discussion below is consensus to not move".

* "The result of the discussion below is consensus to move to New title".

* "The result of the discussion below is no consensus. <Necessarily explanation>".

also fine is

* "Not moved per consensus garnered below, ..."

The shorthand "not moved" is ambiguous about consensus. It is ambiguous about whether there was consensus or not, and much worse, it is ambiguous about whether the closing of the discussion was an exercise in looking for consensus, as opposed to authoritarian decision making, or vote counting, or some technical detail in the closer's further explanation. All regular editors know closing discussions is about finding consensus, but (sources somewhere we could look) the most important editors for Wikipedia in terms of content added are not regular editors, but IPs and editors who nearly never edit talk pages. This broad group of editors should be accommodated by simple closing statements that can be read at face value, at least in the first sentence of the closing statement.

Title changes are perhaps the most important interactions between encultured Wikipedians and drive-by editors, and I have seen plenty of cases where the drive-by editors are somewhat excluded by the opaque nature of titling policy and RM process. WP:RMCI should never lock in sloppy practice that is convenient for closers at the expense of simple clarity, but should encourage best practice. --SmokeyJoe (talk) 03:37, 17 February 2022 (UTC)

I also wonder whether THREE in THREEOUTCOMES is not quite right, as "consensus to move but WP:NOGOODOPTIONS" might be considered not one of the three. SmokeyJoe (talk) 03:45, 17 February 2022 (UTC)

There are sometimes situations in which the three outcomes are combined into four, five, and so on. Multiple proposals where consensus is to move one or two and not move one or two, NOGOODOPTIONS where consensus is to move but there is no consensus where to move, and so on. KISS, or Keep It Simple SmokeyJoe. P.I. Ellsworth - ed. ^put'r there 04:13, 17 February 2022 (UTC)

I consider these cases to be bungled bundles. In a bundled multipage RM all the multiple pages are supposed to have all the same story.

I think we might agree, WP:RMCI is in parts overly BOLDly written? SmokeyJoe (talk) 04:51, 17 February 2022 (UTC)

Yes, and one overly bold edit imho was Not moved to Consensus to not move. Overly bold overkill in more ways than one, again imho. P.I. Ellsworth - ed. ^put'r there 05:10, 17 February 2022 (UTC)

Would you support "Consensus to not move"?

I think "The consensus below is to not move" is better. "Consensus" is found in the discussion; "consensus" is not the declaration of the closer. SmokeyJoe (talk) 05:31, 17 February 2022 (UTC)

For the same reason you suggested we be up front with the page move in the first sentence, e.g. "Moved to new title with no consensus per...", the Moved, Not moved or No consensus should be right up front, the first words in the first sentence. They should be the very first words that readers see. P.I. Ellsworth - ed. ^put'r there 08:40, 17 February 2022 (UTC)

• The main problem is that the premise of the section is wrong. There are not three possible outcomes. Generally, there are only two possible outcomes (per page). A page is either moved or not moved. The section conflates possible reasons for a closer's decision with the decision itself and the closer's consequent action (or lack of action). "No consensus" and "consensus to not move" are two of several possible reasons for an outcome, not an outcome itself. (No consensus, incidentally, can in rare cases be a reason for moving a page back to a recent stable title after an undiscussed move). A closer should state, first, whether the page (or each page, in a multi-move RM) was moved or not moved, and then give their reason for that outcome. It is the act of moving or not moving that is important. The closer's reason for that action is important only if the outcome is challenged, and carries only as much weight as other editors are willing to give it. Station1 (talk) 06:20, 17 February 2022 (UTC)

  Agreed. eg. "The result of the discussion is no consensus for the current title, which means move back to <Old title>, the status quo ante", or to "<Old title>, the first post-stub version, per WP:RETAIN".

  Maybe the section title

  WP:Requested moves/Closing instructions#Three possible outcomes

  should be changed to

  WP:Requested moves/Closing instructions#Write a clear closing statement

  -- SmokeyJoe (talk) 07:19, 17 February 2022 (UTC)

  Yes, I think the three outcomes thing may be overblown anyway. The distinction between no consensus and not moved is really not that big anyway, other than possibly differing lengths of time after which it's "acceptable" to argue the whole thing again. This leads to pointless arguments with closers and sometimes even appeals at MRV, when the actual practical outcome is not in doubt.  — Amakuru (talk) 08:34, 17 February 2022 (UTC)

  • Basically, there are not just two possible outcomes for a move request. Yes, there are two possible outcomes for the page in question, but that does not help closers. When it comes to RMs, there are three possible basic outcomes, just as there have been for several years:
    1. Not moved, which means that there is agreement in the RM to keep the current title,
    2. Moved, which means that there is consensus in the RM to rename the page, and
    3. No consensus, which means that there is no agreement in the RM to either keep the current title or rename it to the proposed title, and this usually results in the page staying with its current title (per previous consensus); however, that is not always the case, because sometimes the previous consensus is for a title that's different from the current title.

That's the cake, and everything else is icing. P.I. Ellsworth - ed. ^put'r there 09:04, 17 February 2022 (UTC)

• Support the original proposal. It is the long-standing tradition to use the three-pronged ("Not moved"/"Moved"/"No consensus") approach as described by Paine. Despite possible ramifications (NOGOODOPTIONS etc.) those should be the first words that readers see, and this page mostly became divorced from practice, which is never a good thing for a process-related page. The attempt to "fix" the wording and acquire "more precision" only resulted in mixed practices and ambiguity as to whether "not moved" exactly means. No such user (talk) 09:30, 17 February 2022 (UTC)
• Reword to "Stay / Don't move" XfD's close with a specific action: Keep, delete, redirect, merge. Not sure how RM came to the verbose "consensus to not move" versus an action like "stay" or "don't move". "Not moved" is the end status, not the closer's action. And "Not moved" could have resulted from a no consensus.—Bagumba (talk) 09:35, 17 February 2022 (UTC)
  • ? "Not moved" could have resulted from a no consensus. So could "Stay / Don't move", eh? "Not moved" has had the meaning of "consensus seen below to keep the current title" for many years here at RM. No matter how they're worded, the three basic outcomes still apply the same as they have for many years. If we try to change them now ("consensus to not move" is a recent change from "not moved") we'll just add to the present confusion. I think No such user nailed it with "The attempt to 'fix' the wording and acquire 'more precision' only resulted in mixed practices and ambiguity..." That is quite descriptive of "instruction creep". P.I. Ellsworth - ed. ^put'r there 10:11, 17 February 2022 (UTC)
    • Ha. Well I'm more used to no consensus in XfDs being closed explicity as "No consensus" and not "Keep". Barring new wording to be more intuitive, I'd defer to whatever was the last stable version.—Bagumba (talk) 10:42, 17 February 2022 (UTC)

      I think the status quo is better, where the closer expresses their decision as a fait accompli rather than as an action. If they say "don't move", this resembles one of the !votes in the discussion, suggesting it is a future course of action, rather than "not moved", which is the final decision in the past tense.  — Amakuru (talk) 12:27, 17 February 2022 (UTC)

      “The closer expresses their decision”? That is very poorly put. Closes are not the decision of the closer. SmokeyJoe (talk) 13:27, 17 February 2022 (UTC)

      In a way you are correct and I agree with you. Technically, the community decides whether or not to rename the page. The community comprises the editors involved in the RM and whatever PAGs (community consensuses) are used to support or oppose the page move. The closer ideally is not involved in that decision. The closer has to make a different kind of decision. The closer decides what the consensus is. The closer must analyze the survey and discussion and decide what the involved editors' combined !votes and rationales "add up to" for the disposition of the page. That's the decision I think Amakuru describes above. What is the consensus? We decide that the consensus is this or that or the other, and whether or not there actually is a consensus. It's kind of like a boxing match where the judges make a decision following each round. The fighters are deciding which punch to make, should I left jab or something else, while the judges assess their performance after each round. Both the fighters and the judges are making decisions, just different kinds of decisions. When I close, I sometimes feel like one of those judges, but instead of two fighters I have a friggin' ten- to thirty-editor melee on my hands. P.I. Ellsworth - ed. ^put'r there 15:07, 17 February 2022 (UTC)

      Paine Ellsworth, that’s exactly right. The closer’s job is to determine whether there is consensus, and, if so, what it is, and express that decision in the closing statement. That decision is what can be challenged by others at MR. —В²C ☎ 16:11, 17 February 2022 (UTC)

• Support - given that this is de facto the way that everyone writes a "consensus not to move" close, it does more harm to omit it from the instructions than to keep it. At least someone who doesn't understand a "not moved" can then find or be pointed in the direction of that instruction. SmokeyJoe, with respect there doesn't seem to be too much support for your strong objection to this and it may be a hill you don't wish to die on at this time. Perhaps in an ideal world we'd "educate" all the closers out there and make them all comply with some other terminology, but that seems like it would be a lot of work for not a huge gain. As noted above, we also have the same issue with "Keep" closes at AFD, since "keep" is the default result there even if there's no consensus.  — Amakuru (talk) 12:24, 17 February 2022 (UTC)

  There are no stakes here for me, this is not a hill with a risk of dying for.

  Clearer closing statements for the non-regulars is for the good of the project, not for me.

  I am surprised at the lack of concern for reducing barriers to newcomers. These instructions inform the script writers that closers use for convenience, so it is not an question of educating closers, but of getting the scripts to write default closes more clearly. The issue seems to be with closers using scripts.

  XfDs are less of an issue because AfDs are not held on article talk pages, and, I’ve never come across Andy XfD closes being criticised for being ambiguous, yet it happens at MRV a fair bit. SmokeyJoe (talk) 13:23, 17 February 2022 (UTC)

  At AfD, it is commonly written “no consensus, which defaults to keep”. The closers there do write for the uninitiated. SmokeyJoe (talk) 13:24, 17 February 2022 (UTC)

  Yeah, I don't disagree with anything you say. It does make life a little harder for newcomers. But the entire RM process can be a little confusing for them anyway - many first-timers think it's their job to close their own requests for example. But realistically we're not going to effect a wholesale change in all of our closers, short of correcting them one by one every time they effect a "Not moved" close. Better to document that it happens than to just have leave newbies wondering why so many closes don't correspond to what's written in the instructions.  — Amakuru (talk) 17:13, 17 February 2022 (UTC)

  A wholesale change will come from consensus here to tell the helper script writers to code for unambiguous statements. SmokeyJoe (talk) 21:32, 17 February 2022 (UTC)

  “Better to document that it happens”? In that case, the documentation needs to be linked from somewhere where the audience is reading. Normal editors do not casually read RMCI.

  An XfD example close is “ The result of the discussion was: Speedy deleted”. The action, in past tense, correctly implies that the action occurred without reference to the discussion below.

  Writing the outcome in a fait accompli past tense does imply that the action was independent of the discussion below. It’s ambiguous, unclear. SmokeyJoe (talk) 00:53, 18 February 2022 (UTC)

• Support. Like in many other social endeavors (law, engineering, science, sports, social media, etc etc) , WP has developed its own terminology. For example, the meaning of “consensus” on WP is distinct from the dictionary definition. We don’t intend the literal dictionary definitions for many of the terms used in discussions about what we do here. This is normal. We need concise ways to convey specific meanings; it’s inefficient to spell it out every time. This is one of those cases. Yes, “not moved” in and of itself conveys literally only that there was no move, not why. In particular, taken literally, it doesn’t indicate whether there was no move due to a lack of “consensus”, or because there was “consensus” for no move. But what we’re saying here is that we’ve adopted the convention in the context of RM discussions that Not moved means there was no consensus to move. Yes, it’s one of many terms newcomers must learn. That’s why we explain it at WP:THREEOUTCOMES. —В²C ☎ 16:05, 17 February 2022 (UTC)

  It’s not reasonable to expect ordinary editors to go to RMCI to understand close jargon. SmokeyJoe (talk) 21:30, 17 February 2022 (UTC)

• Support a return to Not Moved as it is an explicit statement of the RM result and is unambiguous. That said, the reason the page was not moved could be anyone of many. Over the years I’ve closed a lot of RMs and try hard to explain why a page was not moved in the close when it wasn’t just an obvious result. One of the most difficult reasons to sort out is when RM participants have wandered all over the map proposing alternative names to the original request, merges, deletions, etc. Another is when there is strong support for the move by obviously biased editors who think they own the page, but their rationale clearly contravenes WP policies and guidelines. IMHO, policies and guidelines should take precedent in closing decisions. I would also support the removal of the word winner in the second outcome description. It implies an RM is a contest and should be removed.Mike Cline (talk) 16:37, 17 February 2022 (UTC)

  “Not moved” is ambiguous as to whether it is not moved due to no consensus or due to consensus to not move. SmokeyJoe (talk) 21:29, 17 February 2022 (UTC)

  @SmokeyJoe:. Although I understand your belief that “Not Moved” is ambiguous, it is not in the context of the section title. There are only two outcomes of an RM—the page is either moved or it is not. Now that said, there are any number of both simple and complex reasons (rationales) that can be used to justify either of the closing outcomes. If you think about this as a formula there are two approaches. 1) RM+Outcome (there are only two permutations). 2) RM+Outcome+Rationale (the permutations are many). In approach 1, the section title should be “Two Outcomes”. In approach 2, the section title should be something like you suggested before: Writing a closing statement. Obviously approach 1 is the simple approach. Approach 2 is somewhat complex because the rationale for any given close—moved or not moved—is contingent on the content of the discussion, the details of the title and the weight of WP policies and guidelines. A section that outlines all the possible permutations of the potential rationale for a close decision, even if simplified, would indeed be rather long.

Stepping back here, we must consider the purpose of this section. It has been suggested that we need to explain to editors closing rationale. I don’t think that is the purpose of RMCI. It’s purpose to guide closers. If there is a compelling need (doubtful) to explain RM closes to editors, then that is the role of a good essay.Mike Cline (talk) 14:26, 18 February 2022 (UTC)

Sure, Mike, always space for good essays. I might try that.

An example will be your recent close at Talk:Persecution of Kashmiri Shias#Requested move 1 February 2022. On examination, it is a perfectly “correct” close, but an effort is necessary to see that. The closing statement language is phrased beginning like a Supervote. It makes no explicit mention of the discussion until the 22-26th words. Many readers have turned off by then. It would be better if the RMCloser assistant scripts were better phrased. Change “The result of the move request” to “The result of the discussion below”. Emphasise in plain and obvious words that the close is a reading of the discussion, not of the closer’s logic. Provide better example to the new editor closers who evidently misread that standard closing phraseology as consistent with supervoting.

—-

… SmokeyJoe (talk) 02:57, 20 February 2022 (UTC)

@SmokeyJoe: Phasing a close is indeed not the easiest thing, especially when the discussion whether short or long is full of complexity. BUT, that said the one thing I will disagreed with in your statement above is: “ Many readers have turned off by then.” Attributing generalized behavior to readers in a discussion is pure folly and a pet peeve of mine. Are you psychic?? There are 43M register users on WP. What % of those are “readers” of RMs? (No one knows). What % of the % we don’t know fall into your category of “many”? Devining how “readers” and “users” may or may not behave is a poor argument for any guidance change. Mike Cline (talk) 16:27, 20 February 2022 (UTC)

Mike, there’s quite a body of literature on theories of reading and cognition, and on effective writing, but what I think is relevant here is congruent signage. There is a lot of data on how many words people read before moving on, it’s a very big newspaper and internet science. Long sentences hurt the casual reader. Note that here, by reader, I mean inexperienced editor who might be about to start closing RM discussions. My point is that “The consensus in the discussion below is …” is better phrasing for making it clear what the closer’s role is. SmokeyJoe (talk) 21:52, 20 February 2022 (UTC)

Remember: when people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.Neil Gaiman. You should close a dozen or so RMs and show us how it should be done. Mike Cline (talk) 01:05, 21 February 2022 (UTC)

Mike, you are quite justified in noting that I am unqualified and commenting from the peanut gallery.

Do you disagree that closes would be just as easy for the closer, and easier for the beginners, if the scripted default language said, instead of “The result is …” said “The result of the discussion below is …”.

Almost always doesn’t mean always. I never said I know exactly anything. I observe that RM script-assisted phraseology is jargonesque.

I picked your recent example as an excellent close, except solely for the RMhelper scripted language, because it’s form in the opening words match another close being discussed at Wikipedia:Move review#Radio 1 FM (Gambia), a terrible close that begins with the same phrasing. In a sense, the second is like a ridiculous parody of the first. It’s as if the inexperienced closer copies the form of closing by experienced closers, but without enough thought on the need for a close to be a reflection of the discussion they are closing.

If the scripted language made explicit reference, in the opening words, to the discussion below, that alone would prompt new closers to close with a reflection of the discussion below. I think this is a tiny thing that would help some, at least, but the helper script writer is not even in this discussion.

Maybe I can make another formal proposal: The RM closer helper scripts must be listed at THREEOUTCOMES, as an indicator that they have been minimally advertised. Much like is done at WP:DRAFTIFY, at Wikipedia:Drafts#Tools for moving articles to draft space SmokeyJoe (talk) 02:35, 21 February 2022 (UTC)

@SmokeyJoe: - We are at a bit of cross-purposes here. I assumed that the proposal here was about the text of RMCI (the closing guideline), not some scripted tool that helps editors close RMs. Personally, I don’t care what the tool says as long as it is consistent with the RMCI guideline. I don’t use the tool, never have and probably won’t. In fact, I have little confidence that any scripted RM closing tool can deal with the various, and many, permutations of RM closing rationale. Advertising the tool at RMCI is fine, but in IMHO closers, regardless of experience, must be familiar with RMCI and all relevant WP Policies and Guidelines re article titles when making a close. The tool might indeed make things functionally easier, but it is doubtful the tool can be a substitute for RM closing experience and a keen understanding and application of WP Policies and Guidelines.Mike Cline (talk) 10:28, 21 February 2022 (UTC)

• Support. I think Station1 is spot on that the current language conflates at least two distinct things: the action (or outcome) and the reason. And SmokeyJoe's suggestion to rename the section to WP:Requested moves/Closing instructions#Write a clear closing statement is also good. older ≠ wiser 17:01, 17 February 2022 (UTC)
• Oppose - While the proposal is given in good faith, it will not "update" wp:threeoutcomes. Instead, it will conflate the section so thoroughly that it will, in effect, become practically unusable. The problem is that the three possible consensus outcomes that a discussion can produce (consensus for, consensus against, and no consensus) can not be described by any manner attempting to directly relate the result of the requested move with any of the three possible outcomes (for two main reasons). Firstly, because there is no corollary correspondence between the result and the outcomes (several ambiguous examples have already been given in this discussion). And secondly, because every discussion has the potential to produce varying combinations of the three outcomes (including multiples of one or more). Therefore the outcomes and RM result can only be explained by a knowledgeable closer in an effective closing summary that uses appropriate nuance and policy based prose. For example: the closer of a well attended RM discussion to move "C" to "Z" might find consensus against moving to "Z" for BLP inappropriateness; consensus against remaining at "C" for similar BLP concerns; no consensus for or against an alternative title where "D", "E", and "F" emerged as appropriate possibilities, suggestions in the discussion; consensus for a 6 month moratorium on any future RMs for reasons of stability and discussion burnout; and prior, policy based consensus for moving "C" to "A". The closing summary would have to be nuanced, by saying, for example: the result of the RM is moved to "A" without leaving a redirect from "C" and changing all back links from "C" to directly target "A"; with prejudice against refiling an RM to ever move page to "C" or "Z" from any title and consensus to impose a six month moratorium on filing an RMs from "A" after which RMs may be filed without prejudice against requesting "D", "E", or "F". Probabilities like this are not contained in the sentiments resultant from changing "consensus for" to "moved" and "consensus against" to " not moved".— Preceding unsigned comment added by John Cline (talk • contribs) 11:21, 18 February 2022 (UTC)
  • While there certainly are RM discussions requiring the kind of nuanced close explanation you're talking about, and of course closers must do so as appropriate (and lack of closers doing so has not been identified as an issue AFAIK), the vast majority of RMs are straightforward and for those with a "consensus to not move" using Not moved is clear and concise. --В²C ☎ 16:10, 18 February 2022 (UTC)
• Todays Wikipedia:Move_review/Log/2022_February#Radio_1_FM_(Gambia) is another example of bad closing, featuring bad closing statements as encouraged by the bad coockie-cutter default language of the closer script, which takes its cues from the overly simplistic approach of THREEOUTCOMES. Closing is not about minimal categorisation of the close, but well explaining the consensus or lack of in the discussion. THREEOUTCOMES is not good. —SmokeyJoe (talk) 04:02, 19 February 2022 (UTC)

  One of the things I’ve learned in the profession world is Root cause analysis. A personal opinion is that it applies to everything. Someone is unhappy about an RM close. Why? Why? Why? Why? Why? There can be many root causes. One, for sure, is that inexperienced closers are closing contentious RMs with overconfidence due to the oversimplification presented by THREEOUTCOMES and scripts that implement that oversimplification. SmokeyJoe (talk) 05:16, 19 February 2022 (UTC)

  That is one of the worst RM closes I’ve ever seen, and perhaps the most blatant super vote I’ve ever seen. —В²C ☎ 06:52, 19 February 2022 (UTC)

  @SmokeyJoe: - Root Cause - NOT. In this case saying the THREEOUTCOMES was the root cause of a bad close is akin to saying Climate Change caused it to rain yesterday. In this case the closer was clueless and violated the basic Conflict of Interest provisions of RMCI. The closer was INVOLVED. Even if the close had been textually perfect, it would have been a bad close. Got my users mixed up.Mike Cline (talk) 14:04, 19 February 2022 (UTC)

  “the” root cause? Root causes are not singular. — SmokeyJoe (talk) 23:17, 19 February 2022 (UTC)

• Oppose. The point of there being “three outcomes” is that we record for a consensus for, consensus against and no consensus. If we are to change the wording to reflect actions taken then there should only be “two outcomes” (moved and not-moved). In my opinion, action taken should be secondary to the recorded consensus. This also allows for closers to avoid “moved” when they don’t have access to move the page. — HTGS (talk) 23:56, 21 February 2022 (UTC)
• Support. 13,098 search results for not moved, vs 217 for consensus to not move. In my opinion, our wikipedia space pages should accurately document current practices. –Novem Linguae (talk) 04:21, 3 March 2022 (UTC)

  It's a corrupt data set upon which you (and apparently others) rely. {{RM top}} has but one field and the closing statement builds off of it in the following manner: "The result of the move request was: {{{result}}} ~~~~. It doesn't have a field for the discussion's outcome and only the most creative closer/template editor can figure out how to squeeze it in through the single parameter. And now, after the result of the move request was entered 13,098 times, it is used to mean the outcome of the discussion? Only on Wikipedia could such a bike shed be built.--John Cline (talk) 10:16, 3 March 2022 (UTC)

  Huh?! From the fact that the template only has one free-text argument, how does it follow that it's somehow a "corrupt data set"? I don't know how Novem Linguae got their result, but I suppose it's rather simple to search for exact strings that start with "The result of the move request was:" and then parse the results. Offhand, I'm inclined to believe those numbers, since "consensus to not move" and "consensus not to move" are indeed rarely used wordings. No such user (talk) 17:46, 3 March 2022 (UTC)

  Harsh words, friend. Here's the search links if you'd like to improve them. [2][3] –Novem Linguae (talk) 19:36, 3 March 2022 (UTC)

  Some of us use our own template to close RMs, John. In mine, I can begin the first sentence with anything I want. I got the idea to begin with "Not moved, and so on, from BD2412 long ago. It makes sense to be as "up front" as possible with the outcome, to begin the first sentence with the exact outcome. Helps posterity, as SmokeyJoe pointed out. P.I. Ellsworth - ed. ^put'r there 01:54, 4 March 2022 (UTC)

  This is purely an aside, but, as mentioned previously, the template you use does not show up at all in mobile view. That portion of posterity using cell phones sees an archived discussion but has no idea how the RM was closed, why it was closed that way, or who closed it. Station1 (talk) 18:23, 5 March 2022 (UTC)

  Didn't know that. Are edit histories available in mobile view? My edit summaries are always crystal clear, although not perfectly precise. P.I. Ellsworth - ed. ^put'r there 04:13, 6 March 2022 (UTC)

  Yes, there is a link to page history at the bottom of each page, but if an edit summary is more than a few words, only the first few words show unless you open up that particular edit. Station1 (talk) 08:55, 6 March 2022 (UTC)

  The devs are working on solutions to many accessibility issues in mobile view, so hopefully, this type of issue will be fixed soon. P.I. Ellsworth - ed. ^put'r there 05:53, 7 March 2022 (UTC)

  To editor Station1: an application of {{If mobile}} is being tested at Talk:Noddy (character)#Requested move 19 February 2022. If you find that to be better in mobile view, I'll try to adapt that in my personal RM closure code and perhaps in {{subst:Requested move/end}}, as well. Let me know. P.I. Ellsworth - ed. ^put'r there 06:44, 7 March 2022 (UTC)

  @Paine Ellsworth: Yes, that looks fine. The only thing that doesn't show are the two arrows and what's below the line in the box: "Links..." and "This is template...", which are probably not important to most mobile readers. Station1 (talk) 07:29, 7 March 2022 (UTC)

  I am not a fan of that closing template. I think it is gaudy, too many colours, too much bold, too much markup, too attention grabbing for something that is now closed. Flashy gaudy colours would be better used on the *active* RM.

  The Bold “ It was proposed in this section that multiple pages be renamed and moved.” is unimportant and distracting. The cartoon arrows are confusing, do they indicate a page swap? What’s the meaning of the blue vs red?

  The small RESULT: is great, as is the statement of the result upfront and the explicit references to consensus, with qualifications (fairly rough, firmer). Closers constantly making explicit reference to consensus in the discussion is good for letting prospective closers know that the closer reads, not decides, the result.

  —- SmokeyJoe (talk) 09:20, 7 March 2022 (UTC)

  The {{subst:requested move/end}} closing template is just an extension of the {{requested move/dated}} template and uses the same formats for the arrows image and the clear statement of "what" was moved to "what". It's been around nearly as long as I have and I've been using it for several years. I consider it to be a more visual separation of the close from the RM, ergo the closer from the involved participants. So I would rather make it more accessible than discard it just because it lacks a strong fandom base. A big plus imho are the move log links; also good for posterity, methinks. P.I. Ellsworth - ed. ^put'r there 00:05, 8 March 2022 (UTC)

  Something being around for a long time is very weak support if it’s the first thing to say. It is a good separator of the closer from the nominator and discussion, yes. I don’t suggest discarding, maybe shrink the arrows and decolorise? Get rid of the bold “It was proposed …” or at least drop the bold formatting. Excessive bold text. How does one find the move log links? Sometimes I find them from the logs link in the page history, but often not. Could the template use, or script that runs it, also add a link to the discussion from the edit summary? SmokeyJoe (talk) 02:37, 8 March 2022 (UTC)

  To editor SmokeyJoe: the bold typeface has been reduced and the image has been changed to (File:Wikipedia page mover.svg) in template {{Requested move/end}}. Since the template is substituted, the changes will only be seen in forthcoming closures. I often add links to the discussions in my edit summaries when I rename pages. Don't know how to make a template do that, and I don't use any script, just a personal template I have on my workpage that I copy and paste to the RMs I close. Wish I could be more help! P.I. Ellsworth - ed. ^put'r there 23:31, 8 March 2022 (UTC)

• Support "Not moved". I have been closing move discussions for over fifteen years. There is a reason that I have arrived at the practice that I employ. A good close states the outcome, and then explains it to the extent that an explanation is necessary. What constitutes "consensus" is tricky, but most often what we have is either a clear consensus or a clear absence of consensus. Now, a narrow absence of consensus is just as much an absence of that necessary component as an overwhelming opposition to the move. There is no ambiguity in saying that the outcome is that the page was not moved if the result of the discussion was that the page was not moved. BD2412 T 02:17, 4 March 2022 (UTC)

  The ambiguity comes when an inexperienced closer copies your style, and it is not clear whether they have read and understood the participants arguments, or whether the inexperienced editor has supervoted. SmokeyJoe (talk) 10:18, 7 March 2022 (UTC)

• As many of those participating in this discussion know, I am not active at the moment, but I have done closes for fifteen years as well. I don't think it would be beneficial to mandate particular wordings on closes, and the page in question is a supplemental explanation rather than a guideline. Complaints that a particular closer did not follow specific bolded phrasing are usually counterproductive. Speaking specifically to BD2412's reply above, when an editor is being strident or appears inclined to bludgeon the process, "consensus not to move" works as a clear indication that the topic does not need to be raised again in the near future. But to single out particular cases by writing that only rarely seems a bit confrontational to me, so traditionally I have used "consensus not to move" much more frequently than this explanation would indicate. BD2412 is completely correct that there is no problem at all if the close states the outcome and explains it sufficiently. Dekimasuよ! 01:51, 16 March 2022 (UTC)
• oppose I tried to read through entire discussion, but tl;dr, just skimmed it. Like Dekimasu said right above this comment: the page in question is a supplemental explanation rather than a guideline. I also think it would not be beneficial to mandate particular wordings on closes. I do use different wording once in a while special:diff/1059126724, ranging from moved, consensus against move, consensus not to move, and a few. I think the closing vocabulary shouldnt be templated. That is, the closing person can choose his wording according to the discussion to be closed. Talking about the wording of "three outcomes", I believe we should not use "not moved". In short, keep "Consensus to not move" on the page, but use whatever you seem fit. I dont know about any closing script, but from the discussion here I think its the wrong way to approach it. The wording of the script should be updated, not the other way around. —usernamekiran (talk) 10:34, 3 April 2022 (UTC)

Simplifying wikilinks following establishment of a new primary topic

I just closed an RM which established a ptopic for Shillelagh. There are a lot of wikilinks across the project of the form [[Shillelagh (club)|Shillelagh]]. As part of the post-move cleanup, would it be acceptable to do an AWB run to simplify these wikilinks to just [[Shillelagh]]? This seems like an improvement in that it simplifies the page source as well as Special:WhatLinksHere/Shillelagh. But I wanted to confirm, because I know some people can get tetchy about "cosmetic" edits. Colin M (talk) 20:46, 18 April 2022 (UTC)

I will note that WP:NOTBROKEN is a guideline. The WP:COSMETICBOT policy says that While this policy applies only to bots, human editors should also follow this guidance if making such changes in a bot-like manner., which I feel includes AWB runs. 🐶 EpicPupper ^{(he/him | talk)} 21:07, 18 April 2022 (UTC)

I don't think these are the sorts of edits WP:NOTBROKEN is trying to discourage. NOTBROKEN advises against replacing [[redirect]] with [[target|redirect]] - i.e. inserting unnecessary pipes which "make the article more difficult to read in page source form" and impede use of the "what links here" tool. The changes I'm describing have precisely the opposite effect. Colin M (talk) 21:11, 18 April 2022 (UTC)

Apart from DAB pages, hatnotes, templates, See also and articles that specifically reference the article title like "Index of X" articles the links should generally not be bypassed. Crouch, Swale (talk) 21:47, 18 April 2022 (UTC)

I would qualify those as cosmetic and unnecessary. I'm not particularly tetchy about "cosmetic" edits, but cleaning up minor pollutions in wikicode is really low on the list of priorities and pollutes other stuff, such as article history and peoples' watchlists. Besides, should we change our mind one day and decide that "Shillelagh" is ambiguous still (e.g. because of a new hot Netflix series with that title), we will have to re-disambiguate links.
Personally, after a move I check and retarget links only for situations outlined in WP:BRINT, particularly #1 (links from navigation templates) and #4 (on dab pages). No such user (talk) 08:15, 20 April 2022 (UTC)

I would think of it this way: those links will never be broken due to being too specific, but a different discussion in the future could decide that there is no primary topic for the term after all. In such a case, the links would all have to be fixed again, manually. In my opinion, that sort of foreseeable outcome is sufficient reason to leave these sorts of links the way they are. Dekimasuよ! 08:52, 20 April 2022 (UTC)

Proposal to modify current practice.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I intend to propose a modification to our current practice regarding the completion of uncontested technical move requests. This will be the WP:RFCBEFORE phase, to determine if interest exists and to gather suggestions for developing a formal RfC in the near future. While any interested editor is welcome, and their participation: appreciated, I am specifically requesting the most active contributors at Wikipedia:Requested moves/Technical requests to please consider the proposal and append their valued insight regarding that consideration. The 25 most active contributors are: Anthony Appleyard, Ammarpad, Lennart97, Crouch, Swale, TheAafi, GeoffreyT2000, Kj cheetham, Frayae, DrVogel, JJMC89, Ahecht, Alex 21, Nnadigoodluck, BarrelProof, Dicklyon, 162 etc., JE98, Station1, Sam Sailor, 2pou. In ictu oculi, Amakuru, Jack Frost, Buidhe, and Richard3120. In a nutshell, I am proposing that we begin to move the completed "uncontroversial requests" to a new section on the newly created moved talk page (for local handling and archival control) instead of just removing them from our project page unto relative obscurity. Such a change better aligns with our current practice regarding contested requests and significantly enhances transparency of the work that we do. While implementing this proposal will not right a longstanding wrong, or inspire utopian ways, it's not pointless change with nothing to solve or unbearable creep in disguise. It is, in my opinion, a simple change adopting a slightly better practice that arguably should have been handled this way all along. And there is a reasonable likelihood of positive collateral benefits in effecting this change as editors begin to see examples of actual "uncontroversial" requests; perhaps gaining knowledge to avoid poor-filings that generate controversy. If there is interest in this proposal, I intend to begin sandbox testing modifications to {{RMassist}}'s /core and /preload parameters to automate much of this, like currently is done. Thank you for considering this, best regards and be well.--John Cline (talk) 05:54, 3 April 2022 (UTC)

Opinion survey RM/TR

• Support archiving is rarely bad (t · c) buidhe 06:03, 3 April 2022 (UTC)
• Support, I think, but I'm puzzled by "a section of the newly created talk page" – you mean a new section on the moved talk page? Also, some technicals might be for other than articles, in which case maybe there's not a corresponding talk page (e.g. if the technical is to move a talk page to sync to an article). Dicklyon (talk) 06:24, 3 April 2022 (UTC)

  Yes, thank you for pointing out the confusing verbage; you parsed it correctly and I am going to refactor it using your better structure. Also thank you for reminding me that technical requests do come in many forms; that's precisely why I asked the most active contributors to participate and earnestly hoped that they would. Thank you again. --John Cline (talk) 06:49, 3 April 2022 (UTC)

• Support. Current practice makes it hard to work out what happened previously at RM/TR. Archives are good. Please make the archive size large, to make it easier to search the archives. --SmokeyJoe (talk) 06:32, 3 April 2022 (UTC)
• Weak support the archiving idea (archive as subpages of current RMTR page, preferably by year & month, for easy searching). Oppose the idea to move RMTR archives to a talk page. Not a fan of archiving cross-namespace. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 07:46, 3 April 2022 (UTC)
• Oppose moving to talk page. Technical requests are simply for moves that a user can't make themselves, there is no reason to archive in a new location since everything is already there in the history with the request already copied into the move edit summary. I would suggest only requests which have been queried or are contested need to be archived, but again I really don't see it as necessary because if a move is strongly contested it will go to discussion anyway! Polyamorph (talk) 08:10, 3 April 2022 (UTC)
• Weak oppose these are similar to WP:AIV and WP:UAA and a link is provided in the move log for those moved and the discussion is moved to the talk for those that get contested. The only benefit I can think of is that people may submit a request that gets contested and withdraw it and later make it again which could be seen in the archive but unless people checked the archive it probably wouldn't make much difference. Crouch, Swale (talk) 09:01, 3 April 2022 (UTC)

  Thank you for your reply Crouch, Swale; I agree with everything you have said, yet, however, to opposite conclusions. While I agree that our practices resemble the AIV/UAA model, I conclude that they should probably be archiving request threads too (I believe that they should). Regarding the permalink in the move summary, if it reflected the "request thread" as of the move's timestamp instead of the request's filing timestamp, I would be satisfied with its adequacy. As it stands, you can not review the permalink, in summary, and know if clarifying discussion ensued or not and this inability, in my opinion, adversely affects the adequacy of the link overall. And while I can't know if the RM/TR archives will be used extensively, often, or at all, I do know that it's better to have an unused archive than to have need for an archive that doesn't exist. I respect your weak opposition and post this rebuttal, not to badger, but to hopefully gain your equal respect for my support. With esteemed regards. --John Cline (talk) 03:42, 4 April 2022 (UTC)

• Weak support No inherent objections, and tracability is a good thing in principle, but not convinced how useful it would be in practice. The archives being easy to search would be critical. -Kj cheetham (talk) 11:19, 3 April 2022 (UTC)

  Searching archives isn't very difficult. Notice the search box I recently added at meta:Steward requests/Permissions#See also. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 12:41, 3 April 2022 (UTC)

• Support: AfD, CfD and TfD all have searchable archives, and I probably would find something similar useful sometimes to see if a previous move has taken place, and the reasons for it. Richard3120 (talk) 14:11, 3 April 2022 (UTC)

  Don't forget https://wiki.riteme.site/wiki/Special:Log?type=move exists for checking for previous move actions too, and can be fairly easily found from individual pages via "Page"/"Pages logs..."/"Move log" if needed. -Kj cheetham (talk) 14:39, 3 April 2022 (UTC)

  I agree, with the caveat that logs quickly swell and move actions beyond the 500 entry max that a search will accommodate, often requiring multiple search attempts and/or advanced search prowess (that mainstream editors tend not to possess) which can become overly cumbersome in very short order. Best regards. --John Cline (talk) 19:13, 3 April 2022 (UTC)

  But if people are interested in the move history log for the page they are currently on, it's fairly trivial to get to that, and I've never personally seen any single article log be anywhere near 500 entries. -Kj cheetham (talk) 17:33, 5 April 2022 (UTC)

  You are, again, correct and I agree. I'll even go as far as stipulating that every conceivable scenario that one could use to demonstrate the benefit of a centralized archive could be countered with an alternative approach proving to be just as if not even more -effective. For example (as you probably know) the external tools available in "page information" are quite useful as well. If it were mine to prioritize, I'd give preference to a consistent, structured use of {{old moves}} on the moved talkpage and changing the permalink in the move summary from linking to the request's filing to one that linked to the discussion as it existed when the edit summary was first used. If need be, I'd forgo an archive entirely if in exchange for those two. Best regards. --John Cline (talk) 05:33, 6 April 2022 (UTC)

  I wouldn't object to either of those changes, though the {{old moves}} template documentation would need some tweaking for the latter, and some kind of automation for the former. -Kj cheetham (talk) 07:56, 6 April 2022 (UTC) P.S. and consideration of edit summaries in scripts like pageswap. -Kj cheetham (talk) 16:07, 6 April 2022 (UTC)

• Weak oppose I would support moving any move requests that had actual discussion to the target talk page, the same way we do for contested move requests (for example, when there is a request for clarification, it is answered, and the page is moved without being contested). However, I would oppose doing it for simple requests, as the full text of the request is already listed in the move log, and archiving it is unnecessary work. --Ahecht (TALK
  PAGE) 19:18, 3 April 2022 (UTC)

  I do not disagree, and had considered proposing the change precisely as you described. As opinions are favoring an archive centralized to the RM/TR project subpage, I can envision such a centralized archival structure with the proviso that only requests that have generated discussion beyond the permalink diff would require additional handling (i.e. copied over to the relevant talk page or, perhaps, updating the permalink). Anyway, thanks for your reply.--John Cline (talk) 19:44, 3 April 2022 (UTC)

• Sounds reasonable to me. I like the idea of making move history more transparent. Is it worth considering the possibility of using a template along the lines of {{old moves}} rather than a talk page section? Colin M (talk) 21:12, 3 April 2022 (UTC)

  I agree with you that {{Old moves}} should be considered for possible use. Thanks for mentioning it.--John Cline (talk) 07:22, 4 April 2022 (UTC)

• Support – I will agree to keeping a record of technical requested moves, however I do think we need to split the records by month so any future pages created for the matter do not overflow. JE98 (talk) 02:02, 4 April 2022 (UTC)

  I don't foresee any problem with formatting an archive this way. I know there are examples of other project pages that use such a cycle. The only unknown is weather or not a single archive page can contain a month of activity without becoming too large. I'll certainly reaserch the matter and follow that cycle if possible.--John Cline (talk)`

  Support having a centralized record of the moves processed through RMTR. Currently there is a "race condition", where if you're interested in reviewing RMTR requests to see if they are reasonable, you're in a speed contest with the people who are processing them. Please note that I'm advocating a centralized record, not notices put on the moved articles' talk pages which are scattered all around Wikipedia and not just the ability to search for what happened to some individual article. That might be desirable too, but isn't as useful as being able to see what happened via RMTR across all articles. Thus, what I am advocating may be somewhat different from what was proposed. Is there currently any record of RMTR requests (other than doing diffs of the history of edits to the RMTR page itself, which is not so readable)? —⁠ ⁠BarrelProof (talk) 15:14, 13 April 2022 (UTC)

• Support: I always wanted something like that for the RMT. However, we might want set up a bot for archiving because manual work is tooo muuuuch. Nonetheless, I agree. ─ The Aafī on Mobile ^(talk) 05:35, 4 April 2022 (UTC)

  Yes, I agree that a bot may be the way to go. I'll be looking in to that, for sure.--John Cline (talk) 07:22, 4 April 2022 (UTC)

• I agree we should make it easier for people to figure why a page was moved, because having to search through the page history can be time consuming. Like Colin, I think a template like {{old moves}} might make more sense. Calidum 14:38, 4 April 2022 (UTC)
• Weak support. Unlikely to be terribly useful, but traceability and search capabilities are good things in principle. No such user (talk) 09:33, 6 April 2022 (UTC)
• Support if I'm understanding the proposal correctly. I've seen too many so-called uncontested moves that that are actually debatable (or even likely unpopular). There are so many things that slip by us... we're busy. Anything to help would be good... I'm actually of the mind that "uncontested" should be removed. There's usually no hurry to make changes to Wikipedia; and as long as the proper redirects are in place, article titles aren't usually a huge problem. If nobody votes at the RM, the closer can close it as "accepted, because not contested". I don't really think this would take any more closer time. Herostratus (talk) 16:33, 6 April 2022 (UTC)
• Neutral - I don't have a problem with it, but like Kj cheetham pointed out, there is also the move log to check, and I typically check a history of both the current and target page to see what's been happening. If implemented, though, I would really like to see some form of script automation to handle this automatically. -2pou (talk) 17:03, 6 April 2022 (UTC)
• Support. I would want to see the specifics ironed out prior to a RfC, but generally I support any change that will make what happens at WP:RM/TR more transparent and accessible. Specifically, the ability to monitor and object to requests needs improvement (see my comment in the second section below). Mdewman6 (talk) 01:26, 8 April 2022 (UTC)
• Oppose This is pointless; page moves are already recorded in the history so redundantly recording it on the talk page accomplishes nothing. * Pppery * _{it has begun...} 14:15, 9 April 2022 (UTC)
• Oppose. These are technical implementations of moves that would normally be performed without any mention on the talk pages, and the summary of what change was made is readily available in the page logs. If an uncontested move turns out to have been inappropriate, the change will be discovered and reversed on the basis of objections to it. I rather fear that logging an extra talk page section would be taken as evidence that the change enjoyed consensus at the time of its implementation, which is not always the case. Dekimasuよ! 15:24, 9 April 2022 (UTC)

  thank you for your participation. Your's is an important concern and though I hadn't considered this before, I've adopted your concern and will factor it in to any proposal that may proceed from here. Thanks again and be well. --John Cline (talk) 00:34, 10 April 2022 (UTC)

• Oppose. Uncontroversial technical requests shouldn't be treated any differently from regular moves, and anyone who is curious about past moves of a page must consult the move log regardless. Ruбlov (talk • contribs) 16:01, 9 April 2022 (UTC)
• oppose unnecessary. RMTR is a request, not a discussion. If they contest the move, they should go to RMCM where it discuss on talk page and will archive the move discussion. Hhkohh (talk) 16:47, 9 April 2022 (UTC)
  • If you just archive all move request, why not use bot to wikify this? Hhkohh (talk) 16:50, 9 April 2022 (UTC)

    Redundant duplication was never the goal of this proposal. Something complementary that adds value was; some good ideas have emerged so I am pleased about that. --John Cline (talk) 01:21, 10 April 2022 (UTC)

General discussion RM/TR

• I think either I'm misunderstanding the proposal or SmokeyJoe, CX_Zoom, and Richard3120 are. I'm assuming that you are proposing that if you move A to B, that you then archive the move request to Talk:B, similar to how the "discuss" link works currently. There wouldn't be a new searchable archive page, right? --Ahecht (TALK
  PAGE) 16:03, 3 April 2022 (UTC)

  Ah, now I think I (we) got it wrong. A clarification from John Cline would be appreciated. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 16:10, 3 April 2022 (UTC)

  I was assuming it wouldn't go to Talk:B, but a more centralised place. Clarification would indeed be welcome. -Kj cheetham (talk) 16:39, 3 April 2022 (UTC)

  Thanks for asking this of me. First, let me say that the proposal, as I envisioned it, is not carved in stone and when better ideas are presented in the discussion, I'm the first person that would rather see it incorporated than to behold an imagined constraint that doesn't exist. Flexibility is the precise reason that I didn't file this as a full-fledged RfC. The nexus of the proposal was my discontent with removing these actioned requests without a structured disposition. Without elaborating on the suggestion I proposed, I'll instead recognize that the knowledgeable opinions others are putting forth seem to favor a centralized archival system and I am convinced that there is plenty of merit for such an approach (I wish I would of had the foresight to of had proposed things along those lines, but I, nevertheless, expect the end product to have a centralized archive at it's core.) I hope this is a helpful reply, apologize if it is not, and pray that the discussion continues so as to achieve the best possible end. I sincerely thank everyone who has responded so far and have not seen a reply yet that hasn't added relevance to this discussion; please continue. And know this: "I am not going to discount any replies; hoping to accommodate and allay all concerns. And I'm not going to take steps, unilaterally, to implement change"; at minimum, I will consult with admin Appleyard before implementing any change. Sincerely.--John Cline (talk) 18:20, 3 April 2022 (UTC)

  I would suggest you to run this through an WP:RFC, not simply consulting an admin whose opinion is no more or less valid than any other user. As it is I was left out from the mass ping, there will be other users who will have valuable insight you don't want to miss. Polyamorph (talk) 07:33, 4 April 2022 (UTC)

  That's fine, I've repurposed this discussion as the WP:RFCBEFORE phase and I'll initiate a formal RfC in the near future. No slight was intended in the manner of choosing the 25 contributors who were pinged. I am glad that you found this discussion without having been pinged and do appreciate your participation. You will get a message when the formal RfC begins because I am going to message everyone who participated here. Regarding my comment about admin Appleyard: I didn't express myself well and for certain, was misunderstood. I apologize to anyone who took offence by it; I never meant to offend. Sincerely. --John Cline (talk) 16:30, 4 April 2022 (UTC)

• I have two primary concerns regarding RM/TR:
  • Can we consider a mechanism (via templates or otherwise) where affected pages can be notified of impending moves at TR, so that users watchlisting these pages can have a chance at contesting them before the moves are executed? Or perhaps there is a strategy for doing this already that I am unaware of? To my knowledge, it seems nearly impossible to contest a TR request before it happens.
  • Is it common/expected that page movers working at TR do some basic checking to see if the request is actually uncontroversial (i.e. not potentially controversial), such as looking for past moves or RMs at the affected page and/or looking at the history of the redirect in the way before executing the request? Or are page movers in these cases mere agents facilitating the requester's bold move, and are not expected to exercise any discretion?

As I've summarized on my user page and described in a conversation with Colin M, many requests brought to TR are potentially controversial and should go through the normal RM process. In my view, we need to improve how we identify controversial and potentially controversial requests that appear at TR. Mdewman6 (talk) 01:26, 8 April 2022 (UTC)

Good comments, interesting, valid, and worthwhile points. I'll comment further after work. Thank you and best regards. --John Cline (talk) 10:48, 8 April 2022 (UTC)

I would hope that the philosophy you describe on your user page is more or less the approach most use before fulfilling a TR. I can only speak for myself, but I agree with all of what you listed in the RM/TR bullet point. How is this enforced? I don't think that it's super explicit, but it would seem to be a combination of multiple steps leading to the ability to fulfill requests at the RM/TR page in the first place. Essentially:

• In order to fulfill the requests, you must be a page mover.
• To become a page mover, at WP:PERM/PM, the Wikipedia:Page mover#Guidelines for granting are listed as prereqs.
• experience with moving pages in accordance with guidelines should include WP:MOVE, WP:PCM, and WP:RMCLOSE
• Per WP:MOVE, WP:BEFOREMOVING should be followed before carrying out the technical request. (This may be the most implicit step.)
  • This includes an evaluation per WP:PCM by 1) taking an impartial view on behalf of others to see if someone may object and 2) checking the move history of each page (current and target) and any RM history that led to the current title.
• If you are willing to handle a TR, you should also be willing to handle the WP:POSTMOVE cleanup.

I believe that "contesting" a TR, is mainly the page movers or admins believing that one of the check for a WP:PCM has failed or is too close to call and needs discussion. A contestation of a page watcher would in effect be handled by said watcher returning to RM/TR and requesting to revert an undiscussed move. -2pou (talk) 20:10, 8 April 2022 (UTC)

I agree with everything 2pou has replied to you. In furtherance, regarding the mechanism for talk page notifications of impending technical move requests, as stated: it creates a paradox where the self-evident belief that others might wish to contest the technical move request precludes the RM/TR process thereby. For this reason, the RM/TR instructions actually say: "Please do not edit the article's talk page. --John Cline (talk) 11:31, 9 April 2022 (UTC)

I also agree with 2pou. RM/TR has processes beyond blindly moving most things that get requested. I also wanted to add for when mistakes are made, there is the process to revert undiscussed moves. -Kj cheetham (talk) 13:27, 9 April 2022 (UTC)

Thanks all for your responses. It is good to know that there is some expectation that page movers/admins working at TR should be briefly reviewing the requests in light of WP:PCM and not just blindly moving pages. Unfortunately, that has not always been the case in my experience. My pointed views on the matter arise from two occasions where pages were moved at TR even though I had just moved them months prior to bring the pages in line with chemistry naming conventions and per consensus reached at WikiProject Chemicals, with detailed edit summaries to that effect being among the most recent edits of the page. A recent move for a defensible reason would definitely make a new move request 'potentially controversial' and never should have been moved at TR. I put more blame on the page movers in these cases than the mistaken users who requested the move; page movers should know better. I understand you can contest moves after the fact, and in the cases above the pages were swapped back after discussion with the requestor and page mover, but that just creates more work for everyone, messy edit history, and quite a bit of unnecessary commotion involving 3 editors over what started as a well-intentioned but incorrect request. It would be much better if we could stave off inappropriate technical requests before they are executed by sending them over to RM where the best page title can be worked out via discussion prior to any moves. Moves at TR are not simple moves and WP:BRD just can't apply in such cases. If users can't reasonably have a chance at objecting to a request prior to being answered, we must trust the page movers to use discretion when addressing the requests. Mdewman6 (talk) 00:37, 10 April 2022 (UTC)

I admit this immediately made me feel slightly defensive, as someone who has looked at the RM/TR most days in the last couple of years, and it looks like you are blaming people rather than processes for what sounds like anecdotal evidence for isolated incidents, rather than evidence of a more systematic problem. We do not want to introduce additional WP:BURO without good reason. Mistakes happen, and I'd say if the majority of requests processed at RM/TR are ok we're doing a good job. I am sorry to hear you experienced issues regarding two moves, and I hope that doesn't happen again. Most moves at TR are simple moves though, including swaps. My proposal would be to add some text and links for additional guidance on the WP:RM/TR page as part of continious improvement, but nothing further than that. -Kj cheetham (talk) 10:16, 10 April 2022 (UTC) P.S. TRs are not always mainspace article moves, for example sometimes it's a request to move a talk page that got separated from a main article, or to fix a mistake which resulted in a redirect accidently being created and wanting to avoid deleting it via the CSD route which needs an admin. -Kj cheetham (talk) 10:59, 10 April 2022 (UTC)

It was not my intention to offend anyone or come across as having ill will toward those performing moves at TR, so for that I apologize. I just wanted to raise the issue and ensure my expectations were the norm and that the experiences I described were not, and see if there are ways we might improve how TR operates. Mdewman6 (talk) 00:03, 12 April 2022 (UTC)

I agree here firmly with Kj cheetham. No evidence has been provided to indicate a systematic issue here. Polyamorph (talk) 07:34, 22 April 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

No one reviewing my request

Kindly review my page move request, I am waiting from 2 days but no one is reviewing it. 103.141.159.74 (talk) 07:48, 26 April 2022 (UTC)

Please be patient. As you can see in the section above this one, there are backlogs that sometimes take time to process. Primefac (talk) 09:44, 26 April 2022 (UTC)

move log

Hello. Currently, if page ABC is moved to XYZ, then no move is shown in the log history of XYZ. It shown in the plain history though. But it gets sort of difficult to find the if the page has big history. Is this some sort of software limitation/issue, or is it intentional? —usernamekiran (talk) 13:47, 13 May 2022 (UTC)

It is a software limitation. It is in the community wishlist (see meta:Community_Wishlist_Survey_2022/Miscellaneous/Enhanced_Move_Logs), so it might get fixed soon. A tip: talk pages in general have fewer edits, so it is easier to find the move entry there. Vpab15 (talk) 16:02, 13 May 2022 (UTC)

I use User:Nardog/MoveHistory to view an article's move history. Ruбlov (talk • contribs) 17:10, 13 May 2022 (UTC)

thanks folks —usernamekiran (talk) 21:47, 15 May 2022 (UTC)

Missing from list?

I've been just a navigator there with no opinion. Talk:Ukrainian Insurgent Army war against Russian occupation#Requested move 30 April 2022 seems to be missing from this list? It's sort of dead/moot (even people who supported it have switched to "oppose" just to get rid of the old RM) and the discussion has successfully progressed elsewhere, but this old open RM is blocking progress. Sincerely, North8000 (talk) 01:29, 19 May 2022 (UTC)

Whether spurred by this comment or not, the discussion was closed about 40 minutes after you posted here. Primefac (talk) 07:27, 19 May 2022 (UTC)

Moratoria

Hey all,

Is there any restriction anywhere on Wikipedia of the ability of a closer to impose a moratorium on future moves? Downsides to moratoria:

1. Worst case (when imposed in a supervote closing) they transform a mere supervote into a complete lockdown of the ability of the community to move a page, thereby circumventing our best defense against supervotes
2. They can be inappropriate when names are in the process of changing. If we reject a move request since "sources don't call it that yet" but then sources decisively change shortly thereafter, it can end up being a very bad thing to have a moratorium
3. In the case of a terrible nomination, moratoria can unintentionally cause essentially a strawman. Take the following example: in April, Alice proposes for car to move to automobile and says "move it because automobile is a fancier name and we're a fancy encyclopedia". The contentious discussion cites no sources and goes nowhere and Bob closes it and places a moratorium on future move requests from car to automobile. In June, Carol notices that Google News results show a clear preference for "automobile" and wants to propose a move based on common name. Why should Alice's terrible move request stop Carol's attempt to help us find the best title?

There are a few situations where I've seen moratoria be good. What are some restrictions or guidelines we can place regarding them? Red Slash 19:34, 18 May 2022 (UTC)

This doesn't seem to be a problem, and we need to be wary of WP:CREEP. Of the three situations mentioned above, all would certainly be bad, but I'm not aware of any of them ever having happened. Any closer can suggest a moratorium but they are rarely invoked because they are rarely useful and never binding. At the same time, there's a general understanding that, absent changing or unusual circumstances, similar RMs should not be re-proposed for at least several months. In unusual cases where that does happen, such RMs are usually shot down fairly quickly anyway. Station1 (talk) 21:07, 18 May 2022 (UTC)

The second one is literally happening right now at Talk:Port Elizabeth. This isn't hypothetical. Red Slash 20:40, 19 May 2022 (UTC)

Yes, that is an unusual case, but it's debatable whether the close of the 30 Sept 2021 RM (not visible on mobile devices) was "imposing a moratorium" or was advice based on the discussion. The closer wrote that "The longer editors wait before trying again, the more likely that they might be successful", which is probably true, and that the wait should be a year or "editors can fully expect that the move request will not be granted", which, as it turns out, might or might not also be valid advice. But even if the close is read as imposing a moratorium, it has been ignored, since a spirited discussion is occurring right now. Should the closer have mentioned anything even hinting that a year should pass, since that is affecting the current discussion to some degree? I don't think you'd find consensus one way or the other on that question, making it difficult to come up with a guideline. Station1 (talk) 07:48, 20 May 2022 (UTC)

I think it was clearly a suggestion and not a definite moratorium. Given that there had been three requested moves (plus a malformed one) within a six-month period, I don't think such a suggestion was out of line although six months may have been a more appropriate suggested waiting period. As for the current RM, any oppose vote citing solely the moratorium (which, again, is not a moratorium) should be discounted by whoever closes it. -- Vaulter 18:44, 20 May 2022 (UTC)

The only time I've imposed a moratorium it was because it had been explicitly discussed and had community consensus. I think it's generally a bad idea to impose one in other circumstances. But even without a moratorium in place, it can be appropriate to speedily close an RM which simply tries to reargue a recent RM, without introducing any new facts or policy arguments. Colin M (talk) 21:35, 18 May 2022 (UTC)

• WP:MORATORIUM. BD2412 T 21:25, 19 May 2022 (UTC)

autoconfirmed move request

hi can someone move Jules Mutebusi to Jules Mutebutsi please. The article uses Mutebutsi constantly throughout so the title should reflect that 207.194.236.26 (talk) 15:25, 30 May 2022 (UTC)

 Not done. There's a good case to be made that the article text, not the title, should be changed. Three of the four sources cited use "Mutebusi". In the future, if you believe a move would be uncontroversial, make your request at WP:RM#TR. Controversial requests should use the WP:RM#CM process. Firefangledfeathers (talk / contribs) 15:33, 30 May 2022 (UTC)

Size of RM backlog over time

Number of active RMs over time

The same data, colored by age of discussion.

I've had a vague feeling that the RM backlog has been growing over time, and decided to see if the data would support this hunch. Though the data is spiky, I think the plots on the right show a general trend of an increasing number of active discussions over time. The current record of 299 active discussions was set earlier this month. Eyeballing the second (stacked) chart, it seems to me that the number of old discussions is increasing at a disproportionate rate. For example, let's compare numbers from today with a day 5 years ago:

• Number of RMs less than 1 week old: 115 today vs. 54 5 years ago
• 1-2 weeks old: 46 vs. 26
• 2-3 weeks: 48 vs. 8
• 3-4 weeks: 29 vs. 3
• >4 weeks: 39 vs. 2

The cause of this trend isn't obvious to me. Are we being more liberal about relisting? Are there not enough participants in RM discussions recently? Not enough closers? But I thought folks here might be interested in this data. It would be interesting to see how this compares to backlogs at other venues like AfD, if anyone happens to know any stats on that. Colin M (talk) 19:45, 22 April 2022 (UTC)

I think this is (in some part) a result of increased workload. The fact is that the number of RMs less than a week old is more than double than what was 5 years ago (115 vs 54). The number of RMs in 1–2 week bracket doesn't concern me either as it resembles the double workload. But, number of 2+ week RMs is far higher than expected. I think there's an issue, but don't really know where exactly to pinpoint it. —CX Zoom[he/him] ^{(let's talk • C • L)} 21:56, 22 April 2022 (UTC)

There are also a lot of RMs for which the discussions are really poorly structured, making them difficult to close. Obvious outcomes get closed quickly, but a discussion with very little input, bad arguments, and/or participants going many different directions, tend to linger. I think we can resolve that with a rule that basically says that unless there is a determination that there is a consensus to move within some "x" period of time (say, within eight days of the last relisting), the discussion will automatically be closed as not moved. Then we set a bot to the task of closing those discussions. BD2412 T 22:44, 22 April 2022 (UTC)

I agree. But when the problem is "participants going many different directions", the closes could sometimes indicate which of the options seem viable. Johnbod (talk) 02:28, 23 April 2022 (UTC)

Change “could” to “should”, even “must”. Anyone might think they can close “no consensus”, but a good close summarises the discussion, no consensus discussions are the hardest to summarise. SmokeyJoe (talk) 04:14, 8 June 2022 (UTC)

While there may be several contributors, I do know that I have seen discussions with 2-3 relists more frequently. -2pou (talk) 02:44, 23 April 2022 (UTC)

The number of relists is way up. There are currently 101 relisted discussions. Two years ago the number of relisted discussions was in the 70s and two years before that it was in the 20s! Calidum 21:28, 23 April 2022 (UTC)

Discussions under 7 days would be better removed from the graphic. All discussions do well to be listed 7 days. Unless the cause of the larger number of old discussions is the larger number of discussions.

Yes, relisting is too liberal. Comment-free relisting does nothing useful, and is a problem because it shuffles the order making systematic review more difficult, and probably stops meaningful relists.

Comment-free relisting should be discouraged. Relists should come with an explanation for why it is being relisted, usually with a re-focusing comment, or pinging earlier participants to let them know about substantive new information or arguments. SmokeyJoe (talk) 01:46, 24 April 2022 (UTC)

Discouraging comment-free relisting would be a good idea. I believe it would also be a good idea to automatically close RM's as "no consensus" if they have been open for more than a month. BilledMammal (talk) 14:45, 25 April 2022 (UTC)

I think a comment-free relist is fine if there's been zero to say three votes, but otherwise it's probably unnecessary. Calidum 14:58, 25 April 2022 (UTC)

I don't think a rule of automatically closing old RMs as No Consensus would be beneficial. Some month-old discussions do have consensus for (or against) a move, but they linger in the backlog because they're cases where assessing and summarizing consensus is difficult, for one of a variety of reasons - for example, it may be a WP:NOGOODOPTIONS scenario, or a case where the side with the stronger policy-based arguments is a numerical minority. Colin M (talk) 15:08, 25 April 2022 (UTC)

Agreed - once you have a backlog, almost by definition quite clear closes can linger on unclosed. Johnbod (talk) 15:13, 25 April 2022 (UTC)

We can add a functionality to {{XfD relist}}, so that it also works for RMs. Alternatively, we may fork a new template from it, as I did here, to easily allow adding notes, if desired. Functionality may be added to RMcloser script. Note that, current relisting technique might have to stay parallely, because RMCD bot relies on it. —CX Zoom[he/him] ^{(let's talk • C • L)} 15:29, 25 April 2022 (UTC)

• From my point of view, one of the reasons is the combativeness of people who dispute potentially controversial closes, building on the complex, ill-structured discussions noted above. My recent "wikiaway" was due to editors who were IRATE about a close that I did that they didn't think was reasonable; not limited to moves but inclusive across all things that need closing. Just one of those can turn a regular closer into someone who doesn't want to touch anything remotely controversial going forward. Sure, call me a snowflake, but there are some who are fine with regular threats to de-sysop 'cause and others who are not. A lot of those long running backlog items have entrenched folks who will throw abuse if it's not closed how they think it should be. --User:Ceyockey (talk to me) 18:21, 25 April 2022 (UTC)

Hiya @Colin M! How did you generate these graphs? Cheers, 🐶 EpicPupper ^{(he/him | talk)} 16:43, 27 April 2022 (UTC)

@EpicPupper: I wrote a Python script to walk through the revision history of Wikipedia:Requested moves/Current discussions (table) and grab structured data about the size of the backlog at the beginning of each day going back to May 2017. The visualizations are also done in Python. I pushed the code and data to GitHub here if you're interested in playing with it. You should be able to just reuse the data from the included csv file rather than having to rerun the scraping code, unless you want to get more recent data from the last week or two. As a sidenote, if anyone was interested in data from earlier than 2017, the history of WP:RMC goes all the way back to 2009, but parsing out the relevant data is slightly trickier, which is why I used WP:RMTABLE instead. Colin M (talk) 15:19, 2 May 2022 (UTC)

Sometimes I do not understand the obvious hesitance to just close as "no consensus". Take Talk:Discord_(software)#Requested_move_2_March_2022 as an example. It has been relisted effectively three times, and judging by the dates, has been relisted even more times in practice. There is clearly no obvious consensus to move. Is it really that important to finetune the closing argument? Why not simply close as no consensus - I'm sure in a year or two the move will be requested again. (I would do this close myself had I realized how old the discussion was. I didn't, and so I instead offered my not-vote, which makes me ineligible) The argument against automatic non consensus closure after a certain point in time, that it could be that there IS consensus for a move, I find weak. That a move that actually has consensus doesn't get carried out is not the worst thing in the world. A renewed request could later point to the earlier discussion, and get the move carried out expediently. CapnZapp (talk) 05:38, 10 May 2022 (UTC)

In light of my comments (immediately above) I support suggestions that a) limit the number of relists and b) sets up a bot to auto-close as "no consensus" after a given time. It would solve all your backlog woes with nearly no casualties. CapnZapp (talk) 05:40, 10 May 2022 (UTC)

Specifically, even relisting more than once should be discouraged without good reason (and "its just not clear yet" is not a good reason. "Discussion remains vigorous and heated" is just about the only reason to hold off decision-time, and that is almost never the case with relistings in practice), and relisting twice should be the maximum allowed. The suggestion (previously suggested above) to have 30 days as the grace period before a request is automatically closed as "no consensus" feels appropriate, and I see no reason for a longer period (heck even after 14 days a backlogged discussion will exceedingly likely just languish until someone finally has mercy on it). CapnZapp (talk) 05:47, 10 May 2022 (UTC)

Yeah, having been away from RM for a few years I was surprised to see how often things get relisted 2+ times now. No consensus is a perfectly valid close. Galobtter (pingó mió) 20:39, 16 May 2022 (UTC)

Put another way, many discussions would reach a clear outcome more quickly if an additional opinion rather than an additional relisting was added to the discussion. Dekimasuよ! 03:54, 8 June 2022 (UTC)

3 weeks later

Out of curiosity, I reran the numbers just now. The total backlog size has decreased almost monotonically over the last three weeks. We had 277 open discussions when I started this thread, and today we're at 205. Almost all of this is due to a reduction in the number of old discussions - the number of discussions more than 2 weeks old went from 116 down to 58. The average age of an open discussion right now is 10.8 days, which is the lowest it's been in months. Thanks to all the closers who have helped chip away at the backlog! Colin M (talk) 17:55, 15 May 2022 (UTC)

@Colin M: dont mention it :-) I hope I could give more time to RM, but currently mrwiki takes a lot of my time. —usernamekiran (talk) 21:41, 15 May 2022 (UTC) that was supposed to be humour. I closed like 5 to 10 RMs, tops. —usernamekiran (talk) 15:44, 17 May 2022 (UTC)

6(ish) weeks later

And the back log is back. That was fun while it lasted. -- Vaulter 20:39, 11 June 2022 (UTC)

Semi-protected edit request on 25 June 2022

Under Uncontroversial technical requests please add

• Talk:Tehrik-i-Taliban Pakistan/Archive 1 → Talk:Pakistani Taliban/Archive 1. This is because Talk:Tehrik-i-Taliban Pakistan was moved, but its archive page was not.

Thank you. 2001:BB6:4713:4858:55B4:7AF:6396:5B29 (talk) — Preceding undated comment added 10:23, 25 June 2022

 Note: Thanks for pointing that out. No need to add at RMTR as I've already moved. But please note that you can also edit the "Uncontroversial technical requests page" at WP:RM/TR. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:52, 25 June 2022 (UTC)

Reinstated close after self-rev

Sorry to create work for someone, but I closed a move request at Talk:Channel 3 (Thai TV channel)#Requested move 28 June 2022 as uncontroversial yesterday. It turned out not to be uncontroversial, so I reverted my close and moved the page back. The original error was mine in interpreting the move as uncontroversial instead of letting discussion proceed, so I apologize for that. However, the editor who requested the move immediately reinstated my close and re-performed the move. I am not able to handle this now, so if someone could evaluate the situation with an eye to letting the discussion proceed as necessary, it would be much appreciated. Dekimasuよ! 02:49, 29 June 2022 (UTC)

Hi @Dekimasu:. I have moved the page back to its original location as a controversial undiscussed move and restored the RM discussion. Cheers Polyamorph (talk) 04:15, 29 June 2022 (UTC)

RM not appearing

I listed History of the Jews in Kingston upon Hull for RM, however it is not appearing on the page. I've never done an RM before, so can someone check that it is listed correctly? JML1148 (talk) 00:15, 2 July 2022 (UTC)

Nevermind, the RM decided to appear - I was being impatient. JML1148 (talk) 00:29, 2 July 2022 (UTC)

No admin instructions?

I don't frequent this page, but I became aware of a requested move that required an administrator, and I completed the move. Being a nice guy, I thought I'd come here and mark the request done so that someone else doesn't waste their time figuring out that I already did it. But, I could find no instructions anywhere on what an admin or pagemover is supposed to do when they've completed a request. Do you add a comment like  Done? Do you just delete the section? What's the norm here? It would help to add some brief instructions at the top of the page. Thanks. (For what it's worth, I just deleted the section for the requested move that I handled; if that wasn't the right thing to do, please let me know.) —⁠ScottyWong⁠— 20:56, 2 July 2022 (UTC)

For technical requests, the usual process is to just remove the section after doing the move, which I think is what you did. I agree it would be good to have some instructions on the page. Vpab15 (talk) 21:30, 2 July 2022 (UTC)

@Scottywong: The instructions are at Wikipedia:Requested moves/Closing instructions and you should be broadly familiar with those instructions before you become active closing requested moves. In the lead it says "Requests listed in the technical requests section can be simply removed after they have been processed." – wbm1058 (talk) 00:51, 3 July 2022 (UTC)

@Wbm1058: Thanks, that helps. It looks like there are some links to those instructions on the page too, I must have missed them. Disregard. —⁠ScottyWong⁠— 02:08, 3 July 2022 (UTC)

Editing that supports or oppose the rationale of a move

I would observe that, in the course of a move cycle, the status quo ante of an article may have direct bearing on the rationale of the move and on the views that might be expressed by editors during the formal phase of an RM. I would propose that during an RM, as a matter of principle, an article should reflect the status quo ante with respect to matters which relate to an RM under discussion (reasonably construed). My rationale is as follows.

These issues became apparent during Talk:Indus Valley civilisation#Requested move 8 June 2022. An RM/TR was made and immediately prior, edits were made that addressed inconsistencies in the article here. Those inconsistencies reasonably instigated the RM/TR. A TR was required. The article was moved, the move was contested as undiscussed and reverted. The RM was then initiated at 15.03 by the proposer. Shortly before, the article was edited by EditorA to restore the proposer's initial edits plus some other inconsistencies. EditorB removed other inconsistencies. The proposer then reverted to the status quo ante before their initial edits. An edit war then ensued.

The edit-warring has been dealt with and my purpose is not to revisit that particular issue but to improve the way we do things. The initial edits by the proposer and, by EditorA and EditorB either directly or closely related to the rationale of the move and were considered in the RM. For myself, I found the state of the article at the time I viewed it inconsistent wrt statements made in the RM and like. It was only by tracing back through the various edits to establish the status quo ante that matters became clear. I believe that WP generally and the RM process specifically would have been better served if EditorA had only restored the status quo ante and EditorB had not made their edit at all. This would have better served editors commenting at the RM and have averted the edit war.

For discussion. Cinderella157 (talk) 12:17, 23 June 2022 (UTC)

Might I suggest that in such cases, a link to the version at the time of the move request (what you call the status quo ante), should be added to the request using the oldid template? That way the perceived reason for the request will be easily accessible. The current version will already be linked. 2001:BB6:4713:4858:55B4:7AF:6396:5B29 (talk) 10:40, 25 June 2022 (UTC)

That could work in some circumstances but it assumes a fore knowledge of the discussion and then, who did what when (before, during or after the fact), who knows what has been done when and ultimately whether everybody is aware of these machinations in the course of the discussion. Sounds a bit like "Who's on third base?" I know, but that is the point. Furthermore, editors should not edit-war over how their preferred version of the article should look and perhaps we should avert that. Cinderella157 (talk) 11:06, 25 June 2022 (UTC)

If I understand the issue correctly, then paraphrased: We should discourage (in some manner) article edits during an RM discussion designed to influence the outcome of the discussion. There is a simple solution to that issue, if indeed it needs one. Simply make it standard practice to apply full edit protection to the article while the RM is open. I am sure the RM bot can do that—add it when the RM is listed and remove it when the RM is closed. Whether that is something the community might want to consider is another thing entirely. Mike Cline (talk) 14:28, 25 June 2022 (UTC)

Sounds like a good idea. There would have to be some kind of provision for implementing critical changes quickly, e.g. if it's a BLP and because of the increased attention it is discovered that there is something inappropriate in the article. Dr. Vogel (talk) 14:55, 25 June 2022 (UTC)

Shouldn’t be an issue as even with Full Protection an Admin can make edits to the article. Mike Cline (talk) 15:36, 25 June 2022 (UTC)

I'm not saying it's an issue, I actually think your idea is great. I just think that, because the protection could last for quite a while, there should be some kind of provision for changes that really can't (or shouldn't) wait. Dr. Vogel (talk) 01:53, 26 June 2022 (UTC)

I think WP:RFPP probably already has the mechanism to request such an edit. All we’d need to do is call attention to it in the RM boilerplate. Mike Cline (talk) 16:01, 26 June 2022 (UTC)

Mike Cline, your paraphrasing would be accurate wrt my intent. At Wikipedia:Requests for comment, I found this statement: Edits to content under RfC discussion may be particularly controversial. Avoid making edits that others may view as unhelpful. Editing after others have raised objections may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RfC is resolved. While WP:3RR is a bright-line, disruptive editing and edit warring is not limited to WP:3RR. I was actually thinking something like a statement: "If you do this you will be considered to be edit warring". Having said that, I put this up to request comments. Full protection could be an issue at very busy topical pages like 2022 Russian invasion of Ukraine‎ is now but it could also be a benefit. Some of these related pages have had multiple and almost frivolous RMs (with several snow closes). Full protection as a consequence of an RM could discourage this. Cinderella157 (talk) 04:09, 26 June 2022 (UTC)

Full protection of a page during the course of an RM? Guys, really? I know it may not be immediately obvious to the handful of us metapedians here, but the vast, vast majority of productive activity on Wikipedia consists in editing articles. To put a stay on that simply because there's a certain type of discussion going on would be immensely counterproductive. Still, making changes to an article in a way that's intended to lend credence to a particular position in that discussion is obviously bad. But it's a blurry area between that and the uncontroversial fixing of the sort of inconsistencies that spring to light in the course of such discussions. Sure, some mention of these considerations can be added to whatever is our ultimate guide to RMs, but I don't think we can realistically expect something above and beyond what we'd normally do in any other similar situation: if you edit an article in a way that may have a bearing on a given talk page discussion (or if you see someone else do that), then just make a note of that in the discussion, and that's it. – Uanfala (talk) 16:55, 26 June 2022 (UTC)

I agree with Uanfala, full protection while RM is ongoing is an overkill. Vpab15 (talk) 21:19, 26 June 2022 (UTC)

OP comment I appreciate the input but the feedback is suggesting that the protection option is overkill. I was actually considering more of an "advice" on the RM page that would identify the expected conduct and which could be cited. At Wikipedia:Requests for comment#Responding to an RfC, we have the following statement:

Edits to content under RfC discussion may be particularly controversial. Avoid making edits that others may view as unhelpful. Editing after others have raised objections may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RfC is resolved.

I would suggest something similar here and perhaps at Wikipedia:Requested moves#Commenting on a requested move.

Edits to content under for an article under an RM discussion may be particularly controversial. Avoid making edits (broadly construed) which tend to either support or oppose the proposed move. In respect to such edits, it is best to return the article to the status quo ante for a move cycle, which may commence before a formal RM is made. Editing to another preferred version may be viewed as disruptive editing or edit warring. Be patient; make your improvements in accord with consensus after the RM is resolved. This advice does not preclude unrelated edits to improve the article.

I have referred to a move cycle since an RM may commence after a user move or request that has been contested. The status quo ante should be construed to be reasonably proximal to commencing a move cycle. Something similar might also be added to the RM banner that appears on an article page once an RM is initiated; however, I think that adding this at Wikipedia:Requested moves should be sufficient. Cinderella157 (talk) 10:20, 6 July 2022 (UTC)

Anthony Appleyard

I just heard the very sad news that Anthony Appleyard has died. He will be sorely missed by all of us at WP:RM and elsewhere. Please see the entry here: Wikipedia_talk:Deceased_Wikipedians#Anthony_Appleyard Polyamorph (talk) 18:55, 5 July 2022 (UTC)

I feared so. I knew he was in an advanced age, and he stopped editing out of the blue. May he rest in peace. No such user (talk) 06:42, 7 July 2022 (UTC)

How to club RM discussions

I am a regular RM discussions non-admin closer and today I found someone who made 2 related RMs as 2 separate requests even though it would benefit from being made as a grouped request. An example is this and this. These must've been a single grouped request.
How can I group this discussion and request systematically?
After that, I might want to relist the discussion to see new response in context of those 2 moves together. >>> Extorc.talk 09:20, 7 July 2022 (UTC)

See Wikipedia:Requested moves#Requesting multiple page moves. Unless there is new information and you are expecting a new outcome, I wouldn't see a need to relist. —Bagumba (talk) 09:26, 7 July 2022 (UTC)

Table of contents missing?

Is it me, or has the Table of Contents gone missing this past week? I find it convenient to be able to zip straight to Elapsed, Backlog or Uncontroversial RMTRs from the top of the page via the Table of Contents. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 05:09, 11 July 2022 (UTC)

It must have been this edit—I reverted it and the ToC is now back. Extraordinary Writ (talk) 05:26, 11 July 2022 (UTC)

Bot's revert

Why? Dawid2009 (talk) 13:34, 12 July 2022 (UTC)

Because you didn't use {{subst:requested move}} properly when formatting your request, which means the bot fails to see it, and manually editing the /Current discussions page is pointless since the bot will overwrite your edits. I've fixed the move request for you, so the bot should add it (and keep it added) on its next run. * Pppery * _{it has begun...} 13:38, 12 July 2022 (UTC)

Semi-protected edit request on 15 July 2022

Indiantapsa (talk) 21:11, 15 July 2022 (UTC)

 Not done You haven't specified what edit you would like to be made. Polyamorph (talk) 21:14, 15 July 2022 (UTC)

updating links following page move

Hi guys, I dealt with this request, and shortly after I got a couple of messages that sound a bit aggressive. My understanding is the responsibility for updating links following an uncontroversial move request lies with the user who requested the move, not with the page mover. Could you let me know if I've broken any rules? Otherwise I don't understand the tone of the messages I received. Thank you. Dr. Vogel (talk) 09:46, 18 July 2022 (UTC)

To my opinion not aggressive but the truth. Moving an article after a RM is one thing, leaving the fall-out of the move to be dealt with by others is "not nice". The Banner talk 10:52, 18 July 2022 (UTC)

The responsibility for cleaning up after a move lies with the editor performing the move. For moves at RM(T), they're the ones most competent to do it (you can't expect everyone on Wikipedia to know of the some of the intricacies involved) and even when others may eventually notice the move and clean up after it, you wouldn't want to risk leaving the encyclopedia in a mess until that happens. The only exception that I can think of concerns links to disambiguation pages: if a dab page ends up with articles linking to it because of a move, the mover isn't required to fix them all (though they're still expected to e.g. make sure all the redirects point to the right places). – Uanfala (talk) 10:54, 18 July 2022 (UTC)

Yes, that's exactly the case here. The links point to Stuart Wright, which the requester explicitly said he's going to turn into a dabpage. So I don't think it's a good idea to touch it until they've had a chance to do that. But being cautious has resulted in me getting messages containing "you've done half the job" and "now do we?" which are completely uncalled for. I just don't see the point of aggression, whether you're right or wrong. Dr. Vogel (talk) 11:12, 18 July 2022 (UTC)

Leaving it to the proposer to create the dab is fine, of course. But after the rugby player article was moved, the links from navboxes should have been updated: that's done after each move, regardless of what is to become of the old title. Yes, receiving messages with a passive-aggressive tone is really unpleasant, but I hope you might also be able to appreciate that for many volunteers here it can be annoying to see an experienced editor with an advanced user right not cleaning up after their use of that user right. – Uanfala (talk) 11:45, 18 July 2022 (UTC)

I do appreciate that, but there's never an excuse for being unpleasant. The person doing the move is a volunteer too. Anyway, I've gone ahead and created the dabpage myself and I've fixed all the navboxes. Dr. Vogel (talk) 11:50, 18 July 2022 (UTC)

Having to clean up after a move is also unpleasant. I keep tab on "Templates with disambiguation links" and fixing the results of moves is a large part of what I do there. The Banner talk 11:53, 18 July 2022 (UTC)

If you find that task unpleasant, you can do a different task. There are lots of jobs on here so we can all find something that we like. Whether a task is interesting or not is subjective. Being unpleasant to a fellow volunteer, much less so. Dr. Vogel (talk) 12:00, 18 July 2022 (UTC)

Did you notice that you are now displaying the same unpleasant behaviour that you were complaining about? The Banner talk 12:10, 18 July 2022 (UTC)

There is a really wide continuum between fixing everything and just performing a move. In this case, asking for the dab to be created before making the move would be warranted. Since it wasn't done ahead of time, another way to go about this in a pinch might have been to leave the redirect in place until the dab page was created instead of suppressing it. The redirect can always be converted to a dab page afterwards. Dekimasuよ! 12:07, 18 July 2022 (UTC)

I agree. And in this case, the redirect was indeed in place until the dabpage was created. Dr. Vogel (talk) 12:15, 18 July 2022 (UTC)

I noticed that you changed the links manually. If you have to do this job in future, WP:AWB (desktop app) or WP:JWB (Javascript tool) may help save you some time and effort by automating the process. WP:DisamAssist can help when incoming links are to an existing disambiguation page. Make sure that in most cases, link update is not required outside mainspace and template space though. —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:11, 18 July 2022 (UTC)

Thank you. Template space is relatively easy, because one edit deals with many articles. Mainspace is a lot more complicated. I didn't know JWB existed, I'll have a look. Dr. Vogel (talk) 12:16, 18 July 2022 (UTC)

To the above, I can add three points. First, if someone demands that you fix the dab links that result from the move (apart from navboxes, redirects, free-use rationales and the like), you can point them to WP:FIXDABLINKS, which states that the mover is not required to do that. For many years this guideline used to say that movers were supposed to do that as well, so bear in mind that people may not have caught up with the updates yet and so their expectations may be different. Second, fixing links is much more important in the hopefully rare cases where one primary topic displaces another: these don't end up in the well monitored WP:DPL reports, so you can't rely on anyone dealing with them. If they're too much to do by yourself, you can leave a note about them at WT:BPAT. Third, if fixing any sort of links, semi-automated tools can be useful, but usually in limited circumstances. Whatever the tool used, the context should be examined to make sure the link is correct. The vast majority of bad links I come across in my day-to-day editing are the result of careless dabfixes. – Uanfala (talk) 12:28, 18 July 2022 (UTC)

Thank you, that's extremely useful. Now I'll know exactly what to do, and why and how. Dr. Vogel (talk) 12:33, 18 July 2022 (UTC)

DisamAssist is really good and simple to use; if you haven't used it, it runs from an existing dab page, analyses all incoming links, and offers you to resolve them to a dab page item by presenting a wikitext snippet from the source. Even if you just want to retarget the existing links, you can turn the redirect to a dab page temporarily, do the job, and restore the redirect. No such user (talk) 12:43, 18 July 2022 (UTC)

Talk:List of first-level administrative country subdivisions#Part 2

There is a move discussion in progress at Talk:List of first-level administrative country subdivisions#Part 2. 2600:1700:6180:6290:9513:4BFE:DEB0:3626 (talk) 11:28, 26 July 2022 (UTC)

Personal name Romanization rules

Hi all, I recently saw Talk:Droupadi Murmu#Requested move 24 July 2022, which in turn reminded me of Talk:Volodymyr Zelenskyy/Archive 1#Requested move 7 January 2022. Two presidents of two different countries, both of whom have an ambiguity in the correct Romanization of their names. Reliable sources, sometimes, go against the personal preferences of the subject. While WP:NCPEOPLE directly deals with self-published name changes, there isn't a dedicated policy that deals with self-published Romanised spelling, although a stretched definition of that policy resulted in Zelenskyy's name change. I was wondering if we should make it an explicit part of NCPEOPLE? —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:15, 31 July 2022 (UTC)

diacritics

Hello. Would it be a good idea to start an RfC to create a guideline/policy to stop using diacritics in article titles of biographies? Basically, we are an English language encyclopaedia, and we should use the names in English form. What are your opinions? —usernamekiran (talk) 13:18, 29 July 2022 (UTC)

The relevant guidelines, for anyone interested, are WP:DIACRITICS, WP:TRANSLITERATE, and WP:COMMONNAME. Currently The use of [diacritics]... in article titles is neither encouraged nor discouraged. Primefac (talk) 14:03, 29 July 2022 (UTC)

Although I personally agree that diacritics are almost never useful in article titles, it is extremely doubtful that you would get consensus for such a change to the current guidelines. Opinion is simply split. So an RfC would likely be a waste of time right now. Station1 (talk) 19:42, 29 July 2022 (UTC)

I think one place to try and find common ground would be a discussion of letters that do not exist in the English alphabet at all, rather than trying to limit diametricdiacritical modifications to existing letters. Recently there have been several moves to add non-English Latin alphabet letters to article titles, e.g. Talk:Səlahət Ağayev#Requested move 18 June 2022 (cf. User talk:Mellohi!#First Japanese Embassy to Europe) and they have generally gone through. In addition, there appears to be a strong tendency among editors participating in such discussions to privilege native spellings. If that does not represent the view of the community as a whole, it should be pointed out. Dekimasuよ! 04:54, 31 July 2022 (UTC)

I recall there were discussions a while back about Azerbaijan-related articles that went the other way. Jabrayil and Charektar comes to mind, but I believe there were others around the same time. Generally, WP:UE applies when English-language sources exist. Station1 (talk) 08:18, 31 July 2022 (UTC)

RfC: Proposed improvements to WP:RM/TR

Due to concerns raised by Onetwothreeip at Talk:Annexation of Crimea by the Russian Federation and Talk:Russo-Ukrainian War that I started the RM "without their permission", I am proposing the following two changes:

1. Make the "discuss" links at WP:RM/TR visible only to the original requester. This would require adding a new {{CURRENTUSERNAME}} magic word (see T311794).
2. Add a "notify requester" link to Template:RMassist/core that would either notify the requester that the discussion has been moved to a full RM (if #1 is opposed) or ask them whether they agree to start the RM (if #1 is supported).

Should we implement one or both changes? Please say below whether you support or oppose each change. If you support #2, then please also say whether you support or oppose making notifying the requester mandatory. GeoffreyT2000 (talk) 23:19, 30 June 2022 (UTC)

• Number 1 seems like it would be more trouble than it's worth: the vast majority of contested technical requests are moved to RM without any problems, so complicating the process further doesn't really seem to be necessary. A better solution might be to improve the RM/TR documentation (e.g. the editnotice) so that it explains what exactly happens if requesters don't use |discuss=no. For number 2, I always just ping all the RM/TR commenters when I start the RM (example), which is a fairly easy way of making sure people are informed without having to resort to talk-page notices. It might be a good idea to do a bit more brainstorming about this issue before we go forward with an RfC (see WP:RFCBEFORE): there may be other possible solutions that we haven't thought of. Extraordinary Writ (talk) 02:06, 1 July 2022 (UTC)
• Unnecessarily complicating things. Vast majority of RMTRs that are moved to full discussion remain uncontested by nominator. These are the only 2 I've seen. When a RMTR is filed, it is expected of the nominator that they'll present their detailed case to sway the RMTR page movers just as they would during a full discussion. As for signature thing. I think changing the lede to «"Foo" → "Bar" – Some reason here. Request from "username1" moved from WP:RMTR for full discussion by "user2 signature"» should alleviate the concerns. —CX Zoom[he/him] ^{(let's talk • {C•X})} 05:32, 1 July 2022 (UTC)
• I agree 1 seems unnecessary given the above. ― Qwerfjkltalk 06:08, 1 July 2022 (UTC)
• Thanks for the notification. I don't particularly see a need for those changes, nor harm in applying them. The problem was not that requested moves were started "without my permission", the problem was that my username was used without my permission in starting those requested moves. I also wasn't notified that my username was used, which was also a problem. Editors should be notified of the results of technical requests, and notified of how the technical request can be moved to a requested move if the technical request is rejected. Onetwothreeip (talk) 07:52, 1 July 2022 (UTC)
• This aspect of the practice at RMT really needs to change. First off, it's really odd to see your signature at the end of an RM requests which you've never started. If you'd wanted to start an RM, you would have started an RM. There are differences in how you approach each venue: at RMT you try to be brief in order for your rationale to fit within the default edit summary of the move, whereas at RM you have more room to present a more detailed argument, which you'd want to do anyway because unlike with RMT, you expect there may be objections. Another thing is that when someone has contested your request, they may have given you a reason to change your opinion, so you may no longer wish for the title to be changed. I think it's most sensible if the initiative for moving forward a contested request is placed with the nominator. – Uanfala (talk) 12:27, 1 July 2022 (UTC)
• Oppose as written, but support some change. Currently, the process is ambiguous and not respected by those approving or rejecting the requests. To address the first, we should change the template from {{subst:RMassist|current page name|requested new name|reason= reason for move}} to {{subst:RMassist|current page name|requested new name|discuss=yes|reason= reason for move}}; editors should know that starting a discussion is the default result of a contested request. To address the second, all that needs to be done is that the decision to select "no" needs to be respected, rather than reviewers switching it to "yes" and opening a move request anyway. BilledMammal (talk) 12:49, 1 July 2022 (UTC)
• Support #2 to notify the requester that the discussion has been moved to a full RM (but not to ask their permission). When moving to RM, the page mover can become the initiator of the RM with the TR rationale by the original poster, and relevant discussion, copied over (perhaps in an archive box) added for information.Polyamorph (talk) 13:53, 1 July 2022 (UTC)
• Oppose both as solutions in search of problems. * Pppery * _{it has begun...} 14:58, 1 July 2022 (UTC)

There is a problem though. When TRs get moved to a full RM, the original comments are copied to a new page. Currently there is a small notice to indicate this is a contested TR but I think it should be made a lot clearer so that there can be no confusion as to who initiated the actual RM. Polyamorph (talk) 15:05, 1 July 2022 (UTC)

• *Oppose as written, but support some change. I'd rather see a PROD style process where any objection by interested editors or the page movers that patrol RMTR leads to a failing of the request, with notification to the requester that they might consider an RM. If the status quo process is kept, I think it needs to be clearer to filers that "If your request is contested or determined to be controversial, a requested move discussion will be started. Please write your request as if it were the opening statement of a requested move discussion." Or something to that effect. Firefangledfeathers (talk / contribs) 15:24, 1 July 2022 (UTC)

• Oppose as written, but support some change. Thankyou to GeoffreyT2000. Addressing this has been on my "to do" list. I think that Uanfala has made a reasonable summary of the issues and the changes needed/appropriate are probably more to process. If a TR is contested, it is quite possible that the reasons given may convince the proposer not to proceed and proceeding by default to RM is a poor choice (a waste of time). Further, a case made for an RM might be quite different than for a TR. I would support the PROD style process per Firefangledfeathers, where a contested TR leads to a failed request. If the proposer wishes to proceed to RM, they may either continue the TR discussion as an RM or refactor their original. In the second case, the RM should be made aware of the original TR. There is some finer detail on how this might best work but I will leave that for now. Cinderella157 (talk) 23:28, 1 July 2022 (UTC)
• Oppose #1, weak support #2. Overall this isn't an issue in the majority of cases I've seen, but I would support better wording of the documentation/template to make it clearer how things work. -Kj cheetham (talk) 10:36, 2 July 2022 (UTC)
  • Comment I'd be interested in knowing what fraction of requests is this actually an issue on, but I'm not sure how easy that would be to find out. Also the current template does have a setting for discuss which can be yes or no, better guidance on that would be helpful. Maybe the default could be no and only set to yes if the requestor is happy it goes to a full RM if it's contested? -Kj cheetham (talk) 19:21, 4 July 2022 (UTC)

Some are SINO some are China? Consensus?

Some articles are "Sino" some are "China"? Shouldn't there be a consensus on format for the multilateral articles.?

Sino

• Africa: Sino-African relations
• Arab League: Sino-Arab relations
• Caribbean: Sino-Caribbean relations
• Latin America: Sino-Latin America relations
• Pacific: Sino-Pacific relations
• Third World: Sino-Third World relations

China

• European Union: China-European Union relations
• United Nations: China and the United Nations

CaribDigita (talk) 02:08, 26 July 2022 (UTC)

Wikipedia should not try to fix inconsistency in the real world. Wikipedia should follow the sources. SmokeyJoe (talk) 14:56, 6 August 2022 (UTC)

Why not just abolish RMT?

Don't get me wrong, WP:RMT is a very useful venue and it works great most of the time. But there are issues: from the way contested requests are handled (see just above), to the absence of archiving (discussed in April) to the well-known fact (last briefly noted here) that requests aren't visible from the pages concerned, which occasionally results in controversial moves that take the page watchers by surprise.

I think all of these issues can be addressed in a simple big step that doesn't require significant new machinery. Just handle such requests the same way that other requests for changes to articles are handled: via the edit request system. Someone wants a page moved? They place a request on the page's talk (like that, just using a dedicated template for moves). Someone wants to contest it? Just comment in the talk page section; converting that to a formal RM will involve just slapping on the RM template – and whatever happens afterwards, that initial discussion will remain on the talk page as a visible record. Someone wants to help out with requests? Just go the maintenance category (like this one), which will have a neat sortable bot-maintained table of existing requests.

I can't think of any ways in which this system would be worse than what we have now, and there are several ways in which it will be better. Thoughts? – Uanfala (talk) 16:24, 2 July 2022 (UTC)

That's a really interesting idea. Talk-page watchers likely have a better understanding of what moves are controversial than the non-specialists at RM/TR, and as you say the proposal would deal with some of the recent problems with RM/TR. Edit requests are also probably more intuitive for newer users, many of whom will have used the process before. Certainly an idea worth thinking about. Extraordinary Writ (talk) 18:02, 2 July 2022 (UTC)

That is indeed an interesting idea. Would it be possible to list open move requests so that page movers can still monitor it? There might not be any active talk-page watchers with page mover rights. Polyamorph (talk) 18:14, 2 July 2022 (UTC)

I think the idea is that you'd be able to watchlist a category (like Category:Wikipedia template-protected edit requests) and/or a bot-updated page (like User:AnomieBOT/TPERTable), just like we currently do for regular edit requests. Extraordinary Writ (talk) 19:25, 2 July 2022 (UTC)

Some kind of list of specifically edit requests for page movers would be essential for something like this I think. -Kj cheetham (talk) 19:20, 4 July 2022 (UTC)

I love Uanfala's idea. Dr. Vogel (talk) 20:49, 2 July 2022 (UTC)

Has good merit. Though I can see merit in explicitly closing the TR and the proposer formally opening an RM rather than this automatically moving to RM (all done on the article TP). That was the issue identified by Uanfala in the RfC above (#RfC: Proposed improvements to WP:RM/TR). If the TR is closed as failed I would see three options. The first is no further action. The second would be to reinitiate the TR as an RM without change. The third is to open a RM ab initio. As identified at the RfC, it is reasonable that a TR might be briefly stated and in moving to an RM it would be reasonable to make a case in more detail and/or to refactor the proposal in light of the comments contesting the TR. To summarise, the OPs proposal isn't a solution in itself but part of a total solution. — Preceding unsigned comment added by Cinderella157 (talk • contribs) 02:29, 3 July 2022 (UTC)

I agree with the idea. When an editor attempts to move a page, but they can't because of lack of rights, then they should be asked to use a technical move request system similar to the current edit request system. This will notify the page watchers, who may contest such a move before it is performed. If the move is contested, the TR fails, and a full RM would be required. Page movers will also be able to track changes if a list similar to User:AnomieBOT/TPERTable is maintained. —CX Zoom[he/him] ^{(let's talk • {C•X})} 09:42, 3 July 2022 (UTC)

I agree, this idea makes a lot of sense. Adumbrativus (talk) 06:51, 6 July 2022 (UTC)

I have a concern that the watchers (and executors) of RMTR are generally page movers and admins with deep knowledge of WP:AT and best RM practices (although they have rarely subject matter knowledge), so requests are executed or disputed with a high degree of consistency. Moving the process to edit request system might result in haphazard and inconsistent decisions by random passers-by who may be versed with the article subject, but not with best AT practices.
However, I also share Uanfala's concerns about the current process from the RfC above. Perhaps we can have the best of both worlds (advertizing move on article talk page and have it displayed at RMTR): let's expand {{Requested move}} so it accepts technical=yes argument (nominator asserting that the move is uncontroversial), and have RMCD bot listing those in WP:RMTR separately from regular RMs, so that RM watcher crew can see it like any other RM. If anyone disputes the move within a reasonable timeframe, they can do so on the article talk page, and the "technical" RM converted to a full RM. Obviously, there are details to work out, but you get the idea. No such user (talk) 07:41, 6 July 2022 (UTC)

The having it in both places makes sense. After all, a dedicated category could be followed on watchlists, or if needed a flag might allow a bot to post them onto an RMT subpage (which could also be watchlisted), much as Legobot does for GANs. CMD (talk) 07:44, 6 July 2022 (UTC)

That sounds like a useful refinement of a good idea. It brings a new process (I'll call it "Tech Move" for now) which is to RM as speedy deletion (SD) is to AfD. Just as a SD normally results in either deletion or an AfD discussion, depending whether a sympathetic admin or an objector gets in first, so Tech Move can result in either a speedy move or a full RM. We could insert a short waiting period like the 48-hour delay at CfD/S, but that's probably unnecessary. Certes (talk) 13:33, 7 August 2022 (UTC)

@Uanfala: I think this proposal has good local consensus. Would you following up on this? It's been about a month. —CX Zoom[he/him] ^{(let's talk • {C•X})} 07:29, 31 July 2022 (UTC)

I've been a bit busy lately. Anyone interested in taking this up? I'd be delighted if they do! Uanfala (talk) 10:14, 31 July 2022 (UTC)

The 'best of both worlds' proposal by No such user sounds best to me. Polyamorph (talk) 18:37, 31 July 2022 (UTC)

I posted at Wikipedia:Bot requests#Bot_supporting_revised_technical_move_request_process to see if there's interest from those more familiar with bot implementation. Adumbrativus (talk) 00:24, 7 August 2022 (UTC)

Wikipedia:Requested moves/Technical requests/Instructions

Do we need the text "Do not request technical assistance on this page if you can do it yourself." added by User:WhatamIdoing in 2019? In some cases it may be a good idea for moves that could potentially be controversial or questionable but are not clearly controversial or questionable, the user may just want to see if they get contested or another pair of eyes thinks the move is OK? Crouch, Swale (talk) 19:07, 3 August 2022 (UTC)

@Crouch, Swale, you should not ask for specifically technical assistance unless you actually need technical assistance. For potentially controversial or questionable moves, you should use Wikipedia:Requested moves#Requesting controversial and potentially controversial moves.

To put it another way, if the problem is "I'm having software/computer problems with making this good move", then you need to request technical assistance. If the problem is "Maybe people will think this move is a bad idea", then you need to use the "potentially controversial moves" system. If that's not clear from the page, then maybe the PCM section should be moved higher than the technical assistance section. WhatamIdoing (talk) 19:16, 3 August 2022 (UTC)

I concur with WhatamIdoing. -Kj cheetham (talk) 10:29, 14 August 2022 (UTC)

has the bot stopped?

If I am reading this correctly, there have been no new listings for over 14 hours (since 14:12 yesterday); and I know there has been at least one request because I made one at Talk:Wendy Smith-Sly over an hour ago (3:24). Has the bot stopped? Adpete (talk) 04:52, 14 August 2022 (UTC)

The issue was earlier raised at User talk:RMCD bot#Bot not running. The bot operator has let us know that "bot-assisted updates will be limited over the next few days". So, the lists may take more time than usual to receive an update. —CX Zoom[he/him] ^{(let's talk • {C•X})} 06:39, 14 August 2022 (UTC)

While we wait for the bot to recover, I have been manually updating the list since a couple of hours ago. I have gone through Related changes of the Category:Requested moves category, and have backfill with what I could find and updated the list with new ones as well. If there's any missing, either add them to the list yourself, or let me know if you are unsure of the formatting. – robertsky (talk) 11:19, 14 August 2022 (UTC)

Smethwick Khalsa Football Federation F.C.

Smethwick Khalsa Football Federation F.C., an English football club, has reverted its name back to Smethwick Rangers F.C. As this was a former name of the club and the club's page has been formerly moved from that original name, I am unable to move it back to Smethwick Rangers F.C. COYB01 (talk) 20:14, 14 August 2022 (UTC)

@COYB01: If the move is uncontroversial, you can list it at WP:RMTR. Certes (talk) 21:43, 14 August 2022 (UTC)

The problems with primary topic RMs

For some time now, I've been taking part in RMs that involve primary topic questions. This naturally presupposes that I don't find these discussions to always go well (otherwise, why would I be wasting my time when things would be perfect without me anyway?). Still, I often find them to be disappointing to a greater extent that anything else on this project. From my point of view, there seem to be three main reasons for that:

1. Varying (mis)conceptions about usage. The guidelines are pretty clear about what "primary topic with respect to usage" means, and it's usually up to common sense whether and how each of the tools listed there could be used in each situation. The trouble is, people will often use those tools regardless of the extent to which they allow any meaningful inferences about usage as defined in the guidelines. For example, it sometimes happens that a direct measure of relevant usage (as available in some of the recently developed tools) is ignored, and instead the emphasis will fall on familiar but very indirect proxies, like pageviews. I think the assumption that people would use common sense is not tenable anymore, and what we'd need to do is spell everything out. Maybe time to make the guidelines even more explicit and also add an explanatory supplement that details how each of the tools can be used in each set of possible circumstances? There's already an essay about pageviews at WP:PPT, and I'm thinking of doing one on the technical aspects of Wikinav, but we need a central document that a) explains everything, b) has community support, and c) can easily be cited in discussions (maybe the very rudimentary WP:PT/U could serve as the starting point for that?).
2. Inherent bias among participants. Primary topic questions involve deciding whether one topic is more significant/notable than all the other, unrelated, topics with the name. But the way these RMs are advertised, they attract participation from the editors of the (proposed or existing) primary topic article (as well as its wikiprojects), but not from any of the contender topics. If someone has spent a good deal of time contributing to an article on a topic they care about, chances are they wouldn't be very happy at the suggestion that their favourite topic isn't as significant as a bunch of other topics that they don't really give a fig about. I think that's the greatest source of heat in those discussions, and probably the main motivator for people to bend common sense when interpreting #1.
   What can be done about that? Maybe closers need to be aware of this participation bias and try to compensate for it (but that's a tall order). Notify all articles that challenge a primary topic? That's going to increase the heat even more, and there's no reason to suppose that several competing "wrongs" would necessarily cancel out to create something that's "right". A change of format maybe? For proposed primary topics, there's probably no reason to notify the article at all: a title change from "Foo (bar)" to "Foo" reflects broader wikipedian considerations and is just a formality as far as the article itself is concerned. Moves in the other direction – from "Foo" to "Foo (bar)" – will still need to be advertised as now: the editors to an article should obviously still have a say on the choice of disambiguator. But maybe these discussions could go in two phases. First, it gets decided whether there is a primary topic: this can be done at a centralised project page, free from partisan input; once that's decided, then an RM can be started on the article's talk page with the sole aim of agreeing on the best disambiguator.
3. Closures. In my experience, most closures are good and some closers are consistently excellent, but I feel like there's still a tendency among a subset of experienced closers to preferentially count votes. Such a tendency exists throughout Wikipedia, but I think it leads to worse outcomes for RMs because it amplifies the effects of #1 and #2. If those two get addressed, then this one wouldn't be that much of an issue. But still, what can be done? Encourage other competent editors to start closing? Or change some of the expectations? We could be a bit more tolerant of backlogs so that closers don't feel like they have to close any particular discussion: when there's a mismatch between vote count and strength of arguments, it may for example be more helpful for a potential closer to instead participate in the discussion and so help sway the balance.

Well, this is just me. What are others' observations about problems with this sort of RMs? Thoughts about the suggested solutions? How about other possible ones? Uanfala (talk) 13:04, 6 August 2022 (UTC)

A problem that feeds these problems is the bad old idea and practice of DABNAME and MALPLACED, which means that if there is no PrimaryTopic, the disambiguation page goes at the basename. This is bad because disambiguation pages at basenames cause several problems. To avoid these problems, editor like to overgenerously assign PrimaryTopic to one of the alternatives. In doing so, the PrimaryTopic intent is corrupted, with spin-off problems around.

The solution is to repudiate DABNAME and MALPLACED, and for dab pages like mercury to be at Mercury (disambiguation), with the basename redirecting to it. Then, editors will not need to contrive PrimaryTopic arguments where there is no PrimaryTopic. SmokeyJoe (talk) 14:54, 6 August 2022 (UTC)

What problems are created by having the dab page at the basename? Firefangledfeathers (talk / contribs) 12:56, 11 August 2022 (UTC)

I'm not sure about this, but I suspect that if all dab pages were at Example (disambiguation) (with Example redirecting there when suitable), we might get fewer accidental links to dab pages. WhatamIdoing (talk) 20:49, 15 August 2022 (UTC)

Such links appear when someone writes Mercury is a metal without bothering to check where the link leads. Unfortunately, that will remain true whether Mercury is a dab, a redirect to dab or an article on a "wrong" topic (such as the planet). WP:MALPLACED is also being debated yet again at Wikipedia talk:WikiProject Disambiguation/Malplaced disambiguation pages#The problems with MALPLACED?. Certes (talk) 10:58, 16 August 2022 (UTC)

I don't see these as problems that require changes to the requested move process. 1 can be countered with better usage arguments (assuming that your premise is correct); 2 is unavoidable, all RMs are listed here and if uninvolved editors don't participate, there's little we can do about it; and 3 already has a solution in WP:MRV. Iffy★Chat -- 17:33, 6 August 2022 (UTC)

Uanfala, I do think it would be good to have a centralized discussion on how/when to use pageviews vs. navigation data or Wikinav. This may have happened already and I missed it. I have a barely-informed opinion—having seen your argument presented at a few RMs—that Wikinav is an amazing tool but not one whose existence means we deprecate the use of pageviews. On your point about bias: I think it's a good idea to notify the talk pages of all articles tied to a name when we're having a PTOPIC-based debate. In general, I share your view on the damaging bias that inevitably pops up, but it's a kind of selection bias that affects most discussions on Wikipedia and I don't have great ideas on how to remedy it. Firefangledfeathers (talk / contribs) 12:56, 11 August 2022 (UTC)

Two comments.

• I see WikiNav and pageview data as examining two different angles of usage, and both have their limitations (many of us struggle with trying to account for so many of WikiNav's omissions and WikiNav also vomits when trying to get results for little-visited pages). Pageviews provide a partial answer to what subject is more popularly known to Wikipedia readers than others, while WikiNav deals with traffic movement.
• I'd assume the bias problem can be partially relieved by having RMCD bot notify every article disambiguated through a dab page any time a dab page is nominated for moving.

— Ceso femmuin mbolgaig mbung, mellohi! (投稿) 19:10, 12 August 2022 (UTC)

Permalinks in prefilled edit summaries

Any ideas about why the permalinks go wrong? I did a move just today and the prefilled edit summary linked a permalink dating back to 9 August 2022. This move that I made two days ago also has a similar problem. I'm sure this is the case with most of the prefilled edit summaries. Any cure to that? ─ The Aafī (talk) 17:05, 18 August 2022 (UTC)

They're broken because Bot1058, which was previously updating Wikipedia:Requested moves/Technical requests/Permalink, went down on August 9, 2022. Not sure how to fix the problem, though. * Pppery * _{it has begun...} 17:08, 18 August 2022 (UTC)

I created a script (User:CX Zoom/scripts/UpdateRMTRpermalink.js), which, if installed, will update the permalink subpage automatically whenever the user goes to Special:BlankPage/UpdateRMTRpermalink. I hope to request at WP:IANB to move it to MW namespace, so that a ?withJS= link can be added in {{RMassist/core}}, which will allow page movers to update it without installing it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:36, 19 August 2022 (UTC)

Wait, I see that bot operator is active again, maybe they can fix the bot. pinging @Wbm1058. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:56, 19 August 2022 (UTC)

Sorry this bot's down. I don't have a robust backup at the moment. Things should be back to normal within a few days. wbm1058 (talk) 01:31, 21 August 2022 (UTC)

Bot missed a proposed move

I think I correctly proposed a move at Talk:AMG/Parade but the bot doesn't seem to have added it to the main discussion list. It has been more than 12 hours. I am not good at this so please let me know if I am doing it wrong and how to do it better. Is there something more I have to do to get the bot to work? Thank you! 72.66.54.194 (talk) 00:58, 21 August 2022 (UTC)

I wonder if the subpage structure (the slash in the name) is incompatible with the bot. Dicklyon (talk) 01:18, 21 August 2022 (UTC)

Sorry, bot updates will still be limited for a few days more. This one has been processed now. – wbm1058 (talk) 02:27, 21 August 2022 (UTC)

@Dicklyon@Wbm1058Thank you for the help! @DicklyonI replied to your comment on the discussion page!

72.66.54.194 (talk) 04:50, 21 August 2022 (UTC)

change name

Please change name of AlAlamein International University To Alamein International University source:https://aiu.edu.eg/ YoussefBadreldin22 (talk) 14:38, 22 August 2022 (UTC)

 DoneI've boldly moved this, as it seems correct per the organization's own website. - UtherSRG (talk) 14:50, 22 August 2022 (UTC)

Request

Hi. Can you move this article from Ramadan revolution to 8 February coup 1963 John576424 (talk) 17:41, 24 August 2022 (UTC)

 Not done Please see WP:RM#CM to create a move request. I have reverted some of your changes, sice they are controversial and have not been discussed. Please discuss on the article's talk page before making controvserial changes in order to get WP:CONSENSUS from other editors. Vpab15 (talk) 17:52, 24 August 2022 (UTC)

non-controversial non-move request

the TX-0 was an early and influential computer. The page is at the appropriate URL https://wiki.riteme.site/wiki/TX-0 but if you click, when you land on the page the title shows up on the page as TX-o with the lowercase letter-o ; it should be TX-0 with the digit zero. Not precisely a move, but from what I understand, shouldn't this title be coming from the URL-name?

edit: I thought I'd check the history, the page was originally created in 2002 with this same flaw 2603:8001:D300:A631:0:0:0:10D0 (talk) 03:00, 30 August 2022 (UTC)

The issue is the funky fonts used by the default legacy Vector 2010 skin. I created the redirects for the upper-case O TX-O and lower-case o TX-o so you could compare the differences in their appearance. Also note from the TX-1 article how this default font renders numbers smaller-sized than letters in article titles. Try changing to another skin such as Monobook which uses a less-funky font and the title should appear more "correct". – wbm1058 (talk) 14:00, 30 August 2022 (UTC)

It is not a vector legacy issue tbf, renders completely normally on my devices. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:06, 30 August 2022 (UTC)

oh, I see, you're right it is a zero, just a short, squat one. FWIW I'm seeing the problem using up-to-date generic both Chrome and Firefox on Fedora Linux. (and I have no idea where skins live in wikipedia, but back in the days of WinAmp I considered the birth of skins to be the death of everything good about computers so I probably won't track them down. However I did use the "view - no style" option in Firefox and the problem goes away in that mode.) Thanks for looking into this. 2603:8001:D300:A631:0:0:0:10D0 (talk) 21:29, 31 August 2022 (UTC)

I don't know what's causing this. When I used vector legacy in desktop mode in android device, it showed "TX-0". On an actual desktop, using the same skin and mode, I also see "TX-o". Although, I don't know what's causing this. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:50, 31 August 2022 (UTC)

I submitted it as a move request cuz I sorta thought moving it to something else and moving it back might fix it. But that's just a thought, I have no idea. 2603:8001:D300:A631:0:0:0:10D0 (talk) 09:35, 3 September 2022 (UTC)

Due to the relative height of "0" (zeroes) in Wikipedia article titles in some devices, it may sometimes appear as "o" (lowercase o)

I assume that this is font style issue. On my desktop (above) the zero in the title is smaller than "t" and about half the size of "h" giving the impression that it is lowercase "o", like an optical illusion you may say. Here the number "1" is also the same height as "0", in fact all numerical digits are this height. But it's presence right beside the zero helps the reader understand that it is in fact a zero and not a lowercase "o". In your case, the title TX-0 was devoid of any other similarly small sized digit nearby, leading to the impression that it's a lowercase "o". Using the same skin on other device (below), "10" is actually taller than even "t" and there is no ambiguity. There are other small differences too, like the shape of "s", the ratio of upper and lower halves of "e", etc. indicating that for whatever reason, different devices are displaying the title in different fonts, and that is causing the issue you had seen. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:23, 3 September 2022 (UTC)

good call, thanks. 2603:8001:D300:A631:0:0:0:1D29 (talk) 07:18, 4 September 2022 (UTC)

When I log into Wikipedia, I use the MonoBook skin from preferences/appearances and the 0 looks like the same height as some capital letters. While not logging in, the different font makes it look like the 0 is an o, definitely. When pasting the article title, the font is of Georgia type while the MonoBook version uses Helvetica. I can't remember when the font of article titles was changed. Iggy (Swan) (Contribs) 08:50, 4 September 2022 (UTC)

Natatorium

Since the discussion is gone, the AFD entry is here: Wikipedia:Articles for deletion/Natatorium Polyamorph (talk) 17:09, 6 September 2022 (UTC)

Semi-protected edit request on 9 September 2022

On the Sept. 8 section, remove the support comment by User:Jèrriais janne as it has been already properly posted at Talk:Camilla, Queen consort of the United Kingdom#Requested move 8 September 2022 and this is only intended to list discussions. - 2001:4453:54A:CA00:4D65:6655:3B86:9168 (talk) 14:19, 9 September 2022 (UTC)

That section just lists the currently open move requests. The list is automatically maintained. The entry for Camilla will be removed once the move request is closed. Vpab15 (talk) 14:28, 9 September 2022 (UTC)

I have fixed the indentation of Jèrriais's support comment, hopefully the bot will fix it in the list as well. Vpab15 (talk) 14:31, 9 September 2022 (UTC)

Ah, I see, It was due to formatting issues in the source talk page and the bot got confused. Thanks for looking at this. Just to clarify, I am not requesting to remove the nom's remarks but just that stray comment that should stay in the talk page. Thanks! 2001:4453:54A:CA00:4D65:6655:3B86:9168 (talk) 14:36, 9 September 2022 (UTC)

No worries. The bot has now corrected the entry. Thanks for raising the issue. Vpab15 (talk) 15:17, 9 September 2022 (UTC)

Caret: arbitrary and unilateral page move

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steel1943 has unilaterally declared that the (mis)use of the word caret by programmers makes their definition the wp:PRIMARYTOPIC, and has made the following series of moves without any prior warning, discussion or consultation as if it is a trivial technical move:

• Caret (disambiguation)‎ 16:54 +5‎ ‎Steel1943 talk contribs‎ (MOS:DABPRIMARY)
• Talk:Caret (computing)‎ 16:52 +30‎ ‎Steel1943 talk contribs‎ (Fix) Tag: Redirect target changed
• Caret (computing)‎ 16:51 +26‎ ‎Steel1943 talk contribs‎ (Fix) Tag: Redirect target changed
• Move log 16:51 Steel1943 talk contribs moved page Talk:Caret (computing) (temp) to Talk:Caret (computing) without leaving a redirect ‎(Move to former name of target page) (revert)
• Move log 16:51 Steel1943 talk contribs moved page Caret (computing) (temp) to Caret (computing) without leaving a redirect ‎(Move to former name of target page) (revert)
• Move log 16:50 Steel1943 talk contribs moved page Talk:Caret (computing) to Talk:Caret without leaving a redirect ‎(Requested by Kleinpecan at WP:RM/TR: ibid.) (revert)
• Move log 16:50 Steel1943 talk contribs moved page Caret (computing) to Caret without leaving a redirect ‎(Requested by Kleinpecan at WP:RM/TR: ibid.) (revert)
• Move log 16:50 Steel1943 talk contribs moved page Talk:Caret to Talk:Caret (computing) (temp) without leaving a redirect ‎(Move away for incoming page) (revert)
• Move log 16:50 Steel1943 talk contribs moved page Caret to Caret (computing) (temp) without leaving a redirect ‎(Move away for incoming page) (revert)

Meanwhile in the real world, caret is the common name for the insertion symbol U+2038 ‸ CARET and is the first experience of most school children. I object to such arbitrary behaviour and request support to reinstate to the status quo ante pending an adult discussion. John Maynard Friedman (talk) 20:16, 15 September 2022 (UTC)

Blame Fgnievinski for changing the primary topic; all Steel1943 did was change from "Caret" redirecting to "Caret (computing)" to the other way around, which was procedurally correct * Pppery * _{it has begun...} 20:24, 15 September 2022 (UTC)

Also see https://wiki.riteme.site/w/index.php?title=Wikipedia:Requested_moves/Technical_requests&oldid=1110467498. -Kj cheetham (talk) 20:26, 15 September 2022 (UTC)

(edit conflict) @John Maynard Friedman: Your assumption couldn't be more wrong. Caret was a redirect towards Caret (computing) for about 6 months. I moved the page in response to a request on WP:RMTR by Kleinpecan (as seen in the very edit history you referenced) after a series of edits was performed by Fgnievinski on 7 March 2022. The move was technical in nature due to Caret being a redirect towards Caret (computing) for 6 months. All edits I did on the disambiguation page were per MOS:DABPRIMARY in regards to the current situation. In other words, next time you point a finger, make sure you are pointing it at the correct editor since the finger should be pointed at Fgnievinski ... well, that, and I agree with you, and would probably support any move request that changes the current status quo. Steel1943 (talk) 20:29, 15 September 2022 (UTC)

@Steel1943: I apologise for questioning your good faith, it is just a pity that you didn't leave an explanatory note that might have saved my blushes. Obviously your procedural move was entirely reasonable in the circumstances. I don't propose to dig myself in any deeper. --John Maynard Friedman (talk) 20:48, 15 September 2022 (UTC)

I responded to this at Talk:Caret#Arbitrary and unilateral page move to avoid repeat discussions. Steel1943 (talk) 20:57, 15 September 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Respecting editors selection of "discuss = no" for technical requests

When an editor selects "discuss = no", that needs to be respected, and if the request is rejected simply removed without action. There have been a few times now that I've made technical requests, deliberately set "discuss = no" as I would want to write a different request if it is rejected, only for other editors to change that to "yes" and open a move request in my name - I would actually consider that to violate WP:TPO, as it results in the meaning of my comment being changed.

I'm not sure where we can clarify this, but it needs to be clarified somewhere. BilledMammal (talk) 00:08, 5 September 2022 (UTC)

Completely agree. The same thing happened to me a while back. Station1 (talk) 05:16, 5 September 2022 (UTC)

I also agree, not sure how best to enhance the wording to support this though. -Kj cheetham (talk) 16:46, 11 September 2022 (UTC)

As you say Kj cheetham, the instructions when posting say "if you do not wish the request to be converted into an RM if contested, then add |discuss=no". This should be respected. I did actually convert a "no" to "yes" one time, purely for ease of creating a RM discussion. But I didn't think about the consequences at the time that this was wrong because it meant I had initiated a discussion on behalf of BilledMammal which they had expressly asked not to. I'm sorry about that BilledMammal, it was a while ago, but it's not something I've done since or would do again. Polyamorph (talk) 19:43, 12 September 2022 (UTC)

Because the instructions are to substitute the template, can the template substitution logic simply be modified to include a commented note, something like | discuss = no <!--This is intentional. Please do not change without requestor's consent per WP:TPO.--> | reason = ... ? -2pou (talk) 20:57, 12 September 2022 (UTC)

If that would work then why not? Polyamorph (talk) 20:21, 18 September 2022 (UTC)

Request

Filmmaker Charlie Lyne now goes by the name Charlie Shackleton, as noted on his Twitter account in 2019. His professional profiles, including website, Sight & Sound author page and IMDb profile, have all been updated to reflect this. The change of name is already reflected in the article. 80.194.19.91 (talk) 09:15, 22 September 2022 (UTC)

References

Request moved to Talk:Charlie Lyne#Requested move 25 September 2022 for discussion, due to lack of response or action here. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:18, 25 September 2022 (UTC)

Moving editnotices alongside the subject page

There is a discussion at Wikipedia:Village pump (technical)#Moving editnotices alongside the subject page that might be of interest to watchers and participants of this page. You are requested to leave a comment, or suggestion there if you would like to. Thank you! —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:34, 26 September 2022 (UTC)

Relisting comment

Just to note that User:TheTVExpert/rmCloser which I see is the most often used tool for RM closes and relists, has been updated to include a comment box on clicking "Relist". —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:46, 30 September 2022 (UTC)

Lucas de Bolle

Hi everyone,

I tried to follow the instructions for this page:

https://wiki.riteme.site/wiki/Draft:Lucas_de_Bolle

I got an error message that I've tried to action. I've no idea though if that has worked. Any help would be great.

Thank you. — Preceding unsigned comment added by Bonjofan (talk • contribs) 12:27, 2 October 2022 (UTC)

Change to WP:RMTR template in regards to contested requests

Just wanted to make WP:RMTR regulars aware that I made this edit to the {{RMassist}} template (specifically {{RMassist/preload}}) that affects the way a contested discussion is posted on the respective talk page. Further details can be found at Template talk:RMassist#Edit performed on Template:RMassist/preload regarding time stamp, as well as the linked edit's summary. Steel1943 (talk) 20:31, 7 October 2022 (UTC)

Good idea. I just opened one at Talk:Ullibarri-Gamboa#Requested move 7 October 2022—let's see if it works! Extraordinary Writ (talk) 20:37, 7 October 2022 (UTC)

Looks like it worked. Many thanks for taking the time to fix this: I was complaining about it just the other day! Extraordinary Writ (talk) 20:52, 7 October 2022 (UTC)

Time to withdraw your complaint. Thanks a lot Steel1943. —CX Zoom[he/him] ^{(let's talk • {C•X})} 21:34, 7 October 2022 (UTC)

Thanks! I had no idea this was bothering anyone else! I'm thinking there may still need to be some sort of comment indented one level after the nomination comment to separate any relative RMTR discussion, but since the more pertinent problem is fixed for now, that great! Steel1943 (talk) 01:23, 8 October 2022 (UTC)

Inquiry about Mass move form

Per WP:MASSMOVE multi-page move is limited to 100. There's an ongoing discussion about as many as 1600 pages in one batch. Does one have to manually fill out the form for all 1600+ pages or can it sped up with the use of a bot or some other means? Qwerty284651 (talk) 14:04, 10 October 2022 (UTC)

See User talk:Tol/Archives/2022/10#Article Alerts archive page moves. Hellknowz has already requested that the said pages be moved by TolBot, a bot operated by Tol. The request is currently pending a BRFA. —CX Zoom[he/him] ^{(let's talk • {C•X})} 15:41, 10 October 2022 (UTC)

Thanks. Qwerty284651 (talk) 17:49, 10 October 2022 (UTC)

Where can I request relist of RM at Gautama Buddha?

Hello, where do I request relist of the RM for Gautama Buddha? It's currently in section WP:RM#October 5, 2022, and due to lapse in a few hours (or maybe already has by the time you read this). The RM discussion is at Talk:Gautama Buddha#Requested move 5 October 2022. Although there are a dozen !votes or so, it seems mostly like a lot of unsupported opinion (on both sides) or evidence-free policy claims, with nothing really solid to base a close on. Votes are still coming in, and I'd like to research some data first, but that will involve a day of investigation, and will put me past the time limit. If we had a week, that would (hopefully) be enough to attract some more voters (either way) who will base their opinion on actual data, and policy. Thanks. (And, where *is* the right place to request relist? Nothing is mentioned at WP:RMRELIST, and I tried editing the October 5 section, but hit edit notice which waved me off—I understand that that is the wrong place, because my comment would get overwritten by the bot. So where, then?) Time-sensitive, so adding @Robertsky and CX Zoom:; thanks, Mathglot (talk) 05:40, 12 October 2022 (UTC)

Thanks for the relisting. Will work on it over the next day or two. Mathglot (talk) 07:22, 12 October 2022 (UTC)

@Mathglot done. Without using the RMcloser script, relisting is essentially done by appending the {{subst:relisting}} template at the end of the opening section/paragraph, after the OP's signature, in the article's talk page. The bot will pick this up in the next run and update WP:RMC and other related pages. – robertsky (talk) 07:41, 12 October 2022 (UTC)

Thanks! Mathglot (talk) 07:43, 12 October 2022 (UTC)

To page movers

Hello,

Just a comment to the page movers out there, when deciding whether or not to leave a redirect during a page move, please check "What links here" and see if there are redirects to the page you are moving. If there are, and there are often are, by not leaving a redirect, you are creating broken redirects which then have to be deleted. But if there are redirects that exist to the page that will be moved and you leave a redirect when you move that page, then the Wikipedia bots can correct those existing redirects to point to the new target.

Additionally, if for some reason you don't want to leave a redirect during a page move and there are broken redirects, it would be very helpful if you either changed them yourself so they weren't broken or if you would tag them for speedy deletion. Thank you! Liz ^{Read! Talk!} 19:37, 25 September 2022 (UTC)

Indeed, no-one wants broken links being being created when they don't need to be. Also page movers should be aware of WP:PMRC, as there's only a limited number of valid reasons to not leave a redirect when moving pages. -Kj cheetham (talk) 20:39, 25 September 2022 (UTC)

Liz can correct me if I am wrong, but the issue this time may have been that sometimes redirects that have no preexisting talk pages are involved in round-robin moves. When one of those redirects ends up at the original title and no talk redirect is created, it breaks links to the existing talk page. Moves that result in broken talk pages / talk page archives are a fairly common issue worthy of a reminder. It's more of a cleanup problem than a behavioral issue like the active repression of appropriate redirects when performing one-way moves. Dekimasuよ! 06:54, 26 September 2022 (UTC)

Ahecht's swapper thankfully allows for the quick creation of the appropriate talk page redirects in round-robins. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 20:31, 12 October 2022 (UTC)

Not for talk page archives though which also get moved without leaving redirects, leading to broken links. On conversation with Ahecht, I realised it is intentional, especially when double-swapping changes the scope of parent talk page. —CX Zoom[he/him] ^{(let's talk • {C•X})} 20:44, 12 October 2022 (UTC)

Multiple relists

I'd be interested to hear people's thoughts on the question of when RMs should be relisted more than once. I generally don't do it unless there's a particularly compelling reason (e.g. when someone has made a new argument that others haven't had time to consider), but recently I've seen plenty of folks relisting for a second or third time just to attract more participation, for instance here and here and here and here. WP:RMRELIST says that "In general, discussions should not be relisted more than once before properly closing", but it also notes that "Despite this, discussions are occasionally relisted more than once". Is there any interest in loosening that language so as to make multiple relists more commonplace (as is the case at AfD and many other venues), or do we still feel that second relists should be the exception rather than the rule? I don't feel strongly either way—I just want to make sure that what I'm doing is in line with current consensus. Cheers, Extraordinary Writ (talk) 03:35, 20 September 2022 (UTC)

• Dunno. On the one hand there's no hurry, why not have multiple relists. On the other hand, an editor could relist an RfC (also AfD etc... this is a global thing I guess) indefinitely to prevent a decision or cause other mischief. Has this been a problem tho? If not let it lie I suppose. Herostratus (talk) 22:44, 20 September 2022 (UTC)

Nearly all RM relisting is busywork, a waste of time, and creates more confusion than help. Waste of time relisting is squarely comment-free relisting. Comment-free relisting adds noise and shuffles the listing order. A useful relisting necessarily includes a meaningful relist comment, such as a refocusing comment for a defocused discussion, or a note that there is new information since the early votes and it pings the early voters to come back and reconsider their votes in light of the new information. Relisters should only be qualified intending closers who on looking at the discussion see that for some reason it is not ready for closing.

The four examples are pointless comment-free relists that should not have been done. SmokeyJoe (talk) 23:13, 20 September 2022 (UTC)

Sorry boss. I strive to do better the next time round. On a more serious note, some re-relists were faults of mine for not pinging the wikiprojects earlier. And yes, terrible busywork, self-afflicted. – robertsky (talk) 15:47, 22 September 2022 (UTC)

So, some relists were done because important notifications weren’t done, and you just did them? It’s important to explicitly state that, so that the newly notified people get their seven days. Many people think that a relist means the discussion gets another seven days from the date of relist, and this is not true, another closer may decide to close even immediately after a comment-free relist. SmokeyJoe (talk) 21:50, 22 September 2022 (UTC)

At the risk of WP:BEANS, notifying a WikiProject doesn't automatically mean seven added days either. If it did, that would lead to a lot of gaming the process. Dekimasuよ! 13:58, 23 September 2022 (UTC)

If someone thinks a missed notification means the discussion seven day minimum needs to be reset, they should say so in the relist comment. A new notification doesn’t automatically justify a relist, let alone a timer reset. SmokeyJoe (talk) 23:21, 23 September 2022 (UTC)

• As an editor who occasionally closes RMs, personally I’d like to see relisted RMs segregated in the que like Elapsed and Backlog. Although there are many times good reasons to relist, there are equally relisted RMs that were ready to close when they hit backlog or elapsed status. Its frustrating to follow an RM into elapsed and backlog status with the intent to potentially close it, only to find it has disappeared. Was it relisted or closed? You got to hunt for it. It would be much easier to sort out if all relisted RMs had their own block in the RM que just above Elapsed and Backlog sections.Mike Cline (talk) 16:30, 23 September 2022 (UTC)

The table at Wikipedia:Requested moves/Current discussions (table) can be sorted by the number of days requests have been open. This order doesn't change when things are relisted, so it can be useful in searching for older discussions that might be ready for closure. Dekimasuよ! 17:10, 23 September 2022 (UTC)

That is indeed an excellent table, and I thank User:Wbm1058 again for it. SmokeyJoe (talk) 23:24, 23 September 2022 (UTC)

• For me, I prefer to follow the general AfD relisting wisdom: no reason is needed if you relist due to the lack of participants. However, if you relist it due to consensus not being clear, you should point this out in a comment. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 01:46, 13 October 2022 (UTC)

Talk:Roxas City#Requested move 23 September 2022

This has been ongoing for almost a month and has no further discussion from the day it was proposed. Requesting closure. Howard the Duck (talk) 02:26, 17 October 2022 (UTC)

Done. Judekkan (talk) 03:02, 17 October 2022 (UTC)

Thanks! Howard the Duck (talk) 12:25, 17 October 2022 (UTC)

RMCI loophole?

In the MRV for Modern paganism, the OP complains that while the closer mentioned the previous RM, they didn't take it into account in their decision on determining consensus. (The RM had unequivocal support for the move.) Given the wording of how WP:RMCI#Determining consensus is written, I endorsed the close. WP:RMCI states Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Wikipedia community in general as reflected in applicable policy, guidelines and naming conventions. (Emphasis mine.) Likewise, the second paragraph makes a similar statement which doesn't seem to lend itself to requiring the closer to allow any weight from previous RMs, nor allowing them to do so. The only caveat given there to WP:IAR is when the requested move will break policy or guidelines or naming conventions.

Is this a loophole? Should the existing wording mean that the closer should consult previous RMs? Should the wording be changed to allow and/or require the closer to make such considerations?

If yes, are there other pieces of work that the closer may want and/or need to consult? (ARB decisions regarding the article in question come to mind for an RM I closed where I took the ARB edit edict of the article into account. This RM is still in MRV.)

Thoughts? - UtherSRG (talk) 15:41, 20 October 2022 (UTC)

Should the closer consult the previous RMs? I think: Yes, but.

The onus to link and provide some comment on previous RMs should lie with the RM nominator. I note that the best RM nominations summarise the prior RMs and why they failed or did something different.

It would be nice if the RM template auto-listed prior RMs, like happens with AfD, but prior RMs are sometimes on unexpected different pages. Maybe just a templated spot and display for prior RMs, like what MRV does for “discussion with closer”. Just having the prompt has a good effect. SmokeyJoe (talk) 21:33, 20 October 2022 (UTC)

I like your suggestion that the RM nominator should have some burden here. And I agree that it would be nice if the template could accommodate. Perhaps the instructions at WP:RM#CM could be updated for including how to at least include pointers to the previous moves, with suggestions for how to locate ones that are not immediately obvious.

That said, RM nominators are not expected to be as knowledgeable as RM closers are. As such, I don't know if all of the burden lies on the nominator. So, given the wording of RMCI, and given an RM that doesn't mention the previous RMs (failed or otherwise), should the closer consult the previous RMs? Or perhaps a better question is: Is there a mandate for the RM closer to consult previous RMs if the previous RMs were not mentioned in the current RM? - UtherSRG (talk) 01:13, 22 October 2022 (UTC)

Personally if I was going to close an RM I'd only look at previous RM in any detail if they were referred to in the latest discussion (anyone involved in the discussion, doesn't need to be the nominator). -Kj cheetham (talk) 12:38, 22 October 2022 (UTC)

P.S. The older a previous RM was, the less weight I'd give it, if any. -Kj cheetham (talk) 16:04, 27 October 2022 (UTC)

There is nothing wrong with a closer reviewing the content of prior RMs, but there is the question: To what end? What information in a prior RM is relevant to the current RM? Policy-Guideline-Essay references? Have previously valid facts—NGRAMS, page views, etc. been invalidated in the new RM? Are the prior RM decisions relevant? What about the scenario where previous RMs over the course of years have always had the same result. What has changed to prompt the current RM? In most cases in my experience, the nominator just doesn’t like the previous decisions. Should the closer conclude that the community has made a consistent decision over the last decade through multiple RMs, especially if nothing significant has changed, and close the RM consistent with the decisions in prior RMs.

An additional speed bump appears if a closed RM decision that relies on significant data in previous RMs makes to MRV. Can the closer be challenged as a SuperVote! if there is a strong reliance on prior RMs in the current decision? I can just imagine the complexity of that discussion. IMHO, move with some care here.Mike Cline (talk) 14:07, 22 October 2022 (UTC)

If the closer discovers important information in a previous RM not linked or even mentioned in the current RM, they should draw attention to that previous RM and the important information and relist, not close. SmokeyJoe (talk) 21:43, 31 October 2022 (UTC)

advertising while first relist

Hello. In case there is no participation in the first week of an RM, while relisting I notify the related wikiprojects in the hopes of getting more participation. Recently I came across Favonian, who does the same. I was wondering, is there user-script to make that faster? Also, should we make it a protocol/guideline to notify relevant wikiprojects if there is zero, or almost zero participation (one vote, and lots of discussion between OP, and voter; or something similar)? If the discussion here is in favour, then we can take it to VP/PR. —usernamekiran (talk) 09:00, 2 November 2022 (UTC)

@Usernamekiran: I use User:TheTVExpert/rmCloser, which makes relisting and advertising a lot simpler. Favonian (talk) 09:07, 2 November 2022 (UTC)

thanks Favonian, I added to my common.js Any thoughts on making it a guideline? —usernamekiran (talk) 09:13, 2 November 2022 (UTC)

Positive, in principle, though I wish we had data regarding the rate of success for such notifications. As of today, the case in which we are both involved is not encouraging. Favonian (talk) 10:55, 2 November 2022 (UTC)

I went through my previous contributions, and the results are not much promising. During Talk:Powertrain layout#Requested move 27 July 2022 I had notified four wikiprojects, yet there was zero participation in the next week. I guess not many editors actively watch talkpages of wikiprojects, or maybe they don't participate in the RMs if the subject doesnt interest them much. In most of the RMs, I see familiar usernames, making me think they are RM regulars (coming to RM from WP:RMC, instead of article/TP or wikiproject). A downside of the RM relist notification can be spamming wikiproject talkpages. But given we would only notify them if there is no participation in the first week, I think notifications would not mount enough to be felt as spamming. —usernamekiran (talk) 10:37, 3 November 2022 (UTC)

A thing I will be doing

First of all, I've noticed that a few to several editors, who help on this page, have been using the summary: "done 1" , or "done 2" , or "done 3" and so on, when removing completed requests from the RM/TR project page. It struck me as a concerted effort to respect and honor AA, A befitting tribute in my opinion, and a thing I am now doing as well. The other thing I intend to start doing is to reply to a technical request with {{doing}} when I begin the round robin process to swap the pages. It is a prudent measure to avoid wasted duplication of effort. Hopefully others will see the benefit and adopt the practice themselves, but it is a thing I will be doing from here (except when I forget). Best regards. --John Cline (talk) 01:09, 3 November 2022 (UTC)

It would be simpler still to remove the request before actually moving the pages (if you encounter a roadblock such as title blacklist or move protection, just revert yourself; it should be moved to "administrator needed" section anyway). Of course, everyone should follow the same steps to prevent conflicts.
I've actually had "move conflict" while swapping pages two times. It was quite funny actually, because it resulted in reverting the swap previously done by the fellow mover. No such user (talk) 08:48, 3 November 2022 (UTC)

I can see how your idea would be more effective (almost full proof). I'm not entirely certain, however, that it would be simpler (in my opinion the jury's still out on that one). I too have conflicted with others as we simaltaioneously handled the same request. I suspect it's happened to most (if not all) of us at one time or another. I do think it would be good for us to become proactive in preventing these eventualities instead of beholding the status quo where they are certain to recur at interval. Best regards.--John Cline (talk) 10:02, 3 November 2022 (UTC)

Similar thing, but not entirely, has happened to me in the past. After closing an RM on talkpage, I got edit conflict. Apparently another user had moved the page, with intention to close the RM afterwords. I agree with No Such User, it would be a simple solution. But necessary thing is, everybody follows the same practice. —usernamekiran (talk) 10:23, 3 November 2022 (UTC)

I don't know how common is this, but I probably also edit-conflicted during a past RM closure. —CX Zoom[he/him] ^{(let's talk • {C•X})} 22:54, 7 November 2022 (UTC)

RM closers have the additional {{closing}} tag that can be used since some take a significant amount of time to write up adequately. The RM/TRs, though, tend to be much quicker, and simply removing them from the list ahead of the move is probably the better alternative. - UtherSRG (talk) 12:01, 10 November 2022 (UTC)

Requested move 18 November 2022

Moved to Talk:AXS_(company)#Requested_move_18_November_2022 (diff)

Primefac (talk) 14:11, 18 November 2022 (UTC)

Requested moves creating links to disambiguation pages

In an earlier discussion - I do not remember where - it was determined that pages movers were not bound to solve the links to disambiguation pages their page move creates. Although I agree with that stance, it makes me unhappy that that effect is now off-loaded to others. Is there a request page (or other option) where these moves can be listed so that a bot operator can pick them up and solve (the bulk of) them? The Banner talk 14:20, 10 November 2022 (UTC)

Would be interested to know if there's such a page as well. I usually resolve such inbound links though AWB for the discussions I close, except for when it is too large or takes too much time for me to handle, like after I had done the close for Australian where there were 3-4,000 links. The backlog was however cleared within the day or so when there were at least two other editors working on updating the links as well. – robertsky (talk) 14:27, 10 November 2022 (UTC)

Page movers (in the broad sense of the term) should repoint incoming redirects and fix links in navigation templates, but they aren't otherwise required to fix dab links, though they're encouraged to help if they can (see the second paragraph of WP:FIXDABLINKS and its footnote).

The place to ask for help is WT:DPL. This project's participants are currently quite active and will most likely swipe up any dab links by the end of the next working day even if you don't ask them to. Bots aren't useful unless in exceptional circumstances because fixing links is sensitive to context. – Uanfala (talk) 14:56, 10 November 2022 (UTC)

Recently, a lot of work was done and the list here is now much shorter. But still you have Iranians with 175 incoming links. As far as I can see, page mover do not fix links in templates. I still see a lot of them showing up at the maintenance page. The Banner talk 17:02, 10 November 2022 (UTC)

page mover do not fix links in template... that's a sweeping statement, but I get you. – robertsky (talk) 17:10, 10 November 2022 (UTC)

Correction, As far as I can see, too often page movers do not fix links in templates.. The Banner talk 17:12, 10 November 2022 (UTC)

Just went to WT:DPL for help with this move close at Show and tell (disambiguation) after reading this talk page section, thanks for the good pointer, folks!! :) — Shibbolethink ^{(♔ ♕)} 15:29, 11 November 2022 (UTC)

• I'm on the same page with Robertsky, and Unfala. Few months ago, I tried to create this userpage, but I didn't list all the link-fixes I performed. I'm willing to accept requests for NOCONTEXT link changes (that's usually before the move, it gets a little messy post move). —usernamekiran (talk) 19:35, 21 November 2022 (UTC)
• In my experiences, I usually at the least fix WP:BRINT issues, and then reevaluate the incoming links later to see if I can fix some (but hopefully all) of them. Steel1943 (talk) 00:26, 22 November 2022 (UTC)

Need to update WP:RMTR instructions?

For the last few months, I've been seeing a lot of clearly non-technical requests posted at WP:RMTR. I think that it may be time to provide some kind of essay or instructions explaining what a technical request is and is not, including reasons why some requests that appear to be technical will be contested due to controversial reasons. (And I'm saying this not knowing if I'll have time to write this, but just bring this up in case someone else might feel enthralled to do so.) Steel1943 (talk) 18:44, 21 November 2022 (UTC)

Personally I'm not convinced an essay would reduce the number of such requests, but could be something to be pointed at in response to such requests. There's already guidance at the top of WP:RMTR and in a box at the right, plus at the higher level WP:RM. For "Administrator needed" requests there is a guide, which is not always looked at by requestors. -Kj cheetham (talk) 14:17, 25 November 2022 (UTC)

Requested move

As an IP I am unable to request a page move (which seems a bit odd), but could someone add to the list (or go ahead and move) The Shoes of the Fisherman (movie) to The Shoes of the Fisherman (film) in line with the naming conventions? Thanks - 2A00:23C7:2B86:9801:6562:A1FC:F7F2:51BF (talk) 16:15, 28 November 2022 (UTC)

• I have gone ahead and moved the article. BD2412 T 16:24, 28 November 2022 (UTC)

• Thanks very much! 2A00:23C7:2B86:9801:6562:A1FC:F7F2:51BF (talk) 16:35, 28 November 2022 (UTC)

  FYI - WP:RMTR is the place to request moves that you yourself cannot perform. - UtherSRG (talk) 16:46, 28 November 2022 (UTC)

• Ah, I thought there must be somewhere, but couldn't it. Thanks for the info. - 2A00:23C7:2B86:9801:6562:A1FC:F7F2:51BF (talk) 08:42, 1 December 2022 (UTC)

Two moves at once?

Is it permissible/possible to operate two RM discussions at the same time for the same article? E.g. request a move of "Article X" to "Article XYZ" and also a move of "Article X" to "Article ABC"? Elizium23 (talk) 20:17, 30 November 2022 (UTC)

Why not just discuss both options in the same RM discussion? -Kj cheetham (talk) 20:20, 30 November 2022 (UTC)

Generally, we do not permit two RM discussions at the same time. However: the question arises in the context when a RM for one article identified a consistency problem and triggered a bundled RM for multiple related articles (Talk:Sexual abuse scandal in the Catholic archdiocese of Chicago). I believe the best course of action was to procedurally close the first RM and bundle it with the second, but that did not happen (it was unbundled instead). However, the situation occurs rarely enough that we don't have to make a rule for it. No such user (talk) 11:30, 1 December 2022 (UTC)

moving/re-titling the page from Terence Trent D'Arby to Sananda Maitreya.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hello, we are opening a discussion about moving/re-titling the page from Terence Trent D'Arby to Sananda Maitreya.

We kindly request to have all the content of the page moved in full to https://wiki.riteme.site/wiki/Sananda_Maitreya and to have the page renamed to "Sananda Maitreya". Since April 2021 the whole discography has been renamed to Sananda Maitreya and it is correct that also wikipedia follows this worldwide update.

Just as one of many examples please check the very first album Introducing The Hardline on Spotify and on Apple Music. Also please check the italian wikipedia page, which already reflects this.

Thank you very much for your precious help in this matter. Francesca Sananda Maitreya - staff (talk) 16:06, 4 December 2022 (UTC)

Hi, please check WP:RM#CM to start a discussion to move the article. The request needs to be done at Talk:Terence Trent D'Arby. Let me know if any question. Vpab15 (talk) 16:33, 4 December 2022 (UTC)

Hi, @Sananda Maitreya - staff: Welcome to Wikipedia, there are a few things I'd like you to know:

• Your username is not in accordance to Wikipedia's policies. Each account must be owned by a single individual. The current username gives the impression that it is an account of the organisation, you can rename your account. Relevant links are shared on your talk page by Uhai.
• If you have a connection to the subject of any article, personal or professional, you constitute a conflict of interest, so please avoid to edit the article directly, but feel free to start discussions at the article's talk page. If you need an edit be done, put {{edit request}} right above your request, an independent reviewer will review it and perform the edits if appropriate. Again, relevant links are shared on your talk page.
• You opened the move request at the wrong place, please follow the instructions by BD2412 below. Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:36, 4 December 2022 (UTC)

@Sananda Maitreya - staff: Per the instructions at WP:RM#CM, to request this page move, click on the "New section" (or "Add topic") tab of Talk:Terence Trent D'Arby, without adding a new subject/header, inserting the following:

{{subst:requested move|Sananda Maitreya|reason=Since April 2021 the whole discography has been renamed to Sananda Maitreya and it is correct that also wikipedia follows this worldwide update. Just as one of many examples please check the very first album Introducing The Hardline on [https://open.spotify.com/album/6K0ySLloZibpwuTsVe7fxS Spotify] and on [https://music.apple.com/gb/album/introducing-the-hardline-according-to-remastered/1632646636 Apple Music]. Also please check the [[:it:Sananda_Maitreya|italian wikipedia page]], which already reflects this.}}

Cheers! BD2412 T 16:35, 4 December 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Straightforward backlogged close

I think that Talk:Mahsa Amini protests#Requested move 9 December 2022, currently in the backlog, shouldn't be difficult for a close by an uninvolved person, though I won't say which way I think it will be closed, since I'm the formal proposer (in reality, I was only trying to tidy up a messy procedural situation, so I'm not quite the real proposer). Boud (talk) 00:57, 19 December 2022 (UTC)

 Done Polyamorph (talk) 08:12, 19 December 2022 (UTC)

Related discussion at Wikipedia:Village pump (proposals)#New bot to change wikilinks following a requested move

Hello! There is a discussion at Wikipedia:Village pump (proposals)#New bot to change wikilinks following a requested move related to requested moves. Thanks, echidnaLives - talk - edits 23:36, 3 January 2023 (UTC)

Focused Ultrasound Foundation

Hi, I am requesting a page to be renamed/moved. I am requesting it to be moved here rather than moving myself per the Wiki:MovingAPage guidelines that first suggest it be requested here before attempting. The reason is this organization is no longer called "Foundation for Ultrasound Research" it is now called "Focused Ultrasound Foundation". The Wiki page is https://wiki.riteme.site/wiki/Foundation_for_Focused_Ultrasound_Research Voila34228 (talk) 21:56, 11 January 2023 (UTC)

WikiData errors

-snip- (I moved this over to Wikipedia talk:Page mover#Wikidata errors, I think that's a better place to ask, but since this page has significantly more watchers, if you might have an answer to why page moves are breaking wikidata interwiki links, please check the discussion over there, thanks!) ASUKITE 17:04, 13 January 2023 (UTC)

Move Utsav Naik (Gujarati actor) page to top-level

I have created the page at https://wiki.riteme.site/wiki/Draft:Utsav_Naik . I am a Gujarati movie actor with 2 upcoming movies. I have added all the credible sources required from popular news publications Utsavnaik12 (talk) 21:12, 14 January 2023 (UTC)

As you have already noticed, WP:AFC is the process for new users wanting to move pages from Draft to mainspace. Your submission is in the queue and it will be reviewed by a reviewer, hopefully in the next 1 or 2 months. Iffy★Chat -- 21:27, 14 January 2023 (UTC)