Wikipedia talk:Requested moves

Enter the title (or part of a title) to search for after "intitle:", then click "search"

Try other variants (e.g. "move discussion") to broaden or narrow your search

Locked

What is the point of locking this page for editing to autoconfirmed users if one of its intended uses is to allow unregistered and new users to request a move? "He opened a pub, but people kept visiting it," as we say in Czechia... --93.91.252.108 (talk) 21:27, 13 December 2019 (UTC)

You don't request potentially controversial moves on Wikipedia:Requested moves. Please make the move request on the talk page of the article you want to move.

You may make technical requests on the page Wikipedia:Requested moves/Technical requests, which currently isn't protected. – wbm1058 (talk) 21:56, 13 December 2019 (UTC)

New technical requests: Place at the top or bottom of the list?

The instructions for uncontroversial technical requests are in a hidden comment, and say:

• Insert the following code in the appropriate section, filling in page names and reason:
• {{subst:RMassist| current page title | new page title | reason = reason for move}}
• ---- and enter on a new line, directly below

That is, newer requests are placed at the top, like XfD. This is not particularly enforced, although seems to be mostly followed. As noted above, Twinkle now supports basic Requested move nominations, and follows those instructions at WP:RM/TR. Ammarpad requested a change to that behavior, asking Twinkle to place newer requests at the bottom, like RfPP or AIV. As such, I figured I'd open a section here to see if those instructions should change. ~ Amory (u • t • c) 16:12, 16 December 2019 (UTC)

Note that as well as the text "directly below" in the comment, the page's edit notice Template:Editnotices/Page/Wikipedia:Requested moves/Technical requests says "insert the following code at the top in the appropriate section" – wbm1058 (talk) 17:09, 16 December 2019 (UTC)

• The instructions are clear about placing newer requests at the top, and seem to be followed. I see no reason to change. --В²C ☎ 17:06, 16 December 2019 (UTC)

  Not necessarily, I've wandered about this myself and have done it sometimes at the top and sometimes after. "Directly below" could mean directly below existing comments or at the top). Crouch, Swale (talk) 18:41, 16 December 2019 (UTC)

  We could change "directly below" to "directly below this line" to avoid any ambiguity. Station1 (talk) 02:10, 17 December 2019 (UTC)

  Agree, WP:CFDS says "PLACE NEW NOMINATIONS AT THE TOP OF THIS LIST, BELOW THIS LINE". And its usually less difficult to work that out since items there tend to stay for 48 hours so show up in order while those at RMT are removed after being moved which is not normally more than a few hours. Crouch, Swale (talk) 08:12, 17 December 2019 (UTC)

  If anyone does change it, just let me know so I can update Twinkle! :D ~ Amory (u • t • c) 01:57, 22 December 2019 (UTC)

• I am the one who made the initial request, but after the initial objection I made it clear I don't want discuss this any further (because frankly I see the isssue not worth wasting time over) However I am commenting again since Amory mentioned me here. My reason of making the request (thinking it was just trivial) seems to be shaped with my workflow. Whenever I open the page I use to start from the topmost listing (which may have been placed just a minute before). If there are many entries for the day, the one at the bottom may spend several hours before being actioned, because of more and more newer requests that are being added. It also occurred to me at the time that the new behavior (listing at the top) started in few weeks/months back as before that most newer requests were placed at the bottom of existing requesting with very few exceptions, (I have not verified this with the page history, but I quite believe it's so). In addition, in many similar boards requests are placed at the bottom of existing request not top, to give few examples WP:RFP and WP:AIV. That was basically what prompted me to seek for the change. To repeat what I said, I don't think there's any benefit in discussing this further, I'd just adjust to the new style. – Ammarpad (talk) 23:28, 17 December 2019 (UTC)
• I have made this change, namely updating the comment to say directly below this line (emphasis added), as well as a further comment also recently added regarding newlines and accessibility (see conversation at WT:TW. Please let me know of any additional changes or tweaks so I can update Twinkle. ~ Amory (u • t • c) 11:57, 31 December 2019 (UTC)

I notice the comment/instructions got changed back. So people (including me) got confused and put newer entries at the bottom of the list. I changed the comment to be clearer. Also I notice several people put blank lines between entries (2 blank lines in one instance), when the comment/instructions CLEARLY say no blank lines. So maybe people just don't read.

I also don't understand why people are making these requests from IP numbers (i.e. they're not logged in) for moves where the target page is a redlink. Just log in and they can make the move themselves. Maybe we could put a helping notice to that effect as well in the comment/instructions. LisztianEndeavors (talk) 15:10, 23 January 2020 (UTC)

Many IP editors don't have accounts. Some don't want accounts, but even if they open one, they can't move pages until they're confirmed. Station1 (talk) 21:32, 23 January 2020 (UTC)

When technical requests are contested...

When technical requests are contested... what usually happens is it gets converted into a regular RM. That sounds good but this is often problematic. First of all, when someone makes a technical request in good faith they assume there is no potential controversy and therefore don't fully explain the reasons for the move. So when it becomes an RM there usually is no strong argument. I find this problematic for two reasons. First, as someone looking at an RM request with weak or no argument I tend to oppose. Secondly, if I'm the person who made the initial technical move request, I don't want it converted to a regular RM request if it's contest. I want it rejected and for me to be notified. Then I could look at and consider the reason given for contesting/rejecting. That might tell me something I overlooked and that the move is not worth proposing - why waste any more time on this? But if I still think it should be moved then I can prepare a proper RM, that day, later in the week, or perhaps months later.

So what I'm proposing is that when technical requests are rejected due to being contested (whether you or someone else is contesting), just delete them and notify the person who made the request. Let them decide whether to even pursue it as a regular RM, and, if so, how to present it. --В²C ☎ 01:30, 17 December 2019 (UTC)

• How often does this happen? Every contested technical request should be taken as a TROUT. If you are making technical requests without serious consideration of possible reasons for contesting/rejecting, then you are not using sufficient consideration and should wind back on doing technical requests. That said, I think I agree that, by default, a rejected technical request should be flicked back at the nominator, not auto-made into a formal RM. I think it could/should be left to the discretion of an WP:RMTR#Contested technical requests admin-clerk. --SmokeyJoe (talk) 01:56, 17 December 2019 (UTC)
• This sounds reasonable to me. I've participated in a fair number of RMs that were born out of contested technical requests and they do tend to begin in a confused state for the reasons you mention. One little complication: an unscrupulous (or confused) editor who has a technical request bounced might just wait a while and then file it again. If they're lucky, no-one will notice, and it might succeed on the next try. Whereas if it got converted into an RM, that would create a permanent record of the previous request. I don't think this is likely to be a significant problem, but just playing devil's advocate. Colin M (talk) 02:08, 17 December 2019 (UTC)
• Born2cycle, see Template:RMassist#To opt out of discussion, if the request is contested. There have been requests in the past to make |discuss=no the default, and force editors to specify |discuss=yes if they want their contested requests automatically converted, but these proposals have been rejected. Search the archives. And I agree that every contested technical request from a highly experienced editor like you should be taken as a TROUT. – wbm1058 (talk) 05:31, 17 December 2019 (UTC)
  • Even if, for example, it's a technical request to revert a recent undiscussed move filed at Wikipedia:Requested_moves#Requests_to_revert_undiscussed_moves? --В²C ☎ 17:44, 17 December 2019 (UTC)
    • I'll assume you're referring to Cinema of Georgia. Yes, that one was a little awkward. Ideally the earlier discussion at Film industry in Georgia (U.S. state) would have been filed as a multimove discussion, but it's not unreasonable to take from Film industry in Georgia needing disambiguation that Cinema of Georgia would also need disambiguation. So the two admins here could have been less bold, but they weren't blatantly unreasonbly bold in their administrative decisions. It's not a good look to see you reverting two admins, even if technically you are procedurally correct. Show a little patience and let a discussion run for a week or two if necessary, even if the discussion is technically being hosted on the "wrong" title, it should be no big deal. I don't think there should be any "first-mover advantage" in cases like this, so it really shouldn't matter that much what title the article is sitting on during "discussion week". A little less reverting may lead to more feelings of good will. – wbm1058 (talk) 21:11, 17 December 2019 (UTC)
• If all contested requests are automatically removed that would just create another problem, inexperienced users may just continue listing the article, I have seen this already. I believe the current behavior is fine, experienced users should already know about |discuss=yes and use it to suppress the link if necessary. So no change is needed here. – Ammarpad (talk) 22:54, 17 December 2019 (UTC)
  • Just to comment on that, I've been part of many, many RM discussions and initiated many myself and I've never once visited the actual Template:RMassist page as WP:RM documented how the template should be used and it never mentioned |discuss=. Also twinkle as far as I can tell, does not support that option. --Gonnym (talk) 12:16, 31 December 2019 (UTC)
    • Yeah, those are all good points, and should be fixed. --IJBall (contribs • talk) 16:26, 31 December 2019 (UTC)
• Totally agree with В²C. When making a technical request I make my rationale telegraphic so that it fits in the automatic edit summary of the move. If I had wanted to start an RM, I would have done so and taken the time to provide a fuller explanation. Also, I'm really uneasy with the way contested requests are normally handled, with the original RMT simply pasted into the format of an RM request. At the very least, this creates a talk page post ostensibly signed by an editor who did not make that post (and a minor point: given that the technical request's original timestamp is used (which is usually several hours before the time the RM has been initiated), then the RM will appear to have been running for a bit longer than it actually has). And yes, I've been using RMT for years and it has never occurred to me to look up the template's talk page and it has never occurred to me that there could be a switch that can turn off the default behaviour, at the least because I never would have expected the default behaviour to be what it is. – Uanfala (talk) 03:08, 8 January 2020 (UTC)
  • I've just added a mention of |discuss=no to the hidden text at RMT [1], though I don't think this solves the fundamental issue. – Uanfala (talk) 03:18, 8 January 2020 (UTC)
    • It was removed, probably accidentally. I restored it. It's a good idea. Station1 (talk) 10:02, 8 January 2020 (UTC)
      • This has been removed yet again, almost immediately after you've added it. The reasons why this happens: the text at the top of the RMT, transcluded from Wikipedia:Requested moves/Technical requests/Instructions, has a button, invisible to everyone except sysops and pagemovers, that clears the requests, and this clearing is achieved by restoring an old revision of the page. I think I've fixed that now [2].
        I'm wondering though, if a more substantial change to the boilerplate text might not be in order. See, the instructions don't documented this practice, and if anything they lead you to not expect it. It's got three bullet points: how to list a request, how to object to a request, and how to start an RM if you request is contested. The presence of this third point sends the message that it's up to you to start an RM, and that makes it even more surprising to see your technical request turned into an RM as part of standard clerking. – Uanfala (talk) 21:48, 26 January 2020 (UTC)
• I've thought about this a little bit more, and I'm finding this practice of automatic conversion to RM even more baffling than before. I can't think of an analogue in other processes on wikipedia. Take deletion, for example. If you tag a page for speedy deletion, or if you prod an article, and then someone objects, then what they'd do is remove the tag and notify you. They wouldn't automatically convert your prod into an AfD, would they? Sending contested techincal requests to RMs makes sense only if the original proposer is a sporadic editor and you don't expect them to be around when their request is challenged. I really can't see why this should be done in any other circumstances.
  And I really don't buy the argument that experienced editors shouldn't make technical requests that will be challenged. The naming conventions can be complex and it's not unusual for a moderately experienced editor to believe something to be a straightforward uncontestable application of a guideline, when in fact there would turn out to be another guideline that overrides that (think of the exceptions to the exceptions to the exceptions when it comes to the capitalisation of French operas). And it is equally likely for the objection itself to be raised out of unfamiliarity with the guidelines: RMT is not patrolled only by seasoned admins, but by newbie pagemovers and by the requesters of the moves themselves. I did have a request contested some time ago by an anonymous editor who believed the cleanup following up on the move wouldn't get done; I had forgotten about this request and I wasn't notified when it got turned into an RM, so when I did come across it a bit later I was totally creeped out at seeing my signature after an RM I had not started. – Uanfala (talk) 22:09, 26 January 2020 (UTC)
• @Uanfala: please review past discussions as outlined at Wikipedia talk:Requested moves/Archive 32#No more discuss link on technical requests – wbm1058 (talk) 03:16, 27 January 2020 (UTC)

Confusing point in "potentially controversial"

In the section that appears as "Requesting controversial and potentially controversial moves", it has the following point:

• *there has been any past debate about the best title for the page;

I could interpret this either as:

• It's potentially controversial if there's been some notable debate in the past

-- or, possibly --

• It's potentially controversial if there's been no discussion.

If both interpretations are intended, shouldn't they be separate points?

Can we better clarify the distinction? --A D Monroe III^(talk) 19:29, 18 December 2019 (UTC)

• It refers to the first interpretation... the move can be considered “controversial” if it has been debated before. Blueboar (talk) 20:08, 18 December 2019 (UTC)

• Is there an equivalent of WP:BEFORE for this? Penistone Line was moved today "for consistency" (and then reverted), yet there's a two year old talk: thread on this where the same move was rejected, because these names are not consistent (some have reasons why they're capitalised). Should those both requesting a move, and actioning a move, check for similar discussions before one of these "non-controversial technical moves"? Andy Dingley (talk) 22:09, 8 January 2020 (UTC)

  Yeah, that was a mess-up. Tony1 apparently forgot that he had participated in my RM discussion about that back in 2017, and thought it looked non-controversial (which I can see, since the evidence is strong that lowercase dominates for Penistone line). So, mistake was made. How often does this happen? I wouldn't think putting more burden on the tech movers to check such things would be a better solution than leaving it up to watchers to object and fix. But yes the proposer should check; I've been guilty of missing such things a time or two myself, but I do usually remember to check. Dicklyon (talk) 01:15, 9 January 2020 (UTC)

• I didn't recall participating in the RM three years ago. I saw that "line" is lowercase in almost all of the many siblings listed in the navbox at the bottom of the article, and thought: no brainer. Tony (talk) 01:24, 9 January 2020 (UTC)

  And I agree: no brainer. Yet as Blueboar points out, it is considered controversial because it has been debated before. Let's discuss it again, and maybe the strong evidence will convince people this time. Dicklyon (talk) 01:27, 9 January 2020 (UTC)

• • I hate to say it, but experience tells me that almost any move involving “decapitalization” should be considered potentially controversial. Capitalization seems to be one of those issues that is continuously debated. Blueboar (talk) 01:58, 9 January 2020 (UTC)
    • Agree. Title changes concerning styling or disambiguation should be never considered suitable for bold moving, unless done by the article creator on a recently created page. Even if there is a directly applicable line of a guideline, because that is evidence of policy-practice mismatch and policy-practice mismatches require getting light of a discussion. —SmokeyJoe (talk) 02:07, 9 January 2020 (UTC)
      • My impression is different. Probably 98–99% of my downcasing moves never get a comment, even those that need to come here for a technical. Most articles get created with caps because editors don't know better. Dicklyon (talk) 02:09, 9 January 2020 (UTC)
        • What if we excluded all articles of less than six months, created by editors of under 500 mainspace edits? At NewPagePatrol, and AfC acceptances, it is normal to fix the title. —SmokeyJoe (talk) 02:14, 9 January 2020 (UTC)
          • Many articles that I fix have been around for many years, with a properly cased redirect that got tagged by a bot so a technical is needed. Dicklyon (talk) 02:16, 9 January 2020 (UTC)
          • My most recent RMTR downncasing request I actually withdrew, because the better title didn't need a technical. It was an over-capitalized article from 2005. Dicklyon (talk) 02:21, 9 January 2020 (UTC)
          • Previous to that, this one where since 2017 the title had caps where the article text used lowercase in sentences. Clearly just a failure to understand that we do article titles in sentence case. Dicklyon (talk) 02:26, 9 January 2020 (UTC)
          • Plus, even experienced editors have a tendency to over-capitalize stuff that's dear to them, so giving special treatment to original titles by experienced editors would be weird. Dicklyon (talk) 02:28, 9 January 2020 (UTC)
          • Before that, this one of a 2006 over-capitalization. Sure you could argue that it's "potentially" controversial, but based on all the discussions of others like it, this was clearly the consensus decision and another RM would be a waste of time. Dicklyon (talk) 02:35, 9 January 2020 (UTC)
            • Did I mention that policy-practice mismatch means that policy is disconnected from the community. Discussion is not just for reliable deliberation in decision making, but for the learning of all involved. —SmokeyJoe (talk) 02:33, 9 January 2020 (UTC)
              • No, I don't think you did. Dicklyon (talk) 02:35, 9 January 2020 (UTC)
                • No. Thought I did, must have imagined it. I'd prefer "uncontroversial" to be worded "for reasons that everyone already knows and agrees with". If you were asked you list your many capitalization fixes (RMTRs plus straight moves), I'd hope they bundle easily. --SmokeyJoe (talk) 03:44, 9 January 2020 (UTC)
                  • Oh, yes, you did mention that. Seems rather theoretical compared to cases I deal with though. Dicklyon (talk) 06:24, 9 January 2020 (UTC)
        • "Probably 98–99% of my downcasing moves never get a comment, "'

That's because of the volume you move, not because they're uncontroversial. Please don't ever assume that an inability to keep up with you is some acquiescence to them. Andy Dingley (talk) 11:43, 9 January 2020 (UTC)

Agreed. And agree with SJ: Any move for style changes should be considered potentially controversial (requiring an RM discussion unless it’s a revert of an undiscussed move). —В²C ☎ 16:53, 9 January 2020 (UTC)

Note... My saying that style moves (such as decapitalization) are controversial does NOT necessarily mean they are “wrong”... something can be correct and yet still be controversial. Blueboar (talk) 17:16, 9 January 2020 (UTC)

Agreed. What's "wrong" is moving for style reasons without discussion (because any style move is potentially controversial), not necessarily the move itself. --В²C ☎ 18:30, 9 January 2020 (UTC)

The theory that my many moves were wrong due to their quantity rather than their quality, and the theory that moves without controversy are "potentially controversial" just because they involve style, have been discussed and rejected elsewhere. A handful of anti-MOS voices want to say that a move motivated by the guidelines in the MOS are controversial, but that idea has never had much traction. Of course, sometimes they are controversial, and we discuss them, but those aren't the ones we're talking about for which the technical/uncontroversial process is used. Dicklyon (talk) 21:12, 9 January 2020 (UTC)

Well, certainly if MOS guidance potentially conflicts with usage in reliable sources then there is definite controversial situation to discuss. But to use the example you gave above, Soufrière Hills volcano, here we have reliable sources like USA Today[3], Science Trends[4] and BBC[5]using Soufriere Hills Volcano or Soufrière Hills Volcano, and, so, you were out of line filing a technical request, let alone moving it yourself unilaterally. --В²C ☎ 21:29, 9 January 2020 (UTC)

Well, the MOS seldom "conflicts" with sources. In the case of the volcano example, that's not anywhere near consistently capped in sources, and the MOS suggests avoiding unnecessary caps. There's no conflict in that just because some sources have a different style that caps it. Dicklyon (talk) 22:19, 10 January 2020 (UTC)

Oh, look, I fixed one within 6 months of its creation. Would it have been less good if I hadn't found it for a few more months? Dicklyon (talk) 06:04, 11 January 2020 (UTC)

• Of course it is more good to fix errors sooner than later. It would be more good of you to post an explanation, whether on the talk page, or the article creator's user_talk page, and to be sure to include a link to the most relevant guideline. --SmokeyJoe (talk) 02:10, 14 January 2020 (UTC)

Join the discussion of possible removal of the process Technical move request

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Proposal:_Removing_Technical_Move_Requests_Process — Preceding unsigned comment added by Regice2020 (talk • contribs) 21:24, 15 January 2020 (UTC)

ElectrifAi

"Please change the name of this article to ElectrifAi. Reason: The name has changed in 2019. Citations: https://www.prnewswire.com/news-releases/electrifai-a-global-leader-in-practical-ai-and-machine-learning-announces-new-ceo-and-launch-of-industrys-first-open-source-platform-300884394 :https://www.design-engineering.com/electrifai-launches-ai-industrys-first-open-source-machine-learning-platform-1004033460/" ZorbaKiki (talk) 21:34, 26 January 2020 (UTC)

@ZorbaKiki: This is not the right talk page for your request. --Izno (talk) 02:57, 27 January 2020 (UTC)

Template won't allow me to request a move

I am trying to request that Ifedohlapo/sandbox be moved back to User:Ifedohlapo/sandbox, but the template won't allow me to submit the request, giving a "current page title is invalid." error.
I know the "current page title is invalid", that is one of the reasons (along with it not being ready for mainspace) that I want the article moved
Can someone please

1. Move the article back to User:Ifedohlapo/sandbox
2. Fix the template so that when asking to move an article with an invalid name, it does not refuse to register the request

Thank you - Arjayay (talk) 13:31, 29 January 2020 (UTC)

I've swapped the pages for you, will look in to the template to see what caused the issue. Iffy★Chat -- 13:44, 29 January 2020 (UTC)

Not sure what issue you were having, as I wasn't able to replicate the issue when previewing Main => User requests at WP:RM/TR. Iffy★Chat -- 14:33, 29 January 2020 (UTC)

Requesting close

Can someone take a look at what is (I think) not a difficult close at Talk:Novel coronavirus (2019-nCoV)? It would be good to move past the current request so that a new one can take place (if needed). Dekimasuよ! 00:56, 31 January 2020 (UTC)

Speedy close needed

Only about a week after closure (with near-unanimous support, after revised !votes) of Talk:Syrian civil war#Requested move 15 January 2020, someone has re-RMed it at Talk:Syrian civil war#Requested move 30 January 2020 with no new arguments of any kind, just recycling the same ones. This is out-of-process and is obvious WP:PARENTSHOPPING for a "better" closing admin, to WP:WIN. It's suspicious that a rapid-fire series of support !votes (making WP:JUSTAVOTE comments that simply reassert the arguments that failed last time without addressing why they failed) has magically appeared, after nothing like that kind of support only a week ago. WT:MILHIST was not canvassed (or even notified with studious neutrality), so where did this clan of over-capitalizers suddenly materialize from? E-mail coordination? Hard to be sure. But the tendentious proof by verbosity pattern is noteworthy: "If I just keeping saying it, I must be right."  — SMcCandlish ☏ ¢ 😼  06:25, 1 February 2020 (UTC)

• Agreed. The process if people disagree with the move or missed it for some reason, is to talk to the closer requesting a relist, and if they refuse and you still disagree with them, to go to WP:MRV. Reopening the same RM in the other direction is almost never appropriate. That said, I was quite vocal in support of the lowercase title at the 2016 RM so some might consider me involved. I'll therefore just join this request for a speedy procedural close.  — Amakuru (talk) 07:25, 1 February 2020 (UTC)

  Yeah, it's not about which direction is being argued, it's that it's immediate rehash with no new information or rationale. We have processes for controverting closes, and WP:BATTLEGROUND isn't it. I'd forgotten (because I focus on content not contributor and thus tend not to try to remember usernames) but see also the participation of the opener of the new RM in the RM just before it: the editor has as self-declared "Jesus, not this again" attitude, of their mind already being made up to favor capitalization no matter what policies or sources indicate for the specific case in question. This is WP:GREATWRONGS / WP:SOAPBOX pushing of "capitalize Military Stuff for Being More Important" nonsense (the editor seems to edit nothing but military material), and the "linguistic" arguments advanced by this person are embarrassingly wrong (like even 7th-graders generally know better) as well as being circular-argument WP:IDHT stuff (repeated again today; no matter how many times you explain something to this editor it just goes in one ear and out the other). This may be some kind of ESL matter, I'm not really sure, but it's clearly a competence one of some kind or another, and it's not a proper use of RM.  — SMcCandlish ☏ ¢ 😼  18:39, 1 February 2020 (UTC)

 Closed — JJMC89 (T·C) 03:25, 2 February 2020 (UTC)

Backlogged request appeal

Hi there. Wondering if an editor who's able to close requests can take a look at Talk:Writers Guild of America Awards 2019#Requested move 23 January 2020. Thanks very much. -- Wikipedical (talk) 00:55, 4 February 2020 (UTC)

Anyone can close it, but there's a lot of work to be done on that one, so maybe people are reluctant to jump in. If you voluteer to do the work, I or someone else can write the obvious simple close. Most of the moves are easy (to redlinks), and if some aren't you can request them at WP:RMTR citing the close; the RMTR template makes the job trivial for a mover. Dicklyon (talk) 01:26, 4 February 2020 (UTC)

 Done — JJMC89 (T·C) 04:50, 4 February 2020 (UTC)

Bug in bot?

This request is currently listed under Wikipedia:Requested_moves#Possibly_incomplete_requests:

• Talk:Objectivism (Ayn Rand) – Objectivism (Ayn Rand) is requested for move to Objectivism, which has non-redirecting content and is not requested for move

However, the request listed there is a multi-page request which includes moving Objectivism to Objectivism (disambiguation) (which currently redirects to Objectivism). So the "... and is not requested for move" part above is incorrect, and I think this request is improperly listed there and indicates a possible bug in the bot. --В²C ☎ 17:33, 5 February 2020 (UTC)

I believe it's an error too. I removed it to see whether the bot would restore it and it did. The function to check for this was recently added (in January), so maybe Wbm1058 should reassess that check. 05:50, 9 February 2020 (UTC)

There's also a somewhat related issue at Talk:Max Rose (politician). The bot apparently thought the request was malformed because it proposed to move the article to Max Rose and eliminate the dab page altogether[6] rather than move it to Max Rose (disambiguation). Someone tried to fix it by changing the proposal into a multi-move request,[7] but now it incorrectly looks like the nom is asking for the dab page to be moved instead of deleted. Station1 (talk) 07:35, 9 February 2020 (UTC)