Wikipedia talk:Requested moves/Archive 31

Archive 25

←

Archive 29

Archive 30

Archive 31

Archive 32

Archive 33

→

Archive 35

Accelerated archiving

Ordinarily we just let a bot archive this page. That usually works well given the bot's parameters which specify keeping a minimum of five threads on this page, archiving a minimum of two discussions at a time and only archiving discussions when 30 days have passed since the last comment was made. The recent discussions here have excessively bloated the size of this page and unduly drawn attention to a particular living person. For that reason, I've manually archived these threads as exceptional cases. I don't think it's necessary to tweak the archiving bot's parameters as this is a rarely-occurring deviation from the usual discussion activity on this page. -- wbm1058 (talk) 17:41, 8 March 2018 (UTC)

How to withdraw request?

Is it possible to withdraw a request? 1.If the request was posted and later the requester wants to withdraw the request before anyone has commented? 2.After there has been comments? How is it done -it is just closed before the seven days? Thinker78 (talk) 04:40, 3 March 2018 (UTC)

Thinker78 If the nominator wishes to withdraw a proposal about which no one has yet commented, or which is unanimously opposed. In this case, the nominator may close the discussion as "withdrawn". Either someone else can close it if you write that you've withdrawn it or you yourself can close following the instructions at Wikipedia:Requested_moves/Closing_instructions#Closing_the_requested_move Galobtter (pingó mió) 05:27, 3 March 2018 (UTC)

Are any guidelines or policies on this? Thinker78 (talk) 08:17, 3 March 2018 (UTC)

See Wikipedia:Requested moves/Closing instructions § Who can close requested moves – wbm1058 (talk) 13:01, 3 March 2018 (UTC)

A self revert is an OK way to withdraw a suggestion, too, if nobody has commented. The bot won't have any trouble doing the right thing after that. Dicklyon (talk) 16:18, 5 March 2018 (UTC)

See also Wikipedia talk:Requested moves/Archive 29 § Withdrawing a move request. wbm1058 (talk) 18:25, 8 March 2018 (UTC)

Request move subpage

See: Wikipedia talk:Requested moves/Current discussions/Table, thanks! Hhhhhkohhhhh (talk) 09:55, 9 March 2018 (UTC)

@Wbm1058: But why the bot has this bug [1]? Hhhhhkohhhhh (talk) 10:08, 9 March 2018 (UTC)

Ha ha guys, April Fools is still three weeks away. Or are you just getting an early start on March Madness? Yeah, either title works I suppose. I'm not sure it matters that much. Are there any problems caused by it being in the current location? I noticed that page is listed in Wikipedia:Database reports/Pages with the most revisions. I'm not sure, but there may be technical issues with moving a page that has so many revisions. I could just make the bot start writing to Wikipedia:Requested moves/Current discussions (table) and redirect Wikipedia:Requested moves/Current discussions/Table to that. Will wait to see if there are any other opinions on this, let's just keep the discussion right here. Thanks, wbm1058 (talk) 13:27, 9 March 2018 (UTC)

BTW, the width of the columns in that table are currently distorted by the request to move Suzukake no Ki no Michi de "Kimi no Hohoemi o Yume ni Miru" to Itte Shimattara Bokutachi no Kankei wa Dō Kawatte Shimau no ka, Bokunari ni Nannichi ka Kangaeta Ue de no Yaya Kihazukashii Ketsuron no Yō na Mono. That's the most blatant violation of the WP:CONCISE article-titling criterion I've seen. wbm1058 (talk) 13:35, 9 March 2018 (UTC)

At 209 characters, it holds the current record for longest title on Wikipedia (with spaces included in the count). Apparently there is a technical restriction to 256 bytes in UTF-8 encoding. —BarrelProof (talk) 21:10, 10 March 2018 (UTC)

That's been moved to Suzukake Nanchara, so the new champion concision-violator is To authorize the Secretary of the Interior to take certain Federal lands located in El Dorado County, California, into trust for the benefit of the Shingle Springs Band of Miwok Indians. Usually significant legislative bills are given shorter, catchier names in order to promote their passage, but I suppose it's not necessary to do that when the bills aren't at all potentially controversial. wbm1058 (talk) 13:15, 11 March 2018 (UTC)

Formatting of "Discussions"

Currently, this page says "23 (Discuss)ions have been relisted." Notice that the three letters "scu" in the middle of the word "Discussions" are underlined, and there are parentheses mixed into the word. Is there any reason for that? —BarrelProof (talk) 23:03, 9 March 2018 (UTC)

• Yes. The underlining is a code for bot recognition. It’s what you get for engaging volunteers to do the work I guess. —SmokeyJoe (talk) 03:27, 10 March 2018 (UTC)
• Wikipedia talk:Requested moves/Archive 30#Discuss, Wikipedia talk:Requested moves/Archive 30#Bot text formatting. It takes some getting used to. Dekimasuよ! 03:32, 10 March 2018 (UTC)
• Is there a way to “hide” the coding... so that bots will find it, but people won’t see it? Blueboar (talk) 13:50, 10 March 2018 (UTC)

To clarify, this wasn't done for the benefit of the bot. Obviously it's not working to serve the intended purpose, so I just removed that coding. wbm1058 (talk) 15:26, 10 March 2018 (UTC)

@Wbm1058: But the same thing still occurs below that point. If something is not meant for human consumption it should be invisible (or as close as possible to invisible) to humans, like a hidden comment. I assume bots can see hidden comments. ―Mandruss ☎ 15:33, 10 March 2018 (UTC)

Its not for bots, its meant for humans to quickly see that a discussion was relisted/that the bot has recognized the relist Galobtter (pingó mió) 15:40, 10 March 2018 (UTC)

Right, the purpose is to be a subtle indicator for humans that shows which RMs have been relisted. If nobody wants that indicator on these reports, then I can remove it. I just initially put it there while I was working on making the table, as I needed to separate out the relists to make the table. I understand that it's redundant to the --Relisting. indication; it just makes it easier to spot them by scanning the left column of the report. – wbm1058 (talk) 15:44, 10 March 2018 (UTC)

I'm used to it and I think it is slightly useful Galobtter (pingó mió) 15:46, 10 March 2018 (UTC)

In that case it needs to be explained somewhere visible enough to avoid questions like this one. "Word of mouth" is not a good way to communicate what things like that mean. ―Mandruss ☎ 16:13, 10 March 2018 (UTC)

It is at WP:RM#Relisting - When a discussion has been relisted a bot partially underlines the "Discuss" link in the lists of debates: (Discuss). Galobtter (pingó mió) 16:16, 10 March 2018 (UTC)

Right, hence my "somewhere visible enough". It needs to be explained where people will logically look for it, at the top of WP:RM#Current discussions. ―Mandruss ☎ 16:20, 10 March 2018 (UTC)

Now it says: This list is also available in a page-link-first format and in table format. 24 discussions have been relisted. Relistings are partially underlined, like this:(Discuss)

How's that? wbm1058 (talk) 17:45, 10 March 2018 (UTC)

It's an improvement. How's this? 24 discussions have been relisted, indicated by (Discuss). ―Mandruss ☎ 17:52, 10 March 2018 (UTC)

Different suggestion

This isn't an ideal solution, as there is a preference setting which underlines all links. So for those who have it set like that (as I do), the partial underline isn't even visible. I think a more unambiguous symbol is needed; the partial underline is not intuitive. Perhaps just place the word Relisted before or after the "Discuss" link? That would be even easier to scan for. Other options:

• Instead of italicizing all the "Discuss" links, only italicize the relists
• Write Discuss in a different color.

Cheers, --Aervanath (talk) 11:27, 11 March 2018 (UTC)

That's a good point; I hadn't noticed that user preference. Partial underlining is a sub-optimal option. wbm1058 (talk) 15:15, 11 March 2018 (UTC)

@Wbm1058: Neither "other option" is "more unambiguous". Optimal is something that doesn't require one to find and read explanatory text because it's self-explanatory—like stating "Relisted" for each relist. ―Mandruss ☎ 16:42, 11 March 2018 (UTC)

FYI. I've been working on bot stuff recently, and was trying to update my system to a newer version of PHP. Ran into unexpected problems; updating PHP versions is seldom as easy as you would think. Anyhow, I reverted to updating RM from my laptop which is running the most recent "official" version of the bot. Expect to return to this issue soon. – wbm1058 (talk) 18:46, 13 March 2018 (UTC)

Bot-created searchable archives

Occasionally there have been requests for some kind of searchable archive of requested moves, such as this December 2016 request. In response to that, I researched how we could use CirrusSearch to help search for archived discussions on talk pages and in talk archives, and implemented the somewhat-clunky looking search boxes near the top of this page. More recently, this discussion turned on a in my head which prompted me to manually create a prototype page for such bot-created daily archives; see Wikipedia:Requested moves/Log/2018 January 23 which is a partial archive of RMs started on January 23, 2018. These pages would hold exact copies of the discussions which would remain archived on the talk pages that hosted the discussions. The secret to making this system work is a combination of labeled section transclusion and substitution. There are some tricks the bot will need for following discussion pages that moved after a successful RM close. I think it's all very doable though, with a moderate amount of development work, and would be a worthwhile system enhancement. I've got it on my mid-term to-do list. If you don't think bot-created archives would be helpful, then let me know here. Or, if you want to offer encouragement and elevate this on my priority list, you could add a comment of support here too. – wbm1058 (talk) 19:18, 8 March 2018 (UTC)

No strong opinion on the value of bot-generated archives (generally, don't see it as necessary). I certainly don't think LST is necessary (and I actually pretty much despise LST--it creates a number of maintenance difficulties). Something like what article alerts does would be enough (see e.g. WP:VG/AA#RM). --Izno (talk) 20:39, 8 March 2018 (UTC)

Right, this would be partially redundant to the Article Alerts, which I also set up, but also a significant enhancement to that. I wouldn't actually be creating any labeled sections, per se, just taking advantage of the existing RM sections:

• {{#section-h:page name|heading}} (a normal section)

The labeled section transclusions would only persist while the requested moves were open, after the RM close the labeled section transclusions would be substituted and thus there would be none in these archives long-term. wbm1058 (talk) 21:41, 8 March 2018 (UTC)

I don't think it is necessary. We can see a list on Wikipedia:Requested moves/Article alerts and can see page history of move discussion. Hhhhhkohhhhh (talk) 17:02, 10 March 2018 (UTC)

OK, so there isn't any widespread call for this, but neither is anyone saying it shouldn't be done. I think there may be other benefits to setting this up, though. This system could be the foundation for solving issues with followup after moves and/or closes that I have on my to-do list. I need to have some record preserved that a requested move existed, that the bot can easily find, after the {{requested move/dated}} template is removed from the talk page. Right now the bot's only means of following RMs is via transclusions of that template. – wbm1058 (talk) 14:08, 24 March 2018 (UTC)

Requests to revert undiscussed moves

I have seen enough confusion and bad results come from RMs opened as a result of undiscussed moves that I feel we need to make a clear guideline for how to handle them. Whenever we have full RM discussions to revert undiscussed moves, there are issues that come up:

• Misunderstanding/confusion: Is someone voting "Oppose" because they oppose the current (undiscussed move) title? Or are they opposed to the original title (which the "new" title destination listed in the RM discussion)? Sometimes voters get legitimately confused and need to be corrected if their intent can be inferred, but also their vote may go unquestioned and interpreted incorrectly.
• Procedural votes: These are people who are voting strictly because the prior move was undiscussed. On their face, these kinds of votes should not be considered since an RM is a discussion, but I find move closers reluctant to do so.
• Weaponized process: Someone who wants the page to return to the pre-move title might submit an RM proposal back to that old name knowing that the above issues may occur and knowing that the default "no consensus" result means the page will be put back to status quo ante (original title) anyway.

If an undiscussed move is brought to Wikipedia:Requested moves/Technical requests and is contested OR if someone sees an undiscussed move and wants to open a full RM discussion right from the start, in both cases the default action should be to REVERT the recent, undiscussed move and leave it to the BOLD mover to propose an RM. We should never hold an RM discussion with the dark cloud of a recent undiscussed move still hovering over a page. -- Netoholic @ 14:35, 29 March 2018 (UTC)

This was discussed in December. --Izno (talk) 14:49, 29 March 2018 (UTC)

Are all potentially uncontroversial moves considered "for technical reasons"?

Hi. Currently i would like to request a move because i fit the 4th category: "Unregistered users are unable to move pages". I think it's "unlikely anyone would reasonably disagree with the move." Should i file it in the "Requesting technical moves" category, even though it might not really fit the "technical reasons" criterion? -- 46.97.13.26 (talk) 18:39, 5 May 2018 (UTC)

• Yes.--Aervanath (talk) 23:09, 5 May 2018 (UTC)

  @46.97.13.26: "Unregistered users are unable to move pages" is a technical reason, because that's the logic of how Wikipedia works. It doesn't mean you're necessarily unfit to propose the move, just that you don't have the technical ability.  — Amakuru (talk) 10:07, 11 May 2018 (UTC)

from draft to namespace

I ask for assistance with the postponement of the draft article Draft:Aparde in the namespace Aparde, as this feature is disabled for new translators. Please look at the draft and decide if it meets all the requirements for an correct article. I thank you. --User:Felari (talk) 08:10, 14 May 2018 (UTC)

Speedy close requested (third-time forum shopping by an anon)

Talk:Solar System#Requested move 23 May 2018.  — SMcCandlish ☏ ¢ 😼  23:08, 24 May 2018 (UTC)

Serena Armstrong-Jones, Countess Of Snowdon

Request to move the redirect “Serena Armstrong-Jones, Countess Of Snowdon” into an article of her own. The Countess has an existing Wikipedia article under the name “Serena Armstrong-Jones”, so I would gently ask to change it, I think she deserves an article of her own, in fact even lessen known members of he Royal family who had accomplish little or anything relevant had articles of her own ( example: Claire Windsor, Countess Of Ulster and Silvana Tomaselli). Thanks LexLadyOfTheNorth (talk) 04:39, 30 May 2018 (UTC)

Requesting reversion of unilateral move?

Hey, I'm wondering if something is acceptable as a technical request.

Always Be My Maybe (2016 film) was moved from the simpler title Always Be My Maybe a few days ago, even though the only other topic with this title doesn't even exist yet and just barely passes NFILM's requirement that a film have entered principal photography. The 2016 film is, in my opinion, the clear PRIMARYTOPIC at this time, so I suspect this will end up as an RM anyway, but is it okay to request the unilateral move be reverted pending consensus, per BRD?

I ask because, since it's reverting someone else's edits, it's obviously not "uncontroversial", but does may still qualify as a technical request to revert to the status quo while an RM takes place to implement the proposed change of title.

Hijiri 88 (聖やや) 09:34, 6 June 2018 (UTC)

See the "Requests to revert undiscussed moves" section of WP:RMTR Galobtter (pingó mió) 09:37, 6 June 2018 (UTC)

​It is both okay to move the title back, or to request it done at WP:RMTR, per BRD. It is a TWODABS situation, and I support that Always Be My Maybe (2016 film) is the primary topic and should be at the base name. I will swap with the DAB and add a hatnote. Courtesy ping Somethingwickedly. Sam Sailor 10:12, 6 June 2018 (UTC)

Please comment

Please comment on WT:MR#Move review decisions, thanks! Hhkohh (talk) 12:35, 11 June 2018 (UTC)

Request deleted and replaced

I requested a move for a single article and then realised I should have done it for two articles together instead, so (before any comment was added), I replaced the first request with a new one. I'm not sure if that messed up the RM workflow or some bot's operation – apologies if it did. --Deeday-UK (talk) 11:30, 1 July 2018 (UTC)

Capitalistion mistake

There is a mistake in the title of Eilífr kúlnasveinn, kúlnasveinn must have a capital K. Also Halldórr ókristni and Halldórr skvaldri and Hallfreðr vandræðaskáld. And Arnórr jarlaskáld, Auðunn illskælda. Þorleifr jarlsskáld. — Preceding unsigned comment added by Frayae (talk • contribs) 09:13, 5 June 2018 (UTC)

Redirects created. — Frayæ (Talk/Spjall) 18:13, 11 July 2018 (UTC)

Proposal RM instruction for modules

Currently, we have some module RM. However, when we move modules, we can not create redirect on old page, so it may affect some page. I think we can use a bot like Cydebot (talk · contribs) and a page like WP:CFD/W to fix this issue.(let bot fix affected page). Pinging wbm1058 Oshwah and Pppery who may interest in this, thanks Hhkohh (talk) 13:40, 17 July 2018 (UTC)

Also pinging Dekimasu Hhkohh (talk) 13:44, 17 July 2018 (UTC)

I don't think too much energy should be put into moving modules. There should be a really good reason for such moves, not something like "I don't like the name; I think this name is better". Can we develop a list of valid reasons for moving modules, similar to the nine reasons for renaming files, and require that a valid reason be specified? I don't have time to develop a bot or a special page and system to process these; how great is the need to move modules at all? If you want to develop a special template like {{rename media}} and pull this process off of RM, I probably won't object... but I have too many higher priorities to want to spend time futzing with module-moving procedures. – wbm1058 (talk) 14:10, 17 July 2018 (UTC)

We should get rid of all of the special-case move procedures (category, file) instead of adding more. {{3x|p}}ery (talk) 15:20, 17 July 2018 (UTC)

There should be a simple note to inform page movers that moving modules in use requires care to avoid breaking templates like with Module:Location map/data/Gibraltar. Moving any page requires attention to fixing what links to it. Modules are not unique. — Frayæ (Talk/Spjall) 15:54, 17 July 2018 (UTC)

(edit conflict)I tend to agree, especially for poorly named images, but moving modules often can break a lot of stuff. Someone lost or almost lost their pagemover bit a week or two ago for an inadvertent snafu of that sort. Modules are actually different, just not super-mega-shockingly different. Having a tool check and fix stuff isn't a bad idea.  — SMcCandlish ☏ ¢ 😼  16:15, 17 July 2018 (UTC)

Request to move Hemoglobin to Haemoglobin

Haemoglobin is the standard spelling in most of the medical literature around the world. It is the universally accepted spelling while Hemoglobin is seen only inside the United States. I request you to flip the existing redirect for the two spellings. — Preceding unsigned comment added by 61.3.151.103 (talk) 10:08, 29 July 2018 (UTC)

Not done... please read WP:ENGVAR. Blueboar (talk) 10:54, 29 July 2018 (UTC)

@Blueboar: Not done? I was going to say wrong venue. ―Mandruss ☎ 10:59, 29 July 2018 (UTC)

<noinclude> tags around transclusion of Wikipedia:Requested moves/Technical requests/Instructions

I was wondering why there are <noinclude> tags around the transclusion of Wikipedia:Requested moves/Technical requests/Instructions in Wikipedia:Requested moves/Technical requests. I think it would be helpful if the instructions were displayed when Wikipedia:Requested moves/Technical requests is transcluded into Wikipedia:Requested moves. Thanks. DH85868993 (talk) 11:28, 26 July 2018 (UTC)

I think this is old news; see Wikipedia talk:Requested moves/Archive 30#WP:RM/TR "Clear all requests" button.  — SMcCandlish ☏ ¢ 😼  05:05, 28 July 2018 (UTC)

• The technical matter of how these instructions are copied automatically between pages aside, it would require someone changing the function of the 'clear all requests' button or the noinclude tags will reappear. — Frayæ (Talk/Spjall) 11:46, 26 July 2018 (UTC)

I found an alternative approach. I have transcluded Wikipedia:Requested moves/Technical requests/Instructions into the Wikipedia:Requested moves#Requesting technical moves. This makes the instructions visible when viewing Wikipedia:Requested moves, but doesn't require any changes to Wikipedia:Requested moves/Technical requests or the "Clear all requests" button. DH85868993 (talk) 05:26, 30 July 2018 (UTC)

Make "THREEOUTCOMES" intuitive

This was discussed a while back with what seemed like agreement. The closes "MOVED" and "NOT MOVED" are ambiguous. I have now checked the history and see it was added with not a lot of discussion. I propose that it be modified from:

1.  NOT MOVED should be used when a consensus has formed to not rename the article(s) in question. ....

2.  NO CONSENSUS should be used when there is neither a strong consensus to move nor a strong consensus to keep the current title. ....

3.  MOVED should be used when consensus is found to move. ....

to:

1.  Consensus to NOT MOVE should be used when a consensus has formed to not rename the article(s) in question. ....

2.  NO CONSENSUS should be used when there is neither a strong consensus to move nor a strong consensus to keep the current title. ....

3.  Consensus to MOVE should be used when consensus is found to move. ....

• "moved" is a past tense statement of fact. Whether the page was moved or not can be read from the move log. What the closer should be doing is reading and judging the consensus of the discussion. Actions, (page moves) and prohibitions (no later bold page moves) derive from that calling of consensus. In closing, "consensus" is a key word. --SmokeyJoe (talk) 05:40, 27 July 2018 (UTC)

• The proposed wording is closer to what was always my default (except that I write "consensus not to move" rather than "consensus to not move"; and I use "no consensus to move" for #2). However, there are some cases in which something more like "moved" or "not moved" is less likely to create conflict. Even if the close represents a determination of consensus, it may be easier on those whose opinions don't carry the day if the word "consensus" isn't emphasized in the close. At any rate, I would support altering the RMCI wording, but I feel it would be counterproductive to absolutely mandate that certain phrasing be employed. Dekimasuよ! 05:47, 27 July 2018 (UTC)

• I very much agree on that. Certain phrasing must not be mandated. Certain phrasing my be usually a good idea, but there can be exceptions. The more important rule is that the closing statement reflects the discussion. Sometimes a discussion can find a creative solution that doesn't match template wording. --SmokeyJoe (talk) 05:50, 27 July 2018 (UTC)

• There are literally only two possible actions that can be the result of any move proposal: the article is either moved or not moved, and that result should be clearly stated in the close. Everything after that is the reason the closer decided to move or not move the article, which should also be stated (except maybe in the most obvious and uncontroversial cases). Reasons might include consensus to move, consensus not to move, no consensus resulting in the status quo, or in rare cases no consensus resulting in reverting a recent undiscussed move. The concept of three outcomes, rather than two, never made much sense to me, but I agree that how, or even if, a closer words the close can differ based on circumstances and should not be mandated. Station1 (talk) 00:42, 28 July 2018 (UTC)

• Thank you for bringing this up! I was, coincidentally, just today thinking that the wording there was confusing and needed work, for several of the reasons you highlight.  — SMcCandlish ☏ ¢ 😼  05:07, 28 July 2018 (UTC)
• Might it be worth adding a bit more about PRIMARYTOPIC situations, noting that the burden of evidence lies on those wanting to have a topic primary. Crouch, Swale (talk) 08:36, 28 July 2018 (UTC)

  A related issue is that PRIMARYTOPIC is grounded firmly in lasting encyclopedic significance, while the most common, and bogus, primary topic argument presented is how many hits the page has this week versus competing pages, a massive WP:RECENTISM problem. It's like people are not reading PRIMARYTOPIC at all.  — SMcCandlish ☏ ¢ 😼  14:11, 1 August 2018 (UTC)

Template:Move review has been twice relisted for deletion

Template:Move review is on its second relist at Templates for Deletion. Thought I'd give a shout here, in light of the discussion above, to draw more participation. wbm1058 (talk) 16:55, 4 August 2018 (UTC)

Band/duo moves

The move request at Talk:The Ghost (Faroese band) that was the primary location for discussion on the large number of recent band/duo requests has been closed, but the others remain open. Without Talk:The Ghost (Faroese band) open and listed at the top of the pile, it's a bit more difficult to see that the moves were basically discussed as a group. It would be helpful if someone could review the others in order to avoid any misunderstandings. Also pinging User:Primefac who closed the main discussion. Dekimasuよ! 17:10, 5 August 2018 (UTC)

Bump. Dekimasuよ! 18:15, 7 August 2018 (UTC)

RMCD bot notices inside articles

The userspaced template User:RMCD bot/subject notice is being applied at the top of articles any time an RM is opened. Where was the consensus discussion by which the community decided this was a good idea?

It definitely is not. It's palpably having the effect of driving into RM discussions an increasing amount of subjective preferences-based "voting", by people very unfamiliar with our title policy, naming convention guidelines, and style guidelines. This is resulting in a lot of moves that shouldn't happen (or thwarting of many that should), and is generally making a mockery of WP:CONSISTENT policy and the application of our style guidelines like WP:NCCAPS, MOS:CAPS, and MOS:TM in particular.

I'm of a mind to open a WP:VPPOL RfC to put an end to this, unless there's a strong showing that the community authorized this and is satisfied with the results.  — SMcCandlish ☏ ¢ 😼  14:10, 1 August 2018 (UTC)

There are dozens of maintenance templates of various types on the tops of articles. These include "merge" and "split" notices, as well as these move notices. Also deletion notices and all manner of cleanup notices. I don't know how or when these were all invented, but I don't like them much. — Frayæ (Talk/Spjall) 15:26, 1 August 2018 (UTC)

It has been implemented since 2016. Here is the discussion. --Izno (talk) 15:53, 1 August 2018 (UTC)

However, I do not see an explicit BRFA for the task either on the bot user page or in the what links here to that page. I think I would agree that a BRFA for this task would have been appropriate and that a consensus discussion probably would have been required. --Izno (talk) 15:56, 1 August 2018 (UTC)

I understand that people who arrive at move discussions via WP:RM may tend to be more versed in article titling policy, on average, but I don't think it's consistent with Wikipedia philosophy to add layers of opacity in order to avoid getting comments from particular types of editors. The closers should evaluate the strength of arguments when it is possible to do so. At any rate, pinging wbm1058, who runs the bot. Dekimasuよ! 18:22, 1 August 2018 (UTC)

That's backasswards. It's not consistent with Wikipedia's philosophy to lure non-editor readers into a debate where they're almost guaranteed to not understand the terms of the discussion and are very likely to be sharply criticized for advancing arguments antithetical to our title decision-making process, which is exceptionally arcane (I did an exacting flowchart of it once, and it's staggering). That's a spectacularly terrible WP:BITE factory. It's also not consistent with Wikipedia's purpose or normal operations to inject into readers' faces a bunch of internal self-ref administrivia; readers are not here for a window into editorial WP:P&G nitpicking. The most consistently controversial thing of this sort, historically, is the visibility of WP:TFD messages in template output, and it is routinely suppressed when it appears in a bunch of articles. The more articles is shows up in, more people get pissed off. PS: "We added this thing without discussion or BRFA permission, and now that it's causing problems and you object to it mean means you're trying to hide something and be un-wiki" is a really crappy thing to imply, and logically invalid.  — SMcCandlish ☏ ¢ 😼  19:55, 1 August 2018 (UTC)

I am not part of the "we" that added this; I was completely inactive in 2016. But when I returned, I did not notice more disruption as a result of the template. The well-established WP:AFD messages at the tops of articles seem like a more natural comparison than WP:TFD. Dekimasuよ! 20:27, 1 August 2018 (UTC)

Forgive me if it sounds like I'm objecting to you in general. Dekimasuよ! 20:30, 1 August 2018 (UTC)

One likely would not notice much if one were just closing RMs and moving on, and not dealing with a rising level of anti-guideline activism (both in the sense of long-term MoS haters getting more and more vocal, and a handful of new voices being added to their number), and an increasing number of unjustified divergences from the naming conventions to satisfy fannish expectations, leading in turn to a rising number of demands for such exceptions, none of them actually justifiable under IAR. It's not actually comparable to AfD. Readers have a legit interest in content completely disappearing off the face of the 'Pedia. They do not have a legit interest in RM discussions until they absorb our title policies and guidelines, any more than they have a legit concern about TfD until the understand our templating system.  — SMcCandlish ☏ ¢ 😼  23:32, 1 August 2018 (UTC)

Have to disagree SMcCandlish, disagree that the readers’ connection to article titles is at the same zero level as for templates. Titles are part of the content. Indeed, titles are the most important content of an article. Titles imply scope. Titles are the urls and hovertext that bring some readers to the article, whether correctly or misleadingly. If RM discussions are too arcane for unencultured readers, that is a reason for reform RM discussions, not to hide them. Barriers to newcomers should be reduced wherever possible. —SmokeyJoe (talk) 21:52, 6 August 2018 (UTC)

I'd also note that the template is useful for telling editors not to move things themselves during open move discussions. This probably helps avoid a lot of unnecessary move protection. Dekimasuよ! 18:24, 1 August 2018 (UTC)

That can be done by moving the text to the {{Rm}} template, so that it appears at the top of the RM discussion. And a page accidentally being moved during an RM doesn't matter anyway. It happens, and no one cares.  — SMcCandlish ☏ ¢ 😼  19:55, 1 August 2018 (UTC)

OK. I would support adding the wording to the RM template if a change proves necessary. Dekimasuよ! 20:32, 1 August 2018 (UTC)

No, a page "accidently" moving without closing the RM is somewhat disruptive. I patrol somewhat for this, to minimize the disruption. wbm1058 (talk) 21:06, 1 August 2018 (UTC)

Where has it been actually disruptive? I've seen it happen any number of times, people note that the move happened, it's often immediately reverted, and when it's not it has no impact. If the consensus is to move from A to B, or to remain a A because B's a bad idea an interim move to C will just be undone for either the A or B result. But none of this has anything to do with the issue at hand.  — SMcCandlish ☏ ¢ 😼  23:35, 1 August 2018 (UTC)

It's not disruptive in the sense of drama. Just disruptive in the sense of wasting time. The amount of time wasted varies; sometimes RMs can get sufficintly twisted up so as to take up considerable time to sort out and untangle. Sorry I can't think of any specific examples at the moment. It's not a really big deal in the scheme of things, though. wbm1058 (talk) 23:51, 1 August 2018 (UTC)

SMcCandlish, in the nearly two years since this was implemented, you are the second editor I can recall that has made a strong objection to article-space tagging by the bot. PBS was the first to object, within two months of implementation. This task is just based on the local consensus linked to above. I did not go back to BRFA for secondary approval, as in my judgment this wasn't a sufficiently substantial change to my already previously approved bot to merit that. I've made several enhancements over the years, and if I had to go back to BRFA for every one of them, with all the delays while waiting for responses from members of the bot approvals group, it would for me be an insufferable level of bureaucracy. It's bad enough that I have to wait months sometimes to get approval for my completely new bot tasks. At this point I don't think a trip back to BRFA would be helpful as by now I have all the technical kinks worked out, and the main purpose of BRFA is to get technical approval to implement a task that already has community approval. I think I have a pretty good sense for reading community consensus for these matters, as I hate to put a lot of time and effort into technical solutions only to see them rejected. I've also implemented a change to {{orphan}} to make it invisible when it's over two months old. There were still a couple of editors who insisted on moving it to talk pages, or deleting it all together, but it easily survived a template-for-deletion discussion. You are of course welcome to take this to a village pump policy RfC, but you might want to consider your chances for success and the community time which might be taken up by such a discussion.

Now, regarding the "increasing amount of subjective preferences-based "voting", by people very unfamiliar with policies and guidelines, etc." I have a different take on that. Since the implementation of WP:Page mover I think we've had an increasing number of {{subst:RMnac}} closes. These less-experienced closing editors, while helpfully mitigating what had been lengthy backlogs at RM, may have more of a tendency to simply count !votes, and less skill at evaluating the arguments in view of their conformance to policies and guidelines. I don't know what the answer is, but, in theory, at least we have WP:Move review as an opportunity for taking a second look at closes that may be less than ideal. Regards, wbm1058 (talk) 19:34, 1 August 2018 (UTC)

In short: it was a massive change. Whether you should have intuited that it would be one is immaterial, and I'm not going to play some blame game. I care about the effect, not about the intent back-when. Next, TfD is extremely conservative and will not delete a template used by an approved bot, pretty much no matter what (I've learned this the hard way.) That has absolutely nothing to do with broad community examination and acceptance of spamming our readers with RM notices and inviting them into discussion "death traps" where their ignorance of our P&G are going to make them look and feel foolish, unheard, ganged up on, etc.

Whether a bunch of our newer RMNAC people are "differently clued" (yes, some are) is also a completely unrelated matter. Or maybe it's not: If anything it exacerbates the problem: a bunch of noobs are lured in, vote for "POKÉMON DONE GONE!" to match the marketing-allcaps logo of a new game, get groused at by the regulars for not understanding MOS:TM and MOS:CAPS and WP:NCCAPS, and are all angry, then some noob-ish RMNAC'er just goes along with it by counting heads and failing to actually understand the P&G that apply, and we end up having an MR, and it probably doesn't close as it should because MR generally will not reverse a close unless the consensus is that the closer clearly made an error (not whether particular arguments presented were solid or not), so we'll probably be stuck with the bad article name for months or years and do repeat RMs. It's a something like a quintuple-failure situation, easly avoided by not spamming the content page with notices about RM threads on the talk page.
 — SMcCandlish ☏ ¢ 😼  19:55, 1 August 2018 (UTC)

TfD was an OK venue for appealing the status of Template:Orphan; I was just giving that as an example of a previous appeal of a local consensus. A WP:VPPOL RfC sounds like a good choice for this. I'd be interested to see how many others share your perspective, it's certainly a reasonable one. This may have been consensus in the past, but hasn't been what I've been feeling at WT:RM for the past few years. wbm1058 (talk) 21:06, 1 August 2018 (UTC)

This might sound strange, but why not make the template invisible to everyone except experienced editors? — Frayæ (Talk/Spjall) 20:15, 1 August 2018 (UTC)

I can do that, if a consensus forms for it. wbm1058 (talk) 21:06, 1 August 2018 (UTC)

Autoconfirmed? I didn't realize that was technically possible. It would entirely resolve my objection, since experienced editors do care. (As MoS's most active shepherd the last few years, I spend a lot of time considering reader needs and discounting editor preferences; I don't want to seem blind to the latter, especially if it can be achieved without harming the interests of the former.) Would obviate "yet another RfC", too.  — SMcCandlish ☏ ¢ 😼  23:43, 1 August 2018 (UTC)

I was thinking in terms of opt-in. Those editors who wanted to see the notices would opt-in to see them, by editing their common.css file. wbm1058 (talk) 23:58, 1 August 2018 (UTC)

We can manage the display of most elements of interest by user group by adding a certain HTML class. I am not exactly sure which class to add in this case. A note at MediaWiki talk:Common.css would probably get the attention of people who have used that before. --Izno (talk) 01:18, 2 August 2018 (UTC)

I should review the previous convention. Before, when we did not provide routine article-space notice of routine requested moves, we did use Template:Move review to provide article-space notices of move reviews. The thinking was that, if the RM insiders were having trouble reaching a consensus, we should try to bring in more general readers or editors to try to get a broader consensus to settle the matter at move review. Thinking that we didn't want to move an article like Hillary Clinton behind the general reader/editorship's backs, so if the title wasn't an easily settled procedural matter, we should notify everyone. Now, that everyone is notified of all routine RMs, the feeling is that Template:Move review is redundant, so now it's up for deletion. I implemented the change in the bot "by popular demand", people had been asking for it, in different venues, at different times. – wbm1058 (talk) 21:25, 1 August 2018 (UTC)

There has been an ongoing general concern that there is often insufficient participation at RM to get to a solid consensus for a decision. I've gradually increased the number of notices in an attempt to juice up participation. First there were new WikiProject notices sent to projects that didn't subscribe to article alerts. Then I added notices to the pages proposed for moving. Then the pages that could potentially be effected by the move. So far, the attitude's been the more the better, and every time I've added new notices, the addition has been welcomed. Maybe we've reached the limits of that now. wbm1058 (talk) 21:44, 1 August 2018 (UTC)

It surely didn't make much sense to direct non-editor readers to MR, either, which is even less easy to understand than RM. I like your idea above of constraining display of the notice.  — SMcCandlish ☏ ¢ 😼  23:43, 1 August 2018 (UTC)

It's completely appropriate and desirable to place these notices on the article. We should be encouraging readers to become editors in every way possible, and getting involved in (or even just observing) a move discussion on a topic of interest to them is an excellent point of entry. It would be a terrible decision to give even the appearance of trying to limit participation to the self-selected cognoscenti of article title policies. Move discussion closers are supposed to weigh policy-based arguments rather than simply counting votes. And when there is a bad move close, there is WP:Move review. older ≠ wiser 23:18, 1 August 2018 (UTC)

Did you read a single thing I wrote? We absolutely should not be encouraging readers to become editors specifically in a way that is likely to be immediately unpleasant. New editors should come on board to work on content and to integrate into the collaborative side of the community, not to get embroiled on day one in a tedious "style fight" involving a bunch of acronym-laden, convoluted rules they will not understand for months, maybe years, and often populated by unreasonably angry, tendentious cranks. It's going to give them a terrible impression of the place.  — SMcCandlish ☏ ¢ 😼  23:43, 1 August 2018 (UTC)

Yes and I thoroughly disagree. older ≠ wiser 23:46, 1 August 2018 (UTC)

Thanks for the heads up. I still think that putting this announcement in article space is a mistake. I also stated that others such as the merge templates should be removed from article space. The name and content of articles is an editorial issue and we have talk pages and the Wikipedia name space for such issues. Maintenance/editorial templates, unless like {{unreferenced}} which also warn the reader of potential problems with the content of the article, should not appear in article space. "It's completely appropriate and desirable to place these notices on the article. We should be encouraging readers to become editors in every way possible" That is not the mission of this encyclopaedia (WP:PILLARS). Your comment is one that many people who are passionate editors support, but I think it is mistaken. So I don't repeat myself, see my 2007 comment also User:Shanes/Why tags are evil and Wikipedia:Manual of Style/Self-references to avoid. In the case of page moves there is a tab at the top of the standard skin that allows any editor to move a page. Only if the move is controversial will it be subject to a RM, it is not reasonable to expect a person, who is not an editor, to spend hours get in up to speed on subjects such as what is a Wikipedia reliable source, before they can make a meaningful comment, when they came to a page to find out facts about a specific subject far removed from editing Wikipedia. It is much better that if they are interested in editing pages that they follow the sentence and link at the top of ever page that says "Welcome to Wikipedia, the free encyclop[a]edia that anyone can edit". I think that header sentence makes the argument that these templates are desirable as hooks for readers to become editors superfluous. -- PBS (talk) 09:34, 6 August 2018 (UTC)

• There was a survey in Dec 2012 on MRV and RM notices on the article, here. My opinion remains the same. MRV is very much a back room process, an editor decision review process, and the notice does not belong on the article. For RMs, unsure. If the name change is a scope-altering major decision, then yes. If it is fiddling that no reader really cares about, then no. —SmokeyJoe (talk) 21:46, 6 August 2018 (UTC)
• Like many others, I'm indifferent to placement of RM tags. I haven't seen a significant influx of n00bs in RM discussions, and I tend to at least take a quick skim over most of them. The few IPs that participate are mostly "regulars", judging on their approach and comments. Generally, I don't like maintenance tags and I would support hiding most of them from non-logged-in users (except for those pinpointing blatant problems, like "unreferenced" and "POV"), but until that happens, I find the RM tags to fall in the same range as {{merge}}, {{citation style}} or {{lead too short}}, and therefore they are acceptable in the mainspace. No such user (talk) 10:15, 8 August 2018 (UTC)

• Quite the contrary, No such user, all those are maintenance templates are self-referencing and fail to meet the guidance in Wikipedia:Manual of Style/Self-references to avoid. The last time this was debated in an RfC with a lot of editors expressing a view was in 2013 Wikipedia:Village pump (proposals)/Archive 108#Proposal to move the Orphan tags to the talk page, where the vast majority of participants (46/5) are not in favour of placing templates such as {{orphan}} in article space. The later template-for-deletion discussion which wbm1058 referrers was not as widely publicised as the initial debate, those who had taken part in the first debate were not invited to the second one. I was forced to remove my comments in that debate because I was invited as a meet-puppet. -- PBS (talk) 14:22, 8 August 2018 (UTC)

• I said I don't like them, didn't I? Just like hidden maintenance categories, we should have hidden maintenance templates, visible only to editors; or whatever technical solution is implemented by consensus. But until something is done with all of similar self-referential ones as a group, I don't see why the RM one should be singled out. No such user (talk) 15:38, 8 August 2018 (UTC)

• Notices of proposed title changes are very useful and should remain exposed to readers. They help the project gather input on proposals, and thereby establishing consensus. On the other hand, the move review process is best handled by regular participants who are well aware of titling policies and guidelines. Exposing it to the article space would probably bring no benefit, while risking re-litigation of the title move, which is not the goal of move review. In summary, keep process as is. — JFG ^talk 10:58, 8 August 2018 (UTC)

  Most moves are made by editors clicking on the move tab with no other editor input, let alone reader participation. Given that many new editors do not clearly understand the complicated nuances of WP:AT and its implementation via the WP:RM process, can you (JFG) link to an example where a reader has made a useful contribution to a requested move conversation by way of a template in article space? -- PBS (talk) 13:52, 8 August 2018 (UTC)

Capitalization, MOS and UCRN

I have read through the request at Talk:Spider-Man: Far From Home and my reading indicates that it is ready for closure, but the discussion has all the makings of something that will be sent straight to MR no matter the close, including allegations of canvassing. I am wondering whether any other closers would be interested in discussing or performing a group close, either officially or unofficially, to give the close additional legitimacy. Also pinging User:BD2412 who relisted the discussion. Dekimasuよ! 18:14, 7 August 2018 (UTC)

I would be willing to participate in such an effort. I'm running an errand, and will be back on in half an hour. bd2412 T 18:18, 7 August 2018 (UTC)

Thanks. No particular rush–I assume 3 closers would be best. Dekimasuよ! 19:12, 7 August 2018 (UTC)

I agree. I'm good with any experienced and uninvolved third closer. bd2412 T 19:22, 7 August 2018 (UTC)

Looks like in the absence of a third closer we have ended up with a WP:NAC. Here's hoping it doesn't go too badly. Dekimasuよ! 20:40, 8 August 2018 (UTC)

As it turns out, this has been closed by User:Paine Ellsworth; quite frankly, I would have closed it much the same way as he did. I think the absence of consensus is clear, and neither side had such an overwhelming policy argument that it would override the other in the absence of a clear consensus. bd2412 T 21:50, 8 August 2018 (UTC)

Effect on Page view statistics

I recently initiated two name changes (Brown-tail to Brown-tail moth and Actias luna to Luna moth). I noticed that in both cases there was a loss of prior history of page view statistics. Has this question come up before, and is there any way to resolve it? David notMD (talk) 10:29, 10 August 2018 (UTC)

@David notMD: Page view data is not lost. It is simply not moved with the page. Page views are now split between Brown-tail and Brown-tail moth and Actias luna and Luna moth. — Frayæ (Talk/Spjall) 10:52, 10 August 2018 (UTC)

Nice! For both moths, late spring/early summer peak in interest with the appearance of the winged moths: for Luna, for beauty, and for Brown-tail, for the annoying rash. David notMD (talk) 11:55, 10 August 2018 (UTC)

Arguments to avoid page

Often, people just say "Support" or "Oppose" without giving any rationale whatsoever, such as at Talk:Giant panda#Requested move 15 August 2018. Also, sometimes, people give some vague comments at RMs such as at Talk:Lebanon national basketball team#Requested move 20 August 2018. I have asked for Tbhotch to elaborate his comment to be more specific. I thus propose that we shall create an "arguments to avoid" page for WP:RM at Wikipedia:Arguments to avoid in move discussions similar to the ones we already have for AfDs, deletion reviews, RfAs, etc. GeoffreyT2000 (talk) 01:20, 23 August 2018 (UTC)

New move screen text

There is now quite a bit of additional text on the move screen in the middle of the important buttons, reading If you check this box, the associated talk page will be automatically moved to new title, unless a non-empty talk page already exists there. In this case, you will have to move or merge the page manually if desired. Does anyone know where this text is located, or who I can talk to about this change? 1) The "non-empty talk page" point is either imprecise or incorrect, depending upon one's perspective, so it really needs to be edited for clarity. 2) The talk pages should almost always be moved along with the page being moved, so if desired is not great wording either. 3) Minor point, but the box is checked by default, so "if you check this box" should just be "if this box is checked". Was there discussion of this addition somewhere? Dekimasuよ! 17:33, 24 August 2018 (UTC)

I could not locate the text in the "Move page" box in the MediaWiki namespace, only the header through the "Note to admins and page movers". Dekimasuよ! 17:39, 24 August 2018 (UTC)

Controlled by MediaWiki:Movepagetalktext. Assume was added on Thursday deploy.. Galobtter (pingó mió) 17:44, 24 August 2018 (UTC)

Thanks. So there was something similar until 2015, until it was deleted by MSGJ with the summary: "deleted page MediaWiki:Movepagetalktext (G6: Housekeeping and routine (non-controversial) cleanup: not needed, see talk page)". At that time, it read:

This page has a talk page, which will be automatically moved along with it unless:

A non-empty talk page already exists under the new name, or

You uncheck the box below.

In those cases, you will have to move or merge the page manually if desired. Please request a page move on Wikipedia:Requested moves if you cannot do so, but please do not just copy and paste the contents, as doing that destroys the edit history of the page.

That was marginally better than what we've got now, if this is necessary at all. I note that "moved to new title" sounds strange as well. So there are still some issues: the checkbox is labeled "Move associated talk page", so I really don't think it's necessary to explain that "if you check this box, the associated talk page will be automatically moved" (there's also a logical contradiction here... if you have to check the box, it isn't really automatic). That leaves space for something like If there is edit history at the new location for the talk page other than a redirect to the current location, the talk page must be moved manually. Please be sure to preserve significant talk page history at the target when necessary. as the text. Dekimasuよ! 17:57, 24 August 2018 (UTC)

May just want to remove the notice by creating a blank page there - the number of cases where this is an issue I think isn't much (or at-least I don't think I've ever experienced the issue), because if you can move the article, there either isn't a page at the target (and thus no talk page) or the target redirects toward the article you're moving, where most of the time the talk page will redirect similarly. Where there is a talk page blocking the move I think 99% the target page will have some edit (even rcats) blocking a move. Galobtter (pingó mió) 18:07, 24 August 2018 (UTC)

Thanks for the perspective–as an admin, having to take care of the talk page is a frequent occurrence because usually we're performing moves that do require deletion of the target page (and that often would leave the talk behind, usually just because of an edit history showing various places the talk has redirected over time). But admins should know how to handle this already, so I agree with you that we may want to go back to removing the notice. Dekimasuよ! 18:32, 24 August 2018 (UTC)

AAR people moving pages should generally know these things, and if they don't they should read Help:Moving a page which is linked in the header, but if we are trying to help streamline the process, the best way to go is to get the talk page out of the way first (G6, etc.) and then allow the interface to move the article and talk together "automatically". Dekimasuよ! 18:06, 24 August 2018 (UTC)

THREEOUTCOMES and post move chalenges

The discussion at Talk:Bury#Requested move 11 August 2018 was closed as move after being relisted. However it has been challenged by editors who didn't participate in the discussion, is it usual to reopen the discussion or start a new one. @Amakuru: @Dekimasu: Crouch, Swale (talk) 07:35, 30 August 2018 (UTC)

Proposal delay 48h after listing in WP:RM/TR

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.

---

Currently, we can move immediately after someone listed in WP:RM/TR, sometime we cannot easily contest. So I suggest that we should change current policy to Request may take 48 hours to process after listing if there are no objections. in order to reduce move revert after an unconventional move like WP:CFDS Hhkohh (talk) 03:30, 9 September 2018 (UTC)

• Oppose. Reviewing admins/page movers already open an RM if the request is likely to be controversial. Anyone can request a revert to an undiscussed move, or open a formal RM, with minimal disruption to the project. Without a more thorough rationale, including specific examples of where the current system doesn't work, this appears to be a solution in search of a problem. Bradv 03:41, 9 September 2018 (UTC)
• Oppose Per above. If an editor finds an issue with a listed request after it's been filed, they can file an RM themselves. Requiring a 48 hour wait is simply going to clog up the requests at RMTR; see how many there are per day. -- Alex^TW 03:45, 9 September 2018 (UTC)
  • It is not a problem. WP:CFDS usually listed 80 request Hhkohh (talk) 03:55, 9 September 2018 (UTC)

And? That's not a reason to create more delays and backlogs. We're trying to minimize those as it is. -- Alex^TW 03:57, 9 September 2018 (UTC)

• oppose technical requests can be handled only by page movers, and admins. Both of whom are familiar with page title/moving policies. They can turn questionable requests in RM. This would simply increase the bureaucracy and delay/backlogs. —usernamekiran(talk) 04:21, 9 September 2018 (UTC)
  • usernamekiran But WP:CFDS only can be processed by admins. So RMTR should be Hhkohh (talk) 04:28, 9 September 2018 (UTC)
    • CFDS is a "discussion" venue. As the page states Speedy renaming or speedy merging of categories may be requested only if they meet a speedy criteria. That venue hosts different cases. Some of which don't need 7 days discussion, but they are not not 100% obvious cases either. So 48 hours waiting period can be justified there. And basically, categories and their policies are a whole different breed. —usernamekiran(talk) 05:04, 9 September 2018 (UTC)
• WP:SNOW oppose per everyone else. There have never been issues of a backlog of speedy move reversion requests. 142.160.89.97 (talk) 06:05, 9 September 2018 (UTC)
• Comment – I'll remove the RfC listing for the time being in line with WP:RFCBEFORE. 142.160.89.97 (talk) 06:08, 9 September 2018 (UTC)

Do not think so. Leave it Hhkohh (talk) 06:18, 9 September 2018 (UTC)

@Hhkohh: Why don't you think so? Were you in compliance with WP:RFCBEFORE? 142.160.89.97 (talk) 06:19, 9 September 2018 (UTC)

Can you give an explanation about it? Why do you think WP:RFCBEFORE apply? Hhkohh (talk) 06:22, 9 September 2018 (UTC)

Uhhh, because this is an RfC and none of the following were done:

Before using the RfC process to get opinions from outside editors, it's often faster and more effective to thoroughly discuss the matter with any other parties on the related talk page. Editors are normally expected to make a reasonable attempt at working out their disputes before seeking help from others. If you are able to come to a consensus or have your questions answered through discussion with other editors, then there is no need to start an RfC.

So why do you "not think so"? And do you believe this to be in line with WP:RFCBEFORE?

And what is with all of these unexplained reversions? 142.160.89.97 (talk) 06:29, 9 September 2018 (UTC)

Sorry, not only in RM subject, but also in all subjects and this is a proposal new guideline for moving pages, so better is RFC. Hhkohh (talk) 11:37, 9 September 2018 (UTC)

@Hhkohh: erm, what do you mean by "not only in RM subject, but also in all subjects and this is a proposal new guideline for moving pages"? —usernamekiran(talk) 12:26, 9 September 2018 (UTC)

Because the proposal will affect all people who go to WP:RM/TR in my opinion Hhkohh (talk) 12:30, 9 September 2018 (UTC)

To be specific, this is a problem because yesterday 142.160.89.97 listed a large number of book titles on WP:RM/TR for shortening per WP:SUBTITLE and Hhkohh did not have time to object because I processed them within the hour. He has reverted some of them now and these are at RM. It should be noted that if 142.160.89.97 was registered they could have made almost all the moves themselves, without listing them here at all, and that this RfC cannot deal with bold moves made without being listed here. I do not see how this is a failing of the system, if anything, it is on me for processing moves according to a guideline without realising that this could be controversial. — Frayæ (Talk/Spjall) 12:40, 9 September 2018 (UTC)

• Oppose WP:RM/TR is not a discussion venue and having to wait to complete a request would not be an improvement. If someone objects after the request has been completed it can be undone or sent to discussion. — Frayæ (Talk/Spjall) 08:36, 9 September 2018 (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.

Anthony Davis

I failed to include the secondary page move in the template.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 03:48, 14 September 2018 (UTC)

 Fixed wbm1058 (talk) 13:13, 14 September 2018 (UTC)

Proposal to start auto archiving WP:RMT page

Currently editors are simply deleting content from WP:RMT instead of marking as done and archive by bot. This is not normal. Pages like WP:RFPP and WP:PERM etc are archived for historical purposes. Hence I suggest the same should be done here as well. --DBigXrayᗙ 11:15, 31 August 2018 (UTC)

• Support an archive bot archiving the page. It would be clearer to people making requests what has happened if they are marked as done and not simply removed. For the time being I will continue as normal but I welcome this idea. — Frayæ (Talk/Spjall) 20:20, 31 August 2018 (UTC)
• Support - Per DBigXray. - FlightTime (open channel) 20:22, 31 August 2018 (UTC)
• AIV doesn't keep an archive, nether does CFDS. Crouch, Swale (talk) 13:53, 3 September 2018 (UTC)

There is no justifiable reason for AIV to keep archive, the page history is as good as archive, thee is no back and forth discussion. please see my reply below.--DBigXrayᗙ 15:47, 3 September 2018 (UTC)

• Oppose - seems like a solution looking for a problem. The two buttons (move and discuss), which are available on the RMT page always generate permalinks in the page history or on the talk page of the article concerned, (i.e. [2] for a move, and [3] for a discussion). This is far more useful than a general archive, since each case is attached to the actual article it concerns rather than a in a generic page.  — Amakuru (talk) 13:59, 3 September 2018 (UTC)
• Oppose like WP:CFDS, do not archive it Hhkohh (talk) 14:01, 3 September 2018 (UTC)

hi Amakuru, Hhkohh, A user can directly place his move request on WP:RMT instead of posting on Article Talk page. (in fact when I needed such a move i posted on RMT directly) The reasons for move is added by the submitter. that line is useful to other page watchers who would like to know the reason for move. sometimes, the move although on the face of it may looks uncontroversial but later turn out to be in appropriate. In Other cases the request appears to be inappropriate on the face of it and there are further queries and replies by the Mover and the submitter to clarify the validity of the request. example [4] An Archive would help search the entry with time stamp and all. Searching in the page history is applicable to all the pages on wikipedia, yet we have archives. The reason is same. I am not sure as to how an archiving by a bot will be looking for problem ? --DBigXrayᗙ 15:43, 3 September 2018 (UTC)

But all the information you mention is available in a far more useful format through the permalinks, as I described. Listings on WP:RMT are usually one-liners detailing the proposed move, which are then either enacted or discussed. The entire content of that line is easily brought back any time someone wants it, from the article history or the talk page, by following that permalink. Here is an example of such a permalink: [5]. It serves the purpose of retrieving the listing. Hiving them all off into a separate archive page is completely pointless.  — Amakuru (talk) 15:52, 3 September 2018 (UTC)

And how did you get this Permalink above ? Eg. Lets say I want to find out about RMT for Harchand Singh Longowal using the Page search history [6]. The search for Harchand Singh Longowal turns out irrelevant results. such a search would have been so easy with an Archive. A search for example [7] may also be tricky if i am looking for the thread. --DBigXrayᗙ 16:05, 3 September 2018 (UTC)

In answer to DBigXray's question, look in the history of Harchand Singh Longowal, where you will find this edit summary. In the summary, click on the 'Requested' link and it brings you to the WP:RMTR request. This convenient system of permalinks was mostly worked out by User:Wbm1058. EdJohnston (talk) 16:31, 3 September 2018 (UTC)

Thanks Ed, this was helpful.--DBigXrayᗙ 11:53, 4 September 2018 (UTC)

Still no need to archive. If we archive WP:RMTR, so we also need to archive all uncontroversial moves, that is too complex, you can just see Move Log Hhkohh (talk) 21:36, 3 September 2018 (UTC)

• Oppose current system works fine. Adding a bot or anything else would complicate stuff. TonyBallioni (talk) 16:13, 3 September 2018 (UTC)
• Oppose. Recent moves are already listed at Wikipedia:Requested moves/Article alerts, and every discussion is archived on the corresponding article's talk page. Bradv 03:43, 9 September 2018 (UTC)
• Comments on the above: Article alerts doesn't track "technical requests", just the "current discussions". In theory there should not be any lengthy discussions about "technical requests"; if a significant discussion develops at RMT, the request should be considered as "potentially controversial" and moved to the talk page of the page requested to be moved (i.e., converted to a "current discussion"). It would be possible to write a bot to step through the page history at RMT, and generate a report or reports of the activity there. But the first step is to define what the need is, so a bot could be custom-designed to meet that need. Maybe you want to see who the most active admins are on that page, so you can give them barnstars or T-shirts for their helpful work. Maybe you want to see whose "technical requests" are most often converted, so you can trout-slap them for wasting too much of editors' and admins' time. Or some other purpose. I previously discussed the possibility of archives of "current discussions" HERE; that's still on my back burner as a lower-priority enhancement. – wbm1058 (talk) 14:21, 14 September 2018 (UTC)

Requested move 19 September 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: not moved per WP:SNOW. TonyBallioni (talk) 20:03, 19 September 2018 (UTC)

---

• Wikipedia:Requested moves → Wikipedia:Articles for renaming
• Wikipedia:Proposed mergers → Wikipedia:Articles for merging

– Consistent with WP:AFD. 192.107.120.90 (talk) 17:52, 19 September 2018 (UTC)

• Oppose. Names of Wikipedia processes are well bedded down now, and there is no good reason to change them. This is the second RM on RM this year and the last one failed. If it ain't broke, don't fix it.  — Amakuru (talk) 19:14, 19 September 2018 (UTC)
• Oppose per Amakuru and propose immediate close per WP:SNOW after 4th consecutive Oppose. --В²C ☎ 19:24, 19 September 2018 (UTC)
• Oppose This would be very confusing. I move pages, I don't rename pages. The difference is likely to be semantic, but consider it's called page moving on all guidance and policy pages and system messages across Wikipedia in all languages. — Frayæ (Talk/Spjall) 19:28, 19 September 2018 (UTC)
• Support PM as this is the equivalent of AFD when its only a merge rather than full delete, unsure about RM per Articles for Deletion v Redirects for discussion. Crouch, Swale (talk) 19:30, 19 September 2018 (UTC)
• Oppose. It should not be consistent with WP:AFD for the simple reason that "Requested moves is a process for requesting the retitling (moving) of an article, template, or project page on Wikipedia". Sam Sailor 19:56, 19 September 2018 (UTC)
• Oppose - Per Frayae. - FlightTime (open channel) 19:58, 19 September 2018 (UTC)
• Oppose, doesn't need to be consistent here. --SarekOfVulcan (talk) 20:00, 19 September 2018 (UTC)

---

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Template issue

Twice in recent days I've noticed that use of {{collapse top}} and {{collapse bottom}} within a WP:RM proposal causes that RM to be the last one showing on Wikipedia:Requested moves/Current discussions and therefore WP:RM. In other words, no earlier RMs are listed below it. Removing the collapse templates solves the problem as soon as the RMCD bot makes its next round. This has occurred at Talk:Brown Willy effect and Talk:Reptilians. Other than removing the templates from individual RMs, I'm not sure what to do about this. Station1 (talk) 07:24, 14 October 2018 (UTC)

Mass renaming of election articles, bypassing WP:Requested moves

Wikipedia:Village_pump_(policy)#Mass_renaming_of_election_articles,_bypassing_WP:Requested_moves --SmokeyJoe (talk) 05:16, 19 October 2018 (UTC)

Feedback request service

Is there something similar to Wikipedia:Feedback request service for Wikipedia:Requested moves? -- Alex^TW 02:52, 25 October 2018 (UTC)

See also Wikipedia talk:Feedback request service#Add RMs, and FAC & FLC, and FAR and GAR. I've never used the feedback request service, so am not really familiar with how it's configured and used. The bot supporting this is User:Legobot (task 33), per this bot request for approval.

Would you be interested in random notifications from the set of all open requested moves, or only a subset of RMs which would be grouped into topic-based categories?

In the spirit of WP:Articles for deletion§Notifying substantial contributors to the article maybe I could enhance RMCD bot to "notify the good-faith creator and any main contributors of the articles" requested to be moved. Though this could be a significant bit of work to do well. wbm1058 (talk) 17:52, 25 October 2018 (UTC)

Proposal to add notifications recommendation to move process

I propose modifying section WP:RM#Requesting controversial and potentially controversial moves (shortcut: WP:RM#CM) to add a recommendation to notify interested users and projects, analogous to the recommendations we currently have to notify users in the cases of merge or deletion nominations. The notify portion of the merge guideline is at Wikipedia:Merging#Step 1: Create a discussion, and the delete guideline recommendation regarding notification is at WP:AFDHOWTO step III. In each case, the procedures mention the option of using a template available for the purpose of notification: {{Mergenote}}, and {{Afd notice}} respectively.

The proposal has two parts: new verbiage to support the notifications recommendation, and a new template to facilitate it.

Verbiage: I propose we find some suitable verbiage to add to the section along the same lines as the Afd recommendation.

How about the following, adapted from the merge guideline:

Notify involved users (optional): As an optional step, it may be necessary to notify users involved in the affected page, who might not be watchlisting it. Simply go to those users' talk pages and start a new section, leaving a neutral invitation to participate in the move discussion. Make sure to provide a link to the discussion page. Please ensure that the notification of involved users does not breach WP:Votestacking; that is, canvassing support by selectively notifying editors who have or are thought to have a predetermined point of view or opinion.

You may also use the following standard template on the users' talk pages:

{{subst:Move notice|<source page>|<target page> }} # The red link would go blue when the new template goes live.

Example:

{{subst:Move notice|Foo|Foobar}}

As far as where to place it: the "Requesting controversial moves" section currently has two subsections, Requesting a single page move, and Requesting multiple page moves; I think most of the additional content could go in a third subsection, Notify users (or Issue notifications, which would better cover notifying both users and WikiProjects). The template usage example above could either go there, or into the collapsed box entitled 'Template usage examples and notes'.

Template: In addition, I propose we provide a template to take the drudgery out of notification. I've created a new template in my user space based on {{Afd notice}} that we could use for this purpose, along with some test cases. You can view it here and try it out in your sandbox (or in mine, here). I'll mention the new template at Wikipedia:Requested templates so the Template Gnomes can have a look at it, and comment here, if they wish.

Thoughts? Mathglot (talk) 06:26, 29 October 2018 (UTC)

This addition could be useful, as long as it is clear that the process is voluntary. Many moves are routine, often required to conform with policy or guidelines. Requiring or expecting notifications and a waiting period for discussion for such moves would be unnecessarily cumbersome. Other moves are at least potentially controversial, and eliciting a discussion with broad participation may be desirable. One problem is that users may disagree on what is a controversial move. However, if this proposal results in a few less moves being reverted after being noticed by a wider audience, it may be justifiable as an extension of our procedures. - Donald Albury 12:40, 29 October 2018 (UTC)

Agree the template would be useful, {{Cfd-notify}} does include renaming. I'd say that its entirely optional and should not invalidate a move just because it wasn't done. A modified message was posted here based on the bot notifications of other pages that are affected by RM discussions. At Wikipedia:Categories for discussion/Log/2018 October 26#Category:Cars. It was complained that the project was not made aware of the previous CFD. Although categories are outside the RM process, the same principal applies. Crouch, Swale (talk) 13:10, 29 October 2018 (UTC)

@Donald Albury and Crouch, Swale: Yes, this would be entirely optional (the word optional is used twice in the text) and the template is only designed for use in the "possibly controversial" moves, so would not apply to routine moves. There is not intended to be any waiting period for discussion; rather, the text is trying to echo what the {{Requested move}} template says, namely: The discussion may be closed 7 days after being opened, if consensus has been reached. If either of these points in the text is not clear, please feel free to suggest alternative text. I don't so much see the template as an extension of procedures, as a way of reducing the pain of creating a notification that the user may wish to provide, but who might otherwise not do so if it's too tedious and cumbersome to come up with the right verbiage and type it out themself. Really more of a convenience, which might spur some users to notify, who might otherwise just have skipped it.

If either of you are template gurus, I could use a hand, or a tip, with the one item in the To do list on the template talk page. Also, is there a procedure for vetting prospective templates? After waiting a decent interval for other feedback, do I just move it to Template space after any issues raised are taken care of? Or do I have to submit it somewhere, or something? Mathglot (talk) 10:56, 30 October 2018 (UTC)

@Mathglot: I have produced a first draft at User talk:Mathglot/sandbox/Templates/Template:move notice#Move notice. As noted I would only usually use it on new users (and sometimes Wikiprojects) who may not be familiar with the RM process, nowadays we tend to use a ping instead of the user's talk page for this kind of thing anyway, since most AFDs are on new user's articles. Crouch, Swale (talk) 12:08, 30 October 2018 (UTC)

Unilateral revert of move per Closed RM

Would appreciate admin review of this. Please see: https://en.wikipedia.org/wiki/Wikipedia:Administrators'_noticeboard#Jaggi_Vasudev_RM_handled_unusually

—В²C ☎ 07:07, 30 October 2018 (UTC)

• The old principle for NACs was that if challenged, any involved admin may revert (if a bad close) or co-sign (if they support the close).

Now that we have WP:MR, the complainant is supposed to use it (following a polite conversation), to challenge the close. It is not OK to revert a move based on a properly closed RM discussion. --SmokeyJoe (talk) 07:14, 30 October 2018 (UTC)

Cpt.a.haddock (talk · contribs) would appear upset and confused, and he made an odd duplication of the entire discussion [8]. A bit of cleanup is needed. --SmokeyJoe (talk) 07:17, 30 October 2018 (UTC)

I've reinstated the move and removed the new discussion. There are procedures that can be followed if someone disputes a close, and this was not it. Thanks  — Amakuru (talk) 07:27, 30 October 2018 (UTC)

For the record, THANK YOU for cleaning up that mess. Given the activity just a few hours prior to my close, which I hadn't noticed, I did decide to revert my close and move to allow further discussion. --В²C ☎ 20:39, 30 October 2018 (UTC)

Those unable to move pages are unable to edit the page requesting a page move

I find the introduction quite strange. It actually states the following:

Any autoconfirmed user can use the Move function to perform most moves (see Help:How to move a page). If you have no reason to expect a dispute concerning a move, be bold and move the page. However, it may not always be possible or desirable to do this:

• Technical reasons may prevent a move: a page may already exist at the target title and require deletion, or the page may be protected from moves. See: § Requesting technical moves.
• Requests to revert recent undiscussed controversial moves may be made at WP:RM/TR. If the new name has not become the stable title, the undiscussed move will be reverted. If the new name has become the stable title, a requested move will be needed to determine the article's proper location.
• A title may be disputed, and discussion may be necessary to reach consensus: see § Requesting controversial and potentially controversial moves. The requested move process is not mandatory, and sometimes, an informal discussion at the article's talk page can help reach consensus.
• Unregistered users and new (not yet autoconfirmed) users are unable to move pages.

Yet. Unregistered users and (possibly, who knows?) new (not yet autoconfirmed) users are unable to edit this very page! How then are they to make a request? What is the point of this page? Or at least the instruction that refers to users who are excluded from editing it? Very confusing. --2001:BB6:A94:5658:651D:87BD:2EB9:2093 (talk) 23:07, 4 November 2018 (UTC)

You edit the talk page of the page you want moving, not this page. If for some reason, you can't edit the talk page, you can make your request at WP:RM/TR. Iffy★Chat -- 23:11, 4 November 2018 (UTC)

• (edit conflict) IP User 2001:BB6:A94:5658:651D:87BD:2EB9:2093 You can make a non-controversial move request at Wikipedia:Requested moves/Technical requests. that page is not protected.
• If you try editing the page Wikipedia:Requested moves it will shouw you an Edit notice at the top to advertise this to IPs and other users who aren't aware of this fact. --DBigXrayᗙ 23:13, 4 November 2018 (UTC)
  • This was posted at RMT and now done. Crouch, Swale (talk) 09:46, 5 November 2018 (UTC)

Questions for closers about active RM discussions in the backlog

1. Once a request is in the backlog how much if any consideration do you give to whether discussion is ongoing or not?
2. How long should there have been no discussion before you feel it's appropriate to close a request that is in the backlog?
3. For something in the backlog, if discussion is ongoing but consensus is clear, do you wait? Or go ahead and close?
4. What factors go into your decision about whether to close or wait for an RM request in the backlog?
5. Should any of this be clarified at WP:RMCI? If so, what?

Thanks! --В²C ☎ 23:47, 7 November 2018 (UTC)

Unless it has already been relisted twice it should only be closed if the discussion is clearly over, regardless of how long it has been in the backlog. — Frayæ (Talk/Spjall) 01:00, 8 November 2018 (UTC)

I’m just wondering how much closers actually do this. I was under the impression that recently active discussions are often closed if they’re in the backlog and consensus is clear. —В²C ☎ 07:01, 8 November 2018 (UTC)

The primary reason recent RMs have primarily been closed when they're in the backlog is because of the size of the RM backlog. Iffy★Chat -- 09:12, 8 November 2018 (UTC)

• Discussions should not be closed unless they are ready to be closed.

Most RM relisting is pointless busywork, and if you are paying attention to relist dates, you are looking at irrelevant data.

Using the page Wikipedia:Requested moves/Current discussions (table) has removed the considerable annoyance of relisting for me, but I still believe the above points to be true. --SmokeyJoe (talk) 01:33, 8 November 2018 (UTC)

• My approach to this would be to look at what the ongoing discussion is about. If it's just pointless back-and-forth, which won't affect the outcome, then I would close per the existing consensus or lack thereof. If the recent discussion introduces something new into the discussion, then I would probably relist or defer the close. The size of the backlog should play no part in which decision is chosen, but if something is in the backlog and all the points have been made, then it's certainly ripe for closing.  — Amakuru (talk) 10:20, 8 November 2018 (UTC)

Change the name of: Ixquick by StartPage

Good morning. I think that you should change the name of: Ixquick by StartPage. Since the name of: Ixquick is out of date. The updated name is: StartPage. Thank you.— Preceding unsigned comment added by Notewiki2000 (talk • contribs) 03:34, 4 November 2018 (UTC)

Page moved. – wbm1058 (talk) 13:06, 8 November 2018 (UTC)

Enacted discussions

There is discussion on if enacted RMs can be reversed pending further discussion even if closed correctly, see Wikipedia talk:Consensus#Enacted discussions. Crouch, Swale (talk) 18:15, 8 November 2018 (UTC)

Warning about abuse of page-mover privileges

I'm disappointed to see this section on the administrators' noticeboard. Posting here so that other admins who frequent requested moves are aware of it. – wbm1058 (talk) 02:32, 10 November 2018 (UTC)

Splitting articles

I have raised the question about splitting one very long article into one long article, two start-class articles, and a stubby article. What is the process for such a request? Thanks, Oldsanfelipe (talk) 14:56, 13 November 2018 (UTC)

There's no formal process for splits, for simple splits just be bold. For potentially controversial splits or multiple splits, follow the instructions at WP:SPLIT. Iffy★Chat -- 15:02, 13 November 2018 (UTC)

Iffy: Thanks for the quick response. Oldsanfelipe (talk) 15:11, 13 November 2018 (UTC)

Instructions

@L293D: Starting a discussion here for you re: this edit. Please leave it how it originally was and discuss if you think it needs to be changed. -- Alex^TW 23:51, 17 November 2018 (UTC)

Well, I thought my edit summary was clear enough, but here: I think the edit summary should be "done all" rather than "done " because the button clears all requests. Often Page Movers will remove a request and leave other requests with the edit summary "done 1", for example. But here, the button clears all requests anyway, so the only good edit summary is be "done all". L293D (☎ • ✎) 03:22, 18 November 2018 (UTC)

It was clear, sure, but it needs to be discussed here. Looking at 500 edit sumaries just before your "done all" implementation, there are 75 cases of "done <digit>", 11 "done.", and only 9 "done all". There are no stats to back up the fact that those who use the button only use "done all", or whether most of them use digits (I, for one, do). Thus, the clear default summary method is obvious: having "done" means anything can be added to the end (such as digit OR all), whereas "done all" is a specific entry that has to be changed when required by a page mover. -- Alex^TW 04:24, 18 November 2018 (UTC)

I am the one who appended the edit summary first and will agree with Alex that it should stay with "done" only as that's the basic and can even mean "done all" perfectly. Either a figure or "all" can be added as case maybe. –Ammarpad (talk) 06:51, 23 November 2018 (UTC)

Semi-protected edit request on 24 November 2018

i'm a new user.kindly publish my page Mrityunjay singh gautam (talk) 08:20, 24 November 2018 (UTC)

•  Not done This is not the place to request that. Try WP:AFC. Flooded with them hundreds 08:21, 24 November 2018 (UTC)

Reptilians - admin needed

Talk:Reptilians#Requested move 14 October 2018 has been open for about 6 weeks now, and the last edit was over a week ago. There's consensus for the move, but no one has closed it because the page is move-protected. Can an admin please close this discussion, or unprotect the page so that a page mover can do it? Bradv 16:06, 24 November 2018 (UTC)

I have offered to help, but want clarity on the name to move to. - Donald Albury 17:47, 24 November 2018 (UTC)

I think there's a consensus at the moment for the proposed move, but I agree the whole topic area could use some cleanup. Reptilian is currently a disambiguation page rather than a redirect to the plural, and Lizard people redirects elsewhere. The conversation looks like it could use some fresh perspective. Bradv 17:50, 24 November 2018 (UTC)

Killing of Jamal Khashoggi

Talk:Killing_of_Jamal_Khashoggi#Requested_move_28_October_2018 is now at the bottom of the backlog. Numerically, the !votes for option A (assassination) moderately outweigh the !votes for option B (killing). I won't try to summarise the qualitative, policy-based arguments here, since I'm an involved editor, and this is not the place for that (my analysis is visible at the discussion). However, I think I'm allowed to list some meta-level points:

• Regarding the meta-level of policy, a pedantic following of Wikipedia:Consensus#No_consensus, i.e. "default to the title used by the first major contributor after the article ceased to be a stub", would lead us back to, if I recall correctly, Death of Jamal Khashoggi, which almost no editors want.
• The change to Killing of Jamal Khashoggi was intended to be a temporary measure without the intention to prejudge the outcome of the discussion - it's not a "longstanding" title.

Hope this helps someone neutral interested in closing the discussion... Having a month-long discussion continue longer risks diverting energy from article content... Boud (talk) 23:03, 26 November 2018 (UTC)

Health care vs healthcare

I don't feel strongly about which one we should choose, but I do feel strongly that it deserves a discussion, since the two-word form appears to be about 10X more common. It's not possible to have that discussion in a dozen places at once, so please try again using the procedure at Wikipedia:Requested_moves#Requesting_multiple_page_moves. Dicklyon (talk) 19:50, 2 December 2018 (UTC)

@Rathfelder: Oops, I had intended this for your user talk page, but here will do. Maybe others will have opinions. Dicklyon (talk) 22:27, 2 December 2018 (UTC)

• It depends when. Standard usage used to be “to-day” and “battle-field”. English is a changing language. It was normal for compound words to form via hyphenation, but I guess I am not the only one averse to using dashes. —SmokeyJoe (talk) 23:43, 2 December 2018 (UTC)

  I'm pretty sure neither hyphens nor dashes are relevant here, Luddite. Dicklyon (talk) 05:09, 3 December 2018 (UTC)

• Style guides vary. My strong preference is to merge the words. Tony (talk) 03:16, 3 December 2018 (UTC)

  I might be convincable. But with a dozen or more separate open RMs, I felt a dozen or more Opposes were in order. Dicklyon (talk) 05:09, 3 December 2018 (UTC)

Page Mahalia Burkmar moved during debate without warning or explanation (FAO Admins)

@User:Kurtstanleyteh has moved Mahalia Burkmar without warning or explanation to Mahalia (singer) during this debate. This seems highly irregular. I have notified the user and noted this fact in the debate. I don't know if other actions are necessary, or if admins wish to revert the move? MegaSloth (talk) 10:11, 5 December 2018 (UTC)

I have restored it back to the original article name. -Lopifalko (talk) 10:15, 5 December 2018 (UTC)

Post-AfD move review for Paradisus Judaeorum

Paradisus Judaeorum, renamed per Wikipedia:Articles for deletion/Heaven for the nobles, Purgatory for the townspeople, Hell for the peasants, and Paradise for the Jews is currently in discussion at Wikipedia:Move review/Log/2018 December, and may interest watchers here.Icewhiz (talk) 07:15, 11 December 2018 (UTC)

Missing line

At the Requesting multiple page moves section:

after {{subst:requested move

please add | current1 = Current title of page 1

i.e. before | new1 = New title for page 1 with the talk page hosting this discussion

This will enable the code to be used without having to fiddle the number pairs because it doesn’t work without a | current1 . 2A02:C7D:3C1A:7300:8CB2:EE5C:2735:487 (talk) 21:09, 5 December 2018 (UTC)

 Not done: Thank you but that's superfluity. The templates already add that via subjectpagetitle argument. Your claim that it doesn’t work without specifying the name is not true. –Ammarpad (talk) 15:03, 7 December 2018 (UTC)

Actually, in most cases that parameter may be omitted, although there's no harm in going to the trouble of specifying it, as by default the template assumes that |current1= is the page on whose talk the template is placed on.

However, I just got around to updating the WP:RM documentation to show that this parameter may be used for discussions held on centralized WikiProject pages. The Template:Requested move documentation has said that since 26 September 2017.

For a current example of this usage, see Wikipedia talk:WikiProject Formula One#"Formula One" or "Formula 1". – wbm1058 (talk) 17:15, 11 December 2018 (UTC)

He Jiankui

Please remove "(Discuss) – He Jiankui → Jiankui He – Corrected to original order the page was made in and according to his published scientific articles, lab website, and his social media pages CRISPR Editor (talk) 06:06, 6 December 2018 (UTC)" – CRISPR Editor (talk) 22:44, 9 December 2018 (UTC)

The discussion at Talk:He Jiankui § Requested move 7 December 2018 is sceduled to close in about three days, if a consensus is reached. – wbm1058 (talk) 17:25, 11 December 2018 (UTC)

I see, if the face of much opposition, I take this as a request that your move request be withdrawn. wbm1058 (talk) 17:28, 11 December 2018 (UTC)

@CRISPR Editor:  Done – wbm1058 (talk) 17:40, 11 December 2018 (UTC)

Quick move multiple pages

Is there a way outside of AWB to move multiple pages? I've seen that the Welsh Open (snooker) events (such as 2017 Welsh Open (snooker)) are disambiguated, despite there not being any other 2017 Welsh Open articles. However, there are articles from 1992 Welsh Open (snooker) up until the current date.

Is there a userscript to move these on mass as uncontroversial moves, or would you need to do this one by one - Or, requested technical? Lee Vilenski ^{(talk • contribs)} 14:19, 17 December 2018 (UTC)

I don't believe there is such a script, but page movers and admins can move more pages quickly than other users. Also, this proposed move should be fully discussed as Welsh Open (darts) exists. Iffy★Chat -- 14:32, 17 December 2018 (UTC)

Welsh Open isn't the target move, simply the individual years of the event. The darts events themselves are not-notable for an event for each year, and even if they were, they wouldn't be the primary topic.

I've put in a request at WP:PERM. Thanks for your feedback!Lee Vilenski ^{(talk • contribs)} 14:59, 17 December 2018 (UTC)

I have replied at Wikipedia:Requests for permissions/Page mover. I have not approved or rejected the request, but please review my response. Best, Dekimasuよ! 18:52, 17 December 2018 (UTC)

IIRC Only admins can mass move pages using AWB Galobtter (pingó mió) 19:15, 17 December 2018 (UTC)

Lee Vilenski, now that the pages have been moved without discussion despite the comments here and at Wikipedia:Requests for permissions/Page mover indicating that the moves probably shouldn't take place without discussion, at the very least "for" hatnotes to Welsh Open (darts) should be placed on the articles. I don't have time to do it myself today, but perhaps you would be good enough to do so? If that doesn't happen, there might be a later request to revert undiscussed moves in these cases. Dekimasuよ! 16:24, 18 December 2018 (UTC)

Sure, I was going to add hatnotes to the pages, It must have slipped my mind. I'll do that now. Lee Vilenski ^{(talk • contribs)} 16:36, 18 December 2018 (UTC)

These are some proposals on RM

An editor has proposed move RM process to AfD and TfD separately, please comment in WT:TfD#Proposal: move template and module rename nominations from RM to TFD and WT:AfD#Another "articles for discussion" RFC, thanks Hhkohh (talk) 01:21, 23 December 2018 (UTC)

Starting a new RM after another recently closed. When acceptable?

I get that normally we should not start new RMs right after another was just closed, but that alone is not a reason to close a subsequent RM, as there are exceptions. What constitutes an exception?

What if an RM closes largely based on misusing policy, but most of the participants in that RM didn't seem to know that? For example, using COMMONNAME to support a name for a title that is not used at all in English sources? Can we fault the closer for finding consensus when all but one of the participants supported the move? I don't think so. But it's still a problem, isn't it? What if the same arguments are failing in a similar ongoing RM?

Or am I missing something?

Check it out: Talk:1._divisjon#Requested_move_18_December_2018 --В²C ☎ 17:22, 18 December 2018 (UTC)

It depends on the circumstances. Sometimes an RM can be closed as no consensus but with a suggestion to start another one with a different target if the discussion has tended that way. In cases like this one, it should be left at least a couple of months. The proper process would have been to go to the closer and ask them to review or relist, and then take it to WP:MR. Number 57 17:25, 18 December 2018 (UTC)

I've asked the closer to relist. He refuses. My concern is that every hour it remains this way it influences changes all over Wikipedia that will all have to have to be uncovered and reversed. Oh well, if nobody else cares I guess I don't need to. --В²C ☎ 18:18, 18 December 2018 (UTC)

The close has been reverted and relisted. Hopefully we can correct this now. --В²C ☎ 19:34, 18 December 2018 (UTC)

(e/c) He's relisted it. And if he had continued to ignore it, WP:MR was the correct venue. Number 57 19:36, 18 December 2018 (UTC)

• Obviously inappropriate troll close, anyone may revert.
• BADNAC, any uninvolved admin may revert.
• The closer may revert. You may ask the closer to revert, but beware WP:HARASS, a recent trend in the way some people speak to closers they’ve disagreed with.
• WP:Move review

—SmokeyJoe (talk) 21:22, 18 December 2018 (UTC)

Sorry for the confusing “reopen” language in the section header here. I’ve reworded. I’m not asking about when you can revert a close. I’m asking when it’s acceptable to start a new RM soon after one was closed for the same article. Never? —В²C ☎ 22:29, 18 December 2018 (UTC)

There is the essay Wikipedia:Renominating for deletion, which mentions "Requested moves", and cites ""We have a long tradition that after a WP:RM is closed that it is not re-listed for six months after the last listing. --User:PBS (talk) 07:45, 9 July 2009 (UTC)". I have been for a long time unsure whether this essay should be split, deletions from renames. In favour of not splitting is that the advice on appealing and renominating is the same.

In the last few years we have had extended discussions within MRV discussions largely upholding six months as the general rule.

I have argued that following a "no consensus", the six months should reduce to to a default of two months. This would harmonize with AfD. User:PBS I think disagrees.

I vaguely recall broad agreement that a "very good reason" such as changed or new information may justify a quicker renomination, but this certainly doesn't support your case above which was immediate, withing a week, and spoke to mistakes not new information.

If in doubt, ask the previous closer. Ideally, a discussion will state, or allude, to whether more discussion is desirable, and the person to judge is the closer.

Wikipedia:Moratoria is related but doesn't quite speak to this. --SmokeyJoe (talk) 00:05, 19 December 2018 (UTC)

That's an essay, not a policy, exceptions are understood. And if nothing else, one can invoke WP:IAR, I suppose. Re-titling all these articles with non-English names contrary to policy does not improve the encyclopedia; to the contrary. Anyway, the closer finally relented and the original RM has been re-opened and looks like sanity is prevailing (knock on wood). But that's only because this closer relented. Had he not, then starting a new RM would be the only recourse, as the grounds for an MRV were super thin in this case given that all participants but one, up to the point of the close, had supported. If the way the discussion is going now is any indication, a new RM likely would have succeeded in reversing the previous RM decision, assuming people would not object purely on "too soon" grounds (as if there should never be any exceptions). I get the "too soon" argument, but in some cases, local consensus gets it obviously wrong, misreading or ignoring policy, probably through ignorance, especially when article content experts dominate an RM and very few if any RM/title experts are there, and an inexperienced closer comes along and doesn't recognize what's happening... I think we should allow for exceptions to the "before 6 months is too soon for another RM" in cases like this, probably in some other cases. Back-to-back RMs should not be rejected by knee-jerk "too soon" objections. Let's evaluate the situation in each case. --В²C ☎ 02:57, 19 December 2018 (UTC)

Disagree. WP:MR was created to bring respect for the process to WP:RM, and it has been doing that job well. Someone claiming "they all got it wrong" and reverting RM-concluded page moves, or starting new discussions as if the previous discussion and close was worthless, were the features of the gross dysfunction of the old days of WP:RM. Tendentious re-arguing titling decisions will get you blocked and banned. If you don't like the close, and the closer doesn't agree, the answer is MRV. MRV can re-open the RM. MRV would work more quickly and easily if some people, including you, didn't overwhelm it with long-winded wordy repetitive verbosity. --SmokeyJoe (talk) 03:14, 19 December 2018 (UTC)

Point taken about MRV. I forgot that a MRV result can be a revert close/reopen/relist. Not sure if the verbosity is the only or even main reason they take so long to get resolved. But often it's not really an urgent matter, just like with most RMs. But when people are using a dubious result as grounds to change much on WP, then it becomes urgent. I think we need recognition of such situations. --В²C ☎ 03:45, 19 December 2018 (UTC)

For the record, in this case sanity did prevail, as the reverted and re-opened close/move RM in question was now closed as "no consensus". But if the closer had not relented the only recourse would have been an MRV seeking a close/reopen/relist? --В²C ☎ 22:18, 2 January 2019 (UTC)

Revenge of the Dreamers III

trying to start a article for "Revenge of the Dreamers III",— Preceding unsigned comment added by NC792 (talk • contribs)

@NC792: Your account is very new, and very new accounts cannot create articles directly. You need to use the WP:Article wizard. --Izno (talk) 13:27, 9 January 2019 (UTC)

Suggestion: RM regulars participating at Wikipedia:Requests for permissions/Page mover

I have noticed issues (greater or lesser) with a number of NAC page moves recently. This is normal and we can deal with any issues that arise through standard procedures. I don't object to NAC closes or the process for granting the page mover permission.

However, it strikes me that the administrators reviewing Wikipedia:Requests for permissions/Page mover do not tend to be those who frequently review or close discussions at RM. I think we might benefit from having more editors familiar with the process here interacting with editors who are requesting the page mover right. This is a suggestion that we add Wikipedia:Requests for permissions/Page mover to our watchlists and consider adding our perspectives to the discussions there. Dekimasuよ! 19:04, 17 December 2018 (UTC)

I have been trying to monitor the discussions there, but more eyes would still help. Pinging, for example, Amakuru, Andrewa, Anthony Appleyard, bd2412, BrownHairedGirl, and might continue down through the alphabet if necessary. Do you frequent the page at all, or keep an eye on who is being granted these flags? I have seen Galobtter there recently, which is helpful. Dekimasuよ! 01:44, 12 January 2019 (UTC)

Thanks for the ping, Dekimasu.

I don't personally have the time and energy to participate in WP:PERM/PM. However, I have just taken a look at WP:Page mover#Guidelines_for_granting, and I am disappointed to see that experience at WP:RM is not actually required. This seems to me to be a most undesirable omission; page movers should show that they have exercised good judgement in the formation of consensus of page moves. --BrownHairedGirl (talk) • (contribs) 02:08, 12 January 2019 (UTC)

I agree with BHG. It is entirely possible for editors who are not page movers, but have a reasonable amount of experience, to engage in non-admin closures of pages where there is an absence of consensus to move or consensus against a move. They should exhibit some ability to do this before closing discussions that do require a move. bd2412 T 02:15, 12 January 2019 (UTC)

Page mover rights are also granted for doing draftifications at NPP and I think there are other uses for it beyond article moves at RM, which is why I think that isn't a requirement, though I certainly agree that some experience - even commenting, though closing is better - at RM is quite important in demonstrating familiarity with the relevant policies and guidelines (and also teaches people how controversial seemingly uncontroversial page moves can be). Galobtter (pingó mió) 05:36, 12 January 2019 (UTC)

@BD2412 & Galobtter: I wouldn't necessarily want to see RM closures. Closures may be relevant, but it seems to me that what matters is demonstrated ability to weigh an article title against policy. That may come from closures, but since WP:RMCI rightly discourages non-admins from closing contentious or complex discussions, it seems to me to be that non-admin closures are unlikely to involve much detail.

So I think that it is more likely that good analysis and judgement would be displayed through participation in the discussion. I'd be looking for evidence that the candidate was routinely doing a lot more than "support per nom" or "oppose per Foo", and was getting out some substantive policy-based reasoning which showed a grasp of the nuances. --BrownHairedGirl (talk) • (contribs) 05:40, 12 January 2019 (UTC)

I am trying to engage those requesting the permission in conversations, hoping to convince them to read through aspects of titling policy with which they do not seem familiar. Unfortunately with the criteria as they are I find it a bit difficult to simply say no to editors without much experience. Usually "without much experience" means no history of participation in RM discussions at all. Dekimasuよ! 06:50, 12 January 2019 (UTC)

The engagement is good. The sort of cases where someone technically meets the criteria but shouldn't get the right usually are discussed among multiple admins and makes for a more convincing decline when it is clear someone was evaluated thoroughly. Galobtter (pingó mió) 07:53, 12 January 2019 (UTC)

Objective opinions, please

After looking at my close (very short and simple) and the discussion challenging it on my talk page, I'd like a few objective opinions from experienced closers about whether it's appropriate or not and whether I should reopen.

The close is here:

• Talk:Proteza_koniecpolska

It has been challenged here:

• User_talk:Born2cycle#Please_reopen_RM.

Thanks! --В²C ☎ 20:50, 22 January 2019 (UTC)

• Closing statements should explain the close, and reflect the discussion. They should not, for example, extrapolate into deletion recommendations if no one in the discussion alluded to deletion. —SmokeyJoe (talk) 21:12, 22 January 2019 (UTC)
  • My statement in question, But if the apparent dearth of such RS is accurate, this article should probably be removed from the English WP., is not a deletion recommendation, given the huge IF it starts with, and the "probably" qualification. It's practically identical in meaning to what the notice at the top of the article itself already states: If notability cannot be established, the article is likely to be merged, redirected, or deleted. Anyway, who restricts what can be said in closing statements? Where? Closers are generally given wide latitude in what is said there, and often use it. If you think closing statements should be restricted as you're suggesting here, or in any other way, then I suggest you try to see if you can get consensus to include such guidance at Wikipedia:Requested_moves/Closing_instructions. In the mean time, don't try to hold me or anyone else to your imagination of what you believe the restrictions should be. --В²C ☎ 21:30, 22 January 2019 (UTC)
    • You have wide latitude with what you say in your userspace pages. Closers of formal discussions do not have “wide latitude”. I think closing statements should be restricted to qualified respected closer’s, or cautious statements for beginners. I think you should not be closing discussions because you don’t get these subtleties and it takes forever to explain stuff to you. —SmokeyJoe (talk) 22:00, 22 January 2019 (UTC)
      • If you had a valid point, you would have nothing to explain, as you could simply point to the relevant guideline or policy. But since you're making up rules as you go, just to harass me, you've got nothing to base your opinion on. No wonder it takes "forever to explain". It's not explainable. --В²C ☎ 22:24, 22 January 2019 (UTC)
• B2C - If you are not prepared to be criticized for your close, perhaps you should not have asked for opinions. As for mine: I think Smokey makes a valid point. I also think you should have closed the RM with a simple “no consensus”... and then (perhaps) followed it up with a separate talk page thread with advice on “next steps”... doing this would have separated your “official” action as a closer from your “unofficial” advice as an experienced fellow editor. By combining the two, you opened the door to challenges that you could have avoided. Blueboar (talk) 22:43, 22 January 2019 (UTC)
  • Thanks for the advice, though I have to note our past disagreements could be coloring your opinion. I recall other closers leaving similar advice in their closes. I do not recall anyone else doing that ever being criticized for it. Do you? --В²C ☎ 22:50, 22 January 2019 (UTC)
  • I've revised the closing statement again, Blueboar, to say this: No move due to lack of support even after relisting. I suggest references in English WP:RS be found to help determine the WP:COMMONNAME for this topic. But if the suggested dearth of such RS is accurate, also consider the notice on this article which says, "If notability cannot be established, the article is likely to be merged, redirected, or deleted." [9] Better? --В²C ☎ 22:58, 22 January 2019 (UTC)
• Although someone else started the thread with "Please reopen", I don't it is nearly that serious. Moving forwards... It is a problem article. Few sources, none good, and what there is is local Polish. I reacted against what I read was a suggestion to move to deletion, and I know enough about railway lines on Wikipedia to know that that is not a suggestion to be made lightly. My best idea is Talk:Proteza_koniecpolska#Merge_to_Częstochowa#Transport. It is a side line that serves Częstochowa. --SmokeyJoe (talk) 23:12, 22 January 2019 (UTC)

Request for clarification regarding third bullet instruction

In the instruction's third bullet: "If your technical request is contested, or if a contested request is left untouched without reply, ...", the "or" conjunction seems inappropriate. In my opinion, the text needs some manner of modification. Do others agree? If so: how should it be changed? Thank you.--John Cline (talk) 08:35, 24 January 2019 (UTC)

T210739: Target deletion during page move fails

Tracked in Phabricator
Task T210739

​​Does anyone seem to have figured out what's causing the MWException bug when moving pages? I'm not involved with Phabricator, but does the thread here being rated as "high" mean that it will be taken care of anytime soon? This used to seem like a random error, but it's happening to me quite frequently now. Dekimasuよ! 02:39, 14 January 2019 (UTC)

• It had stopped for a while, but now it has returned. bd2412 T 02:41, 14 January 2019 (UTC)

​​​​​Any thoughts on creating a default admin gadget until T210739 is resolved? See phab:T210739#4896481/zh:MediaWiki:Gadget-T210739.js. I made a user script version for now. Thanks for the code, Xiplus. — JJMC89 (T·C) 21:10, 21 January 2019 (UTC)

• So process wise, you want people to just manually delete the target first? Seems like we could take care of that with just directions. — xaosflux ^Talk 21:35, 21 January 2019 (UTC)

  Yes, that is the only workaround that I know. The gadget/script just makes it easier. — JJMC89 (T·C) 22:07, 21 January 2019 (UTC)

  MediaWiki:Delete and move confirm (newly resurrected) seems sufficient? I dunno that we need to inject a brand-new ooui menu into every sysop's workflow, especially if it's intermittent. ~ Amory (u • t • c) 01:34, 22 January 2019 (UTC)

  As far as being intermittent, it's been a while since I've had even one of these moves work properly. It seems pretty consistent at this point. Dekimasuよ! 02:56, 22 January 2019 (UTC)

  I have been getting the error every time I try to move over existing pages, so I mostly gave up trying and just delete them first. Well, the user script is there for anyone who wants to use it. — JJMC89 (T·C) 04:20, 23 January 2019 (UTC)

Anomie has solved this, bailing out the developers working on the new feature that will enable blocking editors from editing or moving specific pages. Alas, the "replecation bug" de facto blocked us all! It appears to me like the fix should make it into Thursday's software release; when it does send him some barnstars. The detective skills used to track it down were first rate. I have some new appreciation for the complexities involved in programming for a system that makes changes to a database that is replecated on many servers. – wbm1058 (talk) 21:37, 23 January 2019 (UTC)

Yay! Working again. – wbm1058 (talk) 01:12, 25 January 2019 (UTC)

Guidance on swopping existing page and existing redirect page

Sorry if this is in the wrong place, but I can't find any forum that seems more appropriate. The article Tonight at 8:30 needs to be moved because the actual title of the work in question is Tonight at 8.30 (full stop, not colon). But there is a redirect page called Tonight at 8.30. I realise I'll need to change about 70 links from other articles, but I don't know how to go about swapping the real page and the redirect round. Any help gratefully received. Tim riley talk 12:19, 25 January 2019 (UTC)

Make a request at WP:RM/TR and a page mover or an admin will swap them for you. Iffy★Chat -- 12:30, 25 January 2019 (UTC)

Thank you very much. I shall follow your advice. Tim riley talk 12:39, 25 January 2019 (UTC)

Neutral nominations vs. nomination that lobby for one result

Re:

"Unlike other request processes on Wikipedia, such as RfC, nominations need not be neutral. Make your point as best you can..."

and

"Nomination already implies that the nominator supports the name change, and nominators should refrain from repeating this recommendation on a separate bulleted line."

I don't think that this is a good way to do things. I think that the nominator should have the option of either making his point in the nomination or creating a neutral nomination and making his point in a "support as nominator" bulleted line.

I would like to discuss this informally here before I create an RcF asking the question. --Guy Macon (talk) 00:35, 26 January 2019 (UTC)

Nominators already do and can when they are neutral to the move in question, thereby removing the implication. They just add a sentence that says 'RMd procedurally' or 'I have no preference', etc. --Izno (talk) 00:47, 26 January 2019 (UTC)

• Support flexibility. A nomination can lead from the strength of the central simple argument (similar to the edit summary of a bold page move), the “support” is obvious, or they can redundantly with an abundance of clarity make a dot point “support as nominator”. Or people can go RfC neutral non style, present neutral information as background, and then make the POV argument from their first dot point. Any closer who doesn’t understand should not be closing. —SmokeyJoe (talk) 00:57, 26 January 2019 (UTC)

• Closers should understand whatever is thrown at them, but this is still not a necessary change. The "neutral" part of the statement is already there, e.g. "Taq Bostan → Taq-e Bostan –". Anything after the en-dash that is not an argument in favor of the move is superfluous, because the proposed change has already been noted. The fact that a move is being proposed, and from where to where, is already shown within in the requested move template. Dekimasuよ! 01:12, 26 January 2019 (UTC)

• After several reads I still cannot read this. Can I ask you to better consider accessibility issues. Some of us, Hyphen luddites, simply cannot process anything involving “en-dash” without considerable effort involving rewording to remove all dashes. In my professional life, I have never used a dash, and never will. —SmokeyJoe (talk) 01:25, 26 January 2019 (UTC)

• Sorry. I was simply drawing upon the most recent open move request from the main RM page. If you look at any open move discussion, it begins with a neutrally-worded template, followed by the line that consists of the current title, an arrow to the proposed title, a [sideways line], and then the reason for the change. I am suggesting that anything following the neutral template, the current title, and the proposed title other than a reason for the change is superfluous, because the template already serves as a neutral description of what the discussion entails. Dekimasuよ! 01:33, 26 January 2019 (UTC)

• I think I agree With Guy Macon, but do not see much need to change anything. I read the instructions as non-mandatory advice. Failure to follow exactly should not see the request speedily closed. For someone new to RM, a simple single line of instruction is better than swaths of documentation on all viable options. —SmokeyJoe (talk) 02:43, 26 January 2019 (UTC)

• That's pretty much what we do now: link to WP:RM#Nom when nominators !vote. I can't recall anything being speedily closed for this reason, although I may have done procedural closes when the text was never altered from "place your rationale here." Dekimasuよ! 03:38, 26 January 2019 (UTC)

• I would oppose any change to this setup at Wikipedia:Requested moves. There is a simple solution: if you don't think a move needs to be made, don't request a move. Requesting that an action be taken (a change to the title of a page) is fundamentally different from requesting that others to contribute to an open-ended discussion as in requests for comment (there are only three possible outcomes in a move discussion). There is no such thing as a neutral nomination at WP:RM; if evidence in favor of the move is not presented, there is no case to answer. To request a move despite being uncertain of whether one should take place is a burden on the system, and changing this will invite the creation of frivolous requests. Another reason we instituted this setup (in addition to mostly deprecating the separation of "debate" into survey and discussion sections) was to reduce the tendency to treat the discussion as a vote. Whether the editor requesting the move notes support separately or not should have little effect on the outcome of the discussion. Again, the underlying principle is to simply say what you mean. Dekimasuよ! 01:16, 26 January 2019 (UTC)
  • I don’t really understand your response to me, but I agree with all of this dot point. I oppose open ended RM nominations. Every nomination must include a specific proposal, otherwise the request is premature. Use a simple talk page thread for discussion of options that are general or open ended. Neutral nominations are possible, but they should be restricted to a procedural nomination by the closer of another discussion where the closer reads a consensus to follow up with a differently focused proposal. —SmokeyJoe (talk) 01:18, 26 January 2019 (UTC)
    • I completely reject the false dilemma of asserting that a neutral opening statement is the same as an open-ended opening statement. The system used on RfCs has many examples of neutrally worded openings that include a specific proposal. There is absolutely nothing wrong with saying what you want to do in the opening and then explaining all the reasons why you think it should be done in your "as nominator" comment. --Guy Macon (talk) 07:12, 26 January 2019 (UTC)

• When a move request is opened, the specific proposal is included in the template; there is no need for any additional neutral opening. "Taq Bostan → Taq-e Bostan" is already functionally equivalent to a neutral statement asking, "Should Taq Bostan be moved to Taq-e Bostan?" The information generated by the template is followed by the reasons you think the move should be performed. There is no need for any "as nominator" comment or !vote after you have already said why the change should be made. I'm not understanding why this is an issue, but there are about 190 move requests open now, so would it be possible for you to find a few where you think a change to the instructions would have been helpful and share them here? Dekimasuよ! 07:49, 26 January 2019 (UTC)

Administration of page move

People who know how to move pages over other pages while preserving history will understand what error occurred, but Muboshgu did some maneuvering of pages that resulted in lost history for moving Edwin Jackson (disambiguation) to Edwin Jackson. We need some assistance.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:28, 28 January 2019 (UTC)

​I've history merged the disambiguation page. — JJMC89 (T·C) 05:23, 28 January 2019 (UTC)

Did I miss something in the edit histories? – Muboshgu (talk) 06:09, 28 January 2019 (UTC)

Muboshgu, It seems that you created a new page or something without regard to edit histories.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:26, 29 January 2019 (UTC)

TonyTheTiger, there was a disambiguation page that shouldn't have existed. I redirected it to the new redirect page after moving the baseball player to a disambiguator. I'm still unclear on what I did wrong. – Muboshgu (talk) 15:37, 29 January 2019 (UTC)

At a glance it looks like you may have created a new disambiguation page at Edwin Jackson when there was already one at Edwin Jackson (disambiguation), instead of moving the existing dab page to the plain title. Dekimasuよ! 16:06, 29 January 2019 (UTC)

Dekimasu is spot on. — JJMC89 (T·C) 02:22, 30 January 2019 (UTC)

Moving disambiguation on a lot of pages

Hi there, I hope you can help. I've brought up at both WT:SPORTS and WP:RFC to no comments regarding moving articles with the suffix (bowls), such as Paul Foster (bowls) to be moved to a more suitible name, such as Paul Foster (bowls player). However, as this seems to be on a lot of player bios, I'd want a consensus that this was the correct move. This would only be the way forward for players, so say, an article that was created for Jack (bowls) (the piece of equipment) would be fine.

There's also an argument for Paul Forster (bowler), however, "bowler"s would be quite easy to mistake for skittles players, or ten pin bowlers. Where would be a good place to raise the question for a change in naming convention for these types of articles? Lee Vilenski ^{(talk • contribs)} 14:17, 5 February 2019 (UTC)

Perhaps WT:NCSP? There are many sports that are generally handled with this sort of disambiguation. Dekimasuよ! 17:34, 5 February 2019 (UTC)

Questionable page move

Resolved

It seems improper for Template:Julius Caesar (play) to have been moved from Template:Julius Caesar by The Transhumanist. Should this be reverted. There is no ambiguity in need of disambiguation.--00:05, 5 February 2019 (UTC)

It looks a good move to me. Category:Julius Caesar is huge, it is entirely reasonable to expect a complementary WP:CLS navigation template for Julius Caesar, and for Template:Julius Caesar (play) to match its parent article Julius Caesar (play). --SmokeyJoe (talk) 00:50, 5 February 2019 (UTC)

I am not an expert in the policy regarding template disambiguation, but on article space pages we don't disambiguate until the competing page comes into existance. Is there a policy in this regard for templates to match article space and category space even in the absence of a competing page?-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 01:56, 5 February 2019 (UTC)

In article space, there is a practice of hyper-concision aka brevity aka title minimalism. It is little benefit for any reader or editor. For templates, it would have even less than zero benefit. Templates, like categories, should follow their parent article. They should not be briefer, but sometimes there are reasons for increased description. Templates and categories following their parent article for titling style makes things very much easier for understanding template and category associations with articles. Articles are what really matter, templates and categories serve articles. --SmokeyJoe (talk) 02:12, 5 February 2019 (UTC)

Thanks for the clarification.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:12, 7 February 2019 (UTC)

You’re right, TonyTheTiger, the community generally eschews unnecessary disambiguation, and most don’t consider uses that don’t have coverage on WP when making disambiguation decisions. I am not aware that templates are treated differently. That said, in this case the disambiguation appears necessary, as explained by SJ above. —В²C ☎ 07:32, 7 February 2019 (UTC)

Early close for RM of 2010–2017 Toronto serial homicides

This move request (Talk:2010–2017 Toronto serial homicides § Requested move 31 January 2019) is only five days old, but I'm planning to nominate the article for Wikipedia:In the news tomorrow Feb 8 and would rather it be at a stable location – and have time to rewrite the lead for a move, if needed. Would it be possible to close the move discussion today? Though I don't want to rush it or have an ill-considered decision. – Reidgreg (talk) 17:20, 5 February 2019 (UTC)

The discussion was relisted @ 11:58, 7 February 2019 – wbm1058 (talk) 16:15, 7 February 2019 (UTC)

@StraussInTheHouse: You relisted this discussion though there is close to 1,500 words of discussion by a dozen editors (including nom). The relisting instructions recommends Users [...] relisting a debate with a substantial discussion, should write a short explanation on why they did not consider the debate sufficient to close. For my own curiosity (I'm interested in move procedures) I'd appreciate knowing why you relisted it. – Reidgreg (talk) 16:42, 7 February 2019 (UTC)

Hi Reidgreg, I relisted it because two guidelines had been cited for opposite sides of the argument (WP:PERP and WP:CONSISTENCY) and I didn't feel that consensus was clear enough to close as either moved or not moved. Thanks, SITH (talk) 17:31, 7 February 2019 (UTC)

Yoghurt Principle

I'd appreciate input/comments/suggestions on this RM-related essay I wrote years ago, and recently made some revisions too. Particularly from RM closers who have not seen it.

Please leave comments on the talk page of the essay itself.

• User:Born2cycle/Yogurt_Principle

Thanks! --В²C ☎ 21:47, 17 December 2018 (UTC)

My only comment is that you continue to demonstrate exceptional persistence in flogging a horse which has been dead for years.

If there was a barnstar for long-term WP:IDHT, you would be a worthy recipient. --BrownHairedGirl (talk) • (contribs) 02:13, 12 January 2019 (UTC)

Every time I am reminded of that, my yog hurts. Jonathunder (talk) 23:38, 22 January 2019 (UTC)

The Yogurt Principle is a general principle that applies to many situations other than the one it is named after. Hopefully we have learned from it. Sadly, many closers remain reluctant to close per general consensus just because there is no local consensus. —В²C ☎ 03:34, 23 January 2019 (UTC)

As you keep talking about this, I'll give my (dismissive) response to it: I see no coherent principle presented here other than that you think moves that you like are good moves. For several of these, your "strong policy-based arguments" seem like WP:ILIKEIT and nothing more; in a few cases policies changed between the discussions. In one case (Hillary Clinton), usage changed. And Ivory Coast (or at least the parallel case of East Timor) continues to be contentious to this day. power~enwiki (π, ν) 03:40, 23 January 2019 (UTC)

Post the 2016 campaign, HC reverted to HRC. The community made a bad decision, for no benefit to any reader, giving in to the agitators.

The principle is a matter of circular logic for when it works; it can be said to "describe" any situation where something moves from a stable situation to a more stable situation, considered in hindsight. It is not a principle for "applying" as it does not have a robust underlying theory. The notion that a powerful closer should discriminate between a "local consensus" and a "general consensus" is seriously flawed. If there is a difference, a discussion participant must introduce the argument to the discussion. If the closer does this, it is a WP:supervote. --SmokeyJoe (talk) 03:58, 23 January 2019 (UTC)

No robust underlying theory? Perhaps you missed this part of the nutshell: there are strong policy-based reasons to move to the proposed title, and the move would result in a situation where there are no strong policy-based reasons to move the article back. The underlying theory is that in such a situation once the move is made, there would be "no strong policy-based reasons to move the article back", and thus the article would be stable. How is that not robust? And these situations are not as subjective as one might think. After all, anyone can easily imagine a proposed move as if it had been performed, and then see what if any policy-based reasons there may be to move it back. The classic example is of course Yogurt itself, in which several of us pointed out repeatedly for years the dearth of policy-based reasons there would be to move the article once the article was moved to Yogurt, and nobody else was able to counter because of course there were no policy-based reasons that would apply. This of course has been made obvious for the 8 years of absolute peace since the move, but my point is it was just as obvious before the move to anyone who seriously considered it. And so it is in many other situations (not saying it always is; YP applies only situations where it is obvious).

As to The notion that a powerful closer should discriminate between a "local consensus" and a "general consensus" is seriously flawed... didn't you recently uphold a closer doing exactly that at Wikipedia:Move_review/Log/2018_November#Jaggi_Vasudev? After all, the local consensus there clearly supported the move, 14 to 6, yet the closer whose decision you endorsed declared consensus to oppose the move. I considered that a super vote in that case because both local consensus and policy-based reasons (general consensus) supported the move. --В²C ☎ 19:54, 23 January 2019 (UTC)

If I remember correctly, there was a strong policy-based argument for keeping the page at yoghurt: Namely, that the article had been stable at that title for eight years (coincidently). The only lesson learnt from your self-indulgent essay is that if you keep banging on, you'll eventually get your way. That's not a lesson we should be teaching, in my opinion.--Ykraps (talk) 17:23, 24 January 2019 (UTC)

• I do think that there should be a principal that if the same issue is raised over and over again, and each time a majority is in favor of changing it, but not a supermajority, the persistence of majorities favoring a change in previous discussions should be a factor weighing in favor of the proposal. bd2412 T 22:47, 23 January 2019 (UTC)

Thanks everyone. Ykraps, yes, there was that strong policy-based argument for keeping the page at yoghurt. That's the point: to look past that and think, from that situation, while it was still at Yoghurt, what policy-based argument would there be, if any, if the page was moved as proposed. In other words, while it was at Yoghurt, think about what if it was moved to Yogurt, would there be any strong policy-based arguments to move it back again to Yoghurt? And, the answer, which was obvious then and even more obvious 8 years after the move, was no. Once the article was at Yogurt, back to its original variety of English, there would be no strong policy-based argument to move it back to Yoghurt. That's how it is, and that was always the point. Had nothing to do with getting "my way", unless you recognize that "my way" is nothing but title stability and resolving disputes about titles. I just presented a similar argument favoring restoring the original British English variation at Talk:German mediatisation#Requested move 22 January 2019, which at least some editors found persuasive. That one was not nearly as controversial, but it's a similar underlying principle. Now that it's moved back to the original variant, what strong policy-based argument can there be to move it back to German mediatization? None. Ta da! I got "my way" again. Title stability!

BD2412, recognizing a majority though not a supermajority regularly favors a move is a different consideration. The Yogurt Principle is more about imagining the article is moved as proposed (assuming there are strong policy based arguments supporting and opposing the move), and considering what if any policy based arguments might there be to reverse that move, and, if none, to move it. It's about recognizing that at the current title there is controversy, but at the proposed title there won't be. --В²C ☎ 18:30, 7 February 2019 (UTC)

P.R. Subdivisions - Moving disambiguation on a lot of page Comment

Good day. I'm not exactly sure the best way to go about this so that's why I'm here.
There are articles for almost all of the 901 barrios of Puerto Rico and an editor suggested they not be named with parenthesis (as I did when I created them), but be separated by commas.
The list of articles is List of communities in Puerto Rico. Most of them should be an easy enough move but there may be some issues with articles that have already been moved before.
Please let me know how to proceed. My idea with (User talk:Ymblanter) is to move them:
barrio name, municipality to barrio name, municipality, Puerto Rico

• Lajas, Lajas would become Lajas, Lajas, Puerto Rico.
  
• Algarrobo (Yauco) --> Algarrobo, Yauco, Puerto Rico

Please see the related discussion here.--the eloquent peasant (talk) 16:58, 8 February 2019 (UTC)

and also disambiguation pages would be needed for some: i.e.

• Guayabo Dulce ---> Guayaba Dulce, Hato Mayor, Dominican Republic AND ---> Guayabo Dulce (disambiguation)
• Guayabo Dulce (Adjuntas)---> Guayabo Dulce, Adjuntas, Puerto Rico.

So my question is should we just go ahead and make the moves or should (we call the movers) and place a redirect request on each of the articles' talk page? --the eloquent peasant (talk) 19:23, 8 February 2019 (UTC)

Requests to revert undiscussed moves

How long after an undiscussed move can that section (and as opposed to the standard "Uncontroversial technical requests"). Wikipedia:Requested moves/Closing instructions notes about the stable title, even if not the original title. While this would affect consensus generally, I'm asking here since we have that section. I think I have read somewhere that the standard time for a title to be considered long standing is 2 years.

My suggest might be in general that "Requests to revert undiscussed moves" can be used if:

1. A page has been moved without discussion less than a year from a title that it was stable at for over 2 years.
2. A page has been moved against a previous consensus (particularly a formal RM) regardless of how long ago (per WP:NOTBURO people may consider IAR to not reverting a move where things have changed favouring the move that weren't the case at the time of the previous consensus, particularly if it was noted that the situation may change in the future).

I ask about Boreray, North Uist, in this case it was moved against a guideline (WP:UKPLACE) and the moves were objected at Wikipedia talk:WikiProject Scotland/Archive 12#More cleanup required[10]. The editor was asked to revert them and most were reverted but a few were missed.

The section was added on the 4th of June 2013 by User:Peter James. Generally as I understand it, those at "Uncontroversial technical requests" can easily be contested by moving them to "Contested technical requests" while those at "Requests to revert undiscussed moves" are generally automatically granted unless an immediate revert is deemed unsuitable, compared to a full discussion. See Talk:Kolossus#Requested move 23 January 2018 where the difference was pointed out. Crouch, Swale (talk) 21:40, 9 February 2019 (UTC)

• I support no limit. A limit to lock in a silent consensus gives incentive to make quiet, sneaky moves to barely watched articles. The only exception should be page moves by the creating author in the first few dozen page edits. —SmokeyJoe (talk) 22:22, 9 February 2019 (UTC)
  • I agree. But to reiterate, we’re not talking about ALL undiscussed moves, just those that were at least clearly controversial at the time of the move. There is no requirement to go through RM for uncontroversial moves. —В²C ☎ 06:19, 10 February 2019 (UTC)
    • Surely having no limit would be too far, as B2C notes at least being uncontroversial at the time of the move. AFAIK many moves were made in the early days that if reverted unilaterally would be considered too controversial[11]. With regard to "sneaky moves" all moves are in the move log and editors can check the user's move log so if a page move was made that was not clearly inappropriate and it isn't objected to within a year (which is IMO more than enough time for someone to notice) then it should be considered de facto community consensus. If a move was preformed that is clearly inappropriate that remained in place for years and was attempted to be moved back (with objection), then there would likely be consensus at RM to but it back at the appropriate title. Crouch, Swale (talk) 17:08, 10 February 2019 (UTC)
      • WP:Silence is the weakest form of consensus. Age does not lock in an old decision, however a large number of subsequent edits possibly does matter. —SmokeyJoe (talk) 22:03, 10 February 2019 (UTC)
• Case-by-case analysis of the circumstances seems to have worked fine to this point. Dekimasuよ! 20:04, 10 February 2019 (UTC)
  • Talk:Rum_and_Coke#Requested_move_5_November_2018 was a nice case where the bold move was old, but the reason for exception was the subsequent development of the article, not the time passed. (The question of defaulting to reverting the bold in the case of “no consensus” was moot because the discussion actually found consensus to not move. —SmokeyJoe (talk) 22:01, 10 February 2019 (UTC)

Use an RM-template in my sandbox

I want to prepare a multipage move in my sandbox page. Can I use the {{requested move}} there, not subst'ed? -DePiep (talk) 09:58, 15 February 2019 (UTC)

Do a move

How do I get a user to do a move like on this page? — Preceding unsigned comment added by Quiz shows (talk • contribs) 10:19, 15 February 2019 (UTC)

Which page do you want moved... and what do you want it moved to? Blueboar (talk) 12:51, 15 February 2019 (UTC)

I figured it out. --Quiz shows 21:10, 16 February 2019 (UTC)

Semi-protected edit request on 18 February 2019

Please swap Saturday Night (Is the Loneliest Night in the Week) (currently a redirect) and Saturday Night (Is the Loneliest Night of the Week) (currently the main article) - per article citations, the original song was titled "...in...", with variants sometimes subsequently recorded as "...of...". Thanks, 209.6.209.51 (talk) 17:06, 18 February 2019 (UTC)

The criteria that matters here is not what the original song was titled but how the song is most commonly known today as determined by looking at usage in reliable sources. See WP:COMMONNAME. The proper way to determine this not by one person making the determination unilaterally, but by consensus through discussion, starting by creating a Requested Move discussion at Talk:Saturday Night (Is the Loneliest Night of the Week) per the instructions at Wikipedia:Requested_moves#Requesting_controversial_and_potentially_controversial_moves. --В²C ☎ 18:52, 18 February 2019 (UTC)

I've opened a move proposal at Talk:Saturday Night (Is the Loneliest Night of the Week). - Station1 (talk) 21:20, 18 February 2019 (UTC)

What to do?

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was request processed. В²C ☎ 02:35, 21 February 2019 (UTC)

---

These events occurred in the following chronological order:

1. 2019_Balochistan_attack is filed at AfD [12] See: Wikipedia:Articles_for_deletion/2019_Balochistan_attack
2. 2019_Balochistan_attack is unilaterally moved to 2019_Balochistan_attacks [13] by 11S117
3. 2019_Balochistan_attacks is unilaterally moved to February 2019_Balochistan_attacks [14] by Anupam
4. Same user, Anupam, tries to revert title to be in line with ongoing AfD, but can't, so files technical request to revert accordingly [15]
5. Technical move request accidentally converted to contested request [16]
6. Contested move request converted to revert request [17]
7. Technical request is labeled not done by StraussInTheHouse, at least pending outcome of Afd [18]

Here is the complete discussion as of a few minutes ago:

* February 2019 Balochistan attacks (currently a redirect to Terrorist incidents in Pakistan in 2019) → 2019 Balochistan attack (currently a redirect instead to Terrorist incidents in Pakistan in 2019) (move · discuss) – The article is going through an AFD right now, so I believe that it would be best to wait until the AFD concludes before moving the page. Anupam^Talk 20:14, 19 February 2019 (UTC)

 Not done: re-request once the AfD has concluded, assuming it is kept. SITH (talk) 22:01, 19 February 2019 (UTC)

User:StraussInTheHouse, thanks for your reply. The AfD was named after the original title which was: 2019 Balochistan attack. That is why I feel that the article should reflect the original title before the AfD concludes. I hope this helps. With regards, Anupam^Talk 07:02, 20 February 2019 (UTC)

Yeah, it would actually be better to put it back at the article title that was used when the AfD was opened.  — SMcCandlish ☏ ¢ 😼  12:30, 20 February 2019 (UTC)

Agreed. This should be an automatically accepted revert of a unilateral move (actually two of them) made after the article was nominated on AfD. --В²C ☎ 19:54, 20 February 2019 (UTC)

Agree with В²C. Crouch, Swale (talk) 21:39, 20 February 2019 (UTC)

See: Wikipedia_talk:Requested_moves#What_to_do? for extended discussion.--В²C ☎ 21:31, 20 February 2019 (UTC)

Shouldn't this be an automatic immediate revert to the title it was at at the time the ongoing AfD was filed, as requested? It's a bit confusing to have them be disparate right now, I think.

--В²C ☎ 21:05, 20 February 2019 (UTC) added comment from Crouch, Swale --В²C ☎ 23:24, 20 February 2019 (UTC)

I have processed this. It was probably a misunderstanding. Dekimasuよ! 23:30, 20 February 2019 (UTC)

Resolved

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.

RMNAC

I reverted B2C's latest edits to WP:NAC as going completely in the wrong direct. WP:RMNAC is fairly loose guidance, it too much an under-watched page for things there to be called consensus, and the advice currently written at WP:NAC is in fact much better. WP:BADNAC in particular. I think WP:RMNAC needs to be harmonized with WP:NAC, maintaining the higher standard documented at WP:NAC. Who agrees? --SmokeyJoe (talk) 02:57, 21 February 2019 (UTC)

Having WP:RMNAC in a hatnote on WP:NAC seems like an obviously good idea. That page *should* be an "explanatory supplement", but doesn't appear to be, possibly for the reasons you've mentioned. power~enwiki (π, ν) 03:30, 21 February 2019 (UTC)

A hatnote is not sufficient. I think RMNAC needs a major revision to harmonize. As WP:NAC is much older and better, I think WP:RMNAC should stick to administrative instruction, and point to WP:NAC for advice. --SmokeyJoe (talk) 04:01, 21 February 2019 (UTC)

The current guidance that is in effect for RM NAC is WP:RMNAC, not WP:NAC. For example, WP:BADNAC says that non-admin closures are inappropriate when "The result will require action by an administrator". However, RMNAC explicitly says non-admin editors "are permitted to close the discussion and file a technical move with a link to the closed discussion." That RMNAC is followed over NAC in RMs is not nearly as obvious as it could be at WP:NAC, though NAC does at least have [[19]] which references RMNAC. However, it's far down the page and is easily missed. This can be confusing as was made evident here today. My changes don't change anything about the status quo. They just reference the existence of RMNAC at NAC. Whether RMNAC "needs a major revision to harmonize" and whether "WP:RMNAC should stick to administrative instruction, and point to WP:NAC for advice" is an interesting view, but is not how it's currently implemented and is not current consensus. Maybe that's an RFC that needs to be written and considered. In the mean time the two hatnotes I added, one at the top of NAC and one in the WP:BADNAC section, simply add clarity regarding the way things are today. --В²C ☎ 06:58, 21 February 2019 (UTC)

• WP:RMNAC is a bit of a mess. It is a page of unclear standing, no talk page, a weak claim to consensus, and it wanders between the technical and conversation opinions, such as "Some editors do not approve of non-admins closing contentious debates; indeed, elsewhere on Wikipedia, NACs are not recommended, but NACs are not discouraged for requested moves." I think that line, for example should go elsewhere. In contrast, WP:NAC is much better written, but is focused on deletion discussions.

The things that WP:RMNAC is missing are:

WP:BADNAC#1 (INVOLVED)

WP:BADNAC#2 (contentious discussion)

WP:BADNAC#3 (inexperienced)

WP:BADNAC#4 (requires admin actions)

I think WP:RMNAC should point to, and defer to, WP:BADNAC.

#1 is already well respected everywhere

#2 and #3 may be contentious in the RM community, but these things are characteristic of the AfD community which works much better. As a regular of DRV and MRV, I see massively more problems with NAC closes per RM discussion than per AfD discussion.

#4 doesn't seem to be as big an issue, I'm not sure.

--SmokeyJoe (talk) 07:41, 21 February 2019 (UTC)

Massively more problems? Got a few dozen example to back that up? —В²C ☎ 16:34, 21 February 2019 (UTC)

• I've probably written close to half of NAC at this point, so I'm totally biased. But as a general rule, I think we should be working to centralize guidance at NAC rather than having multiple pages covering NACs for each individual area. Much of the content at NAC applies to all NACs and so it adds to rather than runs parallel to guidance on specific types of closures or specific types of XFDs. GMG^talk 17:58, 21 February 2019 (UTC)
  • I agree in general it makes sense to incorporate what RMNAC says into NAC rather than have a separate RMNAC, though I wonder if we can do that without bloating NAC. --В²C ☎ 18:19, 21 February 2019 (UTC)

Anyone else object to restoring the hatnotes?

Does anyone besides SJ have an issue with the hatnotes I added to WP:NAC? Anyone else object to restoring them? --В²C ☎ 17:48, 21 February 2019 (UTC)

The specifically wording you crafted served to say that WP:NAC is irrelevant to RMs. you in particular are the worst NAC-er, and if not banned from RM, should definitely be banned from RM policy pages. —SmokeyJoe (talk) 21:47, 21 February 2019 (UTC)

"Worst" by what standard? Once again, any evidence supporting your claim? --В²C ☎ 22:19, 21 February 2019 (UTC)

By the way, I simply copy/pasted the wording in the previously existing hatnote for deletion discussions, to also use it for RM discussion, as seen in the diff:

• "the actual guideline on non-admin closures of deletion discussions".
• "the actual guideline on non-admin closures of Requested Move discussions".

Do you have an issue with the deletion wording? Or it's okay because I didn't add it? --В²C ☎ 22:24, 21 February 2019 (UTC)

WP:RMCI should be wound back from where it crosses into soft worded guidance. I should be a technical instruction page, not a guideline. A hatnote stating that "the actual guideline" is that instruction page is wrong. WP:NAC should be considered the guideline. It used to be an essay, but I see the taggery has developed to it being an "explanatory supplement" to an "information page". This is terrible. We need a NAC guideline. --SmokeyJoe (talk) 22:31, 21 February 2019 (UTC)

What does that have to do with my question or my edit? --В²C ☎ 22:39, 21 February 2019 (UTC)

Amakuru, sorry to drag you into this, but can you help us resolve this, please? --В²C ☎ 22:26, 21 February 2019 (UTC)

I did give B2C constructive advice. Ask Amakuru for advice, yes. "I am still meaning to seek to get WP:RMNAC harmonized with WP:NAC; I think you have been served poorly by the loose writing of RMNAC." B2C's edit was to neuter WP:NAC with respect to RMs. Completely the wrong direction to what needs doing. --SmokeyJoe (talk) 22:36, 21 February 2019 (UTC)

I don't want to get too deep into this dispute, but I do think that RMNAC sums up the position of the community reasonably well when it comes to RM discussions. For better or for worse, the majority of discussions are not closed by an admin these days, and it has long been recognised that closing discussions, some of them contentious, is a good way to demonstrate competence if you ever do decide to run for the tools. The page mover user right, although intended primarily as a technical ability rather than a community status, does nonetheless confirm the view that it is the norm for nonadmin users to perform nontrivial page moves. We have the fallback mechanism of WP:MRV to clean up obvious bad closes, but again it is well established that the fact that the closer was not an admin is not in itself a reason to reverse a close. Thanks  — Amakuru (talk) 01:11, 22 February 2019 (UTC)

The point in question is not about non admins closing discussions, it is about whether WP:BADNAC applies to RMs. I think that WP:NAC better matches the community position than WP:RMNAC, specifically on WP:BADNAC#2. I point out that WP:NAC has served WP:AfD longer and better. Yes, non admins sometimes close contentious AfDs, and when they do it well we know we have someone good, and when they do not do it well they pull back. In contrast, WP:RM is a troublesome process that annoys the broader community more than it does good, and it has a long history of WP:LAME troubles. Ivory Coast. Yogurt. Star Trek Into Darkness. Sarah Jane Brown. Massive time sinks. In contrast, WP:AfD runs much more smoothly, and on more important matters. RM should be taken more seriously. B2C is the prime example of a troublesome non admin RM closer. When he closes contested discussions, is he saving the community time and effort? I think not, and I don't understand why he would want to push ahead so boldly, and I don't think it is OK for us to let him neuter the applicability of BADNAC to RMs. Hatnote "see also" sure. --SmokeyJoe (talk) 09:40, 22 February 2019 (UTC)

If we're talking about special esoteric rules for their own sake, then BADNAC does not apply to RMs. It's specified only for XfD discussions. If we're talking about common sense and actual practice, much of the guidance currently grouped under XfD at NAC isn't actually XfD specific, and is an artifact of the history of the page. If you look at NAC as it was two years ago when major rewriting/expansion began, it was almost entirely guidance related to XfD, and a few afterthoughts. But clearly, there is guidance currently under XfD that is general guidance. For example, you could not reasonably argue that you could close RfCs and RMs with a supervote, even though the guidance for supervoting is grouped under XfD.

The problem currently is that the rewrite toward making NAC a guideline stalled out after the last major change regarding IPs closing discussions, and the few of us that were working on it just kindof wandered away to work on other things. What actually needs to happen is that the guidance for XfD needs to be filtered between XfD and general guidance. As we do that, I am of the personal opinion that we should be taking disparate guidance, like that on RM, and moving it over to NAC in a structure that makes sense. If we have moderately experienced editors who are interested in learning about NACs, then it is to their benefit if the guidance is all centrally located, and that group is really IMO the target audience. GMG^talk 11:52, 22 February 2019 (UTC)

I agree that the guidance at BADNAC, and indeed much of the rest of the NAC page, does in practice apply to non-admin closures generally and is not unique to deletion discussions. I agree too that it'd be beneficial to disentangle truly XfD-specific material from our broader NAC recommendations. If there's consensus to do so, I'd be willing to assist. ╠╣uw [talk] 18:51, 22 February 2019 (UTC)

Regarding RMNAC, it does seem a bit confusing or unfocused, and the division of what's defined where (and why) isn't quite clear to me. I see that it identifies as being specifically about non-admin closures of requested moves, but strays into things like conflict of interest which are not uniquely non-admin issues, or into information about technical moves. Per GMG, I'd agree that the content in NAC, BADNAC, and RMNAC should probably be restructured in order to present a single set of consistent, coherent guidance on the questions of who should perform closures, and how problems with closures should be handled. ╠╣uw [talk] 17:23, 22 February 2019 (UTC)

Proposal to make TfD more RM-like, as a clearinghouse of template discussions

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Templates for discussion#RfC: Proposal to make TfD more RM-like, as a clearinghouse of template discussions.  — SMcCandlish ☏ ¢ 😼  05:18, 27 February 2019 (UTC)

En-dashes in titles

Per MOS:DASH we are to use en-dashes, not dashes, in titles. Is there community consensus on this? If so, I think it would be good to note this in the closing instructions. Any suggestions on where best to do this? Actually, it should probably be noted at WP:AT as well. Comments? --В²C ☎ 18:49, 27 February 2019 (UTC)

This is a question of style and should not be elevated to policy at WP:AT. - Station1 (talk) 01:31, 28 February 2019 (UTC)

• This is too confusing for AT. Hyphens work well when correct. E.g. State-of-the-Art Car. If a hyphen is not correct, find another way to write it. Dashes are an entirely unnecessary writing style, always redundant to a clear way to write. Sources are inconsistent, and many sources avoid them entirely. Hand–eye coordination is inferior shorthand to Hand-to-eye co-ordination. --SmokeyJoe (talk) 01:41, 28 February 2019 (UTC)

Merge proposal

See Talk:Cricket in England#Requested move 10 March 2019; nom is really looking to merge two articles. Perhaps someone could take a look and take the appropriate action? PC78 (talk) 18:34, 11 March 2019 (UTC)

Relisting

I'm not sure this has been discussed before, but I think too many requests are getting relisted unnecessarily. It seems to me the default from some users is to relist anything after 7 days are up if there are a handful of participants, regardless of things like strength of arguments. For reference, there are now 42 relisted discussions. There were 19 at this time last year [20]. I think some of the guidance at WP:RELIST, which deals with deletion discussions, could be applied here. Or maybe we could encourage users to wait a day or two after the 7-day period to relist. Calidum 04:53, 16 March 2019 (UTC)

• I think relisting should be discouraged unless there is some good reason to relist, such as a need to refocus the discussion, or call attention to an important point raised late in the discussion. {{Relisting}} aka {{RMrelist}} should be made more like {{Relist}}, in having the parameter for the relisting comment. --SmokeyJoe (talk) 05:20, 16 March 2019 (UTC)

When tech requests are challenged

Hypothetical scenario:

• An article has been at title X for a reasonably long time (more than 6 months) and consensus is presumed due to time if not established by a previous RM.
• User U makes technical request to move Article X to Y
• Admin A moves as requested
• User W challenges the move, as another technical request

What should Admin A do?

1. Convert User W's tech request to a Y→X RM request leaving article at Y
2. Move Y back to X and create X→Y RM request
3. Move Y back to X as requested. Leave it to User U to make an RM request.
4. It depends (if so, on what, and how?)
5. ???

--В²C ☎ 21:50, 25 March 2019 (UTC)

• If it is within a reasonable time frame, it should be restored to the stable title and an RM made from the stable title. If it is not within a reasonable time (say a month or more, depending on the page), and RM should be held at the new title, which at this point should be stable. Whether the admin starts an RM or lets the user is a case-by-case thing. TonyBallioni (talk) 21:55, 25 March 2019 (UTC)
  • 2 generally since that's a revertion of an undiscussed move unless the page was previously moved to X against a previous consensus (as Harris was). Crouch, Swale (talk) 21:59, 25 March 2019 (UTC)
    • I should have said consensus was previously established for X. This may have been through an RM, or a move without an RM but a long time (over 6 months). I added the first bullet above accordingly. --В²C ☎ 23:12, 25 March 2019 (UTC)

• Admin A need not be the same admin, but it should only be an admin who considers reverting an admin's move.

1 or 2. Happy to leave it to the discretion of the admin. There are many considerations that might make the difference. How long is a reasonable time? Has the article been edited in the meantime? Do U or W have stronger prima facie cases?

3 could amount to a the implication that User:U's original technical request was, on review, flawed or without merit.

HOWEVER, whether 1 or 2, please ensure that subsequent RM request discloses the recent history, which once is status quo ante? And please do not move pages during the RM discussion, it makes a simple reading of the discussion easily confusing. --SmokeyJoe (talk) 23:52, 25 March 2019 (UTC)

RMNAC is under attack

"Attack" is a really strong term, but it rhymes. "Scrutiny" might be the best word. I want to remind everyone that we have literally years of precedent saying that it is okay for non-administrators to close even the most contentious, difficult-to-parse move requests, barring maybe one or two move requests per year. (Incel was a brutally contentious move request that got closed by RMNAC and which was endorsed at Move Review. Sarah Jane Brown is... probably not getting closed by a non-admin any time soon.)

Please, if you have any disagreements with our ways of doing things at WP:RM, make your case on the talk page. Red Slash 00:09, 25 April 2019 (UTC)

Agreed. Some clarification at WP:NAC would help. I tried, but was reverted. I tried again, but was reverted again. I also believe this switch from "main article" (on RM NACs) at WP:NAC to "See also" is contrary to consensus. As far as I can tell the attack is from the one editor who holds a very particular view on this not supported by anyone else, let alone consensus. --В²C ☎ 00:22, 25 April 2019 (UTC)

• RMNAC has encouraged some nonadmins to think that due to it, they are “authorised” to close any RM. This reading, fair as it may be, often leads to under experienced closer’s closing contentious RMs with supervotes, and certainly with poor, unimpressive explanations. Red Slash has been in that position, and although the close was endorsed at RM, read the actual MRV closing statement.

Years of precedent is that RM is a disreputable process. It did massively improve with the implementation of MRV, but non-admins closing contentious discussions only damages the respect afforded to the process.

In comparison, the XfD processes are afforded much more respect, and they abide by the wording of WP:NAC. Why should RM have a sloppier standard for closing? —SmokeyJoe (talk) 05:32, 25 April 2019 (UTC)

• I think the problem here is not RMNACs, but your RMNAC. We can assume that admins are able and experienced at appropriately judging consensus and arguments- the community came to a consensus that they were. We can't assume that of non-admins, so it's more important that we can see non-admin closers did, in fact, apply appropriate reasoning in their closures in each individual case. Your close which is now at MRV, which is I assume the reason you're raising this here, did not include any reasoning. When multiple editors complained about your close on your talk page, you brushed them off, still without any reasoning, saying you wouldn't discuss it and wouldn't revert it. That behaviour is problematic and specific to you in this case, not generalized to all NACs. Safrolic (talk) 06:17, 25 April 2019 (UTC)
  • I'd disagree with that. I've had four move closures taken to MRV over the past few years. Three have been upheld and it's looking like the fourth will be as well. The problem doesn't lie with me - it lies with taking a closer to MRV with no justification just because of sour grapes about the proposal failing. The last few closures that got sent to MRV, I got in trouble when I summarized sources, I got in trouble when I referenced policy (it apparently looked like a supervote), and now I have gotten in trouble for not referencing policy. It just looks like people can't stand "losing" and want to try anything possible to overturn it. Red Slash 16:51, 30 April 2019 (UTC)
• IMO non-admins are allowed to close even controversial requests as long as they have the understanding and are impartial. Likewise admins who don't have the understanding or are not impartial shouldn't close such requests. Crouch, Swale (talk) 07:21, 25 April 2019 (UTC)
  • I agree. I don't think the pool of admins produces higher quality closes than does the pool of interested non-admins, including for highly contested RMs. For example, I'm pretty sure it was lame closes mostly if not exclusively by admins that unnecessarily prolonged the Yoghurt/Yogurt fiasco for almost a decade because they repeatedly determined consensus of the discussions without weighting !votes based on policy arguments... --В²C ☎ 16:14, 25 April 2019 (UTC)
  • Bingo. Red Slash 16:51, 30 April 2019 (UTC)

Should noms of RMs be required to support their proposals?

It doesn't happen too often, but once in a while you see a "procedural RM" (whether it's explicitly characterized as such or not) in which someone who does not favor a particular move nevertheless starts an RM for it. Here is a current example:

• Talk:Chairman#Requested_move_17_April_2019

Probably the most common scenario is when an admin converts a technical request into a formal RM.

My problem with these is that a person who does not favor a particular move is probably not the best person to put forth a strong argument in the proposal for that move. Then the RM is more likely to fail, and once it does, proposing a new RM is frowned upon "so soon" after one failed. So it can be a form of disruption (whether intentionally or not).

I note that RMs are not RFCs. RFCs are supposed to be presented in a neutral manner. RMs are proposals for specific actions based on presumably good reasons that should be presented in the proposal. Someone not in favor of the proposal is not going to be a good advocate for it.

Three related questions:

1. Should noms of RMs be required to support the proposal they are proposing?
2. If an admin feels a technical request should be a formal RM, should they notify the requester accordingly to give them the opportunity to make a good case, rather than creating the formal RM with a "bland" supporting argument?
3. Should the creation of an RM by someone who does not favor their own proposal be sufficient grounds to immediately speedy close and hat the RM so that it's not counted as a "recent RM"?

--В²C ☎ 17:41, 18 April 2019 (UTC)

• Re #2: Yes. I've long felt that when a technical request is contested, the requestor should be notified and given the opportunity to either open an RM themselves or simply withdraw the request. When I occasionally make technical requests I truly assume they are minor and uncontroversial and don't bother to make a case for the obvious; if they were contested I'd often just drop them as not worth discussion. And when I contested a request recently, with a ping to the requester, it was quickly moved to a RM before he had a chance to respond. Luckily, the requester and I both caught it and easily came to satisfactory conclusion; if anyone else had jumped in, it would have been problematic to simply close that RM. Station1 (talk) 18:25, 18 April 2019 (UTC)

• I strongly support this, Born2cycle. I'd include it if I were you. Red Slash 00:09, 25 April 2019 (UTC)
• Oppose - Here is another case study: Talk:Veracity of statements by Donald Trump#Requested move 22 April 2019. That was a procedural start in which the starter (me) had not yet decided on a position at the time he started it. I can't see how that RM has suffered as a result. Even if I had taken a position in the opener, it would not have been treated any different than a separate !vote. If anything I'd support making RMs like RfCs in that the starter's argument is a separate !vote like all the others. I see little need for the difference in handling, and it's an unnecessary complication and increase in the learning curve. ―Mandruss ☎ 00:39, 25 April 2019 (UTC)
  • But, Mandruss, why start an RM in such a case? Why not just revert the unilateral controversial move (or file a tech request revert at Wikipedia:Requested_moves#Requests_to_revert_undiscussed_moves), and notify the editor that they need to use RM? Then let them file one, with their argument for the move in the proposal, if they have one. Now, in this case you turned out to favor the move, and your !vote immediately follows the nom, so it's practically identical to a non-neutral RM. Unless you have a good reason to move, good enough to be able to state it in the proposal, I suggest the RM proposal is inherently a violation of WP:TITLECHANGES. --В²C ☎ 16:57, 25 April 2019 (UTC)
    • @Born2cycle: It seemed to me less battleground-y to not just block the improper behavior, but to take it a constructive step further and save the improper behaver the trouble of doing it the right way. I felt that approach reduced the likelihood of igniting a move war and the accompanying drama. My knowledge of the improper behaver's style and personality was a factor—I was fairly certain they would not respond positively to being "[notified] that they need to use RM". One must tread carefully in the AP2 minefield, and it helps to know the main players. While I ended up Supporting, I could have easily gone the other way, and I didn't expect to !vote so early. ―Mandruss ☎ 17:25, 25 April 2019 (UTC)
      • Okay, that makes sense. I guess there is room for exceptions, as always. But, in general, if I ever moved something thinking it was uncontroversial, and someone reverted accordingly, I would much rather they let me create an RM stating the good reason I believe there is to move, rather than they post a neutral one that doesn't advocate for the move effectively, if at all. --В²C ☎ 17:36, 25 April 2019 (UTC)
        • @Born2cycle: Yeah, that's the part of this I don't get. It seems to me every editor who !votes Support is an equal advocate of the move. What's so special about the one who starts the RM? As I indicated, I don't see an essential difference between RMs and RfCs. RMs generally run far less time than RfCs (I'm not sure how that makes sense, but there it is)—and using the separate process allows editors who are only interested in title changes to easily ignore everything else (although that could be accomplished with a "Title changes" RfC category)—but basically they are both proposals or questions seeking wider-than-normal participation. ―Mandruss ☎ 17:54, 25 April 2019 (UTC)
          • It's for efficiency, Mandruss. A dozen or more RMs are filed every day. Nobody has the time to keep up with all of them. The less time each one takes, the more you can process. There is a tradeoff. It's obvious that many people read the nom, then participate. They don't read all the other input, so it doesn't count the same. Now, they might not even read the nom, but I presume most people at least do read the nom. So ideally you have strong argument in the nom, then everyone can just read that and decide whether they agree with the reasoning or not, and vote accordingly. It really helps when the nom includes easily verifiable links to page views or whatever supporting their argument that there is good reason for the proposed move. Otherwise, ever participant has to start from scratch. In other words, I think !voting in an RM should be determining whether you agree with the proposal or not. That's much easier and faster to do if reasoning is providing in the proposal. In fact, I've opposed RMs many times simply because there was no argument submitted for the proposed move, per WP:TITLECHANGES (no good reason to move) --В²C ☎ 18:15, 25 April 2019 (UTC)
            • @Born2cycle: 1. There is nothing to prevent us from saying somewhere that title-change RfCs generally run for about 7 days. The 30 day thing is actually just widespread misinterpretation of the bot de-listing time; nowhere does it say that RfCs should generally run for 30 days. 2. Anybody who takes a position after reading only one side of the arguments is a fool. I often lean one way after reading Support arguments, then change my mind after reading Oppose arguments (or vice versa). That's simply the nature of the human mind. While we can't outlaw foolishness, we certainly shouldn't be assuming it and facilitating it in our design/guidance decisions. ―Mandruss ☎ 18:29, 25 April 2019 (UTC)
              • I'm just saying the RM nom should seed the discussion. Otherwise the first one to show up sees A → B and what? "What's wrong with leaving it at A? Why move to B? No reason given to move, Oppose". Yes, an RM is basically an RFC but only if it is presented with an argument. An RFC is literally a request for comments about something that is explicated in the nom. A neutral RM does not explicate anything; one with a good argument supporting the proposed move does. I think of an RM as being a specialized RFC, one that is requesting comments about a specific argument to move an article. Without providing an argument for the move, it's asking people to comment on essentially nothing, I think. Or, it's asking people to do work that only one person, the nom, should have already done. --В²C ☎ 18:52, 25 April 2019 (UTC)
• I don't think neutrality is a problem, but if someone has a position against the move they're proposing, it's entirely reasonable to think their rationale, if given, may be weak. It could even be used to WP:GAME the system, via an editor who favours a current, inappropriate name which is under debate deliberately creating a RM rationale which doesn't adhere to P&G to bias it toward being rejected, then using that rejection to bias editors watching the page against supporting another RM in the near future. So, only when proposer is actually against their proposal should it be sufficient grounds to close&hat it. Safrolic (talk) 01:10, 25 April 2019 (UTC)
• No for 1, per the discussion at Talk:Bend however (3) those that are clearly frivolous can be speedily closed, those wanting the move can support it but I'd be more lax with the expectation of waiting of Wikipedia:Renominating for deletion#Requested moves especially if someone soon after who favours the move presents a strong case for the move but users who support the move should present their arguments at the current RM (even if the proposer doesn't support it).
• For 2, the RM shows up as a "contested technical request" and the person who contested it/started the discussion can explain why. Contesters often ping noms when they have started the full RM discussion but sometimes also on RMT, its probably preferable to ping them at RMT rather than starting a full RM but for those clearly controversial this is less of an issue. Crouch, Swale (talk) 07:31, 25 April 2019 (UTC)
• No. WP:TIMEWASTE In ictu oculi (talk) 08:09, 1 May 2019 (UTC)
• No. I use procedural nominations occasionally (rarely) at AfD. It's a useful tool for some situations. I think I've done so once or twice at RM also; at any rate, it's certainly a reasonable thing to do in certain circumstances, to clear up an uncertain or contentious situation. You don't have to have a strong opinion on the merits of the case to do that. Herostratus (talk) 13:05, 1 May 2019 (UTC)

Just one editor

Hey all,

Proposing to add something like "Move requests should be closed by just one editor. While high-profile cases may make people want a pre-selected administrator (or three-person team of administrators) to close, in practice that leads to either potentially pre-biased decisions (even moreso if only one administrator is selected) or extremely delayed decisions by people who have to coordinate with one another (in the case of a team). High-profile moves like Hillary Rodham Clinton to Hillary Clinton should be treated the same way we treat any other move: closed by an uninvolved editor with experience in requested moves after a period of at least one week." This is because every single time I've seen a triumvirate or a solicited administrator in action, they've taken forever to decide (and often their decision has nothing to do with how any other RM would be solved).

Whatchall think? Red Slash 23:17, 8 May 2019 (UTC)

• I can support disallowing pre-selection of closing editors, but I can't support mandating all RM discussions to be closed by a single editor. As long as there is an odd number of editors involved in a closure, I don't see any likelihood of disputes. I'd argue that when closures are performed by a team of editors (admins or not), they should avoid coordinating the decision with one another. We can learn a thing or two from how an appellate court works: Each of the closers should act as judges and provide their own verdict, or agree with the closing statement provided by another closer. Whichever verdict gets a majority should be the result enacted. So if 2 admins say there is consensus to move but 1 says no consensus, the page gets moved. feminist (talk) 07:39, 9 May 2019 (UTC)

Re-listed ?

Could someone advise if this was a proper action by a non-admin in a controversial move discussion? SandyGeorgia (Talk) 11:25, 9 May 2019 (UTC)

I don't see anything wrong with this relisting action per se. The fact that a discussion was relisted does not affect when it can be closed. There is no need to wait 7 days after relisting to close a discussion. feminist (talk) 16:05, 9 May 2019 (UTC)

Jamie Rhys Clarke name change on Wikipedia

Hi the Snooker player in question has said his name is Jamie Clarke and not Jamie Rhys Clarke. He said he never used the name Rhys and that it should never have been used. World Snooker and other sources list him as Jamie Clarke so should Wikipedia. I would like his homepage to be changed to Jamie Clarke (snooker player). Is this possible please ?. 178.167.230.220 (talk) 20:53, 10 May 2019 (UTC)

WP:RM/TR is the place to request uncontroversial moves, otherwise you can follow the instructions at WP:RM#CM. I'll move this one as I don't see this as a controversial request. nevermind, this move's been made and reverted before, it needs a full discussion. Iffy★Chat -- 21:00, 10 May 2019 (UTC)

Kaschkasch

Hello,

would it be possible to request the move from Draft:kaschkasch to the main wikipedia on here?

Best and thank you, Laura — Preceding unsigned comment added by LauKri (talk • contribs) 14:29, 14 May 2019 (UTC)

Moves from Draft to Main are not handled here, I have submitted the draft for review on your behalf though. Iffy★Chat -- 14:33, 14 May 2019 (UTC)

Thank you so much!

April 2019 changes

@Red Slash and SlimVirgin: - please discuss here the recent changes made and the revert of those changes. SlimVirgin said in their edit summary discussion was needed. -- Netoholic @ 20:39, 13 May 2019 (UTC)

on balance I probably agree with SlimVirgin, that reword doesn't reflect longstanding community consensus. It's certainly not true to say that non-admins have as much standing as admins in closing discussions,as a general rule. Some editors with a long and respected track record do effectively have "admin" powers in the RM sphere but others, and I would include some page movers in this, should only be tackling the more obvious closes. Although everything is treated case hy case, the current advice seems balanced and sensible.  — Amakuru (talk) 21:15, 13 May 2019 (UTC)

Amakuru, I'm not sure what you agree with SlimVirgin about since she simply reverted and said it needs discussion. I agree with that too, and I hope she weighs in accordingly, otherwise we just have a case of Wikipedia:Status_quo_stonewalling#Reverting_with_"discuss_first"_without_discussing. Anyway, there are two kinds of "longstanding consensus" to consider about this: one is the consensus that has developed by a few involved in editing this obscure guideline. The other is based on recognizing what actually happens and is generally accepted by the entire community involved with RMs. Based on the latter reading of consensus, I think the edits that were reverted are spot on, and should be restored. The fact is that experienced non-admin closers close controversial "close call" hotly-contested RMs all the time, and there is no consensus opposition to this. It's time this guideline better reflected actual consensus. --В²C ☎ 20:23, 14 May 2019 (UTC)

@Born2cycle: thanks for the reply. In a way you're right, but the key phrase there is "experienced non-admin closers". That's fine, I don't think anyone objects to that, and actually in the few months before I became an admin I was probably closing over half the RMs listed, contentious or otherwise. The problem with the change as written is that it appears to invite any Tom, Dick or Harry to perform the contentious closes, whether they're experienced or not. That is not the right way to go IMHO. Cheers  — Amakuru (talk) 21:21, 14 May 2019 (UTC)

Agreed! So with that small adjustment, you're good with the changes? --В²C ☎ 21:25, 14 May 2019 (UTC)

• Good revert. One little thing in particular is closed an RM as “MOVED” is particularly unhelpful. Moved is the result, not a close, not a summary of a discussion. The other thing is that RMNAC is poorly written and in parts poor advice, and WP:NAC offers good, better, advice. The few people who insist on following the letter of RMNAC where it conflicts with NAC are not helping when doing so, resolution costs to the ensuing regular disagreements being the proof. —SmokeyJoe (talk) 01:34, 15 May 2019 (UTC)
• The edit I reverted made several significant changes without discussion, including: "Longstanding advice for non-admins closing deletion discussions is documented at WP:Non-admin closure. The principles of the advice apply equally to closing controversial RM discussion, and in particular: The outcome is a close call (especially where there are several valid outcomes) or likely to be controversial. Such closes are better left to an administrator." SarahSV ^(talk) 03:36, 15 May 2019 (UTC)

Can an article title be changed without discussion?

Can an article title be changed without discussion?

That is what was done here. X1\ (talk) 21:32, 16 May 2019 (UTC)

Yes if its not reasonably likely to be controversial but per WP:BRD you generally need to start a discussion if the move is challenged, the Brexit topic is likely to be controversial so I would start a formal RM for that. Crouch, Swale (talk) 21:35, 16 May 2019 (UTC)

My 2¢: the bold move should be reverted and an RM started if an editor thinks it should be moved. Leviv ich 21:36, 16 May 2019 (UTC)

Can uncontroversial move requests be closed before 7 days have elapsed?

Let's say an editor proposed to move an article via RM. The article title has not been the subject of controversy in the past. The RM nominator has provided a persuasive statement with policy-based arguments on why the proposed new title is more suitable. The discussion is unanimously supported by other editors who agree with the rationale for a move. Can such a discussion be closed early on the grounds that the move is not controversial? feminist (talk) 07:43, 9 May 2019 (UTC)

• Yes I'd also say RMs that are clearly policy based such as removing unnecessary disambiguation, which usually fall under housekeeping can be moved early even by those who might otherwise be considered involved. That said if there is a reasonably possibility that it might be controversial its fine to wait 7 days. Crouch, Swale (talk) 07:47, 9 May 2019 (UTC)
• No. If it's in the regular RM queue it's presumed to be "potentially controversial" (otherwise it could be in the Technical Requests section) and should wait the full 7 days. Often I, for one, don't pay attention except to the Elapsed/Backlog areas. --В²C ☎ 21:11, 14 May 2019 (UTC)
• I'd say yes it can be closed early, per WP:NOTBUREAU and WP:SNOW. Calidum 03:37, 15 May 2019 (UTC)
• Of course. If a consensus can be read that the proposed move is not controversial, it has been agreed, and no one has said anything in opposition, then certainly treat it as if it was a Technical Request or bold Move (which assumes readily reverted for any good argument). --SmokeyJoe (talk) 03:43, 15 May 2019 (UTC)
• Seven days is a good minimum to give everybody a fair chance to participate, bearing in mind that many editors are not here every day. What move is so urgent that it can't wait seven (7!) days? A real consensus will still exist after a few more days, and that avoids the risk of "Hurry-and-close-before-the-consensus-evaporates!". ―Mandruss ☎ 03:49, 15 May 2019 (UTC)

• A need for a quick re-title sometimes happens, but agree that it should be the exception. --SmokeyJoe (talk) 04:14, 15 May 2019 (UTC)

• 7 days with a SNOW exception is what I've always closed RMs under. If the RM is just a day old, it's too early but if it's midway through and the opinion is almost unanimous towards either side, close it and get on with it. --qedk (t 桜 c) 14:29, 18 May 2019 (UTC)