Wikipedia talk:Requested moves/Archive 29

This is an archive of past discussions on Wikipedia:Requested moves. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 25

←

Archive 27

Archive 28

Archive 29

Archive 30

Archive 31

→

Archive 35

I've added an edit request to allow these 3 templates to be automatically substituted to User talk:AnomieBOT/TemplateSubster force. I've been asked to gain consensus before any changes are added. So, would it be a good idea in the long run to automatically substitute these 3 templates? Anarchyte (work | talk) 07:50, 6 June 2016 (UTC)

The instructions to substitute were just recently boldly added. Why do you want to do that? wbm1058 (talk) 10:38, 6 June 2016 (UTC)

It's one thing to just limit usage to "SNOW"-type closes, it's another thing to allow usage for a growing percentage, and most any close. I think tracking transclusions of this (via "what links here") should be useful for identifying potential nominees for adminship. We were more liberal here, as moving a page doesn't always require tools, while deleting a page does. Noting that there is a speedy/proposed deletion record, I believe created by WP:Twinkle, which I don't use, and my lack of use of that tool caused some to be hesitant in supporting my RFA. wbm1058 (talk) 10:52, 6 June 2016 (UTC)

What's the usual practice? If someone wants to move a dab page on the baseline should the template go on the dab page, or go on the article that the editor wants to replace the dab page? In ictu oculi (talk) 16:34, 7 April 2016 (UTC)

You mean the multi-RM template and discussion? Like at other multi-RMs, it could go on either, and the other gets a notification. However, the real problem is that either way this makes primarytopic grabs too easy, since there is not conventionally any notification to the talk pages of all the other affected articles, the ones listed on the disambig page that are going to be harder to get to when someone grabs the title as primarytopic. Dicklyon (talk) 16:44, 7 April 2016 (UTC)

This would probably be a bit of work, but I wonder if it would be possible to allow extra parameters in the move request template, allowing all relevant dab page entries to be notified of the move, without their being actually considered for move themselves?

The RM bot could then go and place a note on any talk page listed under affected1 etc, so those editors could be involved in the discussion. In some cases it might turn out one of the other topics is actually the PTOPIC, not even the one that the nominator suggested. Wbm1058 et al, do you think this could work? Thanks  — Amakuru (talk) 12:47, 12 April 2016 (UTC)

An interesting proposal. I've got other related suggestions on my list, regarding improved notifications of related pages. I'll think on it. wbm1058 (talk) 12:52, 12 April 2016 (UTC)

Cool, thanks. It probably isn't the highest priority item, and I've no doubt you're busy enough, but something to consider anyway!  — Amakuru (talk) 12:59, 12 April 2016 (UTC)

Agreed this would be helpful. We also need the {{rmassist}} template for non-controversial moves to be able to accept multiple items like the regular {{rm}} template. It's a rather silly pain the backside to have to list them with separate templates where there are a bunch. It doesn't come up often (usually when some RfC makes a non-trivial MoS change, as happened at MOS:JR a few months ago), but often enough that the lack of functionality is a hassle. It also generates too much output when substituted, and could surely be made much leaner.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:20, 8 May 2016 (UTC)

The idea of the extra parameters is interesting, but I suspect that almost no one would use it, and it would add to the burden of readers trying to understand how to format an RM request. However, I'll take this opportunity to reiterate a previous suggestion that I had. It is a common and unfortunate practice for people to submit an RM for moving "[[Foo (my favorite recent pop song)]]" to "[[Foo]]", where "[[Foo]]" is some existing dab page. Most people submitting such RMs don't seem to notice (or care) that their destination name is already occupied, and the bot doesn't automatically notify the talk page of the affected destination page. When I point out that the RM is a malformed multi-page move request, their reaction (if any) is often to say that moving the dab page out of the way is an implied minor detail that they didn't think they needed to bother to mention. I suggest that whenever someone proposes a move to an article name that already exists, the bot should notify the talk page of that article name that it may be affected by the move. (Or at least it should do this when the suggested destination name is a dab page.) —BarrelProof (talk) 14:24, 22 June 2016 (UTC)

@BarrelProof: If I'm understanding you correctly, the bot already does do that. If a talk page exists for the target then the bot will leave a note there. At least I assume it still does Wbm1058? Jenks24 (talk) 15:37, 22 June 2016 (UTC)

That doesn't seem to be the case. Talk:Stenbock has an example of just such an incident that is only a few days old. —BarrelProof (talk) 16:30, 22 June 2016 (UTC)

I believe this is covered by a longstanding request: User talk:RMCD bot § Requests for additional automated notices. The bot notifies affected talk pages of specified multi-moves, but not single move requests which effectively are implied multi-moves. I guess it's time I got to work on this. We can't fix this by changing editor behavior, I suppose. wbm1058 (talk) 16:38, 22 June 2016 (UTC)

It would be great to see action on that. (Other such incidents can be found recorded at Talk:Smite (video game), Talk:Binomial (polynomial), Talk:Jimmy Morales, Talk:Kim Davis (county clerk), Talk:Maxim's, Talk:Une vie (disambiguation), Talk:Blood Wedding, Talk:Segal (musician), Talk:Bubblin' (Blue song), Talk:Max George (footballer), Talk:Ben Foster, Talk:Stephen K. Benjamin, Talk:The Year of Living Dangerously (film), Talk:Wonderland Amusement Park (Beijing), Talk:You Make Me, and Talk:What I Did for Love (David Guetta song).) —BarrelProof (talk) 17:10, 22 June 2016 (UTC)

OK, the new version of the bot now checks the talk pages of each proposed move target. For "?" requests (name to be decided), moves over the current page, when the target has no talk page, or when the target's talk page is a redirect, it does nothing. When the target's talk page has non-redirecting content, the bot now posts a notice. The initial run posted new notices to these 11 pages:

1. Talk:English Football League ‎ (Notifying of move discussion on Talk:The Football League)
2. Talk:Hanamkonda ‎ (Notifying of move discussion on Talk:Hanamakonda)
3. Talk:Civil parish ‎ (Notifying of move discussion on Talk:Civil parishes in England)
4. Talk:Anti-French sentiment ‎ (Notifying of move discussion on Talk:Albanophobia)
5. Talk:Anti-Hungarian sentiment ‎ (Notifying of move discussion on Talk:Albanophobia)
6. Talk:Biohacking ‎ (Notifying of move discussion on Talk:Do-it-yourself biology)
7. Talk:Yuliya Stepanova ‎ (Notifying of move discussion on Talk:Yuliya Rusanova)
8. Talk:British Journal of Politics and International Relations ‎ (Notifying of move discussion on Talk:The British Journal of Politics and International Relations)
9. Talk:Run the World ‎ (Notifying of move discussion on Talk:Run the World (Girls)) – this is a particularly interesting one, as that page has another move discussion of its own
10. Talk:Stranger to Stranger ‎ (Notifying of move discussion on Talk:Stranger to Stranger (Paul Simon album))
11. Talk:Where the Light Gets In ‎ (Notifying of move discussion on Talk:Where the Light Gets In (album))

That should cover most of it. Let me know if there are still pages I'm missing that should have cross-post notices, but don't. – wbm1058 (talk) 02:10, 23 June 2016 (UTC)

Thanks so much. —BarrelProof (talk) 05:20, 23 June 2016 (UTC)

Yes, thanks - a really useful improvement. PamD 07:40, 23 June 2016 (UTC)

Thanks for the barnstar, BP! I have just installed one further enhancement. When the target's talk page is a redirect to a different page other than the page which has been requested to be moved, the bot follows that redirect, and if that target's talk page has non-redirecting content, the bot posts a notice there too. This initial run with this enhancement posted notes on four more pages:

1. Talk:The King's University (Texas) ‎ (Notifying of move discussion on Talk:The King's University (Edmonton))
2. Talk:Bravo (New Zealand TV channel) ‎ (Notifying of move discussion on Talk:Four (New Zealand))
3. Talk:United Kingdom European Union membership referendum, 2016 ‎ (Notifying of move discussion on Talk:United Kingdom withdrawal from the European Union)
4. Talk:Sunni Cultural Center, Karanthur ‎ (Notifying of move discussion on Talk:Markaz (disambiguation))

I leveraged some of the work I did earlier to notify relevant WikiProjects... the logic for this is similar, which made it relatively easy to implement. – wbm1058 (talk) 12:57, 24 June 2016 (UTC)

The Wikipedia:Articles for deletion instructions include:

The RM instructions currently only suggest notifying WikiProjects:

Should we add instructions to notify significant contributors? I bring this up because:

1. Castncoot, the top contributor to New York (state), recently complained at Talk:New York (state) that they were not notified of the request to move New York
2. The new Page history report makes it easy to identify substantial contributors

— wbm1058 (talk) 12:16, 22 June 2016 (UTC)

I don't think this is a good idea – it just adds to the bureaucracy (especially if it's an article with a long history). If editors are really interested in picking up things like this, they can have articles on their watchlist or watch one of the article alert feeds for that topic area (e.g. this). Number 57 12:36, 22 June 2016 (UTC)

• Could the concern be dealt with by simply amending the last sentence quoted above to: "Requestors should feel free to notify any other 'editor, Wikiproject or Noticeboard that might be interested in the move request." Blueboar (talk) 12:46, 22 June 2016 (UTC)

(edit conflict):This actually bit me in the bum recently, with Rwandan genocide, I happened to be somewhat off-wiki the week the move took place, and was surprised to see it suddenly moved. I am not the top contributor there, I'm number 5 on the list, but probably the most active in recent years. I think I'm inclined to agree with Number 57 though, this is likely to create a lot of extra burden on people who open RMs, unless it's automated (and then you have questions like how far down the list does the bot go in determining who to ping). By and large I would expect that if someone is very active on an article, they have it on their watchlist and the move request should be spottable there. Nobody WP:OWNs any particular article, after all. Thanks  — Amakuru (talk) 12:52, 22 June 2016 (UTC)

I think it's a good idea to notify recent top contributors only, just as a courtesy (though I suggest that this not be required, as Number 57 says: this adds more to the never-ending Wiki-bureaucracy). If they're working on an article for a long time, they don't want the page to suddenly be moved under them. Sometimes, people (like me) may not watchlist articles that they are working on. Kylo, Rey, & Finn Consortium (talk) 13:32, 22 June 2016 (UTC)

I would oppose any specific invocation that requires RM nominators to notify any specific class of editors (article top contributors in this case). By doing so, the RM nominator may indeed be inadvertently canvassing. The top contributors, whoever they might be, might have an agenda that either favors or disfavors the current title while lessor contributors might have the opposite agenda. Notifying Wikiprojects is usually sufficient to generate enough of a balanced look at the RM from a substantive and policy perspective. --Mike Cline (talk) 13:55, 22 June 2016 (UTC)

I would support the recommendation, or perhaps an unenforced requirement. Some articles are largely only written by one editor; including many I've edited. If someone were to move them I might often not see the discussion. Watchlists aren't as good as pinging; sometimes people get busy and the unread there will really stack up, and sometimes even checking back won't be thorough enough that things will slip by. I don't believe canvassing would be an issue here. ɱ (talk) · vbm · coi) 14:46, 22 June 2016 (UTC)

I support informing top contributors of an intention to move an article, simply out of common courtesy and fairness. The argument above of "might have an agenda that either favors or disfavors the current title" holds no more water than WP:CRYSTALBALL. On the other hand, people who have indeed put a lot of time and energy into an article really should be notified about intentions to move an article, as they deserve to be able simply to air their viewpoints as to why they would support moving or not moving an article. I don't support making this a rule per se, but more of a strongly advised guideline. Castncoot (talk) 14:52, 22 June 2016 (UTC)

• Likely to cause more trouble than it's worth. Too hard to define exactly who is a "top contributor" – creator, most edits, most bytes added? And then even if you pick one of those, is it just the top person, top 3, top 5, top 10? Added to all this new contributors often struggle with starting a new RM anyway. Jenks24 (talk) 15:41, 22 June 2016 (UTC)
• I've got to say, I appreciate the idea, but this would definitely just create more work with too little gain to make it worthwhile.--Cúchullain ^t/c 20:06, 22 June 2016 (UTC)

This is why, as I stated above, you leave it open-ended, encouraging it in concept and treating it on a case-by-case basis as a guideline and not as a rule. Best, Castncoot (talk) 20:11, 22 June 2016 (UTC)

• I support RM proposals having a notice placed on the article for the duration of the RM. I believe that a contentious rename of an article is important enough for an article tag to notify all interested potential editors, including editors who do not normally pay attention to talk page edits on their watchlists. --SmokeyJoe (talk) 03:50, 23 June 2016 (UTC)
  • That's good idea, it might even be able to be done by bot. Wbm1058, did we talk about this somewhere before? Jenks24 (talk) 11:32, 23 June 2016 (UTC)

    Indeed we did. See User talk:RMCD bot/Archive 1 § Considering adding bot-maintained article-space notices. – wbm1058 (talk) 12:06, 23 June 2016 (UTC)

• I'd also support being a notice on the article itself, similar to how AFD does it. I'm leaning towards opposing the idea notifying contributors, partially because the definition of "significant contributors" is too subjective and could lead to problems. But I do believe requested moves, especially contentious ones like the recent New York discussion, should be brought to the attention of more people. Calidum ¤ 03:16, 25 June 2016 (UTC)

Sorry, I edit more in the German Wikipedia. And such things there are really simple. It seems to be really complicated. Can anybody fix the problem to move it: Compare: https://en.wikipedia.org/w/index.php?title=Wikipedia%3ARequested_moves%2FCurrent_discussions&type=revision&diff=726942389&oldid=726942115 --Soenke Rahn (talk) 13:36, 25 June 2016 (UTC)

@Soenke Rahn:  Done. Jenks24 (talk) 13:49, 25 June 2016 (UTC)

Thank you very much. --Soenke Rahn (talk) 14:05, 25 June 2016 (UTC)

Recently User:Ricky81682 boldly moved a heap of Wikipedia:WikiProject Outlines subpages to DraftSpace. He was asked to stop, he then initiated a formal RM, which failed, for reasons as explained there. He now declines to assist with moving the pages back (User_talk:Ricky81682#Please_revert_all_bold_moves_from_subpages_of_WP:Wikiproject_outlines_to_Draft_space.) Could someone please help me find and revert these moves? --SmokeyJoe (talk) 13:38, 27 June 2016 (UTC)

Here are the moves. As notes, there's no consensus to revert these moves either as there's been opposition to that and support for similar moves. -- Ricky81682 (talk) 19:48, 27 June 2016 (UTC)

Why does Wikipedia:Requested moves/Technical requests say to use "old page name, without brackets" and "requested name, without brackets" in RMassist? It took me a few moments to realise it's presumably saying not to make the names into wikilinks - "brackets" could also be read as referring to disambiguation parentheses. The actual request edit page just asks for "current page name | new page name" in the edit notice. --McGeddon (talk) 12:45, 3 July 2016 (UTC)

Good point, I see from the bracket article that there are four types of brackets:

• square bracket
• round bracket (parentheses)
• curly bracket, and
• angle bracket

Template:Requested move checks for these characters and writes an error message when it finds them:

• Invalid character "character" found in the "parameter" parameter – A pagename cannot contain any of the following characters: # < > [ ] { }

The round bracket is the only type of bracket that is valid in a page name. This edit check is done in the Lua Module:Requested move local function validateTitle. RMassist could be enhanced to make the same validity check.

Shout out to Andy M. Wang – thanks for creating Template:Editnotices/Page/Wikipedia:Requested moves/Technical requests – super idea that I should have thought of a long time ago. – wbm1058 (talk) 14:26, 3 July 2016 (UTC)

Thanks. Good idea, the validation would reside in {{RMassist/core}} if added. I might get to this at some other point, on a whim or something. (In the time I've been aware of this procedure, these requests coming in haven't really had big problems) — Andy W. (talk · ctb) 15:42, 3 July 2016 (UTC)

The following was a bad move.

(Move log); 08:44 . . CFCF (talk | contribs) moved page Wikipedia:Proposed draftspace deletion to User:Ricky81682/Proposed draftspace deletion ‎(Not Wikipedia-space ready)

It is a serious project proposal. Promoted or failed, it belongs in project space. I want to revert the move, but cannot because the page mover made a null edit to the redirect. Can someone please revert the move. --SmokeyJoe (talk) 12:03, 16 July 2016 (UTC)

The proposal was SNOWBALL-closed at the village pump. It is safe to say that this just isn't ready for Wikipedia-space. Carl Fredrik 💌 📧 12:06, 16 July 2016 (UTC)

{{Failed proposal}}s, of which there are many (Category:Wikipedia failed proposals), are not userfied. --SmokeyJoe (talk) 12:09, 16 July 2016 (UTC)

CFCF, just so you're aware, users have been blocked before for making null edits to prevent a revert. Usually I would revert this per SmokeyJoe's request, but considering this is Ricky81682's proposal I'd prefer to hear from him first – he may prefer it in userspace. Jenks24 (talk) 13:47, 18 July 2016 (UTC)

• I'm not sure why it was userified. There were two village pumps discussions in support of the general idea and this one in opposition of it as policy (after I think at least three separate WT:CSD discussions proposing a similar kind of idea). Generally userification is done if there is no support for a proposal and it's treated as a single lone editor's ideas. While this has been opposed, it's not like there's zero support for this as a policy. I also find it kind of rude for various non-admins to be voting, closing these calling me being WP:POINTY, and then moving the page around just because a proposal failed. It's been supported by multiple individuals so I don't see why userification is necessary but would people at least give me the courtesy of a RM and a chance to argue this? -- Ricky81682 (talk) 04:11, 19 July 2016 (UTC)

• Agree, discourteous. Also note that it is only the "Adopt as policy as is" section that has been closed. Also note, there is broad agreement that something needs to be worked out. Even the minority that argues old drafts should stay forever does not argue that patently hopeless drafts should stay forever. So, this is a continuing matter. --SmokeyJoe (talk) 04:26, 19 July 2016 (UTC)

• I've reverted the move. Jenks24 (talk) 06:27, 19 July 2016 (UTC)

I asked on the project page to undo the move of WP:TFM and the related template.

In general, when a template relates to a WikiProject, it is not a good idea to post it as a technical request without informing the WikiProject. Debresser (talk) 22:39, 8 August 2016 (UTC)

Template:RMnac has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Pppery (talk) 19:18, 9 August 2016 (UTC)

Of course not, the backlog is hidden by the pointless relisting habit.

So, WP:RM says: "Relisting a discussion moves the request out of the backlog up to the current day in order to encourage further input". I continue to see that the premise is very very weak. Shuffling old into the new does nothing to bring in new reviewers, and creating the illusion of no backlog discourages new reviewers.

Could someone who knows how to, create a page that lists every RM that is relisted but still open? --SmokeyJoe (talk) 23:38, 15 June 2016 (UTC)

@SmokeyJoe: I have been noticing this a lot of late, the backlog being empty almost all the time. Obviously this is in principle a good thing, as that backlog has been a perpetual source of problems here at WP:RM for some time. I think it is possibly a result of the new page mover permission - several people have been granted that, and are now performing non-admin closes or relisting moves very proactively. My slight worry is that if the actions being carried out are either (a) relisting moves that should be closed because consensus is clear or conversation has run dry, or (b) effecting poorly considered closes, for example by raw vote counting with no argument analysis, then that's something to be more worried about. One thing that would be really useful would be to see a consolidated list of all recently closed moves, so that we could quickly go through and look at the kinds of closes being carried out. @Wbm1058: is there any possibility that when your bot removes entries from the current discussions page it could then place those closed discussions on some kind of archive page for a few days? Finding relists is a bit easier, because you can just do a find in page of search term "relisting" on WP:RM. There are some items that have been relisted two or even three times, which doesn't seem quite right to me. Thanks  — Amakuru (talk) 10:50, 16 June 2016 (UTC)

I think it's probably because of the page mover right, as you suggested. I've been trying to clear out the backlog recently, and it's been far easy to do so when I can close the majority of moves myself. Omni Flames (talk) 11:18, 16 June 2016 (UTC)

We've had an influx of new closers due to the creation of the page mover right. I think overall it's been a positive thing, but there do seem to be a few new closers who don't have a lot of experience at RM and are unaware of the usual RM norms. In particular, relisting should only rarely be done more than once (contra to AfD) and I see no reason to ever relist a third time, especially when the backlog is small or nonexistant like it is now. There is no harm in leaving half a dozen RMs in the "backlog" if we are simply waiting for more participation (i.e. relisting once usually gets a spike in participation, but second and third get vastly diminishing returns). Of course if the backlog ever gets gigantic again, then we can be more gung ho about relisting because we don't want closable discussions getting lost amidst ones need further input. I like Amakuru's suggestion of a list of recently closed RMs, that would be really useful. The last two days I've been going through some recently closed/relisted RMs just by looking at old revisions of Wikipedia:Requested moves/Current discussions and leaving a few notes for people – hopefully I didn't come off as condescending to anyone. Jenks24 (talk) 12:43, 16 June 2016 (UTC)

I've added a hatnote on the listings for the seventh day (the day before the items enter the backlog, if not relisted). Feel free to suggest any tweaks in the wording of this bot-placed hatnote. wbm1058 (talk) 15:08, 16 June 2016 (UTC)

@Wbm1058: Actually, not all RMs on the seventh day have been listed for the full seven days. E.g. at the moment the RM at Talk:New York still has ~3.5 hours until it can be closed. This recently came up at MRV (see Syrian Civil War at Wikipedia:Move review/Log/2016 May). Jenks24 (talk) 15:15, 16 June 2016 (UTC)

I see. That means some items are "available for closing" for less than 24 hours before they drop into the backlog? An item entered in the 23rd hour of a day, will drop into the backlog within less than an hour of being "available to close"? I'll see if I can get the bot to insert the hatnote at the appropriate mid-day location in the list. wbm1058 (talk) 15:24, 16 June 2016 (UTC)

Yep, spot on. Jenks24 (talk) 15:29, 16 June 2016 (UTC)

It's definitely a good thing to have more closers, but I agree with others above that it would be good to have an easy way to see recently closed discussions so admins can vet them. I've seen a few cases where a different outcome should probably have occurred, and usually the closers are amenable. However, there's no good way to catch them all now. And I echo Jenks – I'm not sure I can remember a single time where a second, let alone third, relist was helpful.--Cúchullain ^t/c 16:13, 16 June 2016 (UTC)

I've always assumed that the backlog is the "available for closing" list, I don't usually touch ones in the date above that. As you say, entries there may have run for the full seven days (down to the minute), or they may not have.  — Amakuru (talk) 09:10, 17 June 2016 (UTC)

I generally waited for the backlog as well, mainly because I always confused myself trying to convert from UTC to my time and then back again. Jenks24 (talk) 13:55, 19 June 2016 (UTC)

I've created a new Elapsed listings section for items which have run a full (24 hours * 7) days. I don't think it's right to declare a backlog on something that just passed the 7-day threshold potentially just minutes earlier, so I'm going to try to expand the window so that listings stay in this "elapsed listings" section for at least a full 24 hours before dropping down to the "backlog" level. It shouldn't be considered so "normal" to have a backlog. I trust this change won't be controversial, but any feedback is welcome. wbm1058 (talk) 14:58, 17 June 2016 (UTC)

The new version of the bot with the new Elapsed listings section is now officially live. Items stay in this section for ~24 hours, before dropping into the "backlog" section. I'm thinking about one more tweak to this. As some discussions need more than a week to resolve – legitimately complex situations might take two weeks or more of active discussion to come to a consensus – I'd like to rename this section Elapsed for over 24 hours and keep track of how many items are in this section. Allow a few of these legitimate extended discussions to be considered "normal" and only flip on the "backlog" switch – which is intended to raise alarm bells for additional admin attention – when the count passes a specified limit... say more than five items in this section. Any thoughts on this? wbm1058 (talk) 13:39, 19 June 2016 (UTC)

Sounds reasonable. I was actually thinking about this when looking over the New York kerfuffle. I would have relisted that had I been uninvolved not because it necessarily needed any extra input (though more is never really bad), but because for big impact RMs like that there will inevitably be someone who complains that the discussion wasn't open for long enough if you close it after just a week. Jenks24 (talk) 13:55, 19 June 2016 (UTC)

Right. Area of a circle vs. Area of a disk was another one of these extended discussions; see Talk:Area of a circle § RfC article title: "Area of a circle" or "Area of a disk" – they knew that would be a "kerfuffle" so just went into "RfC mode" (30-day discussion mode) from the start. We don't want too many people to be avoiding RM because they think our 7-day window is insufficient and too inflexible. wbm1058 (talk) 14:04, 19 June 2016 (UTC)

• Closing of the backlogged is good, yes. A concern would be that the new page movers are new to the job. Would an experienced admin RM closer please review this recent close and the subsequent non-ideal actions?

A general question would be: If you think a non-admin page mover has closed an RM sub-ideally, what should you do? Talk to him/her first, yes, but then? Advise more experienced admin RM closers, or go straight to WP:MR? WP:MR seems overkill. Are non-admin RM closes subject to unilateral revert by an admin, like with XfD closes? --SmokeyJoe (talk) 07:58, 21 June 2016 (UTC)

That's an odd one. I think the close is incorrect in that there is definitely not a consensus to keep the (then-)current title. However, there's also no consensus to move it anywhere else – lots of decent suggestions, no real agreement. I'd have either closed it as no consensus with no prejudice against a new RM, or left it/relisted in the hope of getting more participation and reaching a consensus. Now that it has been moved twice after the RM was closed, I'd suggest reverting to the original title, "Church militant and church triumphant", and then either re-opening the original RM or beginning a new one. I'll leave this here before acting to see what anyone else thinks – it's not a clear-cut situation and it's always useful to get more opinions.

On the general question, it's always best to talk with people first. I think non-admin closers are generally more likely to reconsider their opinions and adjust. I suppose they may be subject to a unilateral revert (honestly not sure what our policy is?), but we should try to avoid it if at all possible – it's demoralising rather than constructive like having a conversation. I don't see any harm in asking an experienced, uninvolved closer what they think of the decision first before proceeding with more drastic action like MRV, it may help save the time that a MRV will inevitably take (we currently have one open that is a slam dunk relist but has been sitting there for a couple of weeks). That's more a criticism of MRV though, I think the process of having uninvolved people comment on the decisions you've made is actually one of the best learning experiences for a closer. Jenks24 (talk) 08:25, 21 June 2016 (UTC)

@Wbm1058: Would you be able to make an elapsed listings section on Wikipedia:Dashboard/Requested moves too? Anarchyte (work | talk) 13:02, 22 July 2016 (UTC)

 Done. Sorry, this was an oversight of mine. Now fixed. wbm1058 (talk) 11:45, 17 August 2016 (UTC)

In response to the requests by three sysops above

• One thing that would be really useful would be to see a consolidated list of all recently closed moves, so that we could quickly go through and look at the kinds of closes being carried out.
• ...a list of recently closed RMs, that would be really useful
• I agree with others above that it would be good to have an easy way to see recently closed discussions so admins can vet them.

I have set up Wikipedia:Requested moves/Article alerts, which lists, in chronological order, both open and recently-closed move requests. No need to re-invent the wheel, as AAlertBot can already do this. Wish this had occurred to me sooner. This report is updated once per day. – wbm1058 (talk) 11:21, 22 June 2016 (UTC)

Note also Wikipedia:Requested moves/Article alerts/Archive. – wbm1058 (talk) 11:35, 22 June 2016 (UTC)

@Andy M. Wang: Per WP:BRD, I'm taking this to the talk page. I think that the reason should be included in the move summary for multiple reasons:

1. The current (and old) edit summary is very opaque – you have to click on the permalink (which I've seen truncated in some cases like the recent move war between AaAaAA!!! – A Reckless Disregard for Gravity and AaaaaAAaaaAAAaaAAAAaAAAAA!!! – A Reckless Disregard for Gravity) and then find the request in a potentially long list to have any idea why the move happened
2. If the requesting user were able to move the page themselves, they would do so with the reason parameter they specified as the edit summary (which might cause summary length issues, but those are not RM/TR's job to fix). The text added by RM/TR (requested by [requester] at WP:RM/TR) is non-essential - the move reason would make sense without it.

Pppery (talk) 01:35, 27 August 2016 (UTC)

Pppery refers to Special:Diff/736370743 in which I undo the addition of {{{reason}}} from the edit summary generated automatically for requests at WP:RMT. As I understand it, RMT has always been operating via attribution... there are no technical move req logs; moves are quickly undoable. Pppery's bold suggestion puts {{{reason}}} before the consistent part of the summary complete with attribution and description of technical nature. An unpredictable prefix that would hide it if it were very long. Scenario: the "reason" for Special:Permalink/732888473 is over 200 characters already. Adding the MediaWiki prefix "User X moved page Foo to Bar:" makes the moves even less liekly attributable, i.e. the permalink is likely to be lost and visible only in the title's move log without an apparent character limit (as far as I know).

Now I suppose {{{reason}}} could be added at the end of the summary so that whatever is left can appear in the revision history, while the move log benefits from a cited reason right there.

I have the feeling that people give you ideas, Pppery, so I'd like to add: you are extremely over-eager and enthusiastic, which is really admirable, but please don't act on this yet, and perhaps wait for another to chime in. (Minor nit: consider syncing the sandboxes too) — Andy W. (talk · ctb) 02:12, 27 August 2016 (UTC)

Here is the point where I disagree. The fact that it was requested at RM/TR is a minor technical thing that should not deprive the actual reason (for the request) of space. Pppery (talk) 12:19, 27 August 2016 (UTC)

• Is this unintelligible because it is a continuation of a long disagreement spanning multiple pages? Move summaries should always include the reason, preferably including a link to the specific discussion justifying the move. --SmokeyJoe (talk) 05:14, 27 August 2016 (UTC)

  @SmokeyJoe: This is the extent to the discussion. All technical move summaries already include an attributable permalink. The summaries (until yesterday) had almost always been something similar to: "Requested at WP:RM/TR as an uncontroversial technical move. (permalink)". Pppery added the additional customized user-given reason to the front of the edit summary. If the reason is hundreds of characters long, it will hide the implication of a satisfaction of a technical request (along with an attributable permalink) in the edit summary (which has a character limit). I'm saying that I could support adding {{{reason}}} to the back of the edit summary, which will end up being "Requested by User:Example at WP:RM/TR as an uncontroversial technical move. Specific move reason given by user Example" <-- however much of the move reason will still fit in the space of the edit summary. — Andy W. (talk · ctb) 06:58, 27 August 2016 (UTC)

• I'd agree with Andy M. Wang above, but suggest that rather than "Specific move reason given by user Example" we just use "Reason given:" to save space and ensure that more of the reason is readable. Agree that the fact of it being requested as uncontroversial technical move, and link to WP:RM/TR needs to take priority. PamD 15:31, 27 August 2016 (UTC)
  • How about Requested by [requester] at WP:RM/TR: [reason]? Pppery (talk) 15:41, 27 August 2016 (UTC)
    • With "Requested" being the permalink link, I think it's fine (with the way it's phrased, kinds of implies a special action) — Andy W. (talk · ctb) 15:44, 27 August 2016 (UTC)
      • @Andy M. Wang: I was intending for requested to be the permalink, but wasn't sure how to phrase that. Pppery (talk) 15:47, 27 August 2016 (UTC)
        • As no-one seems to be objecting to the reason at the end, I just changed the move summary to be my proposal above. Pppery (talk) 22:36, 27 August 2016 (UTC)

You are invited to join the discussion at Wikipedia talk:Page mover#Repairing WP:MALPLACED dab pages. <<< SOME GADGET GEEK >>> (talk) 17:25, 28 August 2016 (UTC) <<< SOME GADGET GEEK >>> (talk) 17:25, 28 August 2016 (UTC)

I made some revisions of move how-to pages, explained at Wikipedia talk:Moving a page#Revisions on 16 September 2016. Please follow up there if there are any comments. — Andy W. (talk · ctb) 00:27, 17 September 2016 (UTC)

i didn't know any other place to put the request. the seven-day period of this discussion will end tomorrow. will an uninvolved user, preferably an admin, close the discussion and state their decision? --HamedH94 (talk) 07:47, 21 September 2016 (UTC)

Done. EdJohnston (talk) 14:32, 22 September 2016 (UTC)

The Maui Historical Society has changed the name of its museum to Hale Hōʻikeʻike at the Bailey House.— Preceding unsigned comment added by Maui Historical Society (talk • contribs) 20:31, 28 September 2016 (UTC)

Please see Talk:Bailey House Museum. wbm1058 (talk) 20:58, 28 September 2016 (UTC)

Hi, the request on September 26, 2016; 14:35 (UTC) related to VCS Verkehrs-Club der Schweiz imho may have been started for potentially 'trolling' reasons, hence, I kindly ask to close the related topic. thx for taking notice, Roland zh (talk) 18:22, 1 October 2016 (UTC)

please see also Wikipedia:Sockpuppet investigations/Soapamalkanmaime/Archive and Talk:VCS Verkehrs-Club der Schweiz, Roland zh (talk) 18:03, 2 October 2016 (UTC)

I note that a large number of articles dealing with the Roman Catholic Church in various countries have been slated for renaming on Oct. 2, but, each done individually. In fact this seems to fall within a Naming Convention discussion. I'm not completely sure where the discussion should take place given the template has already been applied. --Erp (talk) 22:38, 2 October 2016 (UTC)

• I think it best to deal with these nominations separately (as nominated)... in several cases, there are issues of disambiguation specific to the topic country (especially countries with Eastern Catholic Churches). Blueboar (talk) 00:54, 3 October 2016 (UTC)

And there are also countries where Catholic Church includes churches that don't see the Pope as leader (think Old Catholic Church in the Netherlands). Note that 'catholic' has a specific meaning of 'universal' which makes the name being restricted to one denomination possibly problematic especially given that the Nicene creed states belief in one 'holy catholic church' and quite a few denominations that aren't Roman or Eastern Catholic use that creed. I think this is a situation where a central venue for discussion is needed so a consistent policy on naming is agreed upon. --Erp (talk) 13:07, 3 October 2016 (UTC)

So we have this article at WP:Pages needing translation into English#Dubravko Klarić, which wiki-conventionwise seems ok, except for the language. I was wondering if it is possible to move a page to an other-language wikipedia (hr.wikipedia.org in this case) with retention of the page history. --HyperGaruda (talk) 20:07, 7 October 2016 (UTC)

That needs someone with the export/import permissions. Meta or WP:AN might be better places to start. --Izno (talk) 21:43, 7 October 2016 (UTC)

File:SSC Cer.jpg

Hi, I like to request to move Daulatpur Mohsin High School page, the correct name of the school is "Muhsin" instead of "Mohsin" so this page is requested to move "Daulatpur Mohsin High School" - "Daulatpur Muhsin High School". for better confirmation I am including my school certificate where school correct name is mentioned. (Abu Sayeem Mahfooz Khan (talk) 07:19, 13 October 2016 (UTC))

I know, I know, we haven't done this before, but don't let organizational inertia ("tradition") stop you from realizing that moves are the only major Wikipedia article cleanup activity that does not inform the readers that there is something to discuss on the talk page. Renaming of categories does occur through a notice on the category page. Ditto for the rare case of renaming an image. Deletions, splits, mergers, a bazillion of other clean up notices are there to inform people something is going on, but article renamings (moves) discussions are relegated to talk pages only. For no good reason except "this is how we have always done things". Well, let's change this, in the spirit of standardization of cleanup processes, and common good sense (readers are at least as interested in article's name and discussions as in other cleanup issues). I therefore propose we create a relevant template or two, and encourage their use (or perhaps tie them to some form of bot / script, so that using a RM template on the article would trigger addition of a template to the article, as would it removal). But in case someone bemoans that such automation is too technical, a simple cleanup template "It has been suggested that this article may need to be renamed. A relevant discussion may be found on its discussion page" is the primary thing to consider here. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 09:27, 18 August 2016 (UTC)

See User talk:RMCD bot/Archive 1#Considering adding bot-maintained article-space notices. It's not so much inertia or tradition, but prioritization (too many tasks, too little time, not enough volunteers) that's been holding this up. I'll start working on it, and keep you posted on my progress. I'll note, however, one activity that does not always inform the readers anymore: {{Orphan}} tags which are over a month or two old become invisible, as many complained that they were "article-defacing eyesores" and such. If anyone objects to this, please speak up now, as I'd hate to put a lot of time into it, only to see my implementation be rejected. Thanks, wbm1058 (talk) 15:32, 18 August 2016 (UTC)

Just a note that the bot will honor {{nobots}} tags placed in main-space, so the automatically-placed article notices may be suppressed if desired on individual articles, on a case-by-case basis. Don't know how often this option might be used, but it will be available. wbm1058 (talk) 02:32, 19 August 2016 (UTC)

For the record, and as encouragement to wbm1058, I fully support this proposal. — JFG ^talk 06:51, 19 August 2016 (UTC)

OK, for the next step in development I will be placing {{User:RMCD bot/subject notice}} tags at the top of some articles. That's just a blank page for now, while I work on the bot's end. Once I have the new bot code working, I'll add the notice to that file. wbm1058 (talk) 08:37, 19 August 2016 (UTC)

I've created the {{User:RMCD bot/subject notice}} tag, and after testing this on around a dozen move requests, I'm ready to release it into the wild. There may need to be some minor tweaks to handle more rarely occurring special cases, but basically this is done. The bot will be propagating notices to all open move requests momentarily. For this initial implementation, for multiple-move requests, the notice will only be posted to the article page for the talk page which is hosting the discussion. wbm1058 (talk) 20:57, 19 August 2016 (UTC)

The initial full pass has completed, and all single-move requests should be properly functioning. There's an issue which is causing the notices to be prematurely removed from multi-move requests. Working on the fix now. wbm1058 (talk) 21:15, 19 August 2016 (UTC)

OK, the multi-move issue is fixed, so now  Done.
121 of 123 open requests have subject-space notices on them now. The two that don't:

• List of psychedelic rock artists is admin-protected. I suppose I could apply for admin-editing rights for the bot, if posting notices to fully-protected pages is desired.
• Wikibomb2016 has a {{nobots}} tag on it. wbm1058 (talk) 22:26, 19 August 2016 (UTC)

• @Wbm1058: Thanks for working on this! This was a wonderful idea. I'd encourage an application for admin-editing rights for full transparency of advertising for RM discussions. -- Tavix ^(talk) 19:08, 20 August 2016 (UTC)

Very nice development indeed, wbm1058, thanks again! — JFG ^talk 16:47, 27 August 2016 (UTC)

@Wbm1058: Thank you very much for quick implementation. I gather a template like now at Tsarist autocracy is the result? Good job! --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 07:56, 22 September 2016 (UTC)

Thanks, everyone. Above I said, there may need to be some minor tweaks to handle more rarely occurring special cases, and so far I've seen only one glitch. Template move requests should be sandwiched in <noinclude> ... </noinclude> tags, and the bot needs to remove such template-space notices after the discussion has closed. A patch-fix is on my to-do list. wbm1058 (talk) 13:39, 22 September 2016 (UTC)

OK, Template move requests are now  Fixed. wbm1058 (talk) 20:32, 15 October 2016 (UTC)

I've boldly granted my bot the template editor right, as four other bots already have this privilege, so that it could post a requested move notice on the template-protected Template:R from initialism. Not sure whether asking for full admin rights is worth the trouble. Requested moves of fully-protected pages are relatively rare. I can post such notices myself when I notice such a request.

RMCD bot has also been upgraded to post notices on the talk pages of Lua modules which are part of a requested move discussion. The bot will not post notices in the Module: namespace though, i.e. not on the modules themselves.

And while this scenario shouldn't happen, it did: the bot will not post a notice on pages which are REDIRECTs (which should be discussed at WP:Redirects for discussion). I noticed this situation with the move request at Talk:Mike Meyers (outfielder), where the bot was repeatedly placing and then removing notices on the redirect Mike Meyers (baseball).

I've been developing and testing the enhancement to post notices to all pages where the discussion is hosted on another page as part of a multi-move request. I'll fully release that enhancement shortly. – wbm1058 (talk) 19:37, 17 October 2016 (UTC)

Full notification to all subject-space pages, with a few exceptions (modules, redirects, fully-protected pages) is now  Done.

Current statistics:

• Number of pages hosting discussions: 113
• Pages whose move discussions are hosted on another talk page: 59
• Total number of pages requested to be moved : 172

— wbm1058 (talk) 20:20, 17 October 2016 (UTC)

I disapprove or placing move messages in article space. People who go to a page to read information are not going there to read information about Wikipedia internal procedures, Information about editorial concerns should be placed on the talk page (that is what talk pages are for) this includes proposals to move a page. Unless there is an RfC which gains support placing yet another maintenance message in article space by a bot should stop. -- PBS (talk) 06:13, 18 October 2016 (UTC)

Quite the opposite: a notice of potential title change on top of the article is a great way to gather reader input into the proposals. Too often RMs don't attract enough attention until they get executed, and then we get reader backlash. Pre-emptive notices help avoid unnecessary drama, move reviews, etc. — JFG ^talk 08:01, 18 October 2016 (UTC)

agreed. In my view this notice is much more useful than the "This page has multiple issues" thing which often stays up for months or years, and is an eyesore. It's always time limited, and ensures regular article eeditors who.miss something in the talk page, as well as drive by Wikipedians, or even potential new recruits, can come in and join the debate.  — Amakuru (talk) 08:26, 18 October 2016 (UTC)

A request to move St Matthew Passion is listed as uncontroversial, however the present name was the result of a project discussion in 2010 and should not be moved without checking the current consensus, - see article talk. --Gerda Arendt (talk) 22:03, 24 October 2016 (UTC)

Here is an interesting twist, and I don't have a clue whether or not it can be "fixed": When page movers (or admins in the instance of substantive page histories at the page-move targets) do round-robin swaps using temp pages (like the one I use at Draft:Move/pet page), something a little strange happens. Per the discussion on my talk page that was begun by zzuuzz, the temp pages are then added to the watchlists of users who were watching the pages that were moved. And after that, all the pages that are moved from the temp pages also go on those users' watchlists. So we appear to be making many watchlists grow longer as a result of our round-robin page moves. I thought I would bring this here to see if anyone has any ideas about it.  Paine  ^u/c 09:11, 30 October 2016 (UTC)

Per phab:T15602 I think growing a watchlist is unavoidable, but the growth can be limited. This is similar in principle to User talk:Splarka/Watchlist bug, Little Barrier Island, and Lea Luboshutz which are among the most widely watched pages on Wikipedia. I suggest that rather than using a single common page for temporary moves, use a different one for each move. -- zzuuzz ^(talk) 09:47, 30 October 2016 (UTC)

Other bug reports that might be related:

• phab:T21397
• T53052
• phab:T2050
• T42141

I have not yet found a bug report that addresses this specific issue.  Paine  ^u/c 10:33, 30 October 2016 (UTC)

I suggest that rather than using a single common page for temporary moves, use a different one for each move.

I intend to do this until something better is suggested, add ascending numbers to my pet page each time I use it.  Paine  ^u/c 13:00, 30 October 2016 (UTC)

@Paine Ellsworth: I noticed this with the watchlist on my alternate account too. I use pageswap, which will automatically prepend "Draft:Move/" to the title, resulting in unique temporary page names. — Andy W. (talk) 01:06, 3 November 2016 (UTC)

Thank you,  Andy W., and this should probably be mentioned at one of the project pages about swaps. I somehow got the idea that a single Draft:Move/xxxxx_xxx page title should be used, and I wonder how many others also do this, which causes the problem described above.  Paine  ^u/c 02:25, 4 November 2016 (UTC)

See Wikipedia:Page mover#Round-robin page moves, subsection Watchlists and Wikipedia talk:Page mover#Watchlists.  Paine  ^u/c 03:00, 4 November 2016 (UTC)

Is there a category for RM's that are a week old or more? Iazyges Consermonor Opus meum 04:35, 8 November 2016 (UTC)

7-day old RMs are listed at Wikipedia:Requested moves § Elapsed listings

8+ -day old RMs are listed at Wikipedia:Requested moves § Backlog

Is there a need to categorize these as well? wbm1058 (talk) 15:39, 9 November 2016 (UTC)

@Wbm1058: no need necessarily, i just presumed that as there is a category for RM's, it would contain another category for old ones as well, perhaps titled "week old RM's", would it be possible for a bot to take into account of relisting? I.e. If when a RM is relisted it gets taken out of the "week long RM's" folder. Iazyges Consermonor Opus meum 16:03, 9 November 2016 (UTC)

The category is Category:Requested moves. Its only sub-category is Category:Fulfilled page move requests, which should generally be empty. That's for RMs where the move has been made, but a formal close hasn't been done yet, as the {{Requested move/dated}} template remains on the talk page. When an RM is relisted it's automatically removed from either Wikipedia:Requested moves § Elapsed listings or Wikipedia:Requested moves § Backlog, and listed in the section for the date of the relisting. wbm1058 (talk) 16:10, 9 November 2016 (UTC)

Is there a procedure to withdraw a move request? Or must it go through the whole seven days? I didn't see any guidance or instructions on that. — Gorthian (talk) 18:02, 9 November 2016 (UTC)

If you initiated the move request, and no other editors have yet responded to it, just revert your request.

If a discussion has started (others have responded), best practice generally is to get an agreement (consensus) that the request is no longer valid or wanted, and then anyone participating in the discussion (or a third party) may formally close the request before the 7-day listing period has elapsed, giving the reason as "request withdrawn". Whether such instructions should be added to WP:RMCI, I don't know. It's just common sense, and we do such things in the spirit of WP:IAR. wbm1058 (talk) 21:55, 9 November 2016 (UTC)

Thank you! I will keep this in mind. The particular case I was concerned with was closed by an uninvolved editor after I expressed the desire to withdraw it. I do think something should be added to the instructions—operations here aren't really intuitive. — Gorthian (talk) 22:02, 9 November 2016 (UTC)

I made some misstakes. Can someone please

• move Zerocash2 to Zerocash and move ==History== to lead
• redirect Zcash to Zerocash#Zcash_.28ZEC.29
• Delete Zerocash_delete, Zerocash_delete2, Zerocash_delete3

— Preceding unsigned comment added by Gstree (talk • contribs)

It looks like the previous setup was correct, though. Zcash is the title for the current cryptocurrency, and Zerocash is the name of the initial protocol. So I suggest reverting:

• Move Zerocash2 back to Zcash
• Move Zerocash delete back to Zerocash and revert to revision 748541162, which was a redirect to Zcash
• Delete resulting redirects: Zerocash delete2, Zerocash delete3, Zerocash2

—Laoris (talk) 22:32, 10 November 2016 (UTC)

@GB fan: Great, thank you for restoring this.

@Laoris: It should be easier to describe now: Zerocoin contains Zcoin, so it would be logical if Zerocash contained Zcash and not vice versa as it is at the present. Don't you agree? --Gstree (talk) 03:45, 11 November 2016 (UTC)

@Gstree: not necessarily. Based on the articles, it looks like the Zcash article is about Zcash, the current name for the currency, not Zerocash. And someone thought Zcash was independently notable enough to have its own article.—Laoris (talk) 05:30, 11 November 2016 (UTC)

The official stylization is SKYcable, but MOS:TM does say that CamelCase is allowed if it improves the legibility of the name. I think the move should be reverted. ViperSnake151  Talk  03:08, 25 November 2016 (UTC)

MOS:DATERANGE strongly implies that "Papal conclave, 1549–50" (for example) should instead be titled "Papal conclave, 1549–1550" (there is currently a redirect by that title). Is this true, or is there another rule or other consideration involved?—DocWatson42 (talk) 18:07, 29 November 2016 (UTC)

What's the procedure for requesting moving page A (a disambiguation page) to page B (a redirect) and then deleting page A? In this instance, page A is Live at Birdland (disambiguation) and page B is Live at Birdland, which currently redirects to Coltrane Live at Birdland. (B shouldn't redirect where it does now, as the target is not the dominant one with 'Live in Birdland' in the title.) EddieHugh (talk) 13:07, 5 December 2016 (UTC)

@EddieHugh: If you believe it's uncontroversial, you can either use WP:Requested moves#Requesting technical moves or you can use WP:CSD#G6. If you think it may be controversial, you can use the normal RM process. Why would you want to delete the old page A title? --Izno (talk) 15:29, 5 December 2016 (UTC)

Thanks for the reply. It would be uncontroversial. I'll look into the options. Delete because the old (disambiguation) page would be redundant, so would end up blank. EddieHugh (talk) 16:47, 5 December 2016 (UTC)

@EddieHugh: Why wouldn't you leave the old page name a redirect? --Izno (talk) 17:02, 5 December 2016 (UTC)

That's possible, but there'd be no reason to keep it: anyone typing in "Live at Birdland" would end up at the (new) disambig page. EddieHugh (talk) 17:15, 5 December 2016 (UTC)

@EddieHugh: Which is fine. You should probably review WP:Redirects. --Izno (talk) 17:25, 5 December 2016 (UTC)

@EddieHugh: – we leave Live at Birdland (disambiguation) as a redirect to Live at Birdland for purposes of creating intentional links to the disambiguation, and tag that page with {{R to disambiguation page}}. We don't delete such pages, and indeed if someone did that, a bot would likely recreate the page. wbm1058 (talk) 21:34, 7 December 2016 (UTC)

Thanks. It's all been done now. EddieHugh (talk) 21:39, 7 December 2016 (UTC)

{{subst:Brunswick State Theatre|Staatstheater Braunschweig|reason=The translationese name is seldom (if indeed ever) used in English. This should be a relatively uncontroversial reversion, but some has been messing with the redirect page.}}

I don't know who requested this, but the move to Staatstheater Braunschweig has been done. EdJohnston (talk) 21:52, 7 December 2016 (UTC)

May I suggest that they didn't? Specially that requests here usually aren't phrased with that in mind and any user would do a RM if he wish. Half of the admins patrolling here move everything and the other half almost nothing, if you don't want/wish to do a move either take out of the queue or leave it alone. Bertdrunk (talk) 00:08, 23 December 2016 (UTC)

• I'm confused on what specifically your saying -- is it that you think an admin shouldn't create a new RM? In many cases I can see an admin legitimately posting it as an RM because it needs consensus to move, especially contentious items. I don't believe the fact that an admin proposed a move should carry any significant weight compared to say an experienced RM volunteer. So I'm not sure what you think the harm is with ah admin starting a RM. Tiggerjay (talk) 00:31, 23 December 2016 (UTC)

Isn't strange to do something in someone's else name? If a user would wish to do a RM he would do a RM, if a user would wish to fill a technical request he would fill a technical request. As I said there isn't any coherency, as sometimes they moved the requests to RMs and sometimes they just deleted it altogether, as it's said down here, based only on the guy's face. That's just my 2 cents. Bertdrunk (talk) 00:00, 24 December 2016 (UTC)

perhaps it's just me but I'm now more confused. Could you provide some specific examples of what you're talinh about? Tiggerjay (talk) 09:36, 24 December 2016 (UTC)

I think they're talking about technical requests. We move the technical request to article talk page, if someone contests it, for more discussion. Sometimes, it is removed without discussion because it is in violation of guideline or policy. Fuortu (talk) 10:05, 24 December 2016 (UTC)

And this seems entirely proper. Admins are trusted to tell the difference between an obvious move, a borderline case that needs discussion (which of course is in the name of the person who initially proposed the move, not the admin who moved to discuss it), and an obvious no move that can just be declined. I'm not sure what the issue is here.  — Amakuru (talk) 10:10, 24 December 2016 (UTC)

I agree that the process is entirely proper, but Bertdrunk definitely has a point here. A editor placing a technical request would have phrased it very differently if they were aiming for an RM. I usually try to make mine as brief as possible, so that they fit in the edit summary of the move, whereas in RMs I take the time (and space) to provide some context and more evidence. – Uanfala (talk) 11:16, 24 December 2016 (UTC)

Do feel free to add additional statements and rationales in support of your request after it has been converted from a technical request to a formal discussion. These conversions have generally worked out fine with little objection, however in response to a lengthy discussion "Automated mishandling of a request", I added |discuss= to Template:RMassist, which when set to "no" suppresses the "discuss" link which may be used to convert your request to a discussion on the talk page of the page which is requested to be moved. This makes it harder for admins to do that, but I'm not sure all are on board with this, so can't promise that other admins will honor such implicit requests to simply remove controversial technical requests rather than convert them. I believe the vast majority of editors appreciate these conversions, which save them the trouble of starting their own formal RM. – wbm1058 (talk) 14:32, 24 December 2016 (UTC)

Hi all

Just a quick question about use of {{rmnac}}. In the past, the wording of this page used to say it was optional. Something like "it is recommended that non-admin closers use the template..." I notice that the wording at WP:RMNAC now says Any non-admin closure must be explicitly declared with template... Was this an explicit decision that was made by consensus at some point? And if so, should we be using polite messages to non-admin closers if they don't use it, or indeed inserting it ourselves? I notice there are a few who don't use it, for example, SSTflyer at Talk:Gladstone (disambiguation), so just wanted to clarify really if this is a big deal for anyone. Thanks  — Amakuru (talk) 12:17, 15 December 2016 (UTC)

Great observation Amakuru! I noticed the same thing recently that not everyone uses it. I'm not sure there needs to be an RM specific consensus on its use, but probably a broader consensus on the use of NAC templates for any admin-like action. I'm not sure if such a discussion has actually taken place. But it seems generally accepted as a best practice that RMNAC (or NAC) templates should be used as part of the transparency we espouse on here. As far as how should this be enforced such as talk page notices is probably up for debate. I would say that it would be appropriate to at the RMNAC tag to other closures, but that is just my opinion, not an established consensus. Tiggerjay (talk) 17:57, 15 December 2016 (UTC)

If there has been any discussion that resulted in consensus that any NAC must use this template, I have not been notified of them. SSTflyer 02:26, 16 December 2016 (UTC)

All non admins should use it. I notice, the best nacers use it, and the problem nacers dont. A few exceptions on both sides, but generally holds true. --SmokeyJoe (talk) 13:37, 17 December 2016 (UTC)

@SSTflyer:: The closure guide specifically says to use it.Tiggerjay (talk) 09:39, 24 December 2016 (UTC)

Methinks the {{rmnac}} should not be mandatory. Some people are experienced RM closers without being admins and some admins have no particular experience at closing move requests. Therefore "advertising" one's adminship or lack thereof seems irrelevant. The page mover right was unbundled explicitly to make this a non-admin power. Full disclosure: I am a non-admin page mover and I don't sign with {{rmnac}}. — JFG ^talk 11:19, 25 December 2016 (UTC)

"Mandatory" is the wrong word, but you should use it. Why hide the fact, hide from the RM non-regulars, that you have not run the community tests for extra trusted user, been tested as a consensus-caller, and that you should not be closing controversial closes? --SmokeyJoe (talk) 12:06, 25 December 2016 (UTC)

The somewhat ironic part is that those who we don't need to be specifically concerned about use it, and those where such disclosure would be most helpful are not likely to use it.... That is NOT to say those who do not use it cannot be trusted. But rather, those closures which are probably the most controversial are more likely to be done by a non-admin NOT using the template, versus those non-admins who use it. And just to further make sure nobody is offended I am speak more to those who do not regularly close move discussions... as opposed to anyone who is likely participating and watching this page. :) Tiggerjay (talk) 23:02, 25 December 2016 (UTC)

What's the best process for a "technical" request, which actually turns out to be controversial, and has been implemented precipitously? Should technical requests be carried out "as soon as possible", even to the extent of only being a few hours (and thus no time for any other editor to oppose or raise issues). Or should there be a minimum waiting period to allow for this?

The situation in particular is Welsh narrow gauge slate railways, which was renamed correctly some years ago. A request was made today at Talk:British narrow gauge slate railways#British narrow gauge slate railways and at WP:RM/TR to, "revert a change made by a now-banned user. The article covers railways other than just Welsh ones, so the original title is correct, and is also consistent with the other "British narrow gauge.." articles."

There are a few problems with this: a correct and GF rename made years ago by another user should not be reverted just because they are no longer editing, for whatever reason. Secondly the request is both factually incorrect (the only railways there are Welsh) and editorially incorrect (the only railways that belong there are Welsh).

Most concerning though, this is a request from a new editor, hours old, who is already both familiar with page renaming procedure and its subtleties, "I can't move this back over the redirect created when the original article was moved", yet confused over the terms "blocked" and "banned". No-one has mentioned "banned", the past editor was indef blocked. I do wonder where such a new, new user has come across "banning" as a term before?

So, how best to reverse this?

@Anthony Appleyard: Andy Dingley (talk) 00:50, 30 December 2016 (UTC)

There is one outlier in the list: Delabole Quarry. Right, slate railways can only be located where the slate is, and that's just a few select locations in the world. Maybe include the Cornwall line in a separate section for Other UK narrow gauge slate railways? wbm1058 (talk) 04:56, 30 December 2016 (UTC)

(edit conflict)Regarding what would be appropriate, technical moves are generally consider incontroverial, or ought to be, so there is no need for any sort of waiting period, and it is unlikely that those who are most interested on the merits of a specific article would notice its listing on the RM/TR section anyways. In general it is up to the admin who performs the request to perform the necessary due-diligence to ensure that it is appropriate. That is one of the reasons why it is done by humans and not simply by a bot. But even if an important detail is overlooked by the admin, it can relatively easily be undone.

As to the specific concerns about this specific RM/TR, I'll leave that to others to discuss. TiggerJay (talk) 05:02, 30 December 2016 (UTC)

If the narrow gauge railway issue already has this much to be said about it, it sounds like a candidate for a full move discussion. Technical moves are often requested by IPs and other new editors, and in many cases what they are proposing is a good idea. We don't have to be on our guard at WP:RMTR as much as at other boards. Any mistake is usually easy to undo. EdJohnston (talk) 05:11, 30 December 2016 (UTC)

• @Andy Dingley, EdJohnston, and Tiggerjay: Now at Talk:British narrow gauge slate railways#Move? 30 December 2016. Anthony Appleyard (talk) 06:31, 30 December 2016 (UTC)

Gnoming about fixing 'politican' I found problems with articles on Indian politicians. I'm looking for suggestions on how to proceed with these.

Prakash Rai (politican) needs a name change. However there is already Prakash Rai, a redirect to Prakash Raj (who changed his birth name for professional reasons). So I could move to Prakash Rai (politician), but then we need a DAB. It is reasonable to take over the redirect and populate that with links to politician, actor, and a couple more people?

Rafiqul Islam (politican) needs a name change. Rafiqul Islam is a DAB page with 4 names, missing the politician. Okay, just move and add to DAB page.

Abul Kalam Azad (politican) needs a name change for the politician from Assam. But there is already Abul Kalam Azad (politician) from Bangladesh, and rather notable. How should these two pages be renamed? Include a place name?

It is the last one that is beyond my guessing, so I'm bringing all three here for direction. Shenme (talk) 22:35, 30 December 2016 (UTC)

In your third example, it's clear that the Bangladeshi politician is the primary topic and so should stay at its current title. A hatnote (probably best {{for}}) should then be placed on it, pointing to the politician form Assam. Now, the question is how should that one be titled. The parenthetical disambiguator could be either Indian politician (as in for example V. Arumugam (Indian politician)), or Assam politician (following the pattern of politicians from other Indian states like Satyanarayan Singh (Bihar politician)). – Uanfala (talk) 23:40, 30 December 2016 (UTC)

• Most of the time, a move request listed here has clickable options "move" and "discuss". But since yesterday the "discuss" option in them has disappeared; please restore it. Anthony Appleyard (talk) 05:42, 4 January 2017 (UTC)

  @Anthony Appleyard: I just tried a test and the "discuss" option seemed to be there.[1] Maybe some users are using a different method of generating the request for some reason?  — Amakuru (talk) 09:59, 4 January 2017 (UTC)

  Here, [2] it looks like the user in question used {{RMassist/core}}, with the "discuss=no" option set, rather than the standard {{RMassist}}, as per the instructions on the page. I'm not sure why, but it seems that the issue is not a technical one. Have you seen this on more than one occasion? Thanks  — Amakuru (talk) 10:02, 4 January 2017 (UTC)

See the section #Admins starting RMs above. My opinion is that if the requester doesn't want to discuss their request, we should simply withdraw it, and the lack of the (discuss) link should be taken as an implicit request for withdrawal rather than conversion. The requester is then free to use {{subst:Requested move}} on their own if they wish. Though I would frown on re-submission of a technical request in the hope that a different admin would honor it. wbm1058 (talk) 21:05, 4 January 2017 (UTC)

Is it really necessary to go through all of this to fix the obvious misspelling of the article Rugby League International Calander? Hyperbolick (talk) 14:57, 13 January 2017 (UTC)

 Done JPG-GR (talk) 02:52, 14 January 2017 (UTC)

Please move Ginga: Nagareboshi Gin to Ginga Nagareboshi Gin. — Preceding unsigned comment added by Keznen (talk • contribs) 18:07, January 16, 2017 (UTC)

 Not done. Please bring this up at Talk:Ginga: Nagareboshi Gin. The references given in the article support the name currently in use. Bradv 18:08, 16 January 2017 (UTC)

Please move these two pages:

• Move Akita (page C) to Akita Inu
• Move Ginga: Nagareboshi Gin to Ginga Nagareboshi Gin

Reason for moving: The titles are incorrect. They must be moved.— Preceding unsigned comment added by Keznen (talk • contribs) 06:08, 16 January 2017 (UTC)

See Wikipedia:Administrators' noticeboard/Incidents#Akita (dog) - Akita (page C) – wbm1058 (talk) 16:34, 16 January 2017 (UTC)

Akita (page C) was moved back to Akita (dog).

Sigh what a mess. A new editor with < 50 edits boldly trying to emulate a WP:Page mover. What have we unleashed?

Ginga Nagareboshi Gin redirects to Ginga: Nagareboshi Gin.

Please submit a requested move for the dog, as a potentially controversial move. Follow the instructions for using Template:Requested move.

You might make a technical request for the manga, but you need to explain why the title is incorrect. – wbm1058 (talk) 16:34, 16 January 2017 (UTC)

The reason the article is titled Akita (dog) is because the scope includes both the American Akita and the Akita Inu (Japanese Akita). Moving this to Akita Inu would thus be moving to a title with a scope that was too narrow for the content of the article. My impression; I'm not a dog breed expert. Oh, and Inu means dog in Japanese and this is English Wikipedia. – wbm1058 (talk) 17:10, 16 January 2017 (UTC)

Agreed that's a weird situation. There should probably be a split, since these breeds have separate standards in most contexts. While this is better discussed at the article talk page, the gist is this: The situation is directly analogous to the Manx cat and Cymric cat; the latter is classified as a "Manx Longhair" or "Longhair Manx" subvariety of the former by a few registries, but all the rest treat it as its own breed, and it's independently notable. {{Infobox dog}} doesn't gracefully handle situations where two [related] breeds have been conflated into a single article yet some registries treat them separately; there's only one parameter for classification and standards, and as you can see at Akita (dog) trying to bend it to handle a case like this results in a confusing mess. I can't think of any other cases where we have a standardized breed of dog, cat, horse, etc. that is put into the article on another standardized breed (only crossbreeds and experimental offshoots, for which there's no international breed standards and which aren't themselves notable [yet], and variations (color classes, etc.) that are treated in the same standard, get merged that way). Another issue is that Akita (dog) implies a notable individual dog named Akita, like Lassie or Benji. I think a few other dog breed articles still have this confusing disambiguator. I'd meant to address that at some point. The dogs breeds are the only category of domestic animal breeds that hasn't been cleaned up in this regard; after doing all the cats and chickens and pigs and etc., etc., I kind of ran out of steam several months ago.

If no split were to happen and a disambiguator was retained, it would probably be "(breed)" (cf Brittany (breed), etc.), since "(dog breed)" is presently being used for DAB and set index articles for multiple breeds of a certain class (e.g., Pointer (dog breed), Laika (dog breed)). All of these can probably be reduced to "(breed)" per WP:CONCISE.

As for titles after a split, they'd be American Akita (seemingly the common name now of that breed), and whatever is the WP:COMMONNAME in English sources for the original Japanese breed as distinct from the American one; that might be Akita Inu (I suspect it is, from familiarity), regardless of the origin of the words. Lots of dog breeds have non-English words for 'dog' or 'hound' in their names in English. But it might be Japanese Akita, if usage has shifted. It would take some research, since it would need to exclude sources that do not distinguish the two kinds of Akita (from probably June 1999 and earlier, though not all from after that date make the distinction).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:34, 19 January 2017 (UTC)

We badly need some kind of searchable archive of this stuff, and for this to be "advertised" prominently on the RM page. It appears to me that about 95% of RMs are rehash of innumerable previous discussions, but the consensus determinations in them are rarely cited, because they're so hard to find. For one topic alone, I've had to hand maintain my own archive of results, which is incomplete, and it's a massive hassle. This appears to be the only major WP process the results of which have no searchable history. I would think that Harej's RMCD bot|RMCD bot could be adjusted to move completed discussions to archive pages instead of just deleting them, so RM works more like everything else. I think this is important because RM is a major drain on both editorial and administrative time, the source of intense amount of heat without light (with dispute spilling over into WT:AT, WT:DAB, WT:MOS, and the talk pages of naming convention guidelines, wikiprojects, and articles topically related to the one being moved, on a basis that it's just regular but constant. RM never actually seems to long-term resolve anything, but simply exists as a long-term tug-of-war at tens of thousands of articles.

The best we have right now (that I know of) is doing WikiBlame ("Revision history search") at at history page of Wikipedia:Requested moves/Current discussions, but this tool is slow, and is extremely limited, produces very partial results necessitating search after search after search even for one year of data, is counterintuitive, and rarely is very helpful. We need something much more like the archive searches at WP:ANI or WT:MOS.

The ideal result would actually be for closed discussions to be copied to an archive (not theoretically hard; RMCD bot is already smart enough to identify and repost at the RM page any properly formatted RM when triggered by its template; a closure trigger could have it do an archival job, too). I realize that's essentially "tasking" Harej to write a bunch of code, though. I would think that even existing archival bots could just archive the listings, without their resolutions, directly off of WP:Requested moves/Current discussions, and that alone would be a major boon.

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:28, 15 December 2016 (UTC)

I believe the bot is now maintained by Wbm1058, and many thanks again for their hard work in doing so, the bot is a massive help in maintaining the RM process. I don't know if there's much time for improvements, but I too agree that a complete central searchable archive of completed RMs would be very useful addition to the bot's activity. At the moment, once an RM is closed it disappears off the backlog and there's no easy way for admins to go in and view those old ones. It would be useful for spotting any differences in the way closers handle certain situations as well, and for mentoring less experienced closers. Thanks  — Amakuru (talk) 12:22, 15 December 2016 (UTC)

Yes, per User:RMCD bot §History, I've now maintained this process for longer than the previous operators combined, and am responsible for all recent enhancements. Wikipedia:Requested moves § See also: Wikipedia:Requested moves/Article alerts, which includes a list of recently closed discussions. That's maintained by AAlertBot (but I set up the configuration for requested moves), and now has two archives:

• Wikipedia:Requested moves/Article alerts/Archive
• Wikipedia:Requested moves/Article alerts/Archive 2

Unlike other Wikipedia processes that take place in their own dedicated talkspaces, such as the incidents and style drama boards, requested moves uses the talk pages of the actual articles involved, so all RM discussions are already automatically archived, in the talk archives of the articles themselves.

I realize that following the entire move history of a topic can be a chore at times though, as pages are often first boldly moved, or moved as a result of technical requests, before it becomes apparent that the title is potentially controversial and a more formal discussion begins. Also note that WP:Move review, the "Supreme Court" of the RM process, does maintain a more formal archive.

It would be more helpful if the above was less rant, and prescription of solution(s), and more description of the problem(s) that need to be solved. Some specific examples might help me understand what information you are having trouble easily finding. Thanks, wbm1058 (talk) 14:05, 15 December 2016 (UTC)

Also, if Template:Old moves is used at the top of talk pages, we also have that as an easy index to the move and requested move history. And I should give credit to others for the recent enhancements to {{RMassist}}. wbm1058 (talk) 14:32, 15 December 2016 (UTC)

@Wbm1058 and Amakuru: Credit: Sorry, I just saw Harej's name when I went to the bot's user page. I agree that, from the admin perspective, this would also be of great use in normalizing closes. It would also speed up cleanup efforts, by providing a way to more easily show that noncontroversial consistency moves are in fact noncontroversial and based on a record of previous moves consistently in the same direction. I don't feel I was ranting, and thought the suggestions were pretty specific. Responding to a request for detailed descriptions of problem scenarios is much more likely to be rant-like. But a simple example: I know that whether an article should be titled "Foo Dynasty" or "Foo dynasty" is something that has been discussed numerous times, with a consistent trend toward lower-casing "dynasty" if it is not actually part of the formal proper name (in English, or a cognate term translated into English as "Dynasty"); in most cases it's a post hoc description, so should not be capitalized. After over half an hour of searching with WikiBlame, month by month, I only came up with a few hits, and gave up. Life is too short for that. I would love to be able to just search Rm archives for "dynasty" and have every entry with that word in it come up, the way it does if I search ANI or whatever for this term. I realize that a new bot change won't magically make all the old RMs appear in such an archive, but better to start building one now than never. :-) I suppose a bot could theoretically pull old entries out of history and retroactively build an archive, which would be superbadass, but probably less practical. Wikipedia:Requested moves/Article alerts is helpful, but only shows the original name of the article not the proposed one (which is often more relevant, though the actual close result is the Grail), nor the text of the proposal.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  16:21, 15 December 2016 (UTC)

• Agreeing with SMcCandlish: I'd find such an index helpful as the wikipedia lore needed for RM discussions isn't, and can't ever be contained in the naming conventions, but is often found in the precedents of previous discussions. – Uanfala (talk) 21:33, 15 December 2016 (UTC)

OK, sorry, I think I understand better now. Citing titles containing "dynasty" (upper or lower case "d") was helpful. I'll think on this. No solutions can be implemented overnight. Now, only if the "Knowledge Engine" had the ability to search page histories, and not just the current versions of talk page archives ;) The rationale for {{move-multi}} was so that similarly titled pages could be grouped together into a single talk-page discussion, e..g., move several "Dynasties", and then the centralized discussion would be easier to find than multiple separate discussions. wbm1058 (talk) 21:42, 15 December 2016 (UTC)

So perhaps this is showing what I don't know, but what would prevent us from using this valid reason to be the catalyst to change the way we handle RM into the same way we handle virtually all other discussions like AfD? Is there a specific reason we're using the talk page instead of a dedicated section like the other tasks do? Sure it would be a huge change in process, but is there a specific reason why RM is the outlier here? Tiggerjay (talk) 22:45, 15 December 2016 (UTC)

You wouldn't want to have deletion discussions on the talk page of the article up for deletion, because if the article was deleted, then the deletion discussion would be deleted too! We don't have that problem to deal with here at RM. I don't know where this idea that all the processes except this one are all alike came about. I think when the Flow guys at the WMF were looking into implementing some standardized system for implementing workflows, they were struck by how every single workflow here was different, making it difficult to implement any sort of common workflow system to run everything. The system for proposing merges and merging articles is nothing like AfD. Are RM and Merges the the only workflows mananged to at least some degree by bots? If so, doesn't that make them outliers in a good way? Surely you don't want to go back to doing everything by hand. I may be able to implement some sort of archiving system for RM, give me some time to work on it and see what I can do. – wbm1058 (talk) 02:22, 16 December 2016 (UTC)

I have no issue with the discussions being held and remaining on the article talk pages, since it's an important part of article history, and often brings in all kinds of stuff like reliable source dumps, rescoping decisions, etc. My only concern is stemming the endless WP:FORUMSHOP tide. A huge, huge proportion of RM churn is nothing but tedious rehash, and this could be strongly curtailed with a functional archive system for quick and easy precedent establishment.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:32, 12 January 2017 (UTC)

(←) I think we can probably start helping with this problem by making sure {{requested move}} when substed provides some sort of HTML comment or something of the sort like <!-- Move request -->. Just to take the example about dynasties, I was able to make a really plain search regarding dynasty move requests at [3]. A similar search for insource:'dynasty' rather than intitle:'dynasty' would probably be on the same level of response. However, with the template moving every once in a while and having its text changed every once in a while (better now--I can get results in the 2012s timeframe from the above), it would be good to have some sort of static text for which we can search. --Izno (talk) 13:14, 16 December 2016 (UTC)

Super, Izno, thanks! Your search syntax led me to quickly locate Talk:Han dynasty § Han Dynasty to Han dynasty, which I think is what SMcCandlish was looking for. We have standardized section headers in the form Requested move DD Month YYYY, though that can be overridden; it's a probably good search term: insource:'Requested move' as an alternative to "move request". Also insource:'Move discussion in progress' is a standard header used by the bot on cross-post notifications. Noting that this search syntax is complex and on Wikipedia talk:Articles for deletion there are search boxes where one simply enters a search term and clicks a button, so the template with the button automatically does the insource:'move request' or insource:'Requested move' or insource:'Move discussion in progress' part, can we implement a similar button here? {{archives|collapsed=yes|search=yes}} But the vaunted {{Search deletion discussions}} isn't working for me: An error has occurred while searching: Search request is longer than the maximum allowed length. (659 > 300) – wbm1058 (talk) 15:13, 16 December 2016 (UTC)

Thanks, all, for the input so far. The above is definitely helpful. :-)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:59, 17 December 2016 (UTC)

I started a follow-up discussion at Wikipedia:Village pump (technical)#Search prefix: – will keep on this, and implement some sort of search button(s) that internally construct the best search syntaxes (intitle:, prefix:, etc.) – wbm1058 (talk) 14:05, 24 December 2016 (UTC)

Thanks for looking into it, wbm1058.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:36, 12 January 2017 (UTC)

Followup question here: Wikipedia:Village pump (technical)/Archive 152#Search prefix revisited – search with multiple prefixes? – No responses yet.

The InputBox extension is the foundation that search boxes are built on. I'll see what I can do with that, working within the limitations of the current MediaWiki search. wbm1058 (talk) 21:40, 18 January 2017 (UTC)

Well this is kind of lame. The InputBox extension supports the prefix= parameter but it doesn't support the insource or intitle parameters, so I settled for putting those in the default= parameter that pre-populates the search box. Just enter "dynasty" or whatever after that, then click search, SMcCandlish. – wbm1058 (talk) 23:30, 18 January 2017 (UTC)

@Wbm1058: Ah, yes, I just tried it in the search box higher up this page, and it did produce pretty good results. I guess there's no way to narrow it more than "insource:move"? (I guess the default "Requested move" heading text hasn't been a default forever and is sometimes overridden manually even today.) It seem to find the word "move" anywhere on the talk page. Still, it is definitely closer to a functional RM archive search than we had, and I greatly appreciate the effort and research time.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:41, 19 January 2017 (UTC)

I added a second search box. This should make it more clear how it works. wbm1058 (talk) 16:00, 19 January 2017 (UTC)

Flying Colors (2015 film) was deleted while an RM was in progress on its talk page, which was then speedy deleted. The RM is now in the backlog.

Does the bot handle this, or is manual cleanup required? Andrewa (talk) 03:41, 19 January 2017 (UTC)

Oh my, it was deleted as an expired proposed deletion, while the RM was in progress. Deleting the talk page hosting the discussion is a novel way to close an RM.

The bot rebuilds its current discussions list from scratch every time, so if the talk page has been deleted, the bot won't see it (diff).

If anyone would like the page restored, in order to formally close the requested move, just ask, and I'll restore it. Restoring the talk page will automatically re-open the RM.

We know a thing or two, because we've seen a thing or two. We are Requested moves, dum-de-dum-da-da :) wbm1058 (talk) 04:20, 19 January 2017 (UTC)

Thank you, I hoped the bot would handle it and you're way ahead of me, but just wanted to be proactive in case there was a problem. Perhaps I should have given more of the story, but that's exactly as I saw it too.

It's novel indeed. (;-> It's possibly not the best of procedures... maybe an RM should be considered to implicitly challenge the PROD request? And isn't speedy deletion of a talk page with an ongoing RM discussion contrary to commonsense? Shouldn't it instead be flagged as moot?

But I think the result is OK in this case. And the boot handles it well. Good robust design. So let's just move on. Thanks again. Andrewa (talk) 13:35, 20 January 2017 (UTC)

Sure, but just for clarification, "An administrator may decide on their own to restore an article that has been deleted after a proposed deletion without having to make the request at Requests for undeletion, which is a process intended to assist users in restoring pages or files that were uncontroversially deleted via proposed deletion, under certain speedy deletion criteria" – so challenging the PROD request should be easy, if anyone wants to do that. The talk page with the open RM discussion was simply deleted per WP:G8 – talk page of a deleted page. wbm1058 (talk) 20:53, 20 January 2017 (UTC)

Among the closing instructions at WP:RMCLOSE § Three possible outcomes there's the following text:

There are rare circumstances where multiple names have been proposed and no consensus arises out of any, except that it is determined that the current title should not host the article. In these difficult circumstances, the closer should pick the best title of the options available, and then be clear that while consensus has rejected the former title (and no request to bring it back should be made lightly), there is no consensus for the title actually chosen.

This implies that a requested move could discuss several alternative titles and it seems to suggest that it's possible for the outcome to be a title that wasn't explicitly proposed in the nomination. However, one recent close (and the comments made at the ongoing move review) seem to indicate there's a strong trend in current practice to procedurally close as "not moved" discussions in which the title that receives consensus is not listed within the {{Requested move}} template at the top of the nomination. I disagree with this practice, but if that's what is normally done, then it should somehow be reflected in the closing instructions. Any thoughts? – Uanfala (talk) 14:56, 31 January 2017 (UTC)

@Uanfala: In my experience, and the rule of thumb which I apply when I'm closing moves, is that it's permitted and possible for a consensus to emerge for some other title other than the one proposed. Closing such discussion as WP:NOTMOVED would be a violation of WP:IAR if it is clear that a consensus has emerged. We do not apply "procedural rules" when it's not helpful to do so.  — Amakuru (talk) 15:38, 31 January 2017 (UTC)

I agree with Amakuru. If a proposed title comes late into the discussion, it's up to the closer to see whether those who responded earlier have accepted it. If not, then a no consensus without prejudice for another RM may be appropriate. But if the late proposal convinces the early entrants, and doesn't look like it would have attracted different opposition if it were listed at WP:RM, then the closer can decide that's the consensus. The closing instructions could perhaps say more about such possibilities, but should not be changed to give the closer less discretion, since the point of the discussion is to get to a resolution. Dicklyon (talk) 16:36, 31 January 2017 (UTC)

Want to move the translated article User:USA-Fan/callus shaver to callus shaver. But can´t find any helpful information to do this. --USA-Fan (talk) 15:31, 31 January 2017 (UTC)

"How-to" questions are best addressed at WP:HD, although responders there may direct you to a better venue for your specific question. I don't mean to put you off, but I feel the best way to remember HD is to actually use it. ―Mandruss ☎ 16:47, 31 January 2017 (UTC)

Allready listed there. Thanks. --USA-Fan (talk) 16:59, 31 January 2017 (UTC)

So it is, my bad. ―Mandruss ☎ 17:02, 31 January 2017 (UTC)

Moved here from project page so discussion can continue. Bradv 18:30, 27 January 2017 (UTC)

• Narrow gauge railways in Albania (currently a redirect to Narrow-gauge railways in Albania) → Narrow-gauge railways in Albania (move · discuss) – [see below]
• Narrow gauge railways in Serbia (currently a redirect to Narrow-gauge railways in Serbia) → Narrow-gauge railways in Serbia (move · discuss) – [see below]
• Narrow gauge railways in Turkey (currently a redirect to Narrow-gauge railways in Turkey) → Narrow-gauge railways in Turkey (move · discuss) – [see below]
• Narrow gauge railways in Slovenia (currently a redirect to Narrow-gauge railways in Slovenia) → Narrow-gauge railways in Slovenia (move · discuss) – [see below]
• Narrow gauge railways in Sweden (currently a redirect to Narrow-gauge railways in Sweden) → Narrow-gauge railways in Sweden (move · discuss) – [see below]
• Narrow gauge railways in Ukraine (currently a redirect to Narrow-gauge railways in Ukraine) → Narrow-gauge railways in Ukraine (move · discuss) – [see below]
• Narrow gauge railways in Spain (currently a redirect to Narrow-gauge railways in Spain) → Narrow-gauge railways in Spain (move · discuss) – [see below]
• Narrow gauge railways in Russia (currently a redirect to Narrow-gauge railways in Russia) → Narrow-gauge railways in Russia (move · discuss) – [see below]
• Narrow gauge railways in Poland (currently a redirect to Narrow-gauge railways in Poland) → Narrow-gauge railways in Poland (move · discuss) – [see below]
• Narrow gauge railways in Norway (currently a redirect to Narrow-gauge railways in Norway) → Narrow-gauge railways in Norway (move · discuss) – [see below]
• Narrow gauge railways in Luxembourg (currently a redirect to Narrow-gauge railways in Luxembourg) → Narrow-gauge railways in Luxembourg (move · discuss) – [see below]
• Narrow gauge railways in Lithuania (currently a redirect to Narrow-gauge railways in Lithuania) → Narrow-gauge railways in Lithuania (move · discuss) – [see below]
• Narrow gauge railways in Latvia (currently a redirect to Narrow-gauge railways in Latvia) → Narrow-gauge railways in Latvia (move · discuss) – [see below]
• Narrow gauge railways in Kazakhstan (currently a redirect to Narrow-gauge railways in Kazakhstan) → Narrow-gauge railways in Kazakhstan (move · discuss) – [see below]
• Narrow gauge railways in Hungary (currently a redirect to Narrow-gauge railways in Hungary) → Narrow-gauge railways in Hungary (move · discuss) – [see below]
• Narrow gauge railways in Finland (currently a redirect to Narrow-gauge railways in Finland) → Narrow-gauge railways in Finland (move · discuss) – [see below]
• Narrow gauge railways in Estonia (currently a redirect to Narrow-gauge railways in Estonia) → Narrow-gauge railways in Estonia (move · discuss) – [see below]
• Narrow gauge railways in Denmark (currently a redirect to Narrow-gauge railways in Denmark) → Narrow-gauge railways in Denmark (move · discuss) – [see below]
• Narrow gauge railways in Cyprus (currently a redirect to Narrow-gauge railways in Cyprus) → Narrow-gauge railways in Cyprus (move · discuss) – [see below]
• Narrow gauge railways in Croatia (currently a redirect to Narrow-gauge railways in Croatia) → Narrow-gauge railways in Croatia (move · discuss) – [see below]
• Narrow gauge railways in Austria (currently a redirect to Narrow-gauge railways in Austria) → Narrow-gauge railways in Austria (move · discuss) – [see below]
• Narrow gauge railways in Portugal (currently a redirect to Narrow-gauge railways in Portugal) → Narrow-gauge railways in Portugal (move · discuss) – [see below]
• Narrow gauge railways in Italy (currently a redirect to Narrow-gauge railways in Italy) → Narrow-gauge railways in Italy (move · discuss) – [see below]
• Narrow gauge railways in France (currently a redirect to Narrow-gauge railways of France) → Narrow-gauge railways in France (currently a redirect instead to Narrow-gauge railways of France) (move · discuss) – [see below]
• Narrow gauge railways in Bulgaria (currently a redirect to Narrow-gauge railways in Bulgaria) → Narrow-gauge railways in Bulgaria (move · discuss) – [see below]
• Narrow gauge railways in Europe (currently a redirect to Narrow-gauge railways in Europe) → Narrow-gauge railways in Europe (move · discuss) – [see below]
• Narrow gauge railways in Germany (currently a redirect to Narrow-gauge railways in Germany) → Narrow-gauge railways in Germany (move · discuss) – [see below]
• Narrow gauge railways in the Czech Republic (currently a redirect to Narrow-gauge railways in the Czech Republic) → Narrow-gauge railways in the Czech Republic (move · discuss) – [see below]
• Narrow gauge railways in the Netherlands (currently a redirect to Narrow-gauge railways in the Netherlands) → Narrow-gauge railways in the Netherlands (move · discuss) – [see below]
• British narrow gauge railways (currently a redirect to British narrow-gauge railways) → British narrow-gauge railways (move · discuss) – [see below]
• List of narrow gauge railways in Ireland (currently a redirect to List of narrow-gauge railways in Ireland) → List of narrow-gauge railways in Ireland (move · discuss) – [see below]
• Septemvri–Dobrinishte narrow gauge line (currently a redirect to Septemvri–Dobrinishte narrow-gauge line) → Septemvri–Dobrinishte narrow-gauge line (move · discuss) –
  All moved without discussion by the same user, despite the hyphenation of "narrow-gauge" being the subject of at least two ongoing RMs (here and here, in which that user is participating but which do not appear to be going his way), and previous RMs that have kept/inserted the hyphen (e.g. here), and MOS:HYPHEN which says to hyphenate compound adjectives, and proof that his "it's American" argument is false. This is tendentious, disruptive WP:FAITACCOMPLI abuse of direct moves and should be administratively admonished.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  00:03, 27 January 2017 (UTC)

• In what way is this edit-warring escalation a positive move, or in particular a mere "technical request"? Andy Dingley (talk) 00:17, 27 January 2017 (UTC)

If you have some kind of issue with WP:RM/TR#Requests to revert undiscussed moves being classified under "Technical requests", where it may not be the best fit, you should take that up at WT:RM. I didn't make it that way, but it is the proper venue for requesting the reversion of undiscussed moves, and I decline to be taken to task for using it for its intended purpose. If you have an issue with that fact that it's disruptive to run around moving a large number of articles, with misleading edit summaries, and the clear intent of spiting the outcome of RMs one isn't getting one's way in – and you'll be going against ArbCom's previous decisions about fait accompli behavior, as well as WP:ANI history in dealing with disruptive move abuse – feel free to propose an exception at WT:Disruptive editing. If you want the community to change the definition of "edit warring" to include using the standardized process for reverting undiscussed moves (rather than just going and reverting them manually) as a form of editwarring, and thus undo the WP:RM/TR#Requests to revert undiscussed moves process's rationale for existence, that's probably a proposal for WP:Village pump (policy).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  02:17, 27 January 2017 (UTC)

• @Andy Dingley, SMcCandlish, Bermicourt, and Dicklyon: Lets get this dispute properly sorted out, before anyone has to move all those 42 articles. Anthony Appleyard (talk) 09:06, 27 January 2017 (UTC)
• As uninvolved, I would suggest this course of action. Allow the RM at Narrow gauge railways in Saxony to establish the default for all "narrow gauge" articles. If it passes (the default is hyphen), do all of the above moves without further discussion. Anyone may then open RMs affecting single articles if they feel there is enough basis to vary them from the default. This would require something unusual about those articles/situations, not a re-hash of the arguments at Saxony. No further moves would be done in this group without RM. ―Mandruss ☎ 14:56, 27 January 2017 (UTC) - Struck "uninvolved" as I have now !voted in the Saxony RM. ―Mandruss ☎ 16:32, 30 January 2017 (UTC)

  I have to interject that we've already been through this before [and recently], at Talk:British narrow-gauge slate railways#Requested move 14 January 2017. It's unclear why that precedent is somehow no good, compared to one that will emerge from the Saxony RM.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:03, 27 January 2017 (UTC)

  No doubt you've been making that argument for some time and it hasn't worked (remember the definition of "insanity"). Next step is some uninvolved ruling or arbitration, and I think that could be done by a post at WP:AN, a discussion at WP:DRN, or RfC, among other ways. I suggest you seek a solution like what I suggested, and whether it's for British or Saxony is relatively unimportant. If you lose, you move on, blaming the community for the result and telling yourself you did the best you could.
  Or, you can RM every one of those 42. ―Mandruss ☎ 21:47, 27 January 2017 (UTC)

  @Mandruss: How could I have made the argument for some time if you only just now proposed treating the Saxony RM as a special precedent? This still doesn't answer my original question: Why would the Saxony RM be treated as magically special? Especially in light of Bermicourt's highly non-neutral mass-canvassing (see below) of all the railfans to come bloc vote in that RM? That said, I agree with the general gist. I've raised these FACTION/CANVASS issues [4] at the new, vexatious ANI case against Dicklyon and suggested that maybe it's time for ArbCom to get involved and shut down this "turn a wikiproject into a anti-guideline activism and editor bounty-hunting club" activity.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  22:01, 29 January 2017 (UTC)

  Since that RM discussion that Bermicourt is losing is overdue to close, and is running 6:2 in favor of hyphen, and since no previous discussion has resulted in preferring a space in such compounds used as adjectives, I have to agree with SMcCandlish that these moves by Bermicourt were pointy and disruptive. Waiting for that to close is unneeded, in terms of seeing that these are essentially uncontroversial. If we wait for the close, either it will close as is, or this extra publicity will bring in some skewed new opinions and flip it, which would reward Bermicourt for his bad behavior. I'm not that worried about that, but it seems like a strategy of caving to disruption is not right here. Dicklyon (talk) 16:32, 27 January 2017 (UTC)

  • @ SMcCandlish and User:Dicklyon. It's a little extreme to claim my recent moves as 'disruptive' when I'm simply following WP:BRD and returning them to the titles they had been under for a long time and which were consistent with the naming scheme. If anything, it was the original moves made earlier this month that were disruptive as they were clearly going to be contentious, changing the status quo of a large number of articles that various editors had created, named and categorised using the same convention (i.e. "narrow gauge"). And if we're going to use Narrow gauge railways in Saxony as a default, we ought to notify Wikipedia:WikiProject Trains and extend the time scale for the discussion, not rush to close it before changes to dozens of other articles can be discussed. That sounds very much like sharp practice. And Dicklyon, please moderate your language please, you're engaging in WP:PA again. Bermicourt (talk) 16:37, 27 January 2017 (UTC)
    • For four weeks nobody was bothered by any of these hyphens, except you on the Saxony one. Your revert there was fine, but your move of the rest just when your silly ENGVAR argument at Saxony has been lost is "bad behavior"; that's a comment on your edits, not your person. Dicklyon (talk) 16:46, 27 January 2017 (UTC)
    • Calling someone on bad behavior is not prima facie personal attack. Heaven help Wikipedia if that is ever prohibited by WP:NPA. You can defend yourself against the claims, but you can't cite NPA. ―Mandruss ☎ 16:50, 27 January 2017 (UTC)
      • It seems pretty unfair, though, when the original problem was caused by an editor mass-moving railway articles without flagging it up at the relevant project. When you do that to large numbers of articles that consistently appear to be following a convention, you are taking a risk and really can't cry foul if they are then BRD'd. However, I'll not move any more on the assumption that there will be a wider debate somewhere. Bermicourt (talk) 16:59, 27 January 2017 (UTC)

  To address the user-specific matter: When you know for a fact that the action is going to be controversial, and the matter is already the subject of on-going controversy in multiple discussions, but do it anyway in WP:POINT fashion, this is disruptive and you know it. To touch on broader matters: What's "unfair" is for a good-faith and orderly process like RM to be mired (again) in what could be months of article-by-article rehash over the exact same matter. We just went through this with half a year of tendentiousness against MOS:JR at bios; if that pattern continues to repeat, RM is broken and WP:GAMEable, and needs to be fixed.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:03, 27 January 2017 (UTC)

Canvassing

After Mandruss made his proposal, Bermicourt took to canvassing here, which has so far brought one more to his side on the Saxony RM. Not an acceptable behavior, is it? Dicklyon (talk) 23:26, 27 January 2017 (UTC)

Notifying the relevant WikiProject of a proposed move is not canvassing—it is actually recommended when proposing a controversial move. Bradv 23:52, 27 January 2017 (UTC)

When question at issue is rail fans writing for rail fans, versus wikipedians writing for a general audience, inviting all the rail fans to look and take sides does sound to me like very non-neutral canvassing. Shouldn't he at least balance that with an invitation to the Guild of Copyeditors or some such project as well? Dicklyon (talk) 00:51, 28 January 2017 (UTC)

@Dicklyon: Sounds reasonable given the context. So go do that for him. ―Mandruss ☎ 01:13, 28 January 2017 (UTC)

Last time I tried to balance someone's canvassing that way they jumped all over me; I'll let someone else do it. Dicklyon (talk) 03:04, 28 January 2017 (UTC)

Done.[5] You'll note that I made the notice neutral, instead of doing my best to influence their thinking before they even got there, which I do consider more than a little unethical. ―Mandruss ☎ 03:20, 28 January 2017 (UTC)

Yes, very neutrally done. Hopefully none of this matters anyway. Dicklyon (talk) 04:23, 28 January 2017 (UTC)

Come to think of it, a neutral message is required per Wikipedia:Canvassing#Inappropriate notification, so that was in fact a clear violation of WP:CANVASS. In a just world that would disqualify any !votes from that project, if not earn the violator a block, but I've learned not to expect too much justice at en-wiki. ―Mandruss ☎ 04:42, 28 January 2017 (UTC)

You mean because he presents his argument in favor of no hyphen there? Or because his argument is a gross distortion (where he says "The point at issue seems to be whether we follow a grammatical guideline or the sources.")? Either way, yes, nothing like a neutral notification. Dicklyon (talk) 07:14, 28 January 2017 (UTC)

And part of an increasingly common pattern; any time someone with a specialized-style fixation has some issue with MOS, AT, or NC, they mass-canvass entire fora full of people they know are in about 90% agreement with them, using grossly non-neutral notices. Something has to be done about this. This would not have been tolerated even even three or four years ago, so it must be a factor of the dwindling administrative pool. See also Redrose64's directed and pointed canvassing of ANI action against Dicklyon in the same thread [6], and note that yet another frivolous ANI was filed against Dicklyon, about exactly the same matter, not long after [7]. This is WP:FACTION behavior at its worst.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:52, 29 January 2017 (UTC)

I think that's not quite fair. This railfan faction is unlike anything I've ever seen. Look at their responses on the open RMs about simple capitalization issues, where they seem to have dug in against guidelines for no particular reason, and just stonewall instead of making actual arguments. I don't recall ever running into such a thing before. At least with the astronomers wanting to cap their stuff, they had some sources on their side to talk about, and discussed the alternatives rationally to get their caps. This is new (to me) behavior. Dicklyon (talk) 18:54, 29 January 2017 (UTC)

I encounter it frequently in many topics. I needn't pick scabs by getting specific right now.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:32, 29 January 2017 (UTC)

Perhaps if you actually responded to the points people actually make instead of launching into personal attacks and characterisations of those people as fanboys or parts of factions you might find people responded to you better. If there is ongoing discussion about whether your rationale for moving a given article to another title is correct or not, it is not unreasonable to assume that applying the same rationale to other articles in the same topic area would also need discussion and so moving without discussion would be a bad idea. When you've been repeatedly and explicitly told that it is controversial and repeatedly reminded that all controversial and potentially controversial moves must be discussed first, to use a disputed (or even rejected) rationale to move other articles without discussion beggars belief. To then be astounded that anyone could object to your actions is way into the realms of WP:IDIDN'THEARTHAT and WP:FAITACCOMPLI. Thryduulf (talk) 22:49, 29 January 2017 (UTC)

What next?

Oddly, the 9:3 at Talk:Narrow_gauge_railways_in_Saxony was read as no consensus. So what now? Both move review and RFC have been suggested there. Is anyone up for writing a neutral case for one or the other? Dicklyon (talk) 23:16, 30 January 2017 (UTC)

See my draft at User:Dicklyon/rfc#RfC: Hyphen in titles of articles on railways of a narrow gauge. I invite anyone who wants to help make it a neutral question and productive discussion to make tweaks there, or make suggestions, or start your own alternative proposal. Thanks. Dicklyon (talk) 01:51, 2 February 2017 (UTC)

I've noticed recently (subjective) in move discussions on some articles that there is more participation thank you'd expect - and the penny has dropped that it's because we've added an invitation to participate on the facing side of the article. Which is great. But when in the case of the move affecting many articles including John Lewis (department store) and John Lewis Partnership, when the template is placed on one of the John Lewis articles enjoying a spike that's advertising the RM discussion to 160,000 readers on the spike. That is more significant the normal Alerts imbalance when a discussion is held at only one article rather than on the dab page Talk page. In ictu oculi (talk) 08:58, 11 February 2017 (UTC)

The initial request was malformed. I fixed it. Now a notice has been placed on Talk:John Lewis. wbm1058 (talk) 17:38, 12 February 2017 (UTC)

And after I changed it to a multi-move request, A notice was posted at the top of John Lewis. – wbm1058 (talk) 19:59, 12 February 2017 (UTC)

Yet again, Dicklyon's insatiable appetite for undiscussed page moves takes him to a whole new and unfamiliar field. Low probability of intercept radar has been moved to Low-probability-of-intercept radar. No prior discussion or notice of this.

As always, this is simple slavish pursuance of a minor styleguide footnote, against WP:COMMONNAME and WP:NEOLOGISM. This is an obscure term, even in radar, and I can see no prior use of the hyphenated form whatsoever. This move was inappropriate, obviously controversial in the recent contexts, and should have been discussed at the very least. It should be reverted. Andy Dingley (talk) 11:31, 1 February 2017 (UTC)

The article had the hyphens in the lead for almost 9 years already. Moving it to match seemed uncontroversial. The hyphens help the reader parse the complicated construct. That said, I see your point about it being rare in sources (which are invariably written for specialists), so I have no objection if you want to revert me there and fix the lead back to how it was punctuated before 2008. Dicklyon (talk) 18:44, 1 February 2017 (UTC)

ps. I've done about 100 undiscussed moves in the last 5 days. So maybe I'm maintaining my estimated 1% challenged. Is that OK? Dicklyon (talk) 19:07, 1 February 2017 (UTC)

pps. It's not actually an unfamiliar field for me. I've done a bit or work on LPI signals and radar, and audio (sonar) equivalents. Dicklyon (talk) 19:08, 1 February 2017 (UTC)

And here's a source using low-probability-of-intercept, low-probability-of-detection radar technology. Dicklyon (talk) 19:14, 1 February 2017 (UTC)

But not using it in the context of a title.

WP explicitly chose years ago to use as titles the same form we would link in sentences, to avoid the need to make extra redirects. I can't see why you'd want to leave the hyphens out in title context. What would that help? Dicklyon (talk) 21:22, 1 February 2017 (UTC)

Nor should you assume that because other editors cannot keep up with your rate of moves that they are happy with them, rarely than simply not having your persistence. Andy Dingley (talk) 20:11, 1 February 2017 (UTC)

Well, sure. Most of these were dashes between person names in house names, where my help in doing a big job was explicitly acknowledged and praised, so don't make like I'm doing anything controversial here please. Dicklyon (talk) 21:22, 1 February 2017 (UTC)

Take a look at my move log, and see that I put hyphens into the titles of a few other articles with "low" and "narrow" in their names, while I was collecting examples of hyphenated article titles. I didn't notice any with "high", "broad", "short", "small", "large", or "wide" that were missing hyphens, but then I wasn't looking hard for those and there may be a few. I also took the hyphen out of one, and started a discussion to do so on another, where the compounds were not adjective-before-noun form. No rush reviewing or fixing the rest; more eyes are always helpful. Dicklyon (talk) 21:36, 1 February 2017 (UTC)

100 moves in 5 days is far too many for you to have actually looked at the relevant sources in each case, review any past move proposals (and understand why they reached the conclusion they did) for the article in question or generally in the topic area (especially as you are making other edits and presumably doing things like eating and sleeping as well) and far too many for other people to check your work. The error rate is essentially irrelevant - it's the combination of the absolute number of edits you make that need to be verified, the time period you make them in, and the absolute number of errors you make while doing so. Slow down. Thryduulf (talk) 13:38, 3 February 2017 (UTC)

I support someone reverting every single one of Dicklyon's unilateral moves that involve case changes or dashing changes for the following reason: "undiscussed controversial move". --В²C ☎ 07:25, 16 February 2017 (UTC)

I just boldly removed an endorsement of "Google Books and Google News Archive" from the wording of the page. I don't know when it was added or by whom, but in my experience when there are such poorly thought out and counter-policy statements of "advice" in these pages, they were unilaterally added without proper discussion or consensus, and so I assumed the same was true here. Not everything in Google Books and Google News Archive is a reliable source -- in fact most are not. And explicitly telling users to prioritize these over more reliable searches like adding "site:.edu", "site:.ac.jp", etc. is highly inappropriate. If anyone doesn't like my edit, it should be discussed here and preferably some link to the discussion that led to the previous discussion given. Hijiri 88 (聖やや) 00:02, 8 February 2017 (UTC)

Just checked, and it was apparently added unilaterally by a good-faith user who wanted to prevent people from prioritizing blank Google hits. I doubt anyone even noticed, since the subpage in question is on the watchlists of fewer than 30 editors. It seems like a problem when we have authoritative guidelines that are located within subpages that almost no one is monitoring -- has this ever come up before? Hijiri 88 (聖やや) 00:12, 8 February 2017 (UTC)

It turns out I brought this up last year but forgot about it. A couple of other editors agreed that it should be removed, with one claiming that it had been stable for three and a half years but missing the point that it had probably been added to the subpage with no one noticing. Hijiri 88 (聖やや) 00:24, 8 February 2017 (UTC)

I wanted to check if it had ever been discussed. It was added in August 2012, so it should have been discussed either shortly before that (in Archive 23) or since that (in Archives 24 through 29). Searching for "Google" in these pages is helpful as no consensus for the pre-today wording could have been formed without using this word. The current page uses "Google" only in my above comments. Archive 29 doesn't use it at all. In Archive 28 there are two instances of the word in comments by two users, none in discussion of the advice's wordin, and in the above-linked discussion initiated by me where the wording was unanimously opposed. In Archive 27 it appears four times in comments by three users, none in discussion of the advice's wording. In Archive 26 it appears eight times in comments by six users, none in discussion of the advice's wording. The advice's wording saw several challenges (although one was apparently not about the concerns in question) in Archive 25, which can be seen here and here. In Archive 24 it appears once, not in discussion of the advice's wording. In Archive 23 it appears ten times in comments by four users, none in discussion of the advice's wording. I have not read through the November 2013 discussion yet, but I doubt it resulted in a clear consensus in favour of the wording before my edit. Hijiri 88 (聖やや) 00:48, 8 February 2017 (UTC)

Pinging Fuhghettaboutit who added that text. I've always found it useful in that a Google Books/Scholar search is always more useful than a raw Google search but I can see where you're coming from. Jenks24 (talk) 08:48, 10 February 2017 (UTC)

@Jenks24: a Google Books/Scholar search is always more useful than a raw Google search That's simply not true. "a raw Google search" can include qualifying parameters like "site:.edu". And Google is not the only search engine. This page is not the place to discuss the nuances of this -- the instructions can not and should not be giving an unnuanced "do X, don't do Y". Hijiri 88 (聖やや) 22:17, 17 February 2017 (UTC)

I would not consider using qualifying parameters to be a raw search. Very few editors do more than use quotation marks to get an exact phrase and maybe use "-llc" in Gbooks. Getting these editors to use a books/scholar search rather than a basic web search is a good thing. It might be ingrained enough in RM culture now that we don't need explicit instruction though. Jenks24 (talk) 22:31, 17 February 2017 (UTC)

Well, we will have to agree to disagree on that point. I took the previous wording to be saying that GBooks was better than adding qualifying parameters to a raw search, despite the fact that a great number of, if not most, books are "bullshit". My amended wording addresses both of our concerns by telling users to prioritize reliable source searches. Hijiri 88 (聖やや) 23:23, 17 February 2017 (UTC)

I didn't know that was there, either, but it is indeed good and useful advice, along the lines of what I usually do. Web search finds mostly junk, while book, news, and scholar search find mostly reliable sources. Dicklyon (talk) 00:33, 18 February 2017 (UTC)

@Dicklyon: Like I said to User:Jenks24 above, if you could talk about the text before and after my amendment, rather than the text before my amendment as compared to a hypothetical text that encourages either implicitly or explicitly bare web searches, it would be appreciated. There's no point talking about removing all mention of how web search-based rationales should be structured, since no one is seriously proposing that. Hijiri 88 (聖やや) 00:47, 18 February 2017 (UTC)

Right, didn't read all that. But see my edits that put back some book/news/scholar hint parenthetically, building on your edit (or backtracking some from it?). Dicklyon (talk) 00:49, 18 February 2017 (UTC)

@Dicklyon: Your edits are good. But I do think we should cut it off there. There's a slippery slope from saying "reliable sources" (which is okay) to "reliable sources (e.g., books, etc.)" (which is probably better) to removing "reliable" and the parentheses altogether. Honestly this was the worst part about the wording before my edit: it assumed that "Google Books" and "Google News Archive" searches were, in and of themselves, superior to bare searches, because if it's in a book it must be reliable or noteworthy. I'd be willing to bet a lot of editors aren't aware that GBooks includes compilations of Wikipedia articles -- all searches need to be nuanced, regardless of which search engine or search engine tool they use.

BTW: Until last week I wasn't aware that this was a problem, and didn't realize the scope of the problem and the potential for abuse until a few hours ago. I'd appreciate any input you could offer.

Hijiri 88 (聖やや) 01:15, 18 February 2017 (UTC)

Agree all around. That's a horrible loophole for abuse, and I've seen it happen. Dicklyon (talk) 01:24, 18 February 2017 (UTC)

@Dicklyon: Could you tell me where? Regardless of whether either of my proposals is objectively feasible, my proposals tend to fail if I can't point to multiple examples of instances where they could have prevented disruption, and right now I've only got one and a half. Hijiri 88 (聖やや) 10:35, 18 February 2017 (UTC)

It has been a long time, but I think it was transclusion on WP:AT that hid a bunch of rewrite from watchers. Dicklyon (talk) 16:00, 18 February 2017 (UTC)

Template:RMassist must be used on Wikipedia:Requested moves/Technical requests. Thank you, Scynthian (talk) 07:09, 16 February 2017 (UTC)

You need to make a move request as described at Wikipedia:Requested moves#Requesting controversial and potentially controversial moves. Doug Weller talk 09:24, 16 February 2017 (UTC)

Great, now there's a successfully filed request at Talk:British-Israel-World Federation. wbm1058 (talk) 15:03, 16 February 2017 (UTC)

Someone mangled it; I fixed it back (and opposed). Dicklyon (talk) 18:56, 19 February 2017 (UTC)

Or perhaps I mangled it further. The hyphenation has been fixed, and the hyphenation in the proposal was still wrong, but it was about adding "The", so I fixed it further. Dicklyon (talk) 19:05, 19 February 2017 (UTC)

Huh. It looks to me here that User:Piko 158, a new user and not an admin, deleted a page. How's that possible? Maybe I'm reading this wrong? It was a redirect page, but even if she's a Wikipedia:Page mover, that doesn't allow one to delete redirects, I don't think.

I ask because up to now if I find a redirect blocking a move I have to file a Requested Move (uncontested) which is an extra step. Is there an ability for civilians to delete redirect? Or am I misunderstanding what happened here? Herostratus (talk) 22:18, 23 February 2017 (UTC)

This is a side-effect of moving a page over a redirect. You don't need to file an RMT request if the redirect blocking the move has only a single edit in its history (and it is a redirect to the article being moved). There's info at WP:MOR. – Uanfala (talk) 22:29, 23 February 2017 (UTC)

Autoconfirmed users have always been able to do this; you don't even need to be a WP:page mover. But the appearance of these moves over redirects in deletion logs is new behavior since August 2016. See the phabricator "Moving a page over the redirect leaves an abandoned row in the revision table" and the code review – When moving over a redirect with no revs, there was a weird hack to delete the old redirect page... without logs, or cleaning up the orphaned revision. WHOOPS Switched it to using the standard deletion, which seems to work. Note this will produce a deletion log entry as well as a move log entry. This may scare people.

Thanks for pointing this out. I hadn't noticed that change before. wbm1058 (talk) 22:55, 23 February 2017 (UTC)

Huh, OK, thanks guys. Herostratus (talk) 07:22, 24 February 2017 (UTC)

I am concerned that user:Domdeparis appears to be systematically moving articles "House of..." to "...Family". I left a message on user:Domdeparis talk page:

Since I wrote this I have reverted a move of the House of Arenberg to Arenberg family. user:Domdeparis made the move with the comment 'In English"House of" is reserved for Royal dynasties see House of' (diff).

I think that user:Domdeparis may have a coherent argument for English and by extension British and Irish Nobility, but it needs to be discussed further to see if the assertion is true. If it is then general moves may be in order—although I suspect that articles such as those on the families of the Princes of Wales prior to conquest and those in Ireland before the introduction of the title King of Ireland may contain exceptions.

There is a further problem moving article from "House of ..." to "... family" causes practical problems with people including links to articles to people of the same name only vaguely related to the Noble Family for example how many Spencers are there? This issue also needs considering if article such as "House of Percy" is to be moved to "Percy family".

While argument for the systematic move of English nobility may (or may not) be accepted. There is no systematic rule for Continental European aristocracy.

For Continental European article on aristocratic families, I think that for most WP:RM#CM are needed, because in most of Europe the rules are more complicated and many of the sources that are used for such articles use "House of ..." (if only because like that for the House of Arenberg rely on Non-British sources and use "House of").

This is because there is a more complex relationship between entities such as the Holy Roman Emperor and other noble families who often held their lands to all intense and purposes as sovereign entities and had legal differentiation from non-aristocratic families (Ie formed a noble class), and the titular head of a state was not necessarily an inherited position (in law if not in practice).

See for example the relationship between Sigismund III Vasa and the other families in Polish–Lithuanian Commonwealth. This is also true for other families better known to the British public see for example House of Nassau. Where the article explains in the introduction:

The lords of Nassau were originally titled "Count of Nassau", then elevated to the princely class as "Princely Counts" (in German: gefürstete Grafen, i.e. Counts who are granted all legal and aristocratic privileges of a Prince).

So in summary. I think moving most British "House of ..." articles can probably be decided with one well discussed WP:RM#CM or WP:RFC as an example case to set a president on how to handle all of them. However for articles on European continental aristocracy families, because of the use in sources that are cited and the legal complications of their precise status, any such move should be done through WP:RM#CM, as deciding on the best name for the article is complex and potentially controversial.

-- PBS (talk) 10:20, 11 March 2017 (UTC)

The pages that were moved or propose that they were moved):

-- PBS (talk) 22:08, 12 March 2017 (UTC)

I am posting below my discussion originally at: this version of Talk:House_of_Visconti. Peaceray (talk) 05:25, 13 March 2017 (UTC)

House of may be reserved for royal families in England/Britain/UK, but I am unaware of any such limitation elsewhere. House of redirects to Dynasty, which states

“

The dynastic family or lineage may be known as a "house";[House of 1] which may be styled "royal", "princely", "comital", etc., depending upon the chief or present title borne by its members.

”

wiktionary:dynast has this definition:

“

1. A ruler or governor, especially a hereditary ruler or someone who founded or is part of a dynasty.

”

Comital refers to Count. The Count article states:

“

Count (male) or countess (female) is a title in European countries for a noble of varying status, but historically deemed to convey an approximate rank intermediate between the highest and lowest titles of nobility.[House of 2]

”

The Count article goes on to state:

“

In Italy The title of Conte is very prolific on the peninsula. In the eleventh century, conti like the Count of Savoy or the Norman Count of Apulia, were virtually sovereign lords of broad territories. Even apparently "lower"-sounding titles, like Viscount, could describe powerful dynasts, such as the House of Visconti which ruled a major city such as Milan.

”

Visconti or vicecomes in the Italian context means viscount. I have no doubt that the Visconti used it both in terms of being imperial vicars & in the context of signorie. The fact that they didn't have a pedigree before conquering Milan is inconsequential, as there are plenty of dynasties whose founders attained power by force and having enough wealth to raise armies. Even though they began without pedigree (although Giangaleazzo claimed to be descended from Aeneas!^{[House of 3]}), they were able to marry female descendants into the royal families of England, France, Cyprus, & the House of Wittelsbach, & had kings of England & France among their descendants. Giangaleazzo himself was able to obtain the title of Duke, which subsequently became hereditary.

For comparison, consider the House of Medici. Also consider that the House of Visconti has been included in {{Royal houses of Europe}}.

I think that based upon what I have written here, the case for continuing to call the Visconti dynasty the House of Visconti has been well established.

Peaceray (talk) 18:01, 9 March 2017 (UTC)

Addendum

Two things, one for a move & one against:

• Most other language Wikipedia article names for House of Visconti translate to "Visconti" or "Visconti family"
• In English, however, it seems common to favor "House of" for lesser continental houses, particularly when royalty was later descended from those "houses". For example, please see this Google search:
  • "house of visconti" -wiki -site:wikipedia.org - Google Search:
  • As a further example this book refers to the Ducal house of Visconti.

Alternately, we could eliminate all "House of" articles by moving them to the appropriate family, e.g., Windsor family, Hanover family, Tudor family. It would serve those English Royalists right, since they snobbishly try to exclude everybody else. [Oh dear, are my republican, anti-royalist sentiments showing through? ;-) ]

Peaceray (talk) 05:48, 13 March 2017 (UTC)

The only thing that matters is WP:COMMONNAME. There is absolutely no guarantee of consistency in such matters, and especially no obligation for Wikipedia to hew to some ridiculous "only royal houses are deemed "House of" rule. If this means we have House of Percy and Kennedy family, so be it. So... I'd be strongly in favor of cautioning Domdeparis to slow down and file RMs based on that particular family, and not attempt to assert any kind of nonexistent principle about which groups are referred to as "House of" and which are referred to as "family." SnowFire (talk) 23:43, 13 March 2017 (UTC)

Hi @SnowFire: if you want to "caution" me please feel free to do so but I believe that I am just being bold. I am as @Peaceray: puts it an English Royalist (maybe snobbish) and a descendant of some of these "Houses" and I have never heard anyone use the term "House of" when referring to the families. The tendency to use house of is supremely snobbish putting noble families on the same level as royal families. Regardless of what I think if you wish to keep House of so be it, it will make me cringe when I read it but there are worse things in life. For me the WP:COMMONNAME for royal families is house and other noble families "family" but if you don't agree I certainly won't lose any sleep over it. Domdeparis (talk) 16:05, 20 March 2017 (UTC)

@Domdeparis: Regarding WP:COMMONNAME:

• "House of" has been used for non-Royal Continental families for centuries. For instance, I would call your attention to the following:
  • Anderson, James (1732). Royal Genealogies, Or the Genealogical Tables of Emperors, Kings and Princes. London, Great Britain: Bettenham. OCLC 367947400.

Table CCCCX is entitled The Lords and Dukes of Milan of the House of Visconti, so "House of Visconti" was in use at that time in British texts. Also, I think that royal families tended to use the "House of" nomenclature for ancestors from lessor noble continental families. For instance, I suspect that the House of Lancaster would have said that Henry VI of England was descended from the House of Visconti, even though his great, great grandfather, Bernabò Visconti, seemed content to hold the lowly title of Lord of Milan as long as he had the power & wealth associated with it.

• MacMillanDictionary.com gives this synonym for Members of royal families and the nobility:

house (noun) - an old important family, especially a royal one (especially does not mean exclusively)

• The Library of Congress Subject Headings Manual for "H 1574 Dynasties, Royal Houses, etc" (PDF). gives an example for the "House of Medici", again not a royal house.

Peaceray (talk) 18:27, 20 March 2017 (UTC)

• Comment -- It may be useful to have articles bringing together all the UK peerages held by a given family, where they are numerous - e.g. Neville, Percy, Howard, but this should not be allowed to spread widely, as the list article on each peerage is probably as much as we need. Peterkingiron (talk) 16:34, 26 March 2017 (UTC)

Could someone help with the mass move of pages here? The discussion was closed but the decider didn't move the pages. MCMLXXXIX 16:42, 19 February 2017 (UTC)

Done. JFG, in future if you don't have the time to move all the pages listed at a multi-move RM I would suggest leaving it for someone who does rather than closing it and taking it out of the listing. Jenks24 (talk) 06:09, 20 February 2017 (UTC)

@Jenks24: Many thanks for your help. I did another large multi-move and got sidetracked IRL before completing this one (still got a browser window open for that!) Sorry for the inconvenience, I owe you a cookie! — JFG ^talk 07:46, 20 February 2017 (UTC)

Ah, no worries. Jenks24 (talk) 08:41, 20 February 2017 (UTC)

I always do the moves first and closure second, cleanup third unless particularly urgent (can't offhand think of an example of "urgent" but I know I've found some over the years), figuring that if I get called to glory or otherwise interrupted (I do have some higher priorities than Wikipedia, including but not only wine, women and song) in the middle that leaves the more transparent mess. The bot and macros seem written on this assumption too. Interested in other practices and rationales. Andrewa (talk) 04:55, 29 March 2017 (UTC)

• Oh, the chaos that could happen if JFG & Andrewa started on the same RM at the same time. Maybe Template:Closing. --SmokeyJoe (talk) 05:01, 29 March 2017 (UTC)

Lol, yeah, that could be fun… especially if it's about New York — JFG ^talk 12:41, 29 March 2017 (UTC)

In the interest of raising the bar on the usefulness of RM commenting, how about bringing attention to some of the best ones you see out there?

Just quote the comment and include a link to it.

I'll start... --В²C ☎ 02:49, 22 February 2017 (UTC)

---

• * Oppose. First, on reading policy, if two names are used just as often, we use the name without the middle initial for reasons of concision (as linked & mentioned above) in addition to the other prongs of the naming criteria (article titles policy). Second, I actually find that the middle initial is used far more often in book and academic paper titles. This said, he is even better known as just "Rothbard" but that doesn't mean we change the title to that. "Murray Rothbard" is sufficient for the article title naming criteria: the most recognizable (the name most people will call it), natural (reflecting what it's usually called), precise (unambiguously identified), and concise (not longer than necessary to identify). czar 02:37, 20 February 2017 (UTC) [8].

You just love concision. But it's not clear what he means there by "I actually find that the middle initial is used far more often in book and academic paper titles." What is he comparing, and if he means the initial is more common, why not go with recognizability/commonname and use it? Dicklyon (talk) 03:27, 22 February 2017 (UTC)

I can't prevent this from happening, but I seriously question the value of it. Each participant will choose comments that tend to align with that participant's views on various situations. What's the benefit to this activity? Omnedon (talk) 03:35, 22 February 2017 (UTC)

• Templated linking to standard statements would create a barrier to newcomers knowing what is going on and how to join in, and would involve a decrease in actual thinking. It would decrease the value of RM commenting. No, comments should be written in simple personal English, appropriate to the specific example, just like you speak if sitting around a table human speaking to human. If repeated cases are essentially identical, it calls for writing a guideline. --SmokeyJoe (talk) 04:02, 22 February 2017 (UTC)

What I liked about the particular example I gave was the methodical reliance on WP:CRITERIA. Anyway, this wasn't mean to showcase opinions we agree with, but well-made useful arguments in RM discussions. --В²C ☎ 16:30, 22 February 2017 (UTC)

And my point was that while he referenced the criteria, I was not able to quite understand the point of part of what he said about "used for more often in books..."; it sounded contradictory to his conclusion to go with the most concise. Dicklyon (talk) 16:45, 22 February 2017 (UTC)

---

My all-time favourite move request was Queen Anne of Romania, shortly after she died, closed by yours truly with this rationale:

The result of the move request was: Not moved. OP and supporters argue that the title is a misnomer because the subject was never legally a queen. Dissenters argue that she was nevertheless called Queen for 60+ years of her life while married to the former king, therefore making this her WP:COMMONNAME. Most of the recent RS covering her death still call her Queen Anne. Our titling policy explicitly assigns stronger weight to dominant names in usage, rather than official names. Wikipedia is also not the place to Right Great Wrongs. The policy debate started by this case, while ongoing, is trending towards supporting the common name rationale. Finally, the policy-supported title happens to be the same as the longstanding article title, so this adds some extra weight to keeping things stable. If the longstanding title were contrary to general policy, things would be more difficult to adjudicate (see the recent discussion about New York). Note that this closure is neutral about the best way to write the subject's names in the lead and to explain her queenship or lack thereof. — JFG ^talk 05:50, 16 August 2016 (UTC)

Move supporters argued that she never was a queen, to which opponents said she was always called a queen, with both sides perceived as trying to right great wrongs. One editor raised a delightful parallel with Emperor Norton. Endorsed at move review. — JFG ^talk 12:54, 29 March 2017 (UTC)

There is discussion of a possible change of the article title Liancourt Rocks, a disputed island. Discussion here Siuenti (talk) 14:55, 2 April 2017 (UTC)

I think the section "Wikidata update" could use an update. I don't see leftmost, center and rightmost fields – but rather, top, center, and bottom fields (which are respectively labelled "Label:", "Description:" and "Aliases:"). I believe I figured it out, but perhaps someone could check this and update if necessary. (I apologize if it's my browser displaying the page oddly.) – Reidgreg (talk) 14:17, 8 April 2017 (UTC)

The Wikidata editor interface is not the most intuitive. I tried to update a page I recently moved, but after fumbling around with it I gave up. Just checked in on that and I see that someone else (possibly a bot?) took care of it for me. I view updating Wikidata as totally optional, as that's another project. wbm1058 (talk) 14:56, 9 April 2017 (UTC)

Per the gap in the bot's repertoire pointed out at Talk:Pence (disambiguation), I have updated RMCD bot to post notices of requested moves where the new page proposed for moving to redirects to a different page that the page that is proposed for moving, and that redirect does not have a talk page. As a result of this enhancement new notices were just posted on the following eight pages:

• Talk:Jacqueline Kennedy Onassis ‎ (Notifying of move discussion on Talk:Jackie O (radio host))
• Talk:Ministry of Communications ‎ (Notifying of move discussion on Talk:Ministry of Communications and Information Technology (India))
• Talk:List of typefaces ‎ (Notifying of move discussion on Talk:Samples of monospaced typefaces)
• Talk:Penny ‎ (Notifying of move discussion on Talk:Pence (disambiguation))
• Talk:Divisibility rule ‎ (Notifying of move discussion on Talk:Divisibility (ring theory))
• Talk:Award ‎ (Notifying of move discussion on Talk:GMMSF Box-Office Entertainment Awards)
• Talk:List of Inazuma Eleven episodes ‎ (Notifying of move discussion on Talk:List of Inazuma Eleven GO)
• Wikipedia talk:Userboxes/Location/European Union ‎ (Notifying of move discussion on Wikipedia talk:Userboxes/Location/European Union/United Kingdom)

— wbm1058 (talk) 15:12, 9 April 2017 (UTC)

Can any-body check whether User:Andy M. Wang/closeRM.js is functioning as desired.In my case it prompts me to enter my reason for the close, but only adds an edit summary with the entered reason rather than inserting the close templates etc. Posting it here because the script dev. is highly infrequent on en.wiki.Please ping while replying back.Thanks! Winged Blades ^Godric 11:26, 26 April 2017 (UTC)

• Pinging Yashovardhan Dhanania.

I close manually so I can't be of much use on this script, but I did a test of pageswap to see if any issues you might be having affected it. It seems to be functioning fine. TonyBallioni (talk) 16:16, 26 April 2017 (UTC)

Thanks for the ping. It's working fine for me too. Let's see if someone else shares your problem. Yashovardhan (talk) 16:19, 26 April 2017 (UTC)

The backlog is nearly empty. Does this mean RM is working lick clockwork? Or is a backlog problem being hidden by the inane pointless relisting? What is the benefit of relisting old discussions? I like to review only the old discussions, as I prefer to see what the article-interested people have to say first. People who like to review RMs from the top will have already seen the RM listed. Relisting is a near-silent edit to article-watchers, so what is the point? If there is a point to relisting, is there a way to introduce a way to navigate to relisted RMs from Wikipedia:Requested_moves#Backlog? --SmokeyJoe (talk) 03:52, 1 May 2017 (UTC)

Relisting has the advantage of getting new eyes on a conversation. I tend to be more liberal on moving if no objections have been raised, but will relist some things such as transliterations that tend to get closers flack. I also feel that multi-page moves in general should have at least one comment before a move. My philosophy on using user rights is that being conservative is better in any case where there might be controversy. That being said, I think there is a bias to relisting for no reason and have no problem personally closing relisted RMs before the next 7 days, which is allowed by the policy. I also think closers should feel more comfortable closing as no consensus. If a full conversation has taken place, a closer should use their judgement to determine whether or not a relist is likely to generate a clearer consensus. If the answer is no, then a relist shouldn't be done. TonyBallioni (talk) 03:57, 1 May 2017 (UTC)

If "allowed by the policy" is the only reason for doing something, then how about don't do it. Doing nothing is allowed by policy. I would prefer discussions to be left for seven days following the last substantive comment. See if the weekend editors have a response. Leave it open, unrelisted, in the backlog for seven days, especially in preference to a non-admin "no consensus" close.

Is there any evidence for "getting new eyes"? I think I just explained why it doesn't work. My observations are that it doesn't work.

Didn't someone once create a page that listed all relisted RMs? The backlog section could link to it? --SmokeyJoe (talk) 04:04, 1 May 2017 (UTC)

A good relist includes a relisting comment that attempts to refocus the discussion, or draws attention to a new important point, or a point about policy that participants may have missed. --SmokeyJoe (talk) 04:06, 1 May 2017 (UTC)

I think that relisting does normally add a few comments. A lot of the RMs I close have a clear pattern of comments in the 24 hours after relisting followed by no comments for the rest of the seven days, and there are many discussions in the backlog I check for several days in a row that get absolutely no comments.

I think no consensus after a full discussion is a better outcome than relisting, which rarely changes things if a substantive discussion has taken place. It takes the concerns of the reader into mind: a RM tag on place for a month because of three relists is not good for a highly visible article, and those are the ones that tend to have long substantive discussions take place within the listing period. A potentially controversial move with limited comments that disagree is a different matter, and I think is a strong case for staying open longer.

I think a page listing all relisted discussions would be good. It would allow the regulars who want to comment on those listings find them easier than CTRL+F. TonyBallioni (talk) 04:20, 1 May 2017 (UTC)

Use CTRL+F "Relisting" on the WP:RM page itself? Never thought of that. Tried it. No. The proposer's text is not appreciated. I much prefer the Wikipedia:Dashboard/Requested moves' one line per discussion "Current → Proposed – (Discuss)" style. I wish for them all in this style, sorted by the original date of the proposal, ignoring relist dates. Much like User:Snotbot/Current AfD's, only default sorted by "Time open". --SmokeyJoe (talk) 06:29, 1 May 2017 (UTC)

This is a follow-up to the earlier discussions at Wikipedia talk:Requested moves/Archive 29#No backlog! Did someone close them all? and Wikipedia talk:Requested moves/Archive 28#Alternate List Views Available. The consensus still appears to be for the current relisting conventions. One possibility is to expand the "elapsed listings" window to be longer than 24 hours. That would be easy for me to do. I could also create an alternate version of Wikipedia:Dashboard/Requested moves, Wikipedia:Dashboard/Requested moves (alt), that listed everything by the original date and replaced the "elapsed" and "backlog" sections with an "originally listed more than 7 days ago" section. Editors preferring this format would be able to link to or transclude this page as desired, on their user pages, for example. This is doable, but somewhat more work for me to implement. wbm1058 (talk) 16:47, 2 May 2017 (UTC)

I don't know how much work that is, or how many would make use of it, but I for one would appreciate it. When attempting to clear backlogs, it is well regarded as a good idea that at least some people work at the end of the list. I suspect that a link to a chronological listing of the backlog from Wikipedia:Requested_moves#Backlog might lead to it being well used. --SmokeyJoe (talk) 00:19, 3 May 2017 (UTC)

I've taken a step forward towards this. The report now shows how many discussions have been relisted, and indicates in the bulleted column of (Discuss) links which ones. The bot looks for --'''''Relisting.''''' embedded in the rationales, to distinguish actual relists from someone who happened to use the word "relist" in describing their rationale. So any relisting that does not conform to this syntax will be considered malformed so that item won't sort correctly in any reports I may produce that are sorted by the original request date. As long as everyone uses {{Relisting}} for that, and doesn't override its default, and nobody changes that template without checking with the bot operator first, we'll be fine. I'm open to suggestions for tweaking this. wbm1058 (talk) 18:30, 3 May 2017 (UTC)

What report? --SmokeyJoe (talk) 23:37, 3 May 2017 (UTC) Is Wikipedia:Dashboard/Requested_moves a report? I don't think I can search for underscored "scu"s, and scanning by eye is not pleasant. Is there a trick for showing every collapsed box at once? --SmokeyJoe (talk) 23:50, 3 May 2017 (UTC)

Would it be better instead of underlining the 3 letters change the link text from "Discuss" to something like "Relisting", "Relisted discussion"? Or even something like "Discuss x2", and x3 if something some how gets relisted an additional time, perhaps from a move review etc. As it is the difference is rather subtle. PaleAqua (talk) 00:09, 4 May 2017 (UTC)

I mean the Wikipedia:Requested moves/Current discussions report. Right, my intention is for this to be subtle, as there is limited demand for this in the main report. Bear with me, I'm just laying some groundwork – more to come. wbm1058 (talk) 02:55, 4 May 2017 (UTC)

OK, check out Wikipedia:Requested moves/Current discussions/Table and let me know if that works for you. Thanks, wbm1058 (talk) 22:54, 4 May 2017 (UTC)

It is great, thank you. It will certainly work for me. As a matter of preference, I might have preferred "days open" over "original list date". --SmokeyJoe (talk) 04:30, 5 May 2017 (UTC)

 Done. Great. Thanks SmokeyJoe. I added the "days open" column and page headings, and tidied it up. – wbm1058 (talk) 15:30, 5 May 2017 (UTC)

This edit request to Wikipedia:RM has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Can an admin please replace the text of the redirect with the following?

#REDIRECT [[Wikipedia:Requested moves]]

{{Redirect category shell|
{{R from shortcut}}
{{R to project namespace}}
}}

The Redr template alias is to be replaced with Redirect category shell. GeoffreyT2000 (talk) 00:33, 9 May 2017 (UTC)

Done. Thanks, wbm1058 (talk) 01:16, 9 May 2017 (UTC)

"The debate is not a vote; please do not make recommendations on the course of action to be taken that are not sustained by arguments."

Could I get clarification on this? What is the thinking behind this statement?

Does this mean I should not say "Support" or "Oppose" unless I can add further argument? (What if I agree with previous arguments made and simply want to concur?) Or is this policy just there to tell editors that their opinions are not sufficient justification for a recommendation?

—A L T E R C A R I  ✍ 16:36, 11 May 2017 (UTC)

It seems like a reference to the WP:Vote essay. If you agree with previous arguments made and want to concur without adding any further rationale(s), fine, state the previously stated argument(s) that you agree with. wbm1058 (talk) 19:01, 11 May 2017 (UTC)

Thank you! —A L T E R C A R I  ✍ 21:47, 11 May 2017 (UTC)

WP:RMUM ("Undiscussed moves" section) says:

Anyone can be bold and move a page without discussing it first and gaining an explicit consensus on the talk page. If you disagree with the move... you may revert the move... Move wars are disruptive, so if you make a bold move and it is reverted, do not make the move again. Instead, follow the procedures laid out in § Requesting controversial and potentially controversial moves.

which strongly indicates that WP:BOLD applies to moves. But below at WP:RM#CM (the "Requesting controversial and potentially controversial moves" section) it says:

The discussion process is used for potentially controversial moves. The move is potentially controversial if... Someone could reasonably disagree with the move

Well so which is it? I can see the argument for not generally encouraging bold moves of pages, since they're harder to undo than regular edits. I can see the other way too.

But can we we can get clear guidance one way or the other?

There is a big brouhaha at ANI right now over disagreement over this very matter, and I have seen others.Herostratus (talk) 17:08, 8 May 2017 (UTC)

(It doesn't help that WP:RMUM is poorly stated and a bit confusing. "Anyone can be bold and move a page without discussing it first and gaining an explicit consensus on the talk page. If you consider such a move to be controversial... you may revert the move" means "if someone makes a move and even if you agree with it but you suspect other people might not ("if you consider such a move to be controversial") you "may" roll it back, which is distinctly odd advice.) (Nevermind, this issue fixed with what I believe is a simple correction.) Herostratus (talk) 19:34, 8 May 2017 (UTC)

Herostratus, thanks for raising this issue. The "Undiscussed moves" section was added by PBS with 3 August 2014 edit. Along with that, this related change was made. A notice was posted on this page at the time, but it did not draw much comment. I don't recall that I paid much attention to this before. But now that you point this out, regarding "Anyone can be bold and move a page without discussing it first", no. This is not right. Nobody should be bold and move Hillary Clinton or New York without discussing it first. We need to fix this. wbm1058 (talk) 19:16, 8 May 2017 (UTC)

Yes that's a good point. Herostratus (talk) 19:41, 8 May 2017 (UTC)

Those examples are the 20% of moves which are or may be problematic. Other moves, bringing page names into alignment with our article title policy, naming convention guidelines, and style guideline, are the 80% move case and are usually uncontroversial. Moves are fixable also (though with some effort). No, I don't see this as a problem, especially with other guidance move-related guidance already-present on this page of "hey, don't be dumb" (though not in juxtaposition). --Izno (talk) 19:56, 8 May 2017 (UTC)

The problem is that the other guidance is further down the page, and is, as Herostratus says, contradictory. After reading "anyone can be bold and move a page without discussing it first" someone might quit reading the rest of the page and start pushing the buttons.

Anyone can be bold and move a page without discussing it first and gaining an explicit consensus on the talk page if:

• There is not an existing article at the target title;
• There has not been any past debate about the best title for the page;
• Noone could reasonably disagree with the move.

Editors should be checking these off before they make bold moves. It's OK to occasionally find someone reasonably disagreeing with a bold move, but editors consistently finding others reverting their bold moves should at the least be warned. wbm1058 (talk) 20:56, 8 May 2017 (UTC)

• The guidance is not contradictory... it is quite simple:

1. If your initial assessment is that a move would be non-controversial, you do not need to discuss... you may be bold... go ahead and move (that is what the move button is for after all). However, be willing to accept that your initial assessment may be incorrect, and the move may turn out to controversial after all. No problem... shift to discussion.
2. If, on the other hand, your initial assessment is that the move will indeed be controversial... don't be bold... start off with discussion. Blueboar (talk) 21:49, 8 May 2017 (UTC)

——————

That's how I would interpret it too Blueboar, but it could be clearer. I propose adding the following highlighted clause to RMUM for clarity: "Anyone who has no reason to believe a particular title change might be controversial can be bold and move a page without discussing it first..." --В²C ☎ 22:53, 8 May 2017 (UTC)

"No reason to believe"? The wikilawyers will have a field day arguing about whether you should have had a "reason" or not... I would simplify and just say "Anyone who believes a particular title change will be non-controversial can be bold ... (etc)." Then have a caveat about what to do if the change turns out to be controversial after all. Blueboar (talk) 23:41, 8 May 2017 (UTC)

Yeah, but what about people who would game that wording: "I believed the move would be non-controversial". You can't argue with what someone says they believed. What about: "In obviously non-controversial cases anyone can be bold and move the page without discussing it first..."? I suggest removing the bold clause because this is not really being bold (if it's non-controversial as it should be). --В²C ☎ 00:07, 9 May 2017 (UTC)

If someone says "I thought it was non-controversial" just tell them "Well, you thought wrong... it is controversial. But that's OK... we all make mistakes." No one can "game the system" by making a bold move, or by saying "I thought it non-controversial", because as soon as someone else reverts the move, it becomes controversial (by definition). So... assume good faith... assume the editor really didn't think that his bold move would be controversial (It just turned out that he was wrong in thinking that. No harm). Blueboar (talk) 00:50, 9 May 2017 (UTC)

If only it were that simple. How many times do you tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert, tell them and revert...? See Wikipedia:Administrators'_noticeboard/Incidents#Pattern_of_making_controversial_title_changes_without_RM_or_discussion_by_user_In_ictu_oculi. --В²C ☎ 01:52, 9 May 2017 (UTC)

I don't think we need to write new guidance, per se. It's all there, but just not in the right place. If you didn't notice what I did, I just lifted the three bullet items from the guidance given lower on the page, and changed them from positive to negative statements by adding nots and changing "someone" to "noone". So by the time the reader gets to the lower section, they should already know they're in the right place, so the three bullet items may not be needed there, if we want to keep it concise. Though a bit of redundancy there is OK too I think. wbm1058 (talk) 01:26, 9 May 2017 (UTC)

• No one is suggesting new guidance. Just a little clarification to existing wording at WP:RMUM to prevent any apparent inconsistency with what the other sections say. --В²C ☎ 01:52, 9 May 2017 (UTC)
• That said, Wbm1058, given that we seem to have general consensus on fixing this section, I implemented your suggestion[9] (with slight rewording). What do you think? I'm a bit concerned about having redundant language on the page but it's certainly better than the previous contradictory language... Thanks to Herostratus for bringing this to our attention! --В²C ☎ 02:03, 9 May 2017 (UTC)
• Herostratus reverted the edit implementing Wbm1058's suggestion to use consensus-support language from elsewhere with edit summary "Slow down, this is under discussion at the talk page, there's no hurry, let's see what develops first." What else is there to develop? This is consensus-support language. I implemented because I thought nobody could object. --В²C ☎ 02:46, 9 May 2017 (UTC)
  • I mean, I suppose more or different language could develop, and of course that can be added/replaced too. But for now, at least this is consistent with the rest of the page and removes the contradiction. A clear improvement, no? --В²C ☎ 02:47, 9 May 2017 (UTC)

No not necessarily. I mean, it sounds reasonable, but it's not necessarily too helpful, in that it depends on the use of "reasonable" which people tend to interpret as meaning "what I think, as opposed to what that other fellow thinks". There's no hurry. Maybe actually we should restrict page moves more strictly.

Anyway it's not matter of interpretation. It really does say "Anyone can be bold and move a page without discussing it first and gaining an explicit consensus on the talk page [but] if you make a bold move and it is reverted, do not make the move again". It's uses the word "bold" and so is implicitly referencing WP:BOLD. (WP:BOLD, which is a guideline, opens with "Be bold can be explained in three words: 'Go for it'. The Wikipedia community encourages users to be bold when updating the encyclopedia" (emphasis in the original) and then continues in that vein. It does say later "changes to articles on complex, controversial subjects with long histories or active sanctions, or to Featured Articles and Good Articles, should be done with extra care" and "more caution is sometimes required when editing pages in non-article namespaces". They talk about a lot of places where you want to maybe be not-so-bold, but moving pages isn't one of them.)

And it's been there since 2014, so you can't wish it away. It's a major change of both theory and practice, so there's no hurry.

But the Hillary Clinton example is worth pursuing. Yes it does feel wrong if someone BOLDly moved that to "Hillary Rodham Clinton". I think that's because its a substantial change. In the same vein, if someone BOLDly went into the article and rewrote whole swaths of it on their own dime, that also would not feel right, because it's a substantial change. It partly depends on how visible the article is TBH.

So if it's a substantial change change, maybe it should me more restricted altogether.

I dunno if "No one could reasonably disagree with the move" is very helpful. My recent experience is that there are very few titles that a reasonable person couldn't reasonably claim would be better under a different title, as User:Blueboar notes. And I mean, even if you expanded it to "No one could reasonably disagree with the move, e.g. misspelled title", people are going to be like "Moved Mumbai to Bombay to correct spelling error".

"Reasonably disagree" is vague enough to be useless when titling is involved. Give me a list of ten random titles and I bet I can come up with reasonable cases for different titles for nine of them at least.

One solution would be simple: "Never move a page (unless you are closing an RM). Instead request a technical RM so an administrator may approve, or initiate an RM discussion. If there is an emergency or other good reason and a page must be moved immediately, contact an administrator." That might be too constricting, I don't know. It would slow down title changes maybe, which I don't know if that's a bad thing or not.

Absent that, we might want to expand on what "reasonable objection" covers, with details and examples. This would be difficult work though, and possibly impossible to get agreement on.

Before making major substantial changes in whether and how people can move we should probably have an RfC and bring in outside eyes. It may be that we're not seeing the whole picture and that there are specific or general benefits to allowing WP:BOLD page moves. (And anyway any changes here should have a commensurate change there.) Herostratus (talk) 03:24, 9 May 2017 (UTC)

I withdrew my objection to User:Born2cycle edit for now, and restored it. If I'm the only objector I don't want to stand in the way of what others seem to feel is an improvement. I don't consider the change to be stable yet, and I may propose other refinements in the next few days. But if everyone else is fine with it no other page watcher wants to roll it back... it's reasonable, so fine. Herostratus (talk) 07:07, 9 May 2017 (UTC)

There is a reason I used the word "can" and not "may" (and why the point about moving back uses "may"). So I do not see the contradiction with anything else on the page.

With the current wording the first instance should read probably "may" not "can". -- PBS (talk) 09:34, 9 May 2017 (UTC)

Also I see little point in keeping bold in the current wording as my original point was that people can be bold, if they do that once in a while and move a page without noticing that in the archives somewhere there was a RM, they no drama just ask to have it move back. Basically I wrote it intending it to be read as Blueboar describes it above. The current wording complicates what is meant to be a simple statement of fact by surrounding it with constrains/conditions on bold. If those constraints are to be there then remove the word bold. Personally I think it is better to keep it simple. -- PBS (talk) 09:41, 9 May 2017 (UTC)

I agree: Anyone can be bold and move a page if: → Anyone may move a page if:

The word "move" doesn't even occur in the WP:BOLD guideline. That's an editing guideline, not a page-moving guideline. We could just as well have linked to wikt:bold, but that would be an WP:overlink to an everyday word. Sure, we can give newer editors some latitude if they don't know how to check the logs and archives. But experienced editors should know better. wbm1058 (talk) 14:57, 9 May 2017 (UTC)

Agreed.  Done. [10].

Regarding experienced editors should know better... you'd think... unfortunately we need to make this clear and explicit because some don't know better (or refuse to know). And newer editors who make this error once, that's no big deal. It's the repeat offenders that cause the problems. --В²C ☎ 15:55, 9 May 2017 (UTC)

Which is why the really important part of all this is the instruction to discuss, and don't edit war should a move be reverted. Live by that and the initial (bold) move is fine. Blueboar (talk) 15:59, 9 May 2017 (UTC)

What about someone who regularly makes moves without discussion or explanation even though they are clearly potentially controversial, but is careful to not edit war? Such initial (bold) moves are also fine? --В²C ☎ 16:18, 9 May 2017 (UTC)

Why not? There is no need to make a drama out of something that should be fairly non-confrontational... simply revert the move and shift to discussion. Don't Wikilawer it. It's a simple Bold - Revert - Discuss progression.

Now, if the other editor (the one who made the move) wants to make a drama out of the situation (for example, if he/she refuses to shift to discussion after being reverted) then that's on him/her. That editor is being disruptive, and can be sanctioned accordingly. We already have rules for that. But the initial move is no big deal. Blueboar (talk) 16:55, 9 May 2017 (UTC)

Well, often it's more involved that a simple move/revert. Typically, they also place a new dab page (often riddled with dubious entries) at the original article location - that is, it's a primary topic issue that should be resolved by RM discussion in the first place, not so simple to revert, and sometimes remains so for months before someone notices. --В²C ☎ 17:35, 9 May 2017 (UTC)

Or, say somebody is obsessed with thinking titles should have an even number of characters. So he goes around moving articles in creative ways so that they have an even number of characters. Some percentage of his moves are noticed and are reverted, but some are unnoticed and he gets away with it. What is the motivation for such a person to stop his disruptive behavior? --В²C ☎ 17:39, 9 May 2017 (UTC)

Well, first, there is a possibility that the new titles (and dab pages etc) may actually be better ... so we can not start off with an assumption that the moves are disruptive. Now, there is also the possibility that another editor will disagree with the moves, and revert. So far, neither editor is being disruptive... It's just a routine disagreement - to be settled through discussion. Things only become disruptive if the first editor does not respect the revert, and refuses to shift to "discuss". when the first editor crosses the line into edit warring... that is disruptive. Blueboar (talk) 18:30, 9 May 2017 (UTC)

You seem to be saying BOLD applies to moves just as it does to edits. I disagree. --В²C ☎ 22:44, 9 May 2017 (UTC)

A move is a specific type of edit... but really I simply want to avoid rules that create more drama than they cure. Blueboar (talk) 10:35, 10 May 2017 (UTC)

I suppose it depends on how broadly you define "edit". A move does not change the content of a page, and is not performed by clicking the "edit" or "edit source" tab, but rather by choosing "move" from the "More" dropdown. Other "mores" include deleting pages and changing protection. You could argue that deletions are also "edits" but these are edits that only administrators can make. BOLD does not apply to deletions, and you need to find an approved rationale to justify a speedy deletion. We do not start off with an assumption that all moves are disruptive. Only "bold" moves that don't qualify under the criteria now stated in WP:Requested moves § Undiscussed moves are disruptive. When in doubt, discuss. If you made a good-faith attempt to find past discussions and missed one, or someone surprises you with a reasonable disagreement, no big deal, revert and discuss. I don't believe we have any rules that create more drama than they cure. The goal here is to minimize the number of requests to revert undiscussed moves. Such requests cause extra work for admins and page movers, clutter up the move logs, and if repeated too much, can lead to drama. wbm1058 (talk) 13:12, 10 May 2017 (UTC)

While I'm sympathetic to User:Blueboar's point, just on a practical level move are different from regular edits in that they can be harder to undo, and also all the incoming links have to be cleaned up.

There are a lot of regular article edits every minute that are poor but good-faith and get rolled back, and a lot of other edits that are arguable and get turned back and taken to discussion on WP:BRD grounds. We encourage this though because its a net positive for the project. I don't know as you can the same about moves.

If we told editors "don't make an article edit if you think someone might not like it, get consensus on the talk page first" this would a vastly different project. It might be a better project (I doubt it but who knows) but it would be very different and I can see some downsides to doing that.

Anyway, telling editors " "don't make a move if you think someone might not like it" is really very different. It doesn't really have a big impact on the project one way or another. I just don't see encouraging WP:BOLD moves as necessarily a net positive for the project. Herostratus (talk) 17:13, 10 May 2017 (UTC)

how are moves harder to undo than any other edit? Go to the page history and click on "undo" (then do the same with the talk page). I have done this several times in my years as an editor. Blueboar (talk) 17:41, 10 May 2017 (UTC)

Well If you want to move it back over the redirect, and the redirect has had an edit, you can't do it, for instance.

Here's a good example, just happened. An editor removed a word from an article on grounds "expresses an opinion". I put in a different word with "how about this word for a compromise?". That editor might remove it again with "nah same objection" or put in another different word with "no, but how about this" or whatever -- communicating through edit summaries (obviously if it gets complicated we have to go to talk). I just kind of see moves as little more of a Big Deal than that kind of interaction. Herostratus (talk) 18:01, 10 May 2017 (UTC)

I opened a brief note at the pump, not a formal RfC or anything, just to see if any outside people had any insight. Herostratus (talk) 15:36, 11 May 2017 (UTC)

In the future, please observe WP:MULTI--rather than taking the conversation there, simply leave a one or two-sentence description of the discussion and then point the outside editors to the discussion in question. --Izno (talk) 16:36, 11 May 2017 (UTC)

#More undiscussed "technical requests" (see below) is precisely the kind of drama that this guidance is designed to avoid. Now we have a malformed move request which needs to be sorted out. Quite annoying and time-wasting for admins to have to deal with these. I'm not keen on policy creep here, but if we have to... examples of technical requests: spelling corrections, capitalization corrections, changing a hyphen to an en-dash to conform with an established naming convention, where similar moves have been done in the past. Company name changes... Maybe start a new supplementary guidance page to list these? If editors continue to demonstrate their intent to "game" the system, or that they can't use common sense. wbm1058 (talk) 19:21, 11 May 2017 (UTC)

In the move discussed below, no one is trying to "game the system"... a new editor requested a move (in good faith)... a more experienced editor (an admin?) made the move (also in good faith). Neither expected any objection. OK... It turns out that their expectation was wrong. There is an objection. No big deal... The (admin?) mover is now aware of the objection (and why it was made). If you really can't live with the page being at the "wrong" title for a few days, try asking the mover to undo his move, and return the page to its previous title while we discuss (most admins will be quite happy to do so if you ask nicely). The point is... it was an easily correctable mistake... not some nefarious or underhanded "gaming" of the system. There is no need to make a court case of it. Blueboar (talk) 20:12, 11 May 2017 (UTC)

OK, "gaming the system" is too strong a characterization for this; fortunately there aren't many that go that far. Nonetheless this is something that is taking me quite a bit of time to sort out and "easily" correct. wbm1058 (talk) 20:25, 11 May 2017 (UTC)

Another reason we discourage bold moves that are not routine in nature: the redirect fixing bots. Some pages have a dozen or more redirects to them. When you move one of these pages, you're not effecting just one page, sometimes the bots will follow you and change a dozen or two redirect pages. Then, when the move is reverted, you hope that the bots undo all that. Sometimes they don't, and I've found pages that were obviously redirecting to the wrong place because move-wars got the redirect-fixing bots mixed up. wbm1058 (talk) 19:52, 11 May 2017 (UTC)

Right, that also makes sense. Not much interest at the village pump where I asked, but the 1 or 2 commentors also concur that page moves need more care than regular edits (Izno I understand about MULTI but in this case a quick ask over there was better than dragging more people over to in this more detailed and inchoate thread -- different audience). To tidy up the corners, I also suggested adding a couple sentences about this to WP:BOLD, here: Wikipedia talk:Be bold#Proposal to add a sentence about page moves. I wouldn't necessarily advise any of you page-move-interested people going over there, let the people watching that page discuss it if they care to. Herostratus (talk) 07:39, 17 May 2017 (UTC)

FYI, the VP discussion is at Wikipedia:Village pump (policy)#How to advise about page moves -- be bold, or be cautious? – wbm1058 (talk) 21:24, 17 May 2017 (UTC)

I think we can probably hat this discussion -- I haven't found one person (including myself), here or at the small side-discussion at the pump, who believes that WP:BOLD applies to page moves in the sense of "this might well be controversial, but you never know, so here goes". Even the editor who originally inserted "Anyone can be bold and move a page..." I think meant "Anyone can be bold and move a page" as a description of fact without necessarily endorsing it. And the change has been made. So nothing more to do here I don't think. Herostratus (talk) 17:09, 18 May 2017 (UTC)

See: Wikipedia talk:Be bold#Proposal to add a sentence about page moves. --В²C ☎ 16:20, 22 May 2017 (UTC)

There are quite a few people at that discussion indicating that BOLD should apply to moves just like it applies to edits. Well, if that's the case, then we need to update WP:TITLECHANGES and WP:RM accordingly so the guidance is consistent. --В²C ☎ 21:57, 23 May 2017 (UTC)