Wikipedia talk:Requested moves/Archive 28

Archive 25

Archive 26

Archive 27

Archive 28

Archive 29

Archive 30

→

Archive 35

Proposed style noticeboard

There is talk at the village pump about creating a noticeboard for style issues. Right now, people tend to bring their style questions to WT:MoS and other talk pages: [1] [2]. They do not much disrupt business there, but there is some concern that people may not know where to go to get a clear answer about Wikipedia's policies regarding punctuation, capitalization, spelling, and other style issues. Proponents of the measure say that a noticeboard would be easier for people to find. Opponents of the measure argue that such a style board might facilitate forum shopping and drama. Contributions from users who have experience with Wikipedia's noticeboards and similar pages would be very welcome. Since moves often involve a lot of drama, I figured you guys might be particularly knowledgeable.

The proposal itself is at the Village Pump. A mockup of the style noticeboard is here. Darkfrog24 (talk) 00:20, 4 April 2015 (UTC)

Advice

An Editor made a controversial move of an article without discussing it on this page. I reverted it. He again reverted it to his preferred title. I am unable to revert his change again as the website will not let me. Any advice? I don't want to list it as a requested move because he is the one wishing to make the move; I want it to stay at the place it has been for some years. Frenchmalawi (talk) 23:28, 6 April 2015 (UTC)

Wikipedia:Requested moves/Technical requests § Requests to revert undiscussed moves. See also Wikipedia:Requested moves/Closing instructions: "according to an ArbCom ruling of June 2009, confirmed in September 2011, discussions relating to the naming of Ireland articles (Ireland, Republic of Ireland, Ireland (disambiguation)) must occur at Wikipedia talk:WikiProject Ireland Collaboration, unless it is agreed there to hold the discussion elsewhere. Any requested move affecting these articles that is opened on the article talk pages or any other venue should be speedily closed, with a link to the ArbCom ruling." - Wbm1058 (talk) 05:05, 7 April 2015 (UTC)

The article concerned was not Ireland, Republic of Ireland or Ireland (disambiguation), and they are the only articles where moves are required to be discussed at IECOLL. It was never envisaged that it should apply to any other article. I'm not sure why you thought it necessary to put that in.

For the record, I opened a discussion on the article talk page on 1 February. Neither Frenchmalawi nor anybody else responded for over two months. When one editor finally signaled his support I did the move. The move cannot be called controversial when nobody even wanted to talk about it. Scolaire (talk) 08:21, 7 April 2015 (UTC)

@Scolaire: actually the wording of that arbcom seems slightly confusing - on the one hand it says "discussions relating to the naming of Ireland articles", which would appear to include all articles relating to Ireland, particularly those related to naming of entities. On the other hand, it does explicitly list the three main articles in brackets after that. But anyway, notwithstanding that, I agree that although you were justified in making the move in a WP:BOLD fashion following the informal chat on the talk page, it has now become clear that it is not uncontroversial, and it should therefore be reverted back to the old title, and a formal RM started to gather community consensus and lay the matter to rest. I have now made a technical request for them to be put back to the long term titles. Thanks  — Amakuru (talk) 10:00, 7 April 2015 (UTC)

@Amakuru: the ArbCom case concerned the current name of the current state, specifically whether the article on the current state should be at "Ireland" or "Republic of Ireland". Predecessor states were not part of the disagreement or of the discussion, therefore they were not within the ambit of the ArbCom case. Once you understand this, there is no ambiguity in the ruling: it was only meant to refer to those three articles. I do, of course, respect your judgement concerning the present case. Scolaire (talk) 13:41, 7 April 2015 (UTC)

@Scolaire: thanks for the info on the Ireland naming, that makes a lot of sense. And thanks for the message about the present case. Maybe I'm sometimes a bit too much of a stickler for procedure, and I'm well aware of the many good times to apply WP:IAR, but in cases like this, I think we end up with a more satisfactory result when the process is followed as the guidelines suggest. The very fact that users have come to you with this discussion and argument is a good case in point - the debate is lingering on even though you consider it put to bed. With a formal RM, and the subsequent close and option for move review if necessary, the end result is that even those who disagree with the outcome usually accept it, and questions are put to bed for a long time. Thanks  — Amakuru (talk) 15:26, 7 April 2015 (UTC)

Relisting

Can we please scrap relisting? Right now there are at least two slam-dunk move requests that are held up unnecessarily and inexplicably by it - Talk:First_date_(meeting) and Talk:Movements_for_civil_rights#Requested_move_22_March_2015. All it takes is one opposer (or supporter) of a move request to delay the process and force supporters (or opposers) to keep checking up on the request for another week or more. Move requests that haven't yet reached a consensus but are perhaps close to it are never actually closed on time anyway, and the toughies are left to languish for a month anyway, so what's the purpose of relisting? Red Slash 19:54, 5 April 2015 (UTC)

The two move requests you cite are radically different in nature. First date may be obvious, but the relisting editor also converted the request from a single-page to a multiple-page request. So the re-list is perhaps reasonable on procedural grounds, to give a full-week notice to watchers of talk:First date (disambiguation). "Civil rights movements" is an interesting one which I feel indeed merits a re-list. I'm finding the arguments of the minority to be particularly compelling, while the arguments of the majority supporting the move are surprisingly weak. While we don't count !votes around here, soliciting more discussion so as to avoid charges of "super-voting" seems appropriate to me. Wbm1058 (talk) 03:30, 6 April 2015 (UTC)

I have to say agree with Wbm1058. That's a good spot on the relisting as a multi-move. I always think it's fairer if all affected pages get included, even in fairly slam dunk cases, as some may be watching those spaces and have some knowledge that we at WP:RM aren't aware of. As for "civil rights movements", it was clearly a contentious discussion, judging by the amount of discussion that went on surrounding the votes, and soliciting more input can only be a good thing. One week or two weeks are not a long time in Wiki-land, and the aim here is to secure the *right* result, not just the one that you may or may not favour. So if a load of people come during the second week with valid reasons for opposing that move, then it's a good thing for Wikipedia... @Red Slash: when you say "force supporters (or opposers) to keep checking up on the request for another week or more" you make it sound like a sort of war, where everyone has to protect their viewpoint and fight anyone who tries to move the discussion in a different direction. Whereas in fact it's about figuring out the correct result through consensus building. In general if there's recent discussion going on we shouldn't close either way, to allow full airing of viewpoints.  — Amakuru (talk) 08:19, 6 April 2015 (UTC)

Haha, yeah, I always keep tabs on move requests I've participated in, to see if they get closed the way I believe or not. And if someone raises a point that I think deserves a response, I'm all about replying. Your proposal here that "if there's recent discussion going on we shouldn't close either way" is innovative and is not found in WP:RMCI to my knowledge currently--which is not intended as a criticism, since we are kinda talking about changing RMCI here, just an observation. Red Slash 19:39, 6 April 2015 (UTC)

Not related to either of these two, but I am concerned by some of the relisting I've seen happening recently. On one occasion the discussion had four or five participants, all of whom supported the move. The discussion was then relisted by an admin who was apparently opposed to it. To me this simply looks like an abuse of process. Number 57 11:16, 6 April 2015 (UTC)

I agree. In situations like that, even as a non-admin, I never feel bad about closing over a relisting. There's no guideline or suggestion that an uninvolved closer ever has to wait once seven days have passed, regardless of a relisting or not. And I agree that I've seen those relistings too, and it is frustrating. In fact, in direct contrast to WP:RMCI, I've even seen unopposed and unsupported move requests get relisted. This specifically violates:

Unlike articles for deletion, where lack of participation requires relisting, no minimum participation is required for requested moves because for most moves there is no need to make a request at all; the need arises only because of a technical limitation resulting from the target article name existing as a redirect with more than one edit. Thus, if no one has objected, go ahead and perform the move as requested unless it is out of keeping with naming conventions or is otherwise in conflict with applicable guidelines or policy.

Only if real differences have been exposed and discussion hasn't yet reached a point where they get resolved (but it likely will) should we relist; I'm not convinced that such situations really happen all that often and that it's worth the wait. Red Slash 19:39, 6 April 2015 (UTC) Fair notice: I've edited a fair bit on RMCI, but that part far predates my contributions to the page.

Re: "There's no guideline or suggestion that an uninvolved closer ever has to wait once seven days have passed, regardless of a relisting or not." I think there was at one point, and I think I removed it without objections. More generally, it sounds like this is a question of how the process is being used, rather than a problem with the process itself. Discussions often get several more opinions added all at once upon relisting, and that can be very helpful. Dekimasuよ! 16:34, 7 April 2015 (UTC)

Moves contrary RM results

Scalhotrod moved page Talk:Jill Kelly (pornographic actress) to Talk:Jill Kelly (actress) etc...

There's a flurry of these moves, following failed RMs being moved anyway, or non-admin closes of RMs, repeated moves by 2 or 3 editors of the same articles, etc etc etc, too much activity to keep track of, can somebody else put an eye on it please? In ictu oculi (talk) 20:31, 7 April 2015 (UTC)

Are there any others (specific ones) that you're thinking of? Red Slash 20:45, 7 April 2015 (UTC)

Sorry, you'd have to look at the contribs of the two editors doing them, there are too many to keep track of. In ictu oculi (talk) 20:59, 7 April 2015 (UTC)

addition of significant section without any discussion or consensus

I have removed the following section from the RMCI because it has been added unilaterally over the last few days by a single editor @RedSlash with no apparent consensus by any other editors and/or admins. I do not think it is appropriate without some discussion and/or consensus on its implications and its wording.

Please give an explanation for contentious or divided requests{{shortcut|WP:EXPLAINTHECLOSE|WP:CLOSINGSTATEMENT}}

Remembering that, of course, a requested move is not a vote, whenever you close a request that had a very close numerical count, please clarify things for the "losing" side by issuing a statement of explanation. If one side's arguments were fallacious or ran counter to policy, for instance, those who made those arguments deserve to know that. After a period of discussion that ends 6-5 or 8-8, any decision other than "no consensus" probably demands a brief explanation, at least. Similarly, a 7-4 or 20-12 request that ends in a close of "no consensus" or one in favor of the minority's side also probably demands an explanation.

This, again, is not to say that such a decision cannot or should not be made; we do not count votes at Wikipedia to determine a consensus, period. If (say) twenty editors give rationales that ignore sources and policy, while twelve editors issue arguments that follow them, it is your responsibility as closer to issue a decision against the numerical majority. But a clarifying comment can make it easier for the several real-life human beings who disagree with your decision to understand what their next step is (whether to change their perspectives, learn more about our titling policies, gather more sources for next time, or even take it to move review).

--Mike Cline (talk) 21:43, 7 April 2015 (UTC)

I think it's generally a good thing to explain closes that may be considered contentious. I don't see any reason why a closer shouldn't. Red Slash 22:28, 7 April 2015 (UTC)

While your sentiment seems reasonable and the section added language reflects your sentiment, it is fraught (from my experience) with many problematic issues.

• What constitutes a "contentious close"? Who decides?
• RMs become "contentious" for any number of varied reasons--ethnic sentiment, nationalistic sentiment, battleground issues, obsessive renaming based on Primary Topic, diacritics, over/under disambiguation, upper/lowercasing, ENGVAR, science vs lay terminology, on and on. In many cases, the contentiousness has absolutely no relevance to the titling decision, but opposers and supporters don't see that.
• RMs become contentious because our titling policy and style guidelines are a mismash of inconsistently with conflicts and often incompatible and competing title characteristics.
• RM discussions on contentious issues are rarely collectively coherent or rational and often tainted by personal attacks and uncivil discussion.
• There are more ....

When a closer reviews the discussion, the article and the sources a decision must be made. But explaining that decision can be problematic for all the reasons above and more, and in my experience rarely placates those who believe they "lost" the discussion anyway. Does obligating (as the paragraph implies) the closer to explain the close obligate all those involved in the discussion to accept it? Probably not since we've specifically created the Move Review process to allow the "losers" as you characterize them to challenge the close.

There are rationales that opposers/supporters of move requests make that I find utterly nonsensical in context--absolute bullshit that should have no bearing on the discussion but I rarely call those out in my closes because calling another editor's opinion bullshit just isn't productive. My favorite is the editor who says something to the effect : "Most readers are going to search for this over that" With up to 30 WP million readers a day and a half-billion a month, such pronouncements are not only arrogant, but without any credibility. Even The Amazing Criswell would not make such pronouncements given the odds.

While I believe it is perfectly reasonable for RM closers to provide rationale for their decisions, it should be neither obligatory or encouraged. RMs are not competitions and nothing in the guidance should imply that they are. RMs take time to review, decide, close and make whatever follow-on edits are required. Forcing obligatory closing rationale on closers will do nothing to improve the RM process, will add more time to closes, and more than likely discourage future closers from even participating, especially when zealots begin trying to enforce such guidance on closers they disagree with.

--Mike Cline (talk) 14:04, 8 April 2015 (UTC)

Agreed, sensible removal.  Philg88 ^♦talk 14:09, 8 April 2015 (UTC)

Bug around RM templates

There’s a formatting bug around the RM templates. Please see Template talk:Requested move#Markup bug for details and discuss. —174.141.182.82 (talk) 09:04, 11 April 2015 (UTC)

Southern Ireland

There has been an article about the short-lived UK country called Southern Ireland which existed from 1921-1922 on Wikipedia for years. It was always titled Southern Ireland. Just as its sister country, Northern Ireland is so titled. The short-lived country is referenced hundreds of places on Wikipedia. Recently, on 6 Feb., an editor (i) changed the title to "Southern Ireland (1921-1922)" and (ii) created a dab page for Southern Ireland. It is really frustrating that every time we must now properly reference this former UK country we must type "Southern Ireland (1921-1922)|Southern Ireland". This change was entirely unnecessary and is retrograde. Did any editor or reader ever experience confusion on account of its name? Well, if they had, there was a perfectly good hat note at the top of the article. This move was made without any discussion whatsoever. I don't know how it can be undone technically as the person went off and created a dab page where the article should be. Am I the only one who thinks this sort of behaviour is disruptive and wrong and needs to be stamped out? I don't think its right that the editor who made this change without discussing it now has his changes in effect without having ever discussed them or seeking input from others. My view the changes should be reverted and then if there is still an apetite for change, discussion and consensus should be achieved in the usal way...Thanks. Frenchmalawi (talk) 00:01, 12 April 2015 (UTC)

I correct myself on one point, the move was in fact discussed over a period of about five days by a tiny numbher of editors. We are discussing the title of a UK country and that's how much discussion there was. There really ought to have been a posting on requested moves page. This is an important article about the only contry that has ever left the UK. Frenchmalawi (talk) 00:14, 12 April 2015 (UTC)

Yeah, it would be nice if editors took the hint from that Arbcom ruling and, at minimum, assumed that moving anything with "Ireland" in the title requires discussion and a formal RM.

But, at least there was some minimal discussion among several editors at Talk:Southern Ireland (1921–22) § Article title – and some moves to temporary titles along the way which should have caught the attention of anyone watching these articles.

Southern Ireland is now a dab with four line items. Practically speaking, this is too much to be handled with a hatnote. I see that the previous hatnote was pushing the limits on hatnote length:

This page is about a part of the United Kingdom that ceded in 1922. For the subsequent independent states, see Irish Free State and Republic of Ireland. For the European Parliament constituency, see South (European Parliament constituency).

That hatnote did not even mention what I think of when I hear "southern Ireland" – simply southern Ireland. And by that I mean southern Republic of Ireland. The area defined by the map in South (European Parliament constituency) is roughly what I'm imaging. Though I am just now learning that the Republic is divided into three European Parliament constituencies. I definitely do not equate "Southern Ireland" with the entire Republic, no more than I would think "East Virginia" meant the entire state of Virginia, and not just the area around Virginia Beach and Chesapeake Bay.

So, I endorse that move and am pleased to see no links to the Southern Ireland disambiguation in article-space. Rather than call for reverts of all this now, I suggest appealing with a multi-move request if you want to change it back:

• Southern Ireland (1921–22) → Southern Ireland
• Southern Ireland → Southern Ireland (disambiguation)

— Regards, Wbm1058 (talk) 02:47, 12 April 2015 (UTC)

Thanks for your time and thoughts. As for the dab being too long. Let's face it. There is no Wikipedia article on Eastern Ireland, why would any one think that there would be a Wikipedia article on Southern Ireland in that same sense. There was no need for any disambiguation around that. As for the EU constituency. Serioiusly? Can it really be said that any one has ever input Southern Ireland and expected to read about an EU constituency. The supposed need for a dab is really far, far-fetched. We have dumped a title for a country to use it for an unnecessary DAB page and left the country with a very cumbersome name "Southern Ireland (1921-1922)". I regret that I am now the one who has to raise a request move for thes pages which were moved without being discussed here....Frenchmalawi (talk) 15:38, 12 April 2015 (UTC)

@Frenchmalawi: I think Eastern Ireland reinforces my point. That's a redirect to Leinster, which is a province in eastern Ireland. As Munster is a province in southern Ireland. East Virginia is actually a disambiguation as well. – Wbm1058 (talk) 17:55, 12 April 2015 (UTC)

Hi User:Wbm1058 I want to take your advice and make the requests...Could you give me the link to where I can copy and paste the below request in. I don't know where I am supposed to do that. Or if you can paste it in for me there on my behalf, all the better. Thanks. I don't think I've formatted the text correctly, could you help? Not sure how to do it. I want to make the exact requests you mentioned. Frenchmalawi (talk) 15:56, 12 April 2015 (UTC)

Please continue the discussion at Talk:Southern Ireland (1921–22) § Requested move 12 April 2015 – Wbm1058 (talk) 17:55, 12 April 2015 (UTC)

User:Marrovi

This editor is making a mass amount of moves of diaspora articles to immigration articles ..I dont think they understand the differences between the two. What can we do here to fix all these? This is not the first time theses moves have been done by the editor. -- Moxy (talk) 04:04, 13 April 2015 (UTC)

Changing term used in article while move discussion is taking place

Recently I have noticed that during move discussions some users have decided to alter the content of articles (or connected articles) to their preferred title, while discussion is still taking pplace. This has happened in 'both directions', ie the term used throughout the article has been changed to the proposed title; or, the term used in the article did not match the title at the moment of the move request but was changed to the term used in the title.
Examples of the former would be this move this move in regards to Talk:Mecca, and this move in regards to Talk:Dot the i; the latter can be seen in the case of this move regarding the on-going discussion at Talk:Pajamas. In all the examples given I have reverted these moves to the format used when the move proposal was made.
I believe that changing the term used in the article during a move request is an abuse of process as it can affect how users perceive the structure of the article. Furthermore, changing content during a move request may cause confusion as different users may assume see different versions and assume a different term is the main one used. In particular this may cause problems during request which involve WP:RETAIN where it may be unclear which variety was the first to be used in a non-stub version (the variety used in the first non-stub revision is considered the default).
I am proposing that a policy be created that the term used in the article at the moment of the move request should be maintained during the period of discussion (with the exception of obvious vandalism or a user changing the title just before making a move request).
This policy would be similar to WP:RETAIN (NB: this proposal would not just apply to ENGVAR moves) in that the form used in the article at the time of the move request would be retained for the duration of the move request.
Thoughts? Ebonelm (talk) 22:54, 29 April 2015 (UTC)

Update: this policy could be named WP:MORATORIUM (moratorium) or WP:MORA for short (and ease of spelling). Ebonelm (talk) 23:15, 29 April 2015 (UTC)

• The pajamas case is different from the other two, as I edit the page to reflect the current title while the others were made to reflect proposed titles. Calidum T|C 23:00, 29 April 2015 (UTC)

I noted in my statement that changes go in both directions (and emphasise this in my examples). Nevertheless the term used in the article has flicked between both during its existence, and had been stable at pyjamas since February. I don't intend this discussion to be a forum to discuss the merits of the events on the page pajamas but a more general one. Either way it is wrong to alter the content of the article as it is misleading during the discussion. I noted in my first statement as a disclaimer that I have been the one to revert the changes during these discussions. Ebonelm (talk) 23:15, 29 April 2015 (UTC)

I think it's very simple: The term of the artcle should be the current name of the article. עוד מישהו Od Mishehu 19:25, 30 April 2015 (UTC)

Agree with the above, it is helpful to not to change a term of the article if it matched the title until the request for move is adjourned. Sam.gov (talk) 21:16, 30 April 2015 (UTC)

• The name in the first line of the article and in the infobox should be the current name in the title of the article. That may or may not be "the term used in the article at the moment of the move request", so I don't support the proposal in cases where it would mean that a different name would be retained during the period of the request. Apuldram (talk) 21:42, 30 April 2015 (UTC)

• Neutral comment: This seems obvious, maybe too obvious? Could we deal with this as blatant gaming the system rather than adding to instruction creep? Alsee (talk) 04:01, 1 May 2015 (UTC)

^^^ There may be some wisdom in that. --Kevjonesin (talk) 05:23, 1 May 2015 (UTC)

Gaming the system would be an appropriate policy to use, but it is likely still going to cause disputes. If an article has used a term for two years but has had a different title for all of that time would it be gaming of the system to change the term to the article title? I believe it would be but I'm not sure that that view would be supported by other users without an explicit policy. Ebonelm (talk) 10:29, 1 May 2015 (UTC)

• The expression "term used throughout the article" used in this proposal is vague and too sweeping. The two examples given are from External links sections. The title in an external link should be the title used by the link writer, not a misrepresentation to conform with Wikipedia usage. The name in the first sentence of the lead should be the name used in the title of the article, followed by alternative names in common use. In other sections different names may be appropriate, according to context. Apuldram (talk) 11:16, 1 May 2015 (UTC)

Sorry I have provided a different link regarding the mecca discussion, my original choice was perhaps not the best exemplar. I am aware that the phrasing of my proposal is a bit sweeping, however I assume it is clear enough that we can discuss the proposal and alter the specific language as we go along. In some articles yes different terminology is used in different sections, however that only occurs in situations where different regions have different terminology. In some cases multiple terms may be used universally; in those cases apart from a listing of alternative names in the lead one term should be used throughout. Ebonelm (talk) 11:32, 1 May 2015 (UTC)

Talk:Ksenia Alopina

Can someone close this? According to the rationale, the request is not a move request, but somehow it was relisted anyways. -- 65.94.43.89 (talk) 04:37, 12 May 2015 (UTC)

 Done  Philg88 ^♦talk 06:17, 12 May 2015 (UTC)

Not allowed to change a name page?

Hi, I want to change the name of this page (because the name of this event has changed) but I'm not able to do it: https://en.wikipedia.org/wiki/Quebec_City_Marathon. I'm still in my first steps in Wikipedia but it looks like the title of this page is protected. The "More" next to the History tab does not appear. Can you please help me? Thank you so much. --MeloKeBeK (talk) 19:31, 12 May 2015 (UTC)

It's because your account is not autoconfirmed yet - you need to make ten edits and have had the account for 4 days before you'll be able to move pages yourself. Parsecboy (talk) 19:36, 12 May 2015 (UTC)

Please SNOW close Sarah Brown

Can somebody please close Talk:Sarah_Jane_Brown#Requested move 9 May 2015? It's not quite a week but WP:SNOW clearly applies for this particular proposal. Even the nom closed it voluntarily a few days ago, but that close was reverted (for dubious reasons - see User_talk:JohnBlackburne#Collapsed_discussion). Thanks! --В²C ☎ 16:50, 15 May 2015 (UTC)

The reasons were hardly dubious at all. Nom wasn't getting his way on the May 9 RM, so he simply tried to close that one and restart it all over again. The second proposal, bluntly, was made in bad faith. Also, given your comments on that talk page, I have to ask. Is your purpose in requesting this close meant to allow you to start yet another disruptive RM? Resolute 16:54, 15 May 2015 (UTC)

Of course I have no intention to start another disruptive RM. My intent is the opposite... to start an RM that will lead to a consensus decision there, finally. --В²C ☎ 20:00, 15 May 2015 (UTC)

There will be no new Sarah Brown RM anytime soon. Tarc (talk) 23:52, 19 May 2015 (UTC)

More moves contrary (most) RMs

A third editor has started removing (pornographic) from (pornographic actor) Special:Log/Rebecca1990 I've asked that they revert their moves and use the RM process. In ictu oculi (talk) 17:20, 27 April 2015 (UTC)

The editor is refusing to restore the titles. In ictu oculi (talk) 17:38, 27 April 2015 (UTC)

It's not uncommon for editors to make multiple page moves without going the RM route. GoodDay (talk) 17:46, 27 April 2015 (UTC)

It's not common to keep moving articles like Talk:Jill Kelly (pornographic actress) contrary an RM result, again and again and again. In ictu oculi (talk) 18:01, 27 April 2015 (UTC)

While I agree that the move warring needs to stop... I will note that the RM was on a slightly different proposal (a request to move Jill Kelly (pornographic actress) to Jill Kelly - with no disambiguation). What opening a new RM to settle the issue... make it clear in the nom that there has been a confusing move war, and state which title was the "original" and which is the proposed new title. then sit back and let the community decide. Blueboar (talk) 18:37, 27 April 2015 (UTC)

User:Blueboar, that particular one was but look through the others, so you agree with reverting all the undiscussed moves or you would let all the undiscussed moves become the status quo and starting point? In ictu oculi (talk) 22:36, 27 April 2015 (UTC)

While we're at it an additional problem has been created by these undiscussed moves, which is the small handful left behind because of non-pornographic actors:

Wendy Williams (pornographic actress) vs Wendy Williams (actress)

Priscila Sol (pornographic actress) vs Priscila Sol (actress)

Ben Andrews (pornographic actor) vs Ben Andrews (actor)

Kevin James (pornographic actor) vs Kevin James (actor)

Erik Rhodes (pornographic actor) vs Erik Rhodes (actor)

While the category (pornographic actor) was treated as (landscape architect) or (sport shooter) there was no need to further specify in the dab. But if we're now treating "pornographic" as a surplus descriptive, (American actor), then any (British actor) causes (American actor) to be specified. How are we going to specify Wendy Williams (non-pornographic actress)? This isn't an idle question, as the (American actor) dab demonstrates. For (architect) (landscape architect) the specific "landscape" is not extra disambiguation, but a category descriptor. Which is what (pornographic actor) was, but now it isn't. How do we fix this? In ictu oculi (talk) 11:39, 28 April 2015 (UTC)

This issue has been spilling out over a number of pages. To my knowledge two RMs closed as (Pornographic Actress) based on participation of two people. Other RMs with far larger participation closed as (Actress). A discussion was started to resolve the general issue: Preferred disambiguator: "actor/actress" or "pornographic actor/actress"? It had an outcome of 7 vs 2 in favor of actor/actress, but no formal close. Based on that result I conclude that all of the moves being discussed here were reasonable.

In ictu oculi, I request we avoid further scattering the discussion. Would you agree to adding a formal RFC template to the Preferred disambiguator discussion to draw more uninvolved input and get a close on the issue for articles in general? Alsee (talk) 06:58, 6 May 2015 (UTC)

All of the manual moves are controversial and should rightly be reverted so that the individual cases can be considered on a case by case basis. No manual moves within this topic area should have been made. GregKaye 10:36, 6 May 2015 (UTC)

There are at least 4 WP Pornography editors and 2 generalist editors who want this change. Although the number of those against has been about the same, those against are only voting in 1 or 2 RMs. So this is fait accompli now. English Wikipedia does not distinguish actors and pornographic actors for the purpose of disambiguation. I observe German French Italian Spanish Wikipedias do. But we don't. It is done now. In ictu oculi (talk) 11:59, 6 May 2015 (UTC)

I'm no fan of rebecca1990, as this user has long been using the Wikipedia like a porn-centric Linkedin, but this seems like much ado about nothing. Unless you need to disambig from another actress with the same name, a full (pornographic actress) seems unnecessary. Tarc (talk) 00:02, 20 May 2015 (UTC)

A "porn-centric Linkedin"? bd2412 T 00:05, 20 May 2015 (UTC)

The project has been deluged for years with several thousand porn BLPs; dubious subjects with no notability beyond being once nominated 10 years ago for "best 30-way sex scene with bananas" and whatnot, with a small handful of editors doing most of the editing. These subjects would be unknown outside the porn industry but because of loose notability standards in the early Wikipedia days, they now had a public profile on one of the top-trafficked websites on the planet. Basically free advertising for the XXX industry, but within the last year WP:PORNBIO has tightened (pun unintended) considerably, and we've begun to cleanup. Tarc (talk) 00:32, 20 May 2015 (UTC)

I don't think that is any different from the project being deluged with articles for every person to ever play an inning on an MLB baseball team or every person ever to serve a term in a state legislature. bd2412 T 18:31, 20 May 2015 (UTC)

Well, there is less whipped cream involved.--Fuhghettaboutit (talk) 00:53, 22 May 2015 (UTC)

"Wikipedia:Requested moves/Misplaced XfDs"

FYI, this was just created at DRAFT:Requested moves/Misplaced XfDs; since there doesn't seem to have been a discussion about this new project page , I thought I'd inform you. -- 65.94.43.89 (talk) 05:22, 30 May 2015 (UTC)

Also created was Wikipedia:Requested moves/Old AFC submissions. Both the pages were first created in the draft namespace (since IPs can create pages in draft namespace) and then moved to the projectspace. As must be obvious, these are two big page-move backlogs. A notification was posted at the administrators' noticeboard regarding this. Note: The above IP is not the same person as me. 103.6.156.167 (talk) 06:37, 1 June 2015 (UTC)

RfC on porn star article titles: (pornographic actress)/(pornographic actor) or (actress)/(actor)?

Wikipedia talk:WikiProject Pornography#RfC: Should a person who has appeared in exclusively pornographic films be described as "(actor/-tress)" or "(pornographic actor/-tress)"? Rebecca1990 (talk) 00:15, 12 June 2015 (UTC)

Dated categories?

Can the request templates be modified to automatically add a dated category in addition to the general [[Category:Requested moves]] ? Such as [[Category: Requested moves (13 June 2015)]] would be added to any request template substed on 13 June 2013, in addition to appearing in the alphabetic complete listings at Category:Requested moves ; this will allow sorting for when the bot breaks in future, to see what new requests are about, and which have ended their open periods. -- 70.51.202.183 (talk) 05:16, 14 June 2015 (UTC)

We have many dated maintenance categories which are sorted by month, but I'm not aware of any that are sorted by day. It's an interesting idea though. – Wbm1058 (talk) 16:30, 14 June 2015 (UTC)

Personally, [[:Category:Requested moves|June 14 2015]] would probably be better - this would sort the list in date order instead, oldest at the top (I know, MDY date format, but hey it works). Any feedback? Mdann52 (talk) 18:45, 14 June 2015 (UTC)

That doesn't work across months, if it is to be sorted this way, it should use numeric yyyymmdd format -- 70.51.202.183 (talk) 07:04, 15 June 2015 (UTC)

Broken bot?

The RM list hasn't been updated in over a day. I'd like to believe that's because we've finally achieved perfection in titling across the encyclopedia. It's probably because the bot's broken, though. Anyone know how to alert or fix it? Dohn joe (talk) 15:56, 13 June 2015 (UTC)

Per m:Tech/News/2015/24:

"If you have a bot, you may need to fix it. The default continuation mode of the API for action=query will change at the end of June. [3]"

Is it "the end of June" already? Both of my bots are down, and failing in a library API call. I guess I need to scramble to fix it as soon as I can. – Wbm1058 (talk) 17:09, 13 June 2015 (UTC)

I noticed this too and was going to start a new thread. How can this be fixed? Zarcadia (talk) 18:51, 13 June 2015 (UTC)

See Wikipedia:Village pump (technical) § Impending bot armageddon. I haven't seen any confirmation that the changes promised for July 2 somehow went live early, but I don't have any other explanation for this either. I didn't change any code on my end! Merge bot is down as well, as they share the same code library, where the problem is... it's at a low-level, which I usually don't mess with. Wbm1058 (talk) 19:17, 13 June 2015 (UTC)

So I guess we're extending the 1-week deadline to whatever 1-week after the bot gets fixed is at? (ie. all new discussions from 12 June 2015 onwards, will have the end of their open period become: DateOfBotFixed + 1week ) -- 70.51.202.183 (talk) 05:11, 14 June 2015 (UTC)

I've also asked for help at m:Talk:HTTPS § Bots. Unfortunately it's been my experience that the more technical my questions get, the fewer and less timely helpful responses get. Wbm1058 (talk) 16:36, 14 June 2015 (UTC)

Pretty much, the underlying code just needs to be updated to use https (either the code itself, or the framework used) Mdann52 (talk) 18:10, 14 June 2015 (UTC)

Bot patched to work under HTTPS, and back up again. For now, I've reverted to the version prior to the § Automatic bot notifications, until I'm assured everything is running stable. Calling it a night. Wbm1058 (talk) 03:19, 16 June 2015 (UTC)

Annuity and Annuity (disambiguation)

LlywelynII (talk · contribs) cut and pasted Annuity to Annuity (disambiguation) which was subsequently requested for deletion by others, which would bork the edit history. Can someone roll back the cut-and-paste move? The page Annuity (edit | talk | history | protect | delete | links | watch | logs | views) has a history of several splits, so content from its edit history appears in different articles, prior to its conversion to a disambiguation page in 2006. It is also the target of being overwritten by another page named "annuity" (at Talk:Annuity (finance theory)) which will also bork the edit history. The dab page is already separated from its edit history by the cut-and-paste. This is new move request all messed up due to cut and pasting without consideration -- 70.51.203.69 (talk) 04:34, 16 June 2015 (UTC)

Done the reverts. And at first glance, your suggestion (at Talk:Annuity (finance theory)) of a history split seems the right way to go. I don't have the time right now but if no one else get to it in a couple of hours I'll give it a crack. Jenks24 (talk) 08:46, 16 June 2015 (UTC)

I've left a fairly detailed explanation of what I think should be done with the histories at the RM. It could use a few extra eyes to look over it before it's performed though, especially from people experienced with history merges/splits/swaps. Jenks24 (talk) 13:32, 16 June 2015 (UTC)

Template:RM

You may be interested in this discussion about moving the template RM. Thanks. Lugnuts ^{Dick Laurent is dead} 07:06, 15 July 2015 (UTC)

Just a note that {{Rm}} is a valid redirect to {{Requested move}}. Wbm1058 (talk) 11:36, 27 July 2015 (UTC)

Changing relisting conventions to be easier and more intuitive.

It was brought to my attention on my talk page that some editors are confused by or dislike the current RM relisting convention which inserts the relisting notice inside the original editor's request.

I just did some research on this and found the following discussions from October 2009 and June 2010, where the same issue was raised, but not really resolved:

• Clarity (or change) on bot's recognition of relistings (October 2009)
• Relisted discussions (June 2010)

Currently the bot uses the last date in the reason string, so it doesn't pick up older dates given as part of the rationale, but rather, the signature and timestamp at the end of the rationale. Unless the string "relisted" is found, in which case it uses the first date found. This is a legacy convention from the way the process evolved. Manual re-listers put their reasons for relisting and signatures ahead of the original request, and the bot was originally coded to follow this convention.

It will be simpler and more intuitive to always use the last date found in the rationale string prior to a newline. Relists would just be appended at the end of the rationale, and second relistings would be appended after the first. I'm hereby giving notice of my intention to make this change to RMCD bot's algorithm, and will wait a bit to see if anyone has issues with this change. While I don't expect there to be any objections, I'm sometimes surprised by how some editors will fight tooth-and-nail to stop the most minor changes.

Once the switch is flipped and this is implemented, there will be a brief transition period where some older re-listings fall back into the backlog section, until they're edited to move the relisting notice(s) to the end of the rationale string. – Wbm1058 (talk) 20:31, 29 July 2015 (UTC)

• I too dislike the relisting convention. Inserting a signature inside the nomination clashes with a more important convention that you do not alter others' posts. If relisting must continue, for consistency with the XfD style, develop a RM-relist template. --SmokeyJoe (talk) 22:40, 29 July 2015 (UTC)

  I suppose we could create a fork of Template:Relist, but I'm not sure that's necessary. I don't think we need to create special categories for relisted RMs. The relisting editor should be encouraged to include a brief rationale after "Relisted", and before their signature, in their appended text after the original requester's signature. The bot will pick up the relisting rationale and show it on the RM page. However, lengthy relisting rationales should be put at the bottom of the !voting or discussion section. Wbm1058 (talk) 11:52, 31 July 2015 (UTC)

• However, I think the entire relisting practice has negligible benefit and some negatives. Relisting doesn't draw more attention to the discussion, but instead hides it from the Backlog list. Sometimes relisting is used as a very poor attempt at advertising the discussion. Worst, however, is that relisters very rarely provide any meaningful comment supporting or explaining the relist. Presumably, to relist, you should be uninvolved, competent to close the discussion, having read the discussion and come to the conclusion that it is not ready to close. If you can do that much work, if would be far more helpful to others if you would add a comment reflecting your assessment. If you have not done that much work, I don't think you should relist. --SmokeyJoe (talk) 22:40, 29 July 2015 (UTC)

  Relisting can serve other purposes besides drawing more attention to the discussion. It can also refocus the discussion. For example, let's say the original request was to move Foo to another title to be determined by discussion (a "?" request). If five alternate titles were proposed in the discussion, the relisting editor might say that Bar and Foobar are the two leading candidates, close the "primary" discussion, and open the "general election" discussion with a directive to choose the best option from the two leading candidates. Wbm1058 (talk) 11:52, 31 July 2015 (UTC)

@Armbrust, George Ho, Jenks24, Cuchullain, and Natg 19: This is live now. There are about 50 relists that have fallen back into the backlog because of that; moving the relist notice to append to the end of the original request should pull those which were relisted less than a week ago back out of the backlog. Cheers, Wbm1058 (talk) 15:07, 31 July 2015 (UTC)

In response to SmokeyJoe's comment, I do think relisting has benefits. Sometimes I add a section called 'Relister's comment'. Usually I would relist if it seems that the discussion contains the germ of a good idea, but not enough people have made up their minds about it. So if the thread had to be closed as it stands, as 'No consensus', it would be missing the opportunity to make a good decision, one way or the other. EdJohnston (talk) 18:58, 31 July 2015 (UTC)

Whilst I think relisting is generally a worthwhile thing to have, I would personally like to see two changes; firstly, if an RM has not attracted any opposition in the first week (including no comments at all), it should be moved and not relisted (it just seems a bit of a waste of time otherwise). Secondly, I think the relisters should be banned from participating in the debate. On a few occasions I have seen editors relist a debate that could easily have been closed, and then !vote in the other direction, which seems to me to be an abuse of process. Number 57 04:40, 1 August 2015 (UTC)

N57, agree with your first point almost entirely. I nearly always close anything as moved if it makes it to the backlog with no opposition – there are outliers though, sometimes I will relist anyway if someone has made a good point without specifically opposing, if the proposer has a COI (declared or not), or very rare cases if the move just looks odd and I think could use more eyes. But overall, yes, supportive of that point. Second point, agree completely and it something that seems to have happened more of late, especially nominators relisting their own RMs. This should probably be written into WP:RMCI. Jenks24 (talk) 04:41, 2 August 2015 (UTC)

Court of first resort

Seems to me, the text transitions fairly directly from non-controversial moves to ones that ought to be requested and discussed here. Perhaps we need to say with some emphasis that the first place to settle a controversy about a particular article is in that article's talk page. Here, what we've got should be treated more like an appeals process for use when discussion at the first level doesn't resolve a matter. Jim.henderson (talk) 12:34, 2 August 2015 (UTC)

I'm not sure if I agree with this. Most of the time, an RM discussion does not arise from a dispute, but rather from one editor who is either involved with an article, or is driving by, and for some reason thinks it should have a new name. They could just put a note on the talk page, but for the majority of articles they'd be unlikely to get much response in a timely fashion, still less detailed debate on the matter. WP:RM provides a central forum for such discussion, with the advantage that it is populated by people who have a good understanding of our naming policies and are also familiar with techniques for assessing common names. Of course, the talk discussion always appears on the article's talk page anyway, so we're not losing the input of involved editors. Thanks  — Amakuru (talk) 15:02, 3 August 2015 (UTC)

Although good ole talk page discussions about article titles are a good thing, they generally don't get the attention from policy/guideline savy editors unless there's an RM started. Too many articles get their titles changed already without much thought about article title policy and too many articles get their titles changed unilaterally by editors with agendas. The RM process is the best way to ensure we maintain acceptable titles for our articles and should not be seen as a process of last resort. --Mike Cline (talk) 15:42, 3 August 2015 (UTC)

I don't follow your point. Requested moves is the first step for settling article title controversies, and those discussions do take place on the article's talk page. WP:RM is just a noticeboard for advertising those discussions. It's not until our appeals process, Wikipedia:move review, that discussions are held in another venue off the article's talk page. Wbm1058 (talk) 00:40, 6 August 2015 (UTC)

Template:Vandal move and Category:Page move vandalism to be fixed

Moved from this version of Wikipedia:Requested moves/Technical requests

Do any administrators patrol Category:Page move vandalism to be fixed? That category has been populated for over 24 hours now. Wbm1058 (talk) 18:13, 10 August 2015 (UTC)

• Not personally, I didn't even know it existed until now. I've made the move for the redirect you tagged so it's empty now, but I'll leave this up for a while. Perhaps the person(s) who usually patrol the category were away for a while, or perhaps it does need to be more prominent somehow (as a part of CAT:CSD maybe?). Jenks24 (talk) 18:59, 10 August 2015 (UTC)

  Template:Vandal move and Category:Page move vandalism to be fixed were created on 21 October 2008 by non-administrator ViperSnake151. Their contributions around that time don't give much of a clue as to the rationale for the creation of this maintenance category, other than the edit summary, "okay lets try this". For years the template wasn't advertised to editors anywhere, until I added it to Wikipedia:Template messages/Moving#Requesting technical moves on 26 September 2012. I'm not sure the category was advertised to admins anywhere, until it was added to Template:CSD backlogs, where it is the 11th of 15 collapsible bars, by 103.6.156.167 on 2 May 2015. {{CSD backlogs}} transcludes into {{CSD/Subcategories}}, which in turn is transcluded into Category:Candidates for speedy deletion (CAT:CSD). Alas, with so many collapsed bars there, this seems to get lost. {{CSD backlogs}} is also transcluded into {{CSD admin dashboard}}, but you need to show the "Deletion backlog" to see it. That's part of the larger {{Admin dashboard}}, where it really seems lost in a sea of competing backlogs. See Template talk:Admin dashboard § Is this template intended to be transcluded, or simply linked? for problems with templates like this which translcude too much content.

  It seems to me that this template & category are redundant to simply putting a {{subst:RMassist}} here, as vandalism is just a special case of an undiscussed move, albeit one calling for not leaving behind a redirect when reverted, and thus I'm looking at WP:CfD. – Wbm1058 (talk) 20:56, 10 August 2015 (UTC)

Per Wbm1058's reasoning, it sounds to me that we can do without Category:Page move vandalism to be fixed. Use WP:RMTR to ask for reverts of any undiscussed moves. EdJohnston (talk) 02:40, 11 August 2015 (UTC)

Sounds sensible to me. One less page to watch.  Philg88 ^♦talk 05:05, 11 August 2015 (UTC)

• Wbm1058, Philg88, and EdJohnston, speaking of which, I nominated Template:Vandal move for deletion. Steel1943 (talk) 01:50, 13 August 2015 (UTC)

Increasing participation in RM discussions

One of the obvious difficulties in gaining consensus in RM discussions is lack of participation. Of course many times this results in relisting. I have always believed that WikiProjects related to any given article ought to be notified of RM discussions involving an article under their project’s umbrella. Many editors are shy about this when they start an RM for fear being accused of canvassing. I would like to see wording something like this in the “Requesting controversial and potentially controversial moves” section of this process guideline.

When an RM is initiated, requesting editors should notify any project listed on the article’s talk page or applicable to the target name that an RM has been initiated using a simple template that might be something like this {{subst:RM initiated|article name|new name|discussion link}}. The template when placed on the project talk page would render something like this: A requested move discussion has been initiated for article to change the title to new name. Members of this WikiProject are invited to participate. Discussion Link.

Thoughts? --Mike Cline (talk) 15:43, 23 April 2015 (UTC)

It's a good idea. Maybe it could go further and be automated in the same way that DELSORT works in conjunction with Afd with automatic project notification.  Philg88 ^♦talk 16:06, 23 April 2015 (UTC)

I'd support it too. But I think Wikiprojects of the target page should be notified too, if necessary. For example, if someone proposed moving "James Jameson (lacrosse player)" to the undisambiguated page and that would move another article from that name, those projects should be notified. Calidum T|C 16:23, 23 April 2015 (UTC)

Agree about target name as well. Proposed language adjusted. --Mike Cline (talk) 13:33, 24 April 2015 (UTC)

This already done by the AAlertBot feeds (e.g. Wikipedia:WikiProject Israel/Article alerts for WP:Israel). I have watchlisted the ones relevant to the WikiProjects I am a member of, which allows me to see all RMs that appear. Do we really need to duplicate this on WikiProject talk pages? Number 57 13:55, 24 April 2015 (UTC)

Wouldn't that require all WikiProjects to setup AAlertBot feeds for their project and then get members to follow like you do. Not all editors use their watchlists the same. Not saying its not a viable methodology, but today, too many RMs have pitiful participation because they go unnoticed by projects associated with the RM articles. The real objective here is to get requestors to drive participation of interested editors through explicit project notification. --Mike Cline (talk) 14:58, 24 April 2015 (UTC)

Notifying WikiProject members who don't watch WP:RM about a move affecting the title of an article in their area is likely to attract a bunch of people with little knowledge about policies, guidelines, conventions and consensus regarding how articles are titled on Wikipedia and with a bias favoring "their" article. It's like asking children to evaluate the handling of a race car. "I like the purple one!" Just what we need more of in RM discussions... not. --В²C ☎ 23:25, 15 May 2015 (UTC)

I believe this discussion was opened as a direct result of your comments here [[4]]. Leaving aside your ridiculous, unsubstantiated and insulting remarks for the moment; are you now saying that trying to find a wider audience for move discussions is a bad idea?--Ykraps (talk) 11:04, 17 May 2015 (UTC)

No. I think trying to widen the audience by targeting projects with members who are likely to have a biased interest regarding the subject of the article whose title is in question, and not much experience or knowledge about title decision-making in general on Wikipedia, is a bad idea. But if you want RM discussion riddled with pointless WP:JDLI commentary, this will seem like a good idea to you. --В²C ☎ 15:59, 18 May 2015 (UTC)

I think you mean yes. You don't want a wider audience, you want a selected one. A small group of like-minded editors that writes the rules and then mobs RM discussions to ensure we're all obeying them. Do I think that's a good idea? No, I don't!--Ykraps (talk) 16:53, 19 May 2015 (UTC)

So you are now equating membership in a project with inability to make good titling decisions, and a tendency toward JDLI. How patently absurd. Omnedon (talk) 16:05, 18 May 2015 (UTC)

There are two kinds of project members - those who are knowledgeable about WP title-decision-making and those who are not. When you target the members of a project about an ongoing title change proposal, you are notifying those ignorant about title decision-making as well as those who are experienced it. The latter group is likely to be watching WP:RM and already knows about the proposal; the former group not. Therefore, when a project is notified about an RM proposal the ratio of ignorant/JDLI to knowledgeable/policy-based participation is likely to increase. This is plain logic. Why the animosity? Don't shoot the messenger. --В²C ☎ 16:44, 18 May 2015 (UTC)

Surely participation in these discussion is the best method of education for such editors? Or are you proposing some form of elitism? --Falcadore (talk) 17:38, 18 May 2015 (UTC)

Participation in these discussion is the best method of education for such editors - starting with participation in discussions unrelated to their topic of interest, where they can develop an understanding of the relevant policies unclouded by their perceptions with respect to a particular issue. For example, if there was a proposal to make Rock (geology) the primary topic of Rock, and editors from WikiProject Geology were notified, but those from WikiProject Music were not (or vice verse), then we might have a skewed sample of who thinks which sense of "Rock" is primary. However, if all of the participants had participated in dozens of previous RMs unrelated to geology and music, they would have a far more balanced sense of how primary topics are determined. bd2412 T 17:44, 18 May 2015 (UTC)

B2C, you are in no way "the messenger" here. You're making what I consider to be invalid assumptions about editors and their abilities. Omnedon (talk) 17:46, 18 May 2015 (UTC)

Surely a few new faces at RMs is a good thing, better than only having editors who consider RMs the ONLY important bit of WP. --Richhoncho (talk) 17:58, 18 May 2015 (UTC)

Swings and roundabouts; participation in other RMs might help in respects to standards of wiki-procedures, however familiarity with the subject also helps with the understanding of the application thereof.

Additionally, RMs are not a democratic vote. Closing editors will be able to take into account arguements that may be invalid. --Falcadore (talk) 18:02, 18 May 2015 (UTC)

• Omnedon, what you consider to be invalid assumptions is meaningless unless you identify those allegedly invalid assumptions and explain why you think they're invalid.
• Richhoncho, most editors are not interested in titles, and that's fine. Encouraging them to participate in RM discussions makes as much sense as encouraging the politically uninformed to vote.
• Falcadore, closers should take into account invalid arguments, but unfortunately they all too often are swayed by the numbers. --В²C ☎ 18:34, 18 May 2015 (UTC)

B2C, the objection has already been clearly identified. You are associating project membership with an inability to make good titling decisions. You have no basis for that, nor have you any basis for assuming that "most editors are not interested in titles". Omnedon (talk) 02:05, 19 May 2015 (UTC)

Here is an example of what happens when the audience is widened: [5]. That notification lead to six more years[6] of those guys resisting change of that title, despite having no policy grounds to stand on. --В²C ☎ 19:32, 18 May 2015 (UTC)

Mike: I'll support that. There's nothing unreasonable about making RMs more visible to those in the relevant field; quite the reverse, it brings in not just more participants but also more participants who are knowledgeable about the subject – and insight from such contributors is often valuable. I also agree with the point made by others that joining an RM debate (on whatever topic) is a very good way to learn about the policies and practices of WP article titling, so the more participation the better. ╠╣uw [talk] 19:40, 18 May 2015 (UTC)

The better for what, exactly? Endless and pointless debate about which of two perfectly fine choices should be the title? --В²C ☎ 20:00, 18 May 2015 (UTC)

Rather than discouraging editors from participating in RMs if they are close to the topic, we should be encouraging those editors to participate in RMs for topics unfamiliar to them, so they can provide the neutral and uninvolved view on those topics, and bring that perspective back to familiar topics. Cheers! bd2412 T 02:22, 19 May 2015 (UTC)

B2C: Please see WP:DONTBITE: While it is fine to point a new user who has made a mistake towards the relevant policy pages, it is both unreasonable and unfriendly to suggest that they stop taking part in votes, Articles for Deletion discussions, etc., until they "gain more experience."

Participation is how someone less familiar with the process gains experience; trying to suppress participation because you fear it might attract people you consider inexperienced runs directly counter to Wikipedia's principles. I agree that debates can sometimes grow tiresome and pointless, but in my experience that's not normally the result of having input from people conversant with the subject area – it's more the result of die-hard policy wonks swamping the conversation as they battle to impose their rigid, personal interpretations of the rules. Personally I don't think anyone's participation should be suppressed, but if it was, a bit less of that might improve the process... ╠╣uw [talk] 14:00, 19 May 2015 (UTC)

Stop playing false dichotomy games. I never advocated discouraging anyone from participating in anything. What I oppose is implementation of an automated system that actively encourages the uninitiated to participate in decision-making for which they are ill-prepared. That said, I agree with BD2412 about encouraging newbies to participate in topics unfamiliar to them (though I would say about which they have no vested personal interest rather than "unfamiliar"). --В²C ☎ 20:02, 19 May 2015 (UTC)

Whether you do or don't encourage participation (and you now confusingly seem to say both), I'm just noting that Wikipedia rejects the notion that users shouldn't participate in discussions simply because they lack experience. Further, this proposal is not about alerting newbies – it's merely to put a notice on the talk page of the relevant project, the active participants of which we may reasonably assume to be at least somewhat more experienced than a true newbie.

Mike's proposal would give more visibility to possible commentators of discussions they may wish to be involved in, discussions they currently might not even know are taking place (and which can suffer from low turnout). That right there is a very good thing, and the prospect of diffusing more RM-related expertise and involvement beyond a specialized clique makes it better still. If your fear truly is that the "uninitiated" are "ill-prepared", then the solution is to invite them in so they can become initiated and prepared. ╠╣uw [talk] 14:57, 20 May 2015 (UTC)

Its apparent there's no serious opposition to this idea. I'd like to see the template created before changing the language in the instructions. Who might like to take that on or can someone recommend an editor who might help with this? --Mike Cline (talk) 18:21, 20 May 2015 (UTC)

A quick note on this. Some projects, such as the disambiguation project, already have a noticeboard where these are posted (in the case of disambiguation, Wikipedia:WikiProject Disambiguation/Article alerts). Since disambiguation pages are commonly the subject of move requests based on primary topic assertions, it is probably not necessary to provide any additional notice of such move requests on the project page. However, it would be nice if the project were notified when an editor wished to change an existing primary topic title to a disambiguation page (since the existing title is not a disambiguation page, the disambiguation project is not currently notified of such proposals, and a notification to projects listed on the article's talk page would also miss the disambiguation project). Cheers! bd2412 T 18:27, 20 May 2015 (UTC)

Mike: Sounds good. For technical guidance you might consider pinging the Wikipedia Template Project – I see their goal is to provide "help and guidance in creating, updating, correcting and testing templates." ╠╣uw [talk] 20:10, 20 May 2015 (UTC)

• OPPOSE!!! My concern that implementing this idea will make RM discussions more meaningless and WP will suffer is very serious. Considering so few have participated in this discussion that's significant. And I wasn't the only one. BD2412 also suggested something quite different from what was proposed. --В²C ☎ 19:12, 20 May 2015 (UTC)

Any editor who is opposed to "increased participation" in any part of WP is in the wrong place. --Richhoncho (talk) 12:14, 21 May 2015 (UTC)

FYI - I have initiated a request at WP:WPT to prototype an RM Initiated template that can be easily placed on Wikiproject Talk pages. Once it is available, I'll take to the question of whether increased participation in RMs through Wikiproject notification is desirable to the Wikipedia community at large via an RFC and see where it goes from there. --Mike Cline (talk) 12:30, 21 May 2015 (UTC)

This is an excellent idea to get more eyes into the RM process. The scant opposition is coming across like a gated community fearful of letting the hoi polloi in. Tarc (talk) 12:48, 21 May 2015 (UTC)

For the record, I am not opposing this. I often notify relevant projects myself when proposing a move that would benefit from expert attention. My comment above is merely directed to the idea that we should encourage editors to participate in RMs for other matters before participating in one for a matter that they feel invested in. bd2412 T 15:07, 21 May 2015 (UTC)

• Support as amended. Under normal circumstances I believe more eyes is a net benefit, even if some editors believe that a lack of RM expertise may complicate some processes. When I put SS Sultana up for RM a few weeks ago, one of my first edits after was a neutral notice to WP:SHIPS. Active participants there are experts in naming ship-related articles and are the most likely folk to work towards improvement of such articles. My intention was to make sure the project had input into titling an article clearly in their area of interest. The idea that editors who lack RM experience should be discouraged from participation is dubious. How else are editors supposed to gain such experience if not welcomed into participating such discussion? BusterD (talk) 15:57, 21 May 2015 (UTC)

• Support Someone who takes the trouble to join or watch a project is competent to take part in a RM discussion. Apuldram (talk) 16:10, 21 May 2015 (UTC)

• Support as more participation is better. In any group of editors, there will be some that have more experience than others in any given aspect of Wikipedia. Those that have less, but wish to participate, will gain useful experience. People who wish to participate ought not be told that they shouldn't. Omnedon (talk) 16:47, 21 May 2015 (UTC)
• Support. People will comment on the things they are interested in, not otherwise. --Richhoncho (talk) 17:22, 21 May 2015 (UTC)
• support. --SmokeyJoe (talk) 01:00, 22 May 2015 (UTC)
• Support, and I'm currently working on enhancing RMCD bot to automatically do this, similarly to how other pages in multi-move requests are notified. Wbm1058 (talk) 01:13, 22 May 2015 (UTC)

  @Wbm1058: - Many thanks for the initiative. If this is routinely accomplished by Bot then we'll need to change the wording a bit but still put the onus on requesting editors to ensure appropriate projects are notified. Thanks again. --Mike Cline (talk) 13:44, 22 May 2015 (UTC)

• Oppose this approach. Half the time the problem with an article title is that some "WP:LOCALCONSENSUS" at a wikiproject is doing something daft. A wikiproject-based RM "advertising" system will just WP:VOTESTACK RMs against site-wide consensus. We don't need an automated canvassing tool that does nothing but concentrate the !votes of editors who may already have too much influence over the article's title to begin with. A much more useful approach would be to simply add RMs to the WP:Feedback request service; I'm surprised this wasn't done a long time ago. FRS nets wide-ranging participation from across the WP editorship, and has been a boon to consensus-building for years.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  19:31, 17 August 2015 (UTC)
• Support. Sorry about the delay. No reason why only "fans" of RM should be notified. There is no reason to believe that those monitoring RM represent consensus on article titles, and there is no reason to believe that all those interested in the name of an article are actively monitoring the talk page. Because I am active in sock puppet reversion, I have over 19000 articles in my watchlist, and I would appreciate being informed of proposed moves of mathematics articles. — Arthur Rubin (talk) 21:20, 17 August 2015 (UTC)
• Support per nom. While common sense and common courtesy both suggest that those most likely to be interested in the topic should be informed of proposed moves, a few editors routinely neglect to notify relevant WikiProjects. It needs to be included as a requirement here, as proposed; if it can be automated, so much the better. Justlettersandnumbers (talk) 10:08, 18 August 2015 (UTC)

Automatic bot notifications

I've developed an RMCD bot enhancement to automate WikiProject talk page notifications. Here's the deal:

• The bot will find all WikiProject templates on the talk page where the requested move is initiated, where the template matches the string "{{WikiProject ". This will find most of the tags, but there are cases where shortcuts are used which the bot will not recognize as WikiProject templates, e.g. {{Comicsproj}}, {{TrainsWikiProject}}, {{WPMusInst}}, {{album}}, {{WP Languages}} and {{hurricane}}. These redirects will need to be bypassed for auto-project notifications to work.
• WikiProjects such as WikiProject Disambiguation, which already have Article alerts subpages such as Wikipedia:WikiProject Disambiguation/Article alerts, and do not want to be redundantly notified, may place the tag {{bots|deny=RMCD bot}} on their project talk pages, as I've done at Wikipedia talk:WikiProject Disambiguation.
• Additional pages on multi-move requests will not get this treatment, on the theory that they are related pages which are likely members of the same WikiProjects. If it's desired to give these pages the same treatment, that may be something I could do in a future enhancement, but let's keep this simple first, to ensure that any glitches are worked out.
• The bot coding is similar to that which notifies the additional pages in multi-move requests. The notification message for that is currently hard-coded into the bot, but that's not absolutely necessary. However, the bot does need to find a specific comment on the talk pages to ensure that it doesn't leave redundant notices. Something like <!-- Talk:FIBA EuroBasket crosspost -->, which prevents redundant notice postings on Talk:FIBA EuroBasket 2009. I suggest that we appropriate {{RM notification}} for this purpose. Use of that template is currently documented at Wikipedia:Requested moves § Relisting: If discussion has become stale, or it seems that discussion would benefit from more input of editors versed in the subject area, consider more widely publicizing the discussion. One option is to notify relevant WikiProjects of the discussion using the template {{RM notification}}. Applicable WikiProjects can often be determined by means of the banners placed at the top of the talk page hosting the move request. As we will now be implementing automatic bot-placement of that message, then its use when relisting becomes redundant. {{RM notification}} was once discussed here, and although its documentation doesn't call for substitution nor its coding require it, I only found it transcluded in one place (WikiProject Video games), which I substituted. I can modify this for bot-compliant usage, and then others will be free to tweak the text (bold-revert-discuss) as they see fit. The template will require substitution, and the bot will substitute it when it notifies WikiProject talk pages.

— any questions, comments or concerns? Wbm1058 (talk) 16:13, 22 May 2015 (UTC)

• How does the Bot handle talk pages that are redirected? for example Wikipedia talk:WikiProject Australia redirects to Wikipedia:Australian Wikipedians' notice board. --Mike Cline (talk) 17:21, 22 May 2015 (UTC)

  Good question. I'll have to do some research/testing to see whether it writes to Wikipedia talk:WikiProject Australia as Theo's Little Bot did. I suspect that it might. Maybe I can make it look for redirects and follow them. Wbm1058 (talk) 17:42, 22 May 2015 (UTC)

  Yes, stuck on the redirect page like Theo's Little Bot. I'm working on making it recognize and follow the #REDIRECT. - Wbm1058 (talk) 18:01, 22 May 2015 (UTC)

• I've got it following the redirects now. Australia and New Zealand are fairly unique in that they redirect to WP: rather than WT: pages. Here's a list of most of the active move requests with followed redirects:
  • WT:WikiProject India → Wikipedia talk:Noticeboard for India-related topics
  • Wikipedia talk:WikiProject Pakistan → Wikipedia talk:Notice board for Pakistan-related topics
  • Wikipedia talk:WikiProject Bangladesh → Wikipedia talk:Noticeboard for Bangladesh-related topics
  • WT:WikiProject Philippines → Wikipedia talk:Tambayan Philippines
  • WT:WikiProject Australia → Wikipedia:Australian Wikipedians' notice board
  • WT:WikiProject New Zealand → Wikipedia:New Zealand Wikipedians' notice board
  • WT:WikiProject Canada → Wikipedia talk:Canadian Wikipedians' notice board
  • WT:WikiProject USA → WT:WikiProject United States
  • WT:WikiProject Political parties → Wikipedia talk:WikiProject Politics/Political parties
  • WT:WikiProject College basketball → Wikipedia talk:WikiProject College Basketball
  • WT:WikiProject Salaf → Wikipedia talk:WikiProject Islam/Salaf task force
  • WT:WikiProject Hinduism → Wikipedia talk:Hinduism-related topics notice board
  • WT:WikiProject Christianity → Wikipedia talk:WikiProject Christianity/Noticeboard
  • WT:WikiProject Latinos → Wikipedia talk:WikiProject United States/Hispanic and Latino Americans task force
  • WT:WikiProject Free Software → Wikipedia talk:WikiProject Software/Free Software
  • WT:WikiProject Crime → Wikipedia talk:WikiProject Crime and Criminal Biography
  • WT:WikiProject British TV shows → Wikipedia talk:WikiProject British TV/Shows

• Wbm1058, thanks for your work on this. About the third bullet for notification to additional pages on multi-move requests, I'm not sure that is a good assumption (or maybe I'm misunderstanding). If the move proposes moving "Foo" which is currently a disambiguation page and only has the disambiguation wikiproject template to "Foo (disambiguation)" and as the additional part of the multi-move, to move "Foo (Bar)" to "Foo" where "Foo (Bar)" has some other wikiproject template, will that other project get notified? That sort of situation happens fairly often. Although, I think it's OK to go ahead and work the bugs out of the initial function as proposed, but I would encourage you to try for incorporating the additional notifications later. older ≠ wiser 18:26, 22 May 2015 (UTC)

  OK. See also User talk:RMCD bot § Requests for additional automated notices. I'll make these more of a priority now, while I'm familiar with this piece of the code. Wbm1058 (talk) 12:53, 23 May 2015 (UTC)

I'm about ready to go live with the initial version of WikiProject talk-page updates. For now, I've just hardcoded the text into the bot. After it's running smoothly, I can convert it to subst'ing a template, if that's still desired. Test edits to show what the messages look like are on the pages:

1. Wikipedia talk:WikiProject Organizations § List of designated terrorist organizations listed at Requested moves
2. Wikipedia talk:WikiProject Albums § Template:Allmusic listed at Requested moves
3. Wikipedia talk:WikiProject Western Asia § Zain listed at Requested moves

If you want the message tweaked at all, please reply here. Thanks, Wbm1058 (talk) 18:22, 28 May 2015 (UTC)

Looks good. One of the ideas at the beginning of this discussion was to include somehow the target title of the move. ie. Article X to be moved to Article Y. Not essential, but may prompt more interest if an editor sees the target of the move as well. --Mike Cline (talk) 19:07, 28 May 2015 (UTC)

Examples 1 and 2 above do show the target (the first is an article move; the second is a template). The third example doesn't show a target because it's a "moved somewhere else, with the name(s) being decided below" type of request. Wbm1058 (talk) 20:58, 28 May 2015 (UTC)

MY mistake, only looked at the last example. Good Job. Will adjust guideline text when live. --Mike Cline (talk) 22:06, 28 May 2015 (UTC)

Going live; the first update exceeded the maximum execution time limit which I set for the program, because there were so many WikiProject pages to update at once. The next update should get the rest of them. See the updated pages in special:contributions/RMCD bot. I see that WP:WikiProject Retail is a red-link; I'll look into why that happened. Wbm1058 (talk) 22:42, 28 May 2015 (UTC)

Timed out again. Hopefully the third time will finish them off. Once we're caught up, timeouts should not be a problem, and if they are I'll increase the time limit. Wbm1058 (talk) 22:52, 28 May 2015 (UTC)

I've just blocked the bot as this was posting large numbers of RM notifications on project talk pages (with the moves in many cases not being hugely relevant to the project given that project tagging is often broadly applied). The projects being targeted should have been informed of this discussion, and invited to opt in. Obviously this is a temporary block until the bot is sorted out and/or a broader consensus for this function is obtained. Nick-D (talk) 10:05, 29 May 2015 (UTC)

I've commented-out the line that posts the notices to WikiProject (talk) pages, so it is safe to unblock the bot to restore its usual operations. Wbm1058 (talk) 11:54, 29 May 2015 (UTC)

See User talk:RMCD bot § Issues with WikiProject notifications. I should have done a more thorough investigation into the overlap with the "article alerts" system, sorry. Wbm1058 (talk) 13:06, 29 May 2015 (UTC)

No worries - I've just unblocked the bot Nick-D (talk) 04:22, 30 May 2015 (UTC)

I'm continuing to refine the algorithm for WikiProject notifications. These projects subscribe to Article alerts, so will not be redundantly notified:

• Wikipedia:WikiProject Terrorism/Article alerts
• Wikipedia:WikiProject Military history/Article alerts
• Wikipedia:WikiProject Organizations/Article alerts
• Wikipedia:WikiProject Biography/Article alerts is interesting: "The Article alerts for this page are no longer delivered, because of the size of the report, which causes occasional problems for the bot."
  • My brief bot live-run posted 66 items to Wikipedia talk:WikiProject Biography
• Wikipedia:WikiProject Hungary/Article alerts
• Wikipedia:WikiProject Running/Article alerts
• etc.

See Wikipedia:Article alerts/Subscription list for the full list. Wbm1058 (talk) 00:18, 2 June 2015 (UTC)

I established the first RM-specific article alerts page: Wikipedia:WikiProject Biography/Article alerts/Requested moves

Now transcluded in the header of Wikipedia talk:WikiProject Biography

I imagine a complete index of recent requested moves, sorted by subject area, could be created using this technique. Hopefully without putting too much strain on AAlertBot. Such an index would be sorted by the 124 subcats of Category:Articles by WikiProject, but would omit articles not covered by a WikiProject. I wonder what the percentage of all articles is, that are within the scope of at least one WikiProject? – Wbm1058 (talk) 21:10, 3 June 2015 (UTC)

---

Ready to activate revised version of bot notifications. This version detects WikiProjects subscribing to article alerts, and avoids redundantly notifying them. Its messages also add a small note advising projects on how to opt-out from notifications. Examples of the new notification messages:

• Standard notice
• "?" notice

As most of the previous notifications from the initial run of this have not been reverted, upon reactivation, it is expected to add only about 30 new notifications. Hopefully with the new opt-out advice and more limited scope for notifications, this version will be accepted, and the bot will not have to suffer through another block. – Wbm1058 (talk) 19:24, 10 June 2015 (UTC)

I'll leave {{RM notification}} as-is, so it may still be used for notifications of relistings, so that all WIkiProjects, including those subscribing to article alerts, may manually be selectively (re)notified. Wbm1058 (talk) 19:34, 10 June 2015 (UTC)

My revamped WikiProject notification system is running live now, and updated just over 30 pages. I found one glitch: a notice was relatively harmlessly left on Wikipedia talk:WikiProject Global perspective task force, where few editors are likely to notice it. Talk:Iraq War has a {{WikiProject Global perspective task force}} on it, but Wikipedia:WikiProject Global perspective task force is a red-link. This is unusual, but it usually means that the template redirects elsewhere, so Template:WikiProject Global perspective task force is checked to see whether it's a redirect (it's not). So, even though Wikipedia:WikiProject Global perspective task force doesn't exist, it checks for Wikipedia:WikiProject Global perspective task force/Article alerts anyway, and when that's not found, it punts and writes to the default location Wikipedia talk:WikiProject Global perspective task force. I suppose I could enhance the bot's increasingly complex algorithm so that, when a redirect is not found in Template:WikiProject Global perspective task force, it looks for a {{WPBannerMeta}} in the template, and, if found, looks for the talk page of the page indicated by the "PROJECT" parameter; that would be Wikipedia talk:WikiProject Countering systemic bias/Global perspective. If you spot any more unconventional setups where the bot is not finding the best page for posting RM notices, please let me know. – Wbm1058 (talk) 19:24, 11 June 2015 (UTC)

I've reinstalled the beta version of RMCD bot which posts WikiProject notifications. Per § Broken bot? I had temporarily taken it down. Wbm1058 (talk) 18:38, 26 July 2015 (UTC)

Just noticed another minor glitch in my algorithm: Wikipedia talk:WikiProject First aid § Wikipedia:WikiProject First aid listed at Requested moves – the bot redundantly notified a WikiProject of a request to move the WikiProject itself. Wbm1058 (talk) 11:33, 27 July 2015 (UTC)

 Fixed Wbm1058 (talk) 22:27, 28 July 2015 (UTC)

Use requests for comment for supplemental RM notifications?

I also noticed Talk:Ellalan (monarch) § Requested move 26 July 2015, where someone decided to use WP:Requests for comment to give supplemental RM notifications. Although these two systems were originally developed by the same editor, they are now maintained by two different people, and they weren't really designed to be used together. So, if this practice is to become more widespread, then I'll need to make some accommodations to avoid an epidemic of malformed requests. Wbm1058 (talk) 11:54, 27 July 2015 (UTC)

Policy query

Where does it actually state that you shouldn't move a page when a requested move has just been proposed? You may think that's sort of obvious, but I've had the same editor on two separate occasions move pages where I had just started the formal processes. Case 1; case 2; and yes, Bettifm is the same editor as Whakaoriori. Schwede66 19:53, 21 August 2015 (UTC)

Good question, I can't think of an answer off the top of my head. Generally I think it would just be considered disruptive editing. Assuming no one else can find somewhere this is mentioned, perhaps it should be enshrined in policy somewhere. Jenks24 (talk) 08:11, 22 August 2015 (UTC)

Yes. Quick attempt at what the rule would be: When renaming a page, you should have to check to see if there have been past RMs. If there have, and similar renames were opposed, it should not be renamed without a RM. If there is a current RM, the current RM must be completed before renaming. A competent RM closer may close the RM and make the move, if it unopposed and unlikely to be unopposed (some people initial RMs over-cautiously). --SmokeyJoe (talk) 11:11, 22 August 2015 (UTC)

I have revered the move by Whakaoriori. SmokeyJoe I think you suggested rule is over complex. All that is needed is a comment that "A page move should not be made while an RM in open (unless it is a WP:RMUM in which case the RM should be speedily closed)." -- PBS (talk) 14:59, 22 August 2015 (UTC)

How to report WP:MEAT?

this is fairly blatant and was backed up by two first-ever-edit IPs shortly after. But this isn't an SPI is it? So help, how does one report a user for WP:MEAT? I have already left a warning on User Talk page. In ictu oculi (talk) 11:48, 28 August 2015 (UTC)

I've tagged the RM with Template:Not a ballot, which is what I generally see done at AfDs. I'd suggest reporting the user to WP:ANI, it's pretty blatant, but I'm not sure whether or not blocks are usually dealt for canvassing from other websites. Jenks24 (talk) 14:43, 28 August 2015 (UTC)

The template does not work, let me ask here.

The template does not work, I've tried several times, so I will ask in plain language here, sorry. I'd like to create a disambiguation page for Sarratt, with locations, but also the family name, with already at least Reed Sarratt and Charles Madison Sarratt (who might be related). I don't think I can do this myself as a non-admin. So: can you please move Sarratt to Sarratt, Hertfordshire, then turn Sarratt into a disambiguation page (which I can edit by adding places/names)? Please make sure the talkpage is fine when redirected too. Thank you.Zigzig20s (talk) 11:20, 25 August 2015 (UTC)

@Zigzig20s: I have created a disambiguation page at Sarratt (disambiguation), I hope it is what you envisaged. To move Sarratt to Sarratt, Hertfordshire and replace Sarratt with the disambiguation page will require a consensus. I'd suggest starting a requested move discussion at Talk:Sarratt outlining why you think the Hertfordshire town is not the primary topic. Because you will be requesting more than one page be moved, you will need to follow the instructions at Wikipedia:Requested moves#Requesting multiple page moves. I realise that templates can be tricky and that some of the pages I've linked can tend to talk in technical jargon, so if you need any further help please feel free to reply here or on my talk page. Jenks24 (talk) 14:59, 28 August 2015 (UTC)

Implications of decision

I decided a request move discussion in favor of moving the page. The reasons for the decision apply equally to several related articles, categories and a template that are listed in an earlier discussion. Is it appropriate for me to move all of these per the discussion, or should they be listed separately? RockMagnetist(talk) 23:27, 3 September 2015 (UTC)

@RockMagnetist: the categories should be tagged to go through WP:CFDS so that a bot takes care of everything. Other than that, yes it's appropriate to move all the related articles. Jenks24 (talk) 00:33, 4 September 2015 (UTC)

What about templates? Can a bot take care of that? RockMagnetist(talk) 02:55, 4 September 2015 (UTC)

No, if moved they have to be done manually, sorry I forgot to mention them earlier. Remember if you do move a template you need to update the |name= parameter to the new title you've moved it to. Jenks24 (talk) 12:14, 4 September 2015 (UTC)

How important is it to follow the RM procedure

Hi all

There's something of a mess going on at Talk:Denali right now, due to there being a move request opened two days ago, then a user boldly moving the article, then another user closing the RM 62 minutes after it closed. The issue is now being discussed in a couple of different places. Some might argue the new title is the correct one, and would be very likely to prevail in a properly completed RM, but the trouble with what's happened is that there is no clarity that that has occurred. If the proper procedures were followed, the arguments and mess that are occurring there right now wouldn't have happened, with editors discussing the issue in multiple places, and no definitive official procedure as to what should happen. I don't have a definitive answer as to what the best thing to do here is; in general I like the way RM works and I think it should be followed, but the consensus of the community as a whole may be that it needn't apply for cases that are controversial, but probably also likely to result in a particular outcome. Does anyone else who watches this space has an opinion?  — Amakuru (talk) 10:39, 1 September 2015 (UTC)

Should the community follow typical RM procedure: Yes, it generally results in good naming decisions. Should we expect community zealots on all sides of controversial issues to follow community procedure: No, as that would be asking too much. What the tortured discussion on Denali shows is that our naming convention re Commonname and Official names is a joke. Both are so inconsistently and opportunistically argued on a regular basis, that in effect, they don't mean much. Commonname especially is so vulnerable to selective use of evidence, that it isn't very useful if we want consistency in our naming. Official names however are essentially Black and White, but here again if some zealot what to argue that 3500 google hits indicates the new name isn't the commonname we deny its use as an article title. I personally would much rather see a policy that gives presidence to using the official name of any entity such as geographic features and organizations that have official government sanctioned names. We'd save a lot of angst in RMs. --Mike Cline (talk) 13:19, 1 September 2015 (UTC)

I think this is more of an issue with the editor that closed the RM than the process itself. If they refuse to accept any fault in what they did, then perhaps raise at ANI so they can be told by the wider community that they made a mistake. This is not the first dodgy close I have seen by a non-admin recently though. Number 57 13:40, 1 September 2015 (UTC)

I agree with you, but even on this issue I'm not sure if the community as a whole agrees. What should happen here, according to procedure, is that the article is moved by an admin, back to Mount McKinley, the move request reopened, and allowed to complete its seven day run before being assessed. I would hazard that many admins would refuse to carry that out, however, and editors all across the Wiki would call it a bureaucratic and unnecessary stickling for the rules.  — Amakuru (talk) 13:55, 1 September 2015 (UTC)

Yes, given that consensus on the talk page is overwhelmingly in favor of retaining Denali as the title, it would be a violation of WP:NOTBURO to move it back to the old title for a week for the sake of following the correct process. As for the broader question of having to follow the correct procedure for every move, WP:IAR is a policy for a reason. Calidum 14:09, 1 September 2015 (UTC)

Thank you both, Calidum and Amakuru, for saying that (in general; I have no opinion on the Denali matter in particular, and have not looked at that discussion). I believe the view you've both reinforced, about avoiding WP:BUREAUCRACY, is now the prevailing wisdom. I therefore propose that this position should be very clearly integrated into the WP:RM intro materials, because frequently people want to move things back to the status quo ante name on such technicalities as this, even when there's clearly a consensus that the current name is wrong, but the discussion has closed with slight favor for a better one but no absolutely clear consensus for it (e.g. because there's a third alternative others favor more). The anti-WP:COMMONSENSE result would be to revert back to the stupid name, but it's often what people want when they're WP:WIKILAWYERing to keep a name they're PoV pushing. In such cases it would be better to use the "okay" name and discuss later whether there's an even better one, than return to the "not-okay" name.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:29, 12 September 2015 (UTC)

Proposal for updating Wikipedia:Naming conventions (ships)

Following a Request for Comment on the matter of ship article disambiguation, I have drafted an updated version of Wikipedia:Naming conventions (ships). The proposed text can be found at User:Saberwyn/Proposed ship naming and disambiguation conventions update. Your project is being notified as, if the proposal is accepted, a large number of articles will need to be moved to meet the new guideline.

The most significant change to the guideline is that the only form of disambiguation for articles on ships is the year of launch, expressed in the format "(yyyy)". All other forms of disambiguation are depreciated, such as pennant/hull number, ship prefix, or ship type. Using ship prefixes in article titles for civilian/merchant ships is also depreciated, unless part of the ship's "common name". Examples have been updated as a result of the RFC and other recent discussions, and in some cases, elaborated on. A list of other changes can be found at User:Saberwyn/Proposed ship naming and disambiguation conventions update#Summary of changes for proposal.

Discussion and comments are welcomed at User talk:Saberwyn/Proposed ship naming and disambiguation conventions update. -- saberwyn 03:57, 13 September 2015 (UTC)

• I don't think this is a case of intentional forum shopping... but I note that there was no notice of this posted to WT:Naming conventions (ships) (I have corrected that omission). Suggest it be discussed there first. Blueboar (talk) 12:00, 13 September 2015 (UTC)

Rolling archive

At WP:RFPP there's this feature:

Fulfilled/denied requests

A rolling archive of the last seven days of protection requests can be found at Wikipedia:Requests for page protection/Rolling archive.

Something like this would be very helpful here, especially if covered, say, 30 days, or at least two weeks.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  17:16, 12 September 2015 (UTC)

Yes, something like this would be awesome. A full archive if that could be achieved would be even better. Jenks24 (talk) 12:37, 13 September 2015 (UTC)

Withdrawing?

I would like to withdraw an RfM I made this morning because I discovered it isn't following policy. Is there a mechanism to withdraw it? Thanks, Kautilya3 (talk) 22:04, 18 September 2015 (UTC)

Where is it? Number 57 23:08, 18 September 2015 (UTC)

Here: Talk:Paisaci#Requested move 18 September 2015. - Kautilya3 (talk) 23:13, 18 September 2015 (UTC)

@Kautilya3: I've closed it for you. Number 57 23:16, 18 September 2015 (UTC)

@Kautilya3:, just out of interest, what aspect of "policy" did your request not follow? Do you still think the move should be made, or have you discovered some facts that mean the current title is the correct one? Thanks  — Amakuru (talk) 09:11, 21 September 2015 (UTC)

According to WP:NCIN, a transliteration should be used in at least 75% of the reliable sources to be considered primary. I think Paisachi and Paishachi are about equally prevalent and so neither can be considered primary. I intend to file a new RfM for Paishachi which is the so-called "simplified transliteration." - Kautilya3 (talk) 09:15, 21 September 2015 (UTC)

Alright, thanks!  — Amakuru (talk) 11:43, 21 September 2015 (UTC)

can any one move/rename this template to new name

Kindly rename 'زير تخليق سانچو:Barnstar documentation ' to a new a correct , suitable name which is this 'سانچو:Barnstar documentation.--Jogi 007 (talk) 06:55, 2 October 2015 (UTC)

 Not done The page was deleted under speedy deletion criteria.--Aervanath (talk) 05:16, 4 October 2015 (UTC)

Technical delete Civility

As an AfC reviewer, I would like to accept Draft:Civility but the AfC tools will not allow until the Civility redirect is deleted first. I don't think this a controversial delete. Is this something that can be handled by someone here? ~Kvng (talk) 21:33, 4 October 2015 (UTC)

 Done @Kvng: DES ^(talk) 21:43, 4 October 2015 (UTC)

Thanks for the quick work. ~Kvng (talk) 21:45, 4 October 2015 (UTC)

Template:Inappropriate title-soft

An editor created Template:Inappropriate title-soft on August 26, and requested comments about it. Please feel free to join the discussion at Template talk:Inappropriate title-soft, to either reaffirm the consensus regarding notices of proposed article title changes in mainspace, or perhaps change it. Wbm1058 (talk) 02:30, 7 October 2015 (UTC)

Hi can you help me?

Hi can you help me with UTA Arad page? I want to delete the redirection pages.When you click on UTA Arad page I want to get there directly on that page without other redirections. Thanks !— Preceding unsigned comment added by Alexutz924 (talk • contribs) 13:59, 1 December 2015

It appears that you have been helped at UTA Arad. ←Click on that link to go directly to that page. Let us know if you still need help. Thanks, Wbm1058 (talk) 14:21, 18 December 2015 (UTC)

Inappropriate use of headings ; incorrect table of contents

Sections 4.3 and 4.4 in the TOC (Survey and Discussion) are not true sections and those links are non-functional. Those headings are part of a collapsed usage example. I'm sure there's a way to simulate headings in the example without using actual headings, but I don't know the best way to do that. ―Mandruss ☎ 01:40, 13 December 2015 (UTC)

After a closer look it appears those sections are produced by {{Requested move}} with |talk=yes. Any fix would have to be to that template, not here. I'm not pursuing that, so never mind. ―Mandruss ☎ 00:46, 14 December 2015 (UTC)

@Mandruss: I'm not sure exactly what your issue was, but note that {{fake heading}} is used to simulate section headings in documentation. Wbm1058 (talk) 14:09, 18 December 2015 (UTC)

@Wbm1058: You'll see the issue if you click on 4.3 or 4.4 in the TOC of the associated project page. Nothing happens, which I considered a problem. Those sections don't belong in the TOC. After I figured out that they are generated by a template, and I didn't see much chance of getting the template modified to conditionally use {{fake heading}}, I dropped the issue. ―Mandruss ☎ 14:36, 18 December 2015 (UTC)

Oh, I see, they do work when the by-default-collapsed "Template usage examples and notes" is opened. As the "usage examples and notes" is something I put there, maybe I can find a way to remove those two items from the TOC. Wbm1058 (talk) 14:42, 18 December 2015 (UTC)

@Wbm1058: I was thinking the only way would be to modify {{Requested move}} to support |talk=fake. ―Mandruss ☎ 14:45, 18 December 2015 (UTC)

OK, this is  Fixed now. The documentation is a bit complicated here; now I have two template mirrors which are used for documentation. – Wbm1058 (talk) 21:36, 18 December 2015 (UTC)

Thanks! ―Mandruss ☎ 00:19, 19 December 2015 (UTC)

Draft essay on Arguments to avoid in RM discussions

Along the lines of WP:Arguments to avoid in deletion discussions I have drafted User:Mike Cline/Arguments to avoid in Requested Move discussions. I would appreciate any feedback, especially the addition of other arguments to avoid or better examples for the current categories. Please provide feedback at: User talk:Mike Cline/Arguments to avoid in Requested Move discussions. I would eventually like to see this elevated to a Wikipedia Essay linked to this process. Thanks --Mike Cline (talk) 17:05, 8 November 2015 (UTC)

Comments from User:Born2Cycle moved to draft essay talk page. --Mike Cline (talk) 14:51, 11 November 2015 (UTC)

Great work Mike Cline. I have added my comments to the talk page. Tiggerjay (talk) 17:40, 21 December 2015 (UTC)

ACS UTA Bătrâna Doamnă Arad

Request move for ACS UTA Bătrâna Doamnă Arad to FC UTA Arad. The team reverted back to his former name. Thank you!--Alexiulian25 (talk) 21:02, 26 December 2015 (UTC)

• Please see Wikipedia:Requested moves#Requesting controversial and potentially controversial moves and when you make the request there, please be sure to have multiple, third party reliable sources that support this as the new name as references. Articles aren't simply renamed purely because of an official name change.
  • Upon further notice, it appears you are currently blocked from editing wikipedia. It appears that administrator Anthony Appleyard was involved in this move, so I'll send this request over to him to sort out. Tiggerjay (talk) 17:22, 5 January 2016 (UTC)
• @Alexiulian25 and Tiggerjay: On 4 Dec 2015 I history-merged FCM UTA Arad to ACS UTA Bătrâna Doamnă Arad. Google Translate says that "Bătrâna Doamnă" is Romanian for "Old Lady". Unfortunately, I am not a football fan and I know nothing about Romanian football clubs. Anthony Appleyard (talk) 22:36, 5 January 2016 (UTC)
  • Thanks @Anthony Appleyard: I will post this request over on the appropriate talk page. Will wait for someone more qualified to formally request a move on this topic. I'm not included to open a move request on behalf of a blocked user. Tiggerjay (talk) 00:15, 6 January 2016 (UTC)

What to do?

Sorry, I'm sure there's a guidance somewhere, I just can't find it. If a page is moved without a prior WP:RM discussion and this move is obviously controversial, what am I supposed to do? It's technically impossible to undo this move but it's clearly a violation of WP:TITLECHANGES. HerkusMonte (talk) 06:38, 11 January 2016 (UTC)

@HerkusMonte: Post a request in the Requests to revert undiscussed moves section of this page and an admin will take care of it. Cheers,  Philg88 ^♦talk 06:45, 11 January 2016 (UTC)

Can we formally ban relisters from subsequently !voting

I have recently again seen an editor relist a debate and then !vote in an apparent attempt to sway its outcome. I mentioned this in a couple of recent debates earlier this year and a couple of editors signalled their support for it. Does anyone have any objections to adding this (a ban on !voting for relisters) to the instructions? Number 57 08:45, 23 October 2015 (UTC)

• Sounds odd. I'd prefer to see non admins stop relisting. Admins are held to a higher standard, surely it is not admins playing these games? !Voting to sway and outcome doesn't sound like a shooting offence. --SmokeyJoe (talk) 12:55, 23 October 2015 (UTC)
  • @SmokeyJoe: The most recent one was a non-admin, but the first time I recall seeing it, it was a very experienced admin who subsequently weighed in with a "strong support" and then continued arguing for some time. It's not a shooting offence, but it's clearly inappropriate behaviour – in a way it's sort of a WP:SUPERVOTE. Number 57 13:47, 23 October 2015 (UTC)
    • Re: shooting: I think Number 57 means "ban the practice of !vote after you relist something", not "WP:BAN those who !vote after they relist something". Ah, the perils of jargon.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:27, 25 October 2015 (UTC)
• I'm not sure. Relisting and then voting straight after is obviously poor form, as is relisting a discussion where you're already a participant. But something I occasionally do is relist a discussion and then when it reaches the backlog again, rather than just relist indefinitely, I'll add a vote so that we try and reach a consensus. I'm interested in whether people think that is wrong, or has the perception of impropriety. Obviously if there's a consensus here to institute a blanket rule against relisters voting then I will abide by it. Jenks24 (talk) 13:22, 23 October 2015 (UTC)

This sort of relisting comment is very helpful, thank you for doing that. --SmokeyJoe (talk) 23:07, 26 October 2015 (UTC)

• I don't see a problem with relisters voting right afterwards, provided that there is obviously no consensus prior to their vote (meaning that the vote that the relister makes is not some sort of WP:SUPERVOTE that goes against the current consensus; doing so is almost akin to some sort of WP:INVOLVED issue) and the discussion hasn't already been relisted a ridiculous amount of times. Steel1943 (talk) 13:55, 23 October 2015 (UTC)
  • @Steel1943: I do see it as being a form of a supervote. Typically it is a discussion that would have had a no consensus outcome (so no move) and the relister then votes in favour – tipping the scales in their favoured direction. Number 57 15:14, 23 October 2015 (UTC)
    • @Number 57: I'd say that the situations would be better judged on a case-by-case basis. I could see someone relisting a discussion, then later on, realizing that they have an opinion that they feel they need to voice. Also, such a discussion probably needs to be listed elsewhere since this concern would probably have to apply to all discussion forums, and not just exclusive to RM. Steel1943 (talk) 15:32, 23 October 2015 (UTC)
• As an admin who reviews a lot of in progress RMs and closes a few in backlog on a regular basis, I think the idea here is a good one. Editors who have already voted in a RM really shouldn’t be relisting it as their motivation is always suspect. As well, editors who relist a discussion really shouldn’t now go and vote in the discussion for the same reason. Since editors can vote anytime, even when the RM is in backlog, if they want to weigh-in on the discussion, they can do so without relisting. Even though relisting is a good practice for keeping discussions without consensus or without participation going, any RM can be closed and decided once it’s been listed for 7 days. So I conclude that editors shouldn’t really be doing both—relisting and voting—in the same RM. Too much opportunity for misunderstanding motivations even if well intentioned. --Mike Cline (talk) 14:41, 23 October 2015 (UTC)
• I have no problem with any editor relisting, admin or non-admin, !voter or non-!voter. All a relisting does is extend the time for discussion, and increase the chance that new perspectives will be provided. Although there has to be finality at some point, I think the first relisting of a discussion should be completely open and available to anyone. bd2412 T 16:05, 23 October 2015 (UTC)
• strongly oppose I don't really see how this is inappropriate at all: ANY editor, involved or not, admin or not, can re-list the discussion, if they feel that the discussion is not yet concluded and more input is needed. If the input that was needed was their own input, then that is also their right to be heard. Relisting isn't a super-vote, because it's not a vote at all; it's not even a not-vote! It's merely an extension of the discussion, and I'm fairly certain we are not working to a deadline.--Aervanath (talk) 20:38, 23 October 2015 (UTC)

• Are you an admin 57 might have alluded to above? --SmokeyJoe (talk) 11:34, 25 October 2015 (UTC)

• It could be. Like I said, I see no problem with it, and didn't even think of it as anything significant before it was brought up here. Since it wasn't special, it wouldn't have stuck in my head.--Aervanath (talk) 18:51, 26 October 2015 (UTC)

• What if someone makes a habit of relisting every discussion in which their opinion is disagreed with by a slight majority? --SmokeyJoe (talk) 11:34, 25 October 2015 (UTC)

• @SmokeyJoe:I don't see what difference that makes to the eventual outcome of the discussion. If it's a "slight majority", then that's not consensus, so there's no point in terminating the discussion if someone has another two cents to add. If I feel that I'm bringing a novel argument to the discussion, then there should be time for other editors to chime and and tell me what's wrong with my argument. This whole discussion is mystifying to me, because no one has yet shown me a case where relisting and then !voting somehow changed the consensus. (We do still work off consensus, right? I've been inactive for a while, but I hope we haven't abandoned that ideal completely.)--Aervanath (talk) 18:51, 26 October 2015 (UTC)

I see it as something that can easily irritate some people. A little game to give their own !vote more time of exposure. A difference to the eventual outcome, probably not. A poor appearance, if someone looks like they are playing games, yes. Yes, we certainly do still work to consensus, and the the problem alluded to here is, I think, easily handled by the generally excellent uninvolved consensus-reading closes that are the norm. --SmokeyJoe (talk) 22:34, 26 October 2015 (UTC)

• Support labeling it inappropriate to !vote on something after relisting it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  05:29, 25 October 2015 (UTC)
• Probably if another five days after relisting, if no one else comments, it would be OK for the relister to come up with a !vote. But a relist is an administrative action, and administration and partisan contention in a discussion must not be mixed. At the time of relisting, the relister must have no opinion either way. A neutrally worded attempt to focus a RM discussion is obviously OK, even very helpful. --SmokeyJoe (talk) 11:30, 25 October 2015 (UTC)

• Someone who has already !voted should not relist. Only someone qualified to close a discussion should be allowed to relist it.
• Relisting, then !voting shortly after, doesn't look ideal, but if you honestly only discovered an opinion post-relist, then let's AGF.
• Neutral administrative comments and impartial statements encouraging focus do not count as !votes. --SmokeyJoe (talk) 22:41, 26 October 2015 (UTC)

• Support labeling it inappropriate. What we are discussing is the somewhat archaic concept known as "a seeming impropriety". I think most editors who relist and then add an !vote are doing so with good intent. They don't intend any impropriety. However, because the possibility exists that they might be gaming the system, relisting and !voting seems improper. We do need to hold those who perform administrative actions (whether they are officially admins or not) to a high standard. They should not only avoid actual impropriety... they should avoid even the appearance of impropriety. Blueboar (talk) 15:12, 25 October 2015 (UTC)
• Support some sort of prohibition. Someone should not be relisting a discussion and then immediately voting; nor should anyone who voted in a discussion previously be relisting. I would allow some latitude for a relister to comment after several days in the scenario Jenks describe above. (I also wouldn't mind seeing less relisting done in general, but that's a discussion for another time. Calidum T|C 15:17, 25 October 2015 (UTC)
• User:Tiggerjay here (edit summary "support and relisting") is probably a typical example. There is no wp:Game play, by relisting Tiggerjay presumably is decreasing the chance of an immediate hasty close that would probably take more notice of his !vote. But the relisting is a nearly meaningless act, except that it could be confusing to newcomers to see the one person playing both advocate and administrator. For this reason, even if no other, relisting while !voting, or after !voting, should be discouraged or prohibited, and !voting after a weeks preceding relist should require an explanation for the change of role. --SmokeyJoe (talk) 03:22, 30 October 2015 (UTC)

Interetingly enough, TJ also voted on and relisted a move request at Talk:Dissonants in a similar fashion [7] (though with two consecutive edits instead of doing them together). In this case, there was probably enough of a discussion that the move could have been closed as "no consensus" or "not moved" and the relisting wasn't needed, though the result will likely end up being the same. Calidum T|C 03:39, 30 October 2015 (UTC)

This is a really interesting discussion, and thank you SmokeyJoe for tagging me in this as well as specific diffs. After reviewing all of the comments above, along with about an hour of reviewing policies, I believe the core of this discussion comes down to the question of is relisting an administrative action of similar weight to closing? -- since that is what a supervote is really about. According to the closing instructions, "if a discussion is ongoing or has not reached a reasonable conclusion, you may elect to re-list the discussion." I agree with those who believe that a relisting action is non-administrative and is appropriate for any editor to engage in -- as it is simply calling for renewed and additional attention to the request. So long as there is no obvious attempts at votestacking through relisting, I think we can all assume a little good faith. Furthermore, I believe that newer users wouldn't see a relist and a !vote as a supervote. And I that frequent volunteers for RM would know better to evaluate each relist to see if there is bias or not on the topic, and if editor is trying to swing the consensus. Finally a quick look over at WP:RELIST as it related to AFD (although I'm less active in that realm) is equally vauge on this topic as to relistings and !voting.

Directing attention to the diff's brought up:

• At this relist and !vote I am confident that an experienced volunteer would see that it would make no sense that my vote was trying to do anything other than continue to the discussion while weighing in on this topic. If anything the relist was to see if there was any opposition for the move. Which as we can see, there was value in continuing the discussion.
• As to the other, diff brought up - at best it was no-consensus and a relist again was looking for more input.

In both cases, if we were to close the discussion 'as is' the !vote wouldn't have changed the direction of the consensus or lack there of. Which then begs the question, "why vote and relist at all, and instead simply close the discussion" -- the reason generally comes down to my belief that there is still more to be said about the particular move. While I may be !voting in a specific direction, I believe there is value in additional discussion, either based on existing things brought up, or that there might be more people wanting to weigh in on the topic. I believe closing a discussion before it has been completely discussed just because we've reached the 7 day threshold would be counter productive (see WP:NORUSH).

• Also here is yet another situation of a relist and !vote but in this case the relist was because the proposed name change was changed. Perhaps this is an example of what Number 57 was referring to in his initial proposal, since I was !voting contrary to him. However, what complicates this matter is the proposed name changed from what 57 voted against, to a more appropriate title, retaining the "Convention" element.

However with that said, I firmly believe that once !voted, they cannot close a RM (admin or not) -- which I know is not the topic of discussion here, but simply for clarity sake. (Although it appear I did this once back in 2012).

Additionally, we see that this process of relisting and voting does occur currently and historically with both non-admins and admins alike, including BDD and Aervanath - although I agree it should be rare.

With all of that said, I oppose this proposed change, but of course if we find consensus here, I'd abide by it.Tiggerjay (talk) 17:05, 30 October 2015 (UTC)

Not to sound rude, but I'm not quite sure what point you're trying to get across. Relisting (both an RM and AFD since you brought it up) is an administrative action. That doesn't mean only administrators can do it, but that the editor doing the relisting should be uninvolved (the guidance at WP:RM already says relisting should be done by "uninvolved experienced editors"). And for the record, there is no problem with something being closed as "no consensus" provided there has been sufficient participation. In the case of Dissonants, there was. Calidum T|C 18:54, 30 October 2015 (UTC)

Closing is clearly an administrative function but what about relisting? Therein lies the disagreement between the two sides, as far as I can tell... That is, some believe that relisting is administrative, and others do not. I think some have deduced that because it is listed on the RMCI page (that they have an option to perform a relist). However it's presence there does not imply that it is strictly a role for closers. This separation appears to be supported on actual text and placement on the RM page (which is what our regular users see), relisting is separate and distinct from the closing section (not a subset) and a direct read of that text (in context) demonstrates that anyone uninvolved can do it - with no implication of be a function of adminiship/clerk/etc. Furthermore, even the concept of uninvolved appears to have been injected in 2014 without discussion. The original relisting post on WP:RM said 'anyone' could perform a relist. Remember, just because a closer can relist does not mean ONLY a closer can relist. The concern about relisting being a SUPERVOTE is only valid if it is an administrative function. If SUPERVOTE is not implied, then a relister can vote, they just cannot subsequently close the RM. Moving forward, I would agree to EdJohnston's proposals about (1) clearly disclosure of intent by relister/voter and (2) affirming that a closer can ignore a relisting if there is already consensus. Tiggerjay (talk) 22:23, 30 October 2015 (UTC)

• Unrelated to my comments above, I would be in support to have the instructions cleaned up as follows: (1) have relisting information either on RM or RMCI, not on both (or at the very least have RM a stub of RMCI); (2) to clarify that a discussion can be closed simply after the initial 7 day period, without prejudice to a relisting request. Tiggerjay (talk) 17:15, 30 October 2015 (UTC)

• If we ban relisters from voting, they will never be able to vote. Why not tell or encourage them to vote rather than relist instead? Off-topic, but, as for nominators willing to relist, let them if there is no vote yet or just one vote or one support and one oppose. George Ho (talk) 18:06, 30 October 2015 (UTC)
  • Just to clarify, I meant banning them from !voting in the same discussion that they've relisted. Number 57 18:19, 30 October 2015 (UTC)
    • I know that. Still, relisters should have a right to vote. Of course, they should not game it to their advantage. George Ho (talk) 18:52, 30 October 2015 (UTC)
      • Why shouldn't that right be forfeited if they relist? WP:RM already says relisting should be done by an uninvolved editor. This is a logical extension of that. Calidum T|C 19:00, 30 October 2015 (UTC)
        • Actually, "best left to uninvolved experienced editors" implies high recommendation. George Ho (talk) 19:16, 30 October 2015 (UTC)
• In the abstract it may seem that the same person both relisting and voting may be undesirable. It might be helpful to see some examples of actual misuse. The edit by Tiggerjay that was given as an example seems harmless, though it would technically violate the rule that is being proposed here. That particular discussion was struggling to get enough input and is still not closed. If one person did it a lot (relisting and voting) perhaps I would think differently. One of the charms of the RM process is that it's usually so un-bureaucratic. We are usually free of the sizzling resentments of AfD discussions, and you often see people collaborating. As a middle way, how about *advising* relisters who also vote to comment in their vote about what they are doing. Finally, the closer is free to ignore the relisting if they think a consensus already exists and there has been enough discussion. EdJohnston (talk) 19:53, 30 October 2015 (UTC)
  • I would agree with the middle ground of advertising and ignoring relisting under consensus. Tiggerjay (talk) 22:32, 30 October 2015 (UTC)
    • I would be fine with that, since I thought that was already the norm: subsequent closers are not bound to wait another 7 days to close a relist, if consensus is clear. This way relisting becomes even less of an influential thing and makes it seem less inappropriate to our fellow RM regulars. It seems redundant to me, because I think relisting is a completely uninfluential action, but apparently I am in the minority in this discussion.--Aervanath (talk) 22:05, 4 November 2015 (UTC)

• I also agree with this chain of statements, since relisting a discussion doesn't reset the "7-day" requirement before a discussion can be closed. Steel1943 (talk) 22:14, 4 November 2015 (UTC)

• So what does relisting do? Virtually nothing. I think that if the relister doesn't make a pertinent neutral focusing statement, then don't relist. Old discussions with nothing much new belong at the back of the backlog, where some people prefer to start from. --SmokeyJoe (talk) 22:56, 4 November 2015 (UTC)

• Right, it does virtually nothing; so, why are we having a discussion about trying to blanket-ban relisting discussions with the assumption that any participant involved in the discussion is trying to game the system? As I stated previously, that needs to be determined on a case-by-case basis, not by some bureaucratic policy basically saying "don't ever do this; if you do, you may be blocked from editing." Steel1943 (talk) 23:09, 4 November 2015 (UTC)

• It's about little things that irritate some people. --SmokeyJoe (talk) 23:59, 4 November 2015 (UTC)

Recent RFC on exactly this topic

There was a recent RFC at Wikipedia talk:Deletion process/Archive 9#Relisting process – Should relisting discussions automatically exclude users from any !voting in the discussion? that is clearly relevant to our discussion here. The final consensus was reported by the closer as

Consensus is against including anything in the guideline about relisting and !voting at this time. That said, there is also general agreement that in some circumstances it's not a good idea, and that some caution is advisable when doing so.Sunrise (talk) 20:15, 28 July 2015 (UTC)

This is clearly something we should take into account here, and it seems to me that this is where we were already heading in our discussion above. I'd like to hear some thoughts on the matter. If it looks like most of us are on the same page, maybe someone can propose some appropriate wording for WP:RM and WP:RMCI to reflect the conclusion.--Aervanath (talk) 23:13, 6 November 2015 (UTC)

Suggested Approach

As adopted from a combination of existing policy with wp:relist and the discussion above

The intent of the move request process is to attempt to determine consensus on whether an article should be moved. However, if at the end of the initial seven-day period, the discussion has insufficient participation, and/or it seems to be lacking arguments based on policy, it may be appropriate to relist it, to solicit further discussion to determine consensus. Relisting may be performed by any editor for the reasons provided above. To avoid various community concerns, editors who are the nominator or have recently voiced their opinions on the move should avoid relisting. Additionally those who relist should generally avoid !voting immediately following a relist, instead waiting for a few days.

That said, relisting is not be a substitute for a "no consensus" closure. If the closer feels there has been substantive debate, disparate opinions supported by policy have been expressed, and consensus has not been achieved, a no-consensus close may be preferable. Additionally, relisted discussion may be closed once consensus is determined without necessarily waiting a further seven days.

To relist a move request discussion, simply use {{subst:Relisting}}, which signs the relisting automatically, immediately after the initial move request.

Relisting debates repeatedly in the hope of getting sufficient participation is not recommended. Therefore, in general, debates should not be relisted more than twice. Users relisting a debate for a third (or further) time, or relisting a debate with a substantial number of commenters, should write a short explanation on why they did not consider the debate sufficient.

If discussion has become stale, or it seems that discussion would benefit from more input of editors versed in the subject area, consider more widely publicizing the discussion. One option is to notify relevant WikiProjects of the discussion using the template {{RM notification}}. Applicable WikiProjects can often be determined by means of the banners placed at the top of the talk page hosting the move request.

— Tiggerjay (talk • contribs) 02:45, 10 November 2015‎ (UTC)

Discussion

I am going to call specific attention to a couple of items that I integrated into this suggest approach above. This topic was not resolved to consensus in the prior discussions, but rather this is a draft attempt at "middle ground" trying to address the various concerns of everyone involved... Here are the points I see as important:

1. Defining the purpose of a relist "to solicit further discussion" as adopted by WP:RELIST - if we're going to keep this process, then lets define its purpose and be okay with that.
2. Any editor can relist, as supported by actual admins commenting above.

• However, there is an advisory regarding "avoiding" !voting and relisting, specifically that the nom and recent !voters shouldn't relist, and that the relister shouldn't express any personal opinions on the move request any time immediately surrounding the relist (before or after). However, leaving room for them to be an early !voter, or someone who shares their thoughts after several days of the relist to avoid the potential viewpoint of a SUPERVOTE.

1. Reinforcing that "no consensus" is preferred to relisting, when that is appropriate
2. Reinforcing that relisting doesn't delay closing, when that is appropriate
3. Recommending the use of other methods to call attention to move proposals via Projects
4. Relisting shouldn't generally be done more than twice, but when rarely necessary, a comment should be provided. (This was taken from RELIST which doesn't require comments during relists).

Feel free to share your perspectives. Tiggerjay (talk) 16:43, 10 November 2015 (UTC)

• • I can live with that.--Aervanath (talk) 18:51, 13 November 2015 (UTC)
  • Pinging a few involved editors for their thoughts on this proposed middle ground approach to find something a bit better and more clearly defined. While not perfect, can we agree this is a step forward? Pinging in order of commenting on this discussion: Number_57, SmokeyJoe, SMcCandlish, Jenks24, Steel1943, Mike_Cline, BD2412, Blueboar, Calidum, George Ho, EdJohnston... any omissions are unintentional. Tiggerjay (talk) 04:54, 19 November 2015 (UTC)
• This is ambiguous. A "no consensus" with fewer votes is... kinda shaky and a mockery to what actually defines "no consensus". Without clarity, I can't go for the proposal on restricting relisting and stuff. Let's use "common sense" instead. --George Ho (talk) 04:57, 19 November 2015 (UTC)
• I don't like limiting relisters in a way that makes it hard to relist a discussion merely because it has not received a lot of attention. bd2412 T 05:12, 19 November 2015 (UTC)
• "Additionally those who relist should generally avoid !voting immediately following a relist, instead waiting for a few days." I understand what you're trying to say here, but I dislike how it's worded. It almost feels like its advising relisters who want to vote just to wait a few days before then voting to make it less conspicuous. Ideally (IMHO), if a relister wants to vote later, it should be because they have genuinely tried to close it and then decided voting was the best thing they could do. That of course is just how I tackle it though, so others might have a different view. I'd also suggest that the recommendation of only two relists be dropped down to one, which in my experience is the standard practice at RM (as opposed to AfD where they are generally more keen to relist twice or more). Jenks24 (talk) 06:33, 19 November 2015 (UTC)
• Support. I'm kind of surprised that a solution with that many points didn't raise a lot of red-flags, but it's actually very well reasoned and very moderate. I'd rather see a strong discouragement of relist-then-!vote, but can live with a mild one. I have to disagree with George Ho's take than a finding of "no consensus" when there are few participants is a big deal. "No consensus" just means "consensus has not clearly been reached, so the proposed change should not carry". That's a perfectly accurate summary of what happens when hardly anyone participates. It's far more problematic to declare consensus, for something potentially controversial, where there is low participation. That can take several years to undo if it did not actually reflect a real consensus but it's defenders push hard. A finding of no consensus may be moved past by nothing more than opening the discussion again a bit later and getting more eyes-and-brains on it this time around.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:23, 19 November 2015 (UTC)
  • Thanks, I tried hard to find a very middle ground that satisfied most concerns, while making a step in a better direction. Tiggerjay (talk) 22:37, 19 November 2015 (UTC)
• I still think relisting is irrelevant, unless it comes with a meaningful comment to help refocus. --SmokeyJoe (talk) 11:13, 19 November 2015 (UTC)

• This relist (by User:Jenks24) seems particularly counter productive. I remember seeing it in the backlog, and was thinking about it when it disappeared from the backlog. The backlog is a great place for discussions that have already been ignored by the subject interested editors, where the implication is "please, anyone, give some input here". Relisting did nothing but remove it from the high profile list, and we wait another seven days before flagging it again as backlogged. --SmokeyJoe (talk) 02:52, 17 December 2015 (UTC)
• And now, as I was typing here, User:EdJohnston closed it "no consensus", presumably influenced by the fact that no one had commented for seven days, the seven days it was hidden by relisting. It is almost comical. --SmokeyJoe (talk) 02:55, 17 December 2015 (UTC)

• @SmokeyJoe: Presumably Ed closed it because it reached the backlog again. I would have made the same close at about this time (the UTC day ticks over at 11am my time when I am not often online) if Ed hadn't gotten to it first. I gave it a relist because there was no consensus at the time, but – and I need to be careful how I word this – no consensus is not an optimal outcome. That doesn't mean that I won't close as no consensus, but if there is a chance that giving a discussion an extra week will possibly result in a consensus one way or the other then it's worthwhile giving it a go. Rarely is there a problem with waiting an extra week at RM, it is better to get them right than get them done quickly. A no consensus close is basically an invitation to take up the same discussion again in six months, which is obviously less optimal than a clear result one way or the other.
  I think we fundamentally see the role of the backlog differently. I don't see it as a place where we are generally desperate for comments, it is a place for discussions that are ready to be closed. If more participation is required then relisting or dropping neutral notices at e.g. a wikiproject (or both) is the way to go – very few editors actually seem to be looking at the backlog with an intent to participate in the discussion and I generally find that relisting and pushing it to the top of RM will generate more comments than waiting indefinitely in the backlog. Additionally, there are some discussions where what is simply needed is time to make a close more valid and less likely to be contested – time that is more easily done filtering through the RM list than sitting in the backlog uncloseable for a week but making every potential closer look over it.
  Next I'll toot my own horn a bit, hope no one minds overly. If I recall correctly, that relist was after I'd come back to closing RMs after missing a week or two because of real life commitments and, frankly, the backlog was a mess (my ego would like to say that me being away was the contributing factor, but odds are it was a combination of things). In any case, this is what it looked like, my rough count gives over 90 discussions in the backlog which is obviously a number that makes it impossible for people to comment on backlogged discussions and also, IMO, puts off potential closers, most of whom do not have a solid chunk of hours to commit to the backlog but are able to pick off a couple here or there (and are often willing to do one or two 'difficult' ones, but are unable to just kill 10-20 'simple' ones). In my experience, people are actually more likely to do that if the backlog is in a manageable state – when it blows out we tend to get less admins making closures. Anyway, here is the diff of the next three hours. There a couple of closures by other people, but my rough count is that I closed 27 discussions and relisted one. A few days later, I got through most of the rest of the backlog and it appeared back in reasonable shape. Other people made closures in the interim, but it would be fair to say I made the majority. That time I made 29 closures and relisted six. The backlog was down from 90+ to 13. By the way, as of typing, five of those six relists have had additional comments, most only a day or two after the relist leading me to conclude that people commented on them because they saw them at the top of the queue again. The only one that hasn't (Talk:Life thru a Lens) is a much easier no consensus close after a week of waiting (and has hurt no one because the result is the same either way, it's just clearer with an extra week).
  So what I'm trying to say with this rambling post is that the backlog serves no purpose if it's huge – even people like yourself looking through the backlog to comment can't possibly read over every discussion. It also seems to put off closers. And I forgot to mention this earlier, but it builds distrust in the function of RM – people begin to move articles unilaterally if it looks their RM is going to languish in the backlog forever. A relist, rather than just letting it sit in the backlog, lets the proposer know that someone is monitoring the discussion, gives them someone to ask if they have a question about how long things will take, and gives people who have a little experience with Wikipedia backroom processes (such as AfD) a rough guidance on how long things will last. The drawback of this is that sometimes, in what I think are relatively rare cases (such as the House of Romanov RM), discussions last a little longer than they absolutely need to. Ultimately I think the positives vastly outweigh the negatives. Jenks24 (talk) 08:58, 17 December 2015 (UTC)
• P.S. apologies if this sounds a bit defensive, I do understand your comments here are completely in good faith and an attempt to improve the RM process. Jenks24 (talk) 08:58, 17 December 2015 (UTC)

• Relisted AfD debates are categorised separately, to attract new attention.

Old MfD debates go below the "Old Business" line, and it is easy to review the discussions from bottom up.

At WP:CfD we have Wikipedia:Categories for discussion/Previous 8 to 21 days; Wikipedia:Categories for discussion/Previous 22 to 42 days; and Wikipedia:Categories for discussion/Previous 43 to 63 days, where it is very easy to review old and very old discussions for open discussions by colour coding.

Old RMs, where there is no emerging consensus after the seven days allocated to allow weekly editors to give their input, should be categorised and findable as old RM discussions desiring input from a wider set if editors.

The WP:RM practice of feeding old RMs back into the top of the list is, in my considered opinion, both perverse and counter-productive. I think this practice should be stopped. --SmokeyJoe (talk) 21:41, 17 December 2015 (UTC)

If someone wants to create a tracking page or category for relisted RMs that would have my support. It's obvious when reviewing the list which RMs are relisted though because the relist becomes part of the nomination string. I'm honestly not sure why you consider it "perverse and counter-productive", every XfD process I've participated in (can't recall MfD, that might be an outlier) relists old discussions on whatever the current day's page is. Jenks24 (talk) 09:24, 18 December 2015 (UTC)

Adding an example that shows relisting generates discussion. Talk:Vanathirayampattinam got two comments directly as a result of the relist. It has now sat in the backlog for over 10 days and has not got one comment in that time. Jenks24 (talk) 10:01, 18 December 2015 (UTC)

• As I read these discussions I wonder if it has to do with fundamentally how people approach the list when the go to the page. It is inferred that some people take a bottom up approach, while others a top down. Second to that is the "role" or position that volunteer has ascribed themselves to as a member in the RM process -- that is, for example, some view themselves as general contributors, niche, just the backlog, and closer, etc... and I'm sure there are other ways people see themselves as helping the RM process. But I think the first element, where they start on this list, has a big impact on their perspective of relisting. While perhaps not universal, it would seem that those who start at the bottom (for example those who 'work' the backlog) see moving it to the top as counter productive. While those who work the list 'top down' see relisting as prompting for additional interest. Tiggerjay (talk) 22:05, 17 December 2015 (UTC)

• Yes, thanks Tiggerjay. However, even for those who work from the top down, why does sending the relisted RM to the top help. They have already seen it. I consider it disruptive to reviewing today's nominations to have a random mix of 8 and 16 day old nominations in the same space. --SmokeyJoe (talk) 22:11, 17 December 2015 (UTC)

• Well my point wasn't to argue the merits of the different approaches or to over analyse them, but rather to simply share that those commenting here might be approaching the list differently... But to dive in a bit to what you said... I would guess that people that work the top down see relist as disruptive, as you described. Where as "bottom up" people who like to clear out the backlog, approach it from the perspective of the backlog should be as small as possible. If it can be closed, great. If not, we need to do something with it. Those who work bottom up, see it as a way to (1) acknowledge that someone has evaluated it (close/relist) and (2) the attention of new editors (and often actually find it); and (3) remove it from their 'view' because someone has dealt with it. Yes, there are some top-down people that work the lists religiously (which find it a nuance), but then there are those who only contribute periodically. For those, they get the chance to add the value of their experience into the mix. Tiggerjay (talk) 00:05, 19 December 2015 (UTC)
• Also upon reflection I realized that those who take a bottom up approach find 'not relisting' to probably be a similar nuance that top down find relisting. Using your anology, the backlog can fill with requests that are intentionally left open for more comments, but it can quickly fill up the backlog, leaving those who prefer to work the backlog, having to weed through many articles that they have already reviewed. One added benefit of relisting is that it has the ability to spread the relisted elements across multiple "days" instead of all being in one place. As of right now that would add over 25 relisted items under the backlog category, versus the average of 3-4 on a daily basis. So if you're always working "todays" RMs then you're going to encounter say 10 new requests and 3 or 4 relists (which, BTW are clearly visible on the RM list itself). As opposed to adding another 25+ to an already full backlog, such as now, which as 26 items that really need backlog attention. By keeping all relists in the backlog, you'd double the size of the backlog. Sure, it might be kicking the can down the road for 7 days, but it continues to keep them spread out. It is the perspective of adding 30% relisted items to a daily worklog, versus doubling (ie 100%) of the backlog... And relisting has the benefit of keeping them spaced out every 7 days or so... Tiggerjay (talk) 01:32, 19 December 2015 (UTC)

• I largely agree with the suggestion, but also with the gist of Jenks24's comments. Certainly the "no consensus is preferable to relisting" is a step forward. Number 57 12:35, 19 November 2015 (UTC)
• I am beginning to wonder whether "relisting" as a process serves any useful benefit in RM discussions. Purportedly the purpose is garner more participation in the discussion, but that rarely happens based on relisting alone. More participation in my experience occurs generally from two acts—1) explicit, but neutral notifications on relevant project pages, guideline and policy talk pages and noticeboards. 2)non-neutral (discouraged) or neutral canvassing of interested editors directly. In my view, neutral notifications should be an unequivocal condition when listing a title at RM. The burden should be on the requestor at the time of the request, not another editor who comes along and relists the discussion after 7 days. In my experience, if participation by interested editors has been encouraged, then once an RM hits a "No consensus" state, it rarely goes back. Also, if participation by interested editors has not been encouraged, then relisting rarely alters the state of participation or the discussion. We should ask ourselves this question: If we eliminated the "Relisting" process all together and all RMs over 7 days old would remain in Backlog until closed, would there be a detrimental effect on the overall RM process? I think not. --Mike Cline (talk) 15:04, 19 November 2015 (UTC)

Draft 2: Relisting

This revision attempted to incorporate all of the input provided above (along with some simplifying) with the exception of eliminating the relist process all together. There is merit in eliminating it, but it seems to be against current consensus to eliminate it. Please review and comment. Tiggerjay (talk) 23:53, 25 November 2015 (UTC)

If at the end of the initial seven-day period, the discussion has insufficient participation or arguments based on policy, it may be appropriate to relist it. Relisting may be performed by any editor for the reasons provided, to solicit further discussion to determine consensus. To avoid community concerns regarding WP:GAMING, editors should avoid relisting when they are the nominator or have recently voiced their opinions on the move. Those who relist should avoid !voting immediately to avoid the appearance of a WP:SUPERVOTE.

Properly closing a discussion is always preferred to relisting, whenever possible. Additionally, relisted discussion may be closed without waiting an additional seven days. To relist a move request discussion, simply use {{subst:Relisting}} immediately after the initial move request.

In general, debates should not be relisted more than once before closing. Users relisting a debate for a second time, or relisting a debate with a substantial discussion, should write a short explanation on why they did not consider the debate sufficient to close. When relisting, consider publicizing the discussion to relevant WikiProjects using the template {{RM notification}}. Applicable WikiProjects can often be determined by means of the banners placed at the top of the talk page hosting the move request.

Premature Vote Attempt
The following discussion has been closed. Please do not modify it.
Vote After working on the proposal, Mike Cline (and others) have brought up an excellent point regarding relisting -- perhaps relisting is unnecessary for RM and creates more problems than it solves. Shall we vote on that concept? Tiggerjay (talk) 22:37, 19 November 2015 (UTC) I don't necessarily fall under any of the below categories, but I do think relisting serves a useful purpose. I'll elaborate on this when I get a chance. Jenks24 (talk) 11:52, 20 November 2015 (UTC) Remove Relisting as an element of RM Keep Relisting and adopt above proposal as a step in the right direction Keep Relisting the way it is for now

Final attempt to take something substantive from this discussion

Seeing as how Tiggerjay spent a lot of effort trying to produce a consensus here, and the discussion simply died, I have added this line to the closing instructions:

"Please note that while there is no consensus forbidding participation in a requested move discussion after you have relisted it, there are a sizable number of editors who consider it an inadvisable form of WP:SUPERVOTE. If you want to relist a discussion and then participate in it, be prepared to explain why you think it was appropriate."

It's intentionally a very weak summary of what was expressed above. If anyone still cares to contribute, feel free to revert and continue the discussion here. Yours in good faith,--Aervanath (talk) 23:21, 11 January 2016 (UTC)

Thanks, I have also boldly added which I believe to be uncontroversial of 'relisting at most once' without preparing an explanation. While there is debate on relisting, as long as it is part of the process, I think we all agree that limiting it to one relist without a specific reason is preferred. Tiggerjay (talk) 02:10, 12 January 2016 (UTC)

Alternate List Views Available

• Just a note that there is an alternate format Wikipedia:Requested moves/Current discussions (alt) for the bot-generated current discussions list. There seemed to be some editors who felt that relists were causing the list to be presented in a format which was less than ideal for their preferred personal process of reviewing the open items on the list. It may be possible that, if there is enough demand, I could add another alternate listing. which presented relists separately, or sorted by the date of the original request. So, if you would like to have an alternate list in a different format, post your suggestions here, and if there is enough demand, I'll consider implementing it. Thanks, Wbm1058 (talk) 13:56, 12 January 2016 (UTC)
  • Can you explain how this alternate format works? That is, how does this display differently than the normal list? Tiggerjay (talk) 17:30, 12 January 2016 (UTC)

    This difference is relatively minor:

    • Wikipedia:Requested moves/Current discussions puts the (Discuss) links at the start of each line, right after the bullet
    • Wikipedia:Requested moves/Current discussions (alt) puts the (Discuss) links after the current and proposed titles, but before the rationale for the request

    Each list is basically written at the same time, with each bot update where something has been added or removed from the list, in two consecutive edits

    I'd have to look through the project history to confirm, but I believe the (alt) list was briefly the default, before the current format replaced it

    While this difference in lists is pretty cosmetic, just saying that it's possible to implement another list where the difference is more substantial, e.g. listing "relists" separately or something else — Wbm1058 (talk) 15:35, 13 January 2016 (UTC)

RfC as an alternative to multiple relists

Occasionally I see move requests being submitted through the WP:Requests for comment process, which, as I understand it, typically runs for 30 days, rather than a week. Sometimes they are cross-listed in both RM and RfC, though the syntax for successfully doing that is very tricky, and should be simplified if this were ever to become a common practice. However some, it seems, prefer RfC to RM for whatever reason, and don't advertise their RfC move requests here. For example, see Talk:Ásatrú in the United States#RfC: Should this article be renamed "Heathenry in the United States", which has been controversial, at least in the recent past, yet discussions around the topic draw rather limited participation. Just noting this here, in case anyone wants to comment on this practice. Wbm1058 (talk) 18:56, 16 January 2016 (UTC)

Interesting observation. I used to me more active with RfC, but find myself less involved in RfC lately. I would imagine that it might be similar for others as well. The RfC process might be missing out on the involvement of experienced RM editors. It would be interesting to see some sort of reconcilliation between the two. Tiggerjay (talk) 20:19, 16 January 2016 (UTC)

Backlog is growing

The backlog is growing pretty steadily. Not sure what the case of this is... There are some pretty hefty controversial move discussions without clear consensus needing experienced admins to close. I'm trying to hack "work" away at the list for those where consensus is clear. Tiggerjay (talk) 18:18, 20 January 2016 (UTC) (edited 16:33, 21 January 2016 (UTC))

Apologies for nitpicking, this is intended largely in jest: I suggest you rephrase "hack" to "work". Your closes are not "hack"s. --SmokeyJoe (talk) 05:30, 21 January 2016 (UTC)

The jests are well taken. To be clear I was referring to hacking, in the sense of hacking/whacking down the tall grass that is overgrown. But nevertheless, comment edited. Tiggerjay (talk) 16:51, 21 January 2016 (UTC)

It happens. One trick I use is to look at a diff of the last few days from Wikipedia:Requested moves/Current discussions and see who's closing – I only counted two admin closers in the last three or so days which will bloat the backlog. Thanks for your work, I think you've made the most closes in the last couple of days, but someone will hack through the backlog eventually so there's probably no need to be closing RMs where you're involved even if it's unanimous. Jenks24 (talk) 01:51, 21 January 2016 (UTC)

I hope no one considers "unanimous" a sufficient reason to break the NOTINVOLVED requirement on closers. A nomination with no other comments would count as unanimous. --SmokeyJoe (talk) 05:27, 21 January 2016 (UTC)

Thanks Jenks! Point taken SmokeyJoe, however I read WP:INVOLVED differently. While I would agree that under normal circumstances any editor who has voiced an opinion on a topic should not close it, per WP:INVOLVED, "Involvement is generally construed ... to include current or past conflicts ... disputes on topics. [C]alm and reasonable discussion and explanation...advice about community norms, and suggestions on possible wordings and approaches do not make an administrator 'involved'." So in the event of growing backlogs that are not moving, there is clear consensus, and the close would not be seen as controversial -- in this specific, narrow situation, I believe holding to the narrower scope of 'involved' is acceptable. Tiggerjay (talk) 16:51, 21 January 2016 (UTC)

@SmokeyJoe: Tell me if I've misinterpreted what you said, but I feel like WP:NOTINVOLVED is not as strict as your comment implies. The first sentence of WP:INVOLVED is "In general, editors should not act as administrators in disputed cases in which they have been involved." (emphasis mine) I have always taken that to mean that if there is true unanimity (i.e., not disputed at all), then anyone is free to close the discussion. After all, if it's truly unanimous, nobody's going to complain that you were involved. Also, if it is a requested move with no other comments, and the week has passed with no other comments, then it's perfectly okay to not relist it and just make the move, barring any further policy considerations. If I opened an RM, and no one commented for a week, then I'd simply close it myself and make the move.--Aervanath (talk) 01:44, 22 January 2016 (UTC)

The Capital P Policy section WP:INVOLVED is more stern and more narrow that want I wanted to convey, and it was not a thoroughly considered post. I don't think there is any question here of anyone having crossed WP:NOTINVOLVED.

I wanted to refer to "Good closing practice", and I am not sure is such a thing is documented. It is not good closing practice to close a discussion you are the nominator, even if unopposed, because it may provide a poor example to newcomers. In this situation, maybe it is better to withdraw and boldly move?

I was slight bothered by the reference to unanimity. It begs the question of quorum. Can one or two be called unanimity? There is danger of lack of advertising, of the one or two being a biased selection.

However, your final point reminds me (I had thought thought it this way) that in RM discussions, quorum is one, subject there being zero objection even anytime previously. Considering that point, I have to agree that it is not improper to close an unopposed RM and to do the move. Maybe such a close should ideally call the discussion "unopposed" and not "consensus to move".

Or does any unopposed nomination after the standard period of time allow for a closing of "Concensus per WP:Silence". I think: yes. --SmokeyJoe (talk) 06:42, 22 January 2016 (UTC)

• I think it is fine. At WP:W I see only two screens of listings. NB I consider the format of the listing there to be far more pleasant than that at Wikipedia:Requested moves/Current discussions. The oldest there is not so old. Also, it's not as if these proposed moves belong at the top of the priority list in terms of project needs. --SmokeyJoe (talk) 05:27, 21 January 2016 (UTC)

• Not my normal habitat but I've closed about 20. --Malcolmxl5 (talk) 11:22, 22 January 2016 (UTC)

Requested move Talk:The Blue Flame → Talk:Jimmy James and the Blue Flames

This 26 January request got fouled up. In the Current discussions section it reads:

The Blue Flame → ?

It should read:

Talk:The Blue Flame → Talk:Jimmy James and the Blue Flames

Rationale for the proposed move:
Requesting that Talk:The Blue Flame be moved to Talk:Jimmy James and the Blue Flames. The former article The Blue Flame was moved 9 March 2014 to the current Jimmy James and the Blue Flames.[8] However, the associated talk page was not moved at the time and should be with the new title. Hope this can be straightened out. Thanks, —Ojorojo (talk) 02:11, 27 January 2016 (UTC)

I've made the move as uncontroversial. For whatever reason, talk pages don't list properly if you are trying to move the actual talk page. On the off chance you ever come across a problem like this in future where just the talk page needs to be renamed it's probably easier to just submit it at WP:RM/TR. Jenks24 (talk) 03:14, 27 January 2016 (UTC)

"Potentially controversial"

I seem to be spending an increasing amount of time commenting on moves that were wrongly put into the "uncontroversial" RM section, or just done boldly. My recollection is that the language on this page around what is potentially controversial used to be stronger. In any case it should be made so now. The page is long and complicated and too many people are clearly not getting the message.

• At Wikipedia:Requested_moves#Undiscussed_moves we say: "Anyone can be bold and move a page without discussing it first and gaining an explicit consensus on the talk page." - I take this to be a statement of the technical situation, rather than a "guideline"-type statement that says this is ok, but its import is rather ambiguous. To clarify, we should add something like "But this should not be done if the move is potentially controversial, as defined in the next section." Personally, I think we should then also add something like: "This is especially the case with articles that have any page views or incoming links", as I have often boldly moved articles where "Someone could reasonably disagree with the move" (a very high bar), but only if I am clear my reasons are correct, and the article is obscure and probably little-watched. Poplar was recently "boldly" moved from a redirect to Populus to the disam page by an ex-arb, no less, who quoted the sentence above as justification (it's now a debate at Talk:Poplar).

• At the section for listing "Uncontroversial technical requests", there should be a warning under the heading to remind, or inform, editors what these terms mean. Far too many requests that are clearly potentially controversial and also non-technical get listed here. For example, the section currently holds:

Ancient Greek wedding customs → Marriage in ancient Greece (move (@subpage)) – The article as it now stands was created as part of a merge with Marriage in ancient Greece and Ancient Greek marriage law, and is broader in scope than simply wedding customs. "Marriage in ancient Greece" would more accurately reflect the scope of this article. – Caeciliusinhorto (talk) 16:07, 3 February 2016 (UTC)

(Oppose How is this an "Uncontroversial technical request"? You may well be right, but this is a potentially controversial non-technical request that should have a normal discussion opened. Johnbod (talk) 20:43, 3 February 2016 (UTC))

Another recent example can be seen at Talk:Hiberno-English, where a move listed as "uncontroversial" was reversed (thanks Jenks), and then decisively rejected in a discussion with many participants.

Thoughts? Johnbod (talk) 20:49, 3 February 2016 (UTC)

• Is it being done repeatedly by the same editors, or different editors each time, or by complete newcomers to RM? --SmokeyJoe (talk) 21:23, 3 February 2016 (UTC)

Bold moves are certainly done "repeatedly by the same editors" in some cases, who have I expect often have never seen the page here, or just don't care. But this page is currently too ambiguous to make it clear this is incorrect, and fixing that might help. Of the ones who post at "Uncontroversial technical requests", I haven't noticed 1, so 2 and sometimes 3 I think. Let's face, it the instructions are a long and fiddly read, and many pretty experienced editors very rarely come here, so don't have it at their fingertips. Johnbod (talk) 04:12, 4 February 2016 (UTC)

• I would support more clarity and guidance on what might be considered "controversial"; our approach on Wikipedia, and what has made the project successful, is that we are not bogged down with bureaucracy or the need to get consent before making an edit. However, that has to be balanced against the harm done when someone makes an inappropriate edit. If a page move is clearly inappropriate or disruptive it can be undone and the person responsible given guidance or sanctioned - so I don't think Johnbod is talking about those sorts of moves. I think John is concerned about dubious moves, where an editor sees a reason for a move, but perhaps this reason has been previously discussed and rejected, or where the consensus would be against it for some reason that may not be immediately apparent. Things to look for that would indicate a page move may be controversial would be useful (and while we're at it, consider if the term "controversial" is perhaps unhelpful in itself - perhaps use a word that indicates that a move may cause problems rather than disagreement - how about "problematic"?). Checking incoming links is one way to see if a move may be problematic, and would benefit from a wider discussion. Checking if there is a history of page moves. Checking page views. Checking discussions on the talkpage to see if there has been previous discussion, or if the article attracts polarising views. These are things I tend to do myself before a page move, though interpretations can sometimes differ - in the case of poplar for example, I looked at incoming links for both poplar and populus, and felt that in most cases the poplar link was unclear (a sense of wanting information on "poplar tree" rather than on a genus, and that if populus was intended that might have been the more likely term used).
• My suggestions:
  • Change "controversial" to "problematic"
  • Give guidance on what might cause problems, such as "over 500 links" (though if the move is straightforward the links should just move to the new target - page links are best consulted when creating or moving dab pages), such as previous page moves or discussions, such as high profile - "over 30,000 pages in 90 days", such as the topic being controversial or divisive.
• On the whole I feel that guidance rather than restrictions should be given, and that the status quo should be to allow editors to make bold decisions rather than open a formal page move discussion first. Page move discussions can drag on, and there is usually a backlog. If we inhibit the confidence of editors too much, the backlog will only grow. If a page move does prove to be problematic or "controversial" it will be discussed anyway - so those sort of moves filter themselves naturally. SilkTork ^{✔Tea time} 10:23, 4 February 2016 (UTC)

There is nothing wrong with the existing guidance, except that too many people, including you, don't seem aware of what it is, I think partly because it is getting lost in a rather complicated page. A plunge into terminal vagueness with "problematic" would be a bad idea. Please don't try to guess what I "think". Johnbod (talk) 23:09, 4 February 2016 (UTC)

• The complication and fiddliness of the page can be fixed by reorganizing it. See all the WP:XFD pages as models. The is the only XfD-ish page that doesn't have a really distinctive "These are the instructions" thing. It would probably also help to rename the uncontroversial section "Speedy moves" and lay out specific criteria (some of which can be borrowed from other XfDs that deal with speedy moves). RM is an XfD (the since the D generally stands for discussion, AfD not withstanding), and people would treat it like one if it were presented as one. If this were done, there would be no need to raise or lower the bar about what constitutes an uncontroversial move. Just spell it out more clearly: RM1, RM2, RM2a, etc., qualify as speedy move criteria; if not listed among them, use regular RM process. The end.

  I'm strongly opposed to decreasing the threshold of what constitutes "controversial", because it's already insanely gameable. All it takes is Editor A doesn't like Editor B, so they "controvert" B's moves, then run to ANI and complain that B is abusing speedy RM to make "controversial" moves; if A canvases everyone who doesn't like B and e-mails the right friendly-to-A admin, a dumptruck of shit will pour on Editor B's head, and lead to them being persistently hounded in several topic areas for years. This has actually happened to me (and after the dust settled, virtually every single article in question ended up being moved exactly as I proposed in followup full-RMs, because they were in fact uncontroversial to begin with). It was a ridiculous pile of WP:LAME WP:DRAMA, all engendered by the vague wording here. We absolutely do not need RM making up magically special exceptions to WP:EDITING, WP:CONSENSUS, WP:BOLD, WP:OWN, and WP:5P, and the ability of editors to take WP:AT policy at face value and apply it. We do need more clarity than vague and easily abused notions about "controversial" or "problematic". They're both pretty useless. In the end, the actual controversy generated by gameable rules about controversy is worse than some moves having to be undone and discussed in full RMs because they shouldn't have been speedied. Speedy moving works at other XfDs because the criteria are clear and things that don't qualify are rarely listed much less administratively acted upon.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:56, 10 February 2016 (UTC)

Personally I was against the creation the "Requesting technical moves", as I think that if a move is non-controversial no one will oppose it and unlike requests for deletion there is no reason why most technical should have to be done quickly. So personally think that the "Requesting technical moves" section should be removed from this page. As to the "Undiscussed moves" I added that section to stop move wars and allow the status quo to be the default. This is particularly helpful in discouraging pre-emptive moves by an editor capturing the high ground and hoping that a move back would show no consensus -- this aids stability.[@user:Johnbod:] The wording I used in that section uses "can" and not "may" for a reason: "Anyone can be bold... you may revert". -- PBS (talk) 23:12, 18 February 2016 (UTC)

Agreed that the "Undiscussed moves" section is useful, but the "Rtm" one is as well; when routine maintenance runs into edited-redirect blockages, if they're not dealt with promptly, the cleanup gnoming tends to stop, and the editor will move on to something else, leaving the cleanup unfinished. Rtm is sometimes problematic, because it's not set up with clear speedy move criteria the way the other XfDs have; too much is open to interpretation (and thus misinterpretation and conflict).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:13, 19 February 2016 (UTC)

Default moratoria on repeat RMs

As seen, yet again, this time at Talk:43rd_Canadian_federal_election#Requested_move_9_February_2016 "Could you let me know what policy states the required time between a closed RM and opening a new one?" someone wants and needs policy advice on how long to wait before proposing the same question agains.

I think there has for many years been an unwritten understanding of six months. For example, "We have a long tradition that after a WP:RM is closed that it is not re-listed for six months after the last listing. --PBS (talk) 07:45, 9 July 2009 (UTC)"

Drawing from the similar Wikipedia:Renominating for deletion, I suggest that we agree to the following (or similar):

If an RM discussion on a page has recently been closed, the close deserves some respect. You may ask the closer about the closer, or take it to Wikipedia:Move review if you then still disagree, but otherwise the close must be respected. You may be eager to initial a repeat RM proposal, when identical, or similar. If so, then slow down. A quick repeat without new evidence or arguments is very unlikely to be successful, it is more like to be received as disruption.

If the close did not record a defined moritorium before a new RM, then the following rules apply by default:

If the previous move was close as a "no consensus", do not make a new proposal within two months of the close. If the previous move found a consensus, do not make a new proposal within six months of the close.

In either case, a new proposal must summarize all previous closes on the same discussion, and attempt to make a more comprehensive nomination than was made previously.

In rare cases, new evidence may arise after the close, evidence that may have altered the participants opinions. These cases may constitute reasonable exceptions to the above time limits. The most polite thing to do would be to ask the previous closer's permission.

I am not sure if this is better written into policy, instructions at Wikipedia:Requested moves, or in an essay linked from the policy or instructions. I am leaning to preferring an essay, or supplement, given some authority by being linked from the WP:RM instructions. --SmokeyJoe (talk) 23:59, 9 February 2016 (UTC)

It's about time! I support the thrust of this entirely. It's short enough to include as a section at WP:RM itself; if moved to an essay, it will just be ignored. Some copy editing quibbles:

• "You may be eager to initial a repeat RM proposal, when identical, or similar." doesn't quite parse. Maybe "initiate a repeat RM proposal that is identical or similar"
• Would change "received" → "perceived" (more editors will understand the latter, since that usage of "received" is uncommon).
• The two defaults should be given in list markup, so they don't run together.
• "more comprehensive" doesn't really get at it. The new one needs to specifically provide at least one of:
  • additional rationales
  • stronger support for the previous ones
  • increased clarity, if the previous RM was confused or confusing
• I'm skeptical that we want previous RMs summarized in the new one, as it would make for very long RM postings (and the summaries are unlikely to be neutral very often). Rather, these summaries should be made in a signed comment by the nominator immediately after the RM tag.
• "previous closes on the same discussion" is WP:GAMEable. Try "previous closes of substantially similar move discussions about the page(s) being renominated" (this also avoids the problem that the same page or set of pages can be nominated for completely different kinds of moves, without one implicating the other)
• "The most polite thing to do would be to ask the previous closer's permission" ... "if it was an administrative close." No one needs to ask anything about a WP:NAC. Would also change "permission" to "advice"; admins are not law-givers.
• Maybe add a point: "Immediately proposing the same sort of failed move on a different page with the same alleged titling defect may be perceived as forum shopping if the cases raise no distinct considerations." (Worded carefully; often there are unique considerations, and RMs of remarkably similar names may pass or fail for highly particular reasons, like treatment of the names in RS. What we don't want is someone pursuing a PoV-based change to pursue it individual article by article until they get their way on one, then do a mass RM citing the one "victory" as a precedent. It could actually still be done, but it would take years instead of weeks, and few PoV pushers have that kind of patience.)

 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:24, 10 February 2016 (UTC)

I think what Smokey may be getting at with "more comprehensive" is something to the tune of "be sure to consider previous discussion and specifically provide comment on opposing rationale"? A new discussion should be able to say "these rationale were not IAW X !rule; these rationale did not take into account this (new) evidence); and etc." as well as "these rationale were not presented previously; these evidence were not presented previously".

Agreed that this guidance should be in WP:RM. --Izno (talk) 13:47, 10 February 2016 (UTC)

Thanks SMcCandlish. Good copyediting. I suggest that you or others interested in copyediting do so on the copy below. --SmokeyJoe (talk) 01:50, 11 February 2016 (UTC)

I've made some more substantial changes to the below. I don't think I've changed the intent, but I wanted to clarify the language. This kind of guideline is extremely open to rules-lawyering, and so we should probably be as precise as possible. I think the section on forum-shopping should be removed, though. While I understand the sentiment, I believe it is already covered under WP:Disruptive editing. Cheers,--Aervanath (talk) 10:55, 11 February 2016 (UTC)

Looks good, although I'm on the fence as it relates to essay versus on WP:RM simply because the RM page is already getting pretty long, and I wonder if adding this will contribute to TLDR? Especially for those who are more likely do actually be our targets of this concept. Perhaps a link at both "When not to use this page" as well as under "Requesting controversial and potentially controversial moves" would be better and call the necessary attention. Also the essay would be probably be a good think to include in the closing template as well. Tiggerjay (talk) 17:19, 11 February 2016 (UTC)

If an RM discussion on a page has recently been closed, it is usually seen as disruptive to file a new Requested Move that is similar or identical. If you think the discussion was closed incorrectly, you may ask the closer to reconsider, and then open a discussion at Wikipedia:Move review if disagreement remains. While opening a new Requested Move is not forbidden, per se, a proposal without new evidence or arguments is very unlikely to be successful. It is much more likely to be perceived as disruption by your fellow editors, so a reasonable amount of time should pass before opening a similar or identical proposal.

In certain acrimonious cases, the closer of the most recent Requested Move discussion will have suggested a moratorium of defined length before a new RM should be opened.

If they did not, the following time should pass before proposing a similar or identical move:

• No consensus, 2 months,
• Consensus, 6 months.

In rare cases, new evidence may arise after the close that may have altered the participants' opinions. These cases may constitute reasonable exceptions to the above time limits. If you believe this applies, it is recommended that you ask the previous closer for advice on whether a new discussion will be seen as disruptive.

Whether the normal moratorium period has passed or not, a new proposal should take into account any similar preceding discussions, and attempt to improve on the evidence and clarity of rationale compared to previous proposals.

Proposing the same sort of failed move on a different page with the same alleged titling defect may be perceived as forum shopping if the cases raise no distinct considerations." (Worded carefully; often there are unique considerations, and RMs of remarkably similar names may pass or fail for highly particular reasons, like treatment of the names in RS. What we don't want is someone pursuing a PoV-based change to pursue it individual article by article until they get their way on one, then do a mass RM citing the one "victory" as a precedent. It could actually still be done, but it would take years instead of weeks, and few PoV pushers have that kind of patience.)

• I still think that it is a bit advicey, and a bit long, and think that the core rule of default times to wait belong on WP:RM, with a link to a supplemental essay containing all of the explanation and advice and reiterating the core rule of default times. --SmokeyJoe (talk) 02:49, 16 February 2016 (UTC)
• Are people generally happy with the 2months/6months times? Is it well understood that these, like all things, are subject to occasional exceptions, and that the time measures from the close of the last RM? --SmokeyJoe (talk) 02:49, 16 February 2016 (UTC)
• All fine by me. As a bit of an aside, I often close RMs that are either poorly attended or that have good alternatives suggested that don't get the discussion they should with a note that there should be "no prejudice" against starting a new RM as soon as anyone wants. Judging from the above discussion, it seems everyone is OK with that still happening, so my question is if anyone feels there is any specific way this should be spelled out when making a close? E.g., should I explicitly refer to once it comes into force or is a simple "no prejudice against a new RM with X as the proposed title" alright? Jenks24 (talk) 06:36, 17 February 2016 (UTC)

Your practice of encouraging a followup RM on an idea that grew in the discussion is very good. "no prejudice against a new RM with X as the proposed title" sounds good, I think it clearly applies that a default waiting time doesn't apply. --SmokeyJoe (talk) 11:17, 17 February 2016 (UTC)

I concur.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:52, 17 February 2016 (UTC)

• I agree that perhaps just the core rule, essentially "A new move request that is substantially similar or identical to a previously closed move should wait at least, 2 months for non-consensus closes, and 6-months for moves closed with consensus (either to move to not move). Unless it an alternative wait time was mentioned in the prior move closure." With link to the fuller essay. 08:34, 17 February 2016 (UTC)
• I prefer the fully-developed version. That it's not tiny just means it needs a section header. The more we structure this like other XfD pages, with distinct and hard-to-miss sets of instructions, the better.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:52, 17 February 2016 (UTC)

Beware a coming wave of "like" RMs

Note to RM admins: There is an ongoing WP:LAME dispute at Wikipedia talk:Manual of Style/Capital letters#The word "like", over which I poured a cold bucket of reliable sources with little effect. A number of editors participating in it display little linguistic experience or understanding, and don't even seem to get the fact that there are multiple capitalization standards regarding prepositions: academic, mainstream, and journalistic, of which Wikipedia uses the mainstream one. As a result, several of them are convinced that prepositions they don't want to recognize as prepositions (e.g. "like" used as one in various song title constructions) "must" be capitalized on WP because they see them capitalized in journalistic style (which capitalizes all prepositions of four characters or longer, versus Wikipedia's five or longer, and academic style's none-of-them-ever). At least two of these editors appear to be on a tendentious mission to change the titles of a large number of WP artivles on songs and albums (meanwhile, the fiction, literature, journalism, etc., wikiprojects are not involved in this fiasco, and know better).

I have to suggest that such RMs be speedily closed as forum shopping when they pop up; the ongoing campaign is a WP:FAITACCOMPLI attempt to push in a magical exception for the world "like" to see it always capitalized; if enough song titles are done this way, in a river of "like"-related RMs too long for most editors to keep track of, the over-capitalizers who seem to be trying to speak for the pop music projects will WP:WIN, you see. There are no sources anywhere that support such an exception (including in music journalism), and there thus is not and will not be one at MoS for it. The only plausible change is that MoS could adopt the four-letter rule from journalism, but this is not likely to gain consensus, as it would mean capitalizing "with" and "from" in titles. Far more editors will find millions of cases of that in our articles to be jarring, than the handful who are angry about "like" just because they don't understand there are multiple styles and MoS doesn't use the one that Rolling Stone does. The logic problem here is in supposing that because music journalism is reliable for facts about bands and albums that it's also somehow a reliable source on how WP must write encyclopedic English just because music is involved. This is the specialist style fallacy.

Anyway, if you look at that discussion you'll see that an editor there has created a "hit list" of articles he wants to rename based on his pet, counterfactual theories about language use, and even started crossing titles off of it. He's also drawn up a what looks like a canvassing/battleground roster of editors whom he thinks are on his side vs his opponents (he'd be wrong, since we'd all look at these titles on a case-by-case basis; having supported "Like" vs. "like" in one particular title for a particular reason is not blanket support for always capitalizing it against normal English rules). No one put themselves on his lists, and it all has a WP:POLEMIC character to it. All in all, it looks like a WP:GREATWRONGS campaign in the making, and if it sallies forth, a big swath of disruption at RM is likely.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  23:47, 17 February 2016 (UTC)

How is this anything but an attempt to poison the well with a discussion elsewhere going against your preference? The admins who close requests know how best to judge actual consensus; you don't. Calidum ¤ 05:19, 18 February 2016 (UTC)

MOS is not directly relevant as AT has its own guidance and naming convention guidelines to cover such issues. This policy tends to favour follow the usage in reliable sources and not to be prescriptive as the MOS tends to be. -- PBS (talk) 11:13, 18 February 2016 (UTC)

I don't see how this is poisoning the well but instead warning admins closing RMs against potentially WP:POINTed behavior. --Izno (talk) 12:52, 18 February 2016 (UTC)

It was an attempt to "poison the well" because SMC went well beyond a simple warning ... Be aware that SMC is heavily involved in the discussions at various MOS pages, and has taken a stance. Thus, his call for us to reject the RMs (before they even begin) is just as POINTy as the RMs he warns us about. A more neutral "warning" would have been to simply say: "we may be getting a lot of RMs about how to capitalize the word "like"... be aware that this issue is the subject of current discussions at various MOS pages (link to relevant discussions)."

That said, I do agree that we should approach these RMs with caution. But the caution goes in two directions. There is a lot of WP:GREATWRONGS behavior by some editors on both extremes of this issue (I do not include SMC in that). We all need to be aware of that as we move forward. Let's reject the extremes and find common ground. Blueboar (talk) 17:47, 18 February 2016 (UTC)

"Poisoning the well" is the same metaphor as "salting the earth"; it means making a place uninhabitable (or a resource unusable) by anyone, including oneself, just to prevent someone else from using it. Doesn't apply here; no salt or other poison is being dumped into RM or any articles. This is more in the way of a booster shot against a memetic flu going around. PS (re: Calidum's comment): The RMs are not going against my preference. PS: Supposition that closers automatically know better than anyone else how to close is the argument to authority fallacy; those who understand policy best know best how to close. While many admins here are very well-steeped in policy, and better steeped in some policy that I am, I definitely know this and most other policy a few orders of magnitude better than any "I've been on WP for 9 months" green admin, and than the average non-admin closer, neither of which group is prohibited from closing RMs. An admin hat doesn't magically make you smarter.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:13, 19 February 2016 (UTC)

Re: What PBS said – The idea that "MOS is not directly relevant as AT has its own guidance and naming convention guidelines to cover such issues [and] tends to favour follow[ing] the usage in reliable sources and not to be prescriptive as the MOS tends to be" is simply counterfactual, in at least three ways. MOS is cited (correctly) in thousands of RMs. WP:COMMONNAME determines what the name is ("Sony" vs. "Zony" or "Suny") not how to style it ("Sony" vs. "SONY"). COMMONNAME and the rest of WP:AT are not a style policy and never have been. WP:NCCAPS says nothing at all that conflicts with WP:MOSCAPS. AT and the NC guidelines all defer to MOS on style matters, quite explicitly in about a dozen places. There is no well to poison, but thanks for the accusation of bad faith. What is happening is that a small but tireless and vocal minority are convinced that COMMONAME is a style policy, not a name policy. Their efforts to get certain pet styles forced onto and into articles here (on a narrow subset of topics, mostly song/album titles lately, though it's been others before) by consistently miscasting policy and relying solely upon usage in a particular subset of sources (e.g. music journalism this time around, which uses a "capitalize most prepositions" style that WP and non-journalism style guides off WP do not) has been confusing RM respondents and some closers into going along with a bogus "common style" notion that actually has nothing to do with COMMONNAME's wording or intent. When it comes to cases like "iPod" and "Deadmau5", we use those stylizations not because of WP:COMMONNAME but because both WP:MOSCAPS and WP:MOSTM themselves have provisions to allow for exceptions when the RS very consistently make one. I.e., even the idea that these special cases' styles have anything to do with COMMONNAME is an error.

At any rate, the point of my notice here was that some editors are clearly gearing up for a wave of RMs that should either be shut down pending resolution of the underlying matters at the relevant policypages (it's an open issue at both WT:MOSCAPS and WT:AT at least), or allowed to continue but weighed very carefully as related to each other and inspired by unresolved ongoing controversy – whichever RM admins prefer. They should not be taken at casual face value, as especially NACs are likely to do, or it will just lead to a long string of WP:MRs. It should not be necessary for those who understand that WP follows one of three well-documented capitalization conventions and is not crazily trying to follow three conflicting ones at once, to have to explain this in detail at 50 simultaneous or back-to-back RMs.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  20:05, 19 February 2016 (UTC)

• Related: One of the song-titles-must-be-maximally-capitalized-because-I-say-so editors just showed up at my talk page after making an undiscussed move, with the expressly stated intent of trying to generate a move war on purpose [9]. (It's particularly farcical because the capitalization he performed is not even controversial; the "as something as" construction is adverbial, not prepositional, as any good dictionary clearly indicates, so it would be manufacturing a controversy where none can reasonably happen). Several of these people simply do not know what they are are doing or talking about, they're just on a WP:BATTLEGROUND march about song titles, without any understanding of or regard to any sourceable capitalization standards like the one WP has. The same editor it going on at an R.E.M.-related move (also about "as") insisting that the usage is conjunctive even after both Oxford and Cambridge sources are cited proving him wrong. This is what I'm warning about. The exact same deep-fried nonsense is on the menu for a long list of song/album articles with "like" (often synonymous with "as") in their titles.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  21:07, 19 February 2016 (UTC)

Requested move with a COI

Is this a proper way to request an article move with a COI? I followed the instructions for a controversial move as that seemed like a sensible way to make a move request, rather than doing it boldly, but in actuality the move request is not controversial and shouldn't need an RFC-like format or anything. David King, Ethical Wiki (CorporateM) (Talk) 18:19, 14 March 2016 (UTC)

RfC on Wikipedia talk:Article titles

You are invited to comment on a request for comment on Wikipedia talk:Article titles#RfC: should the artist name be included in the titles of articles about songs and albums when other songs or albums of the same name exist, but do not have standalone articles? Thanks. sst✈ 15:43, 20 March 2016 (UTC)

Specifying disambiguation pages.

I have added: "In particular, use this process before moving any existing page with incoming links to create a disambiguation page at that title". This should go without saying, but people continue to move well-established articles without discussion to create disambiguation pages - often questionable ones, full of partial title matches and obscure meanings relative to a clear primary topic. bd2412 T 18:20, 11 March 2016 (UTC)

Hear hear!  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:13, 19 March 2016 (UTC)

Yes - I agree. Good addition. Dohn joe (talk) 16:59, 7 April 2016 (UTC)

Error in Determining consensus

There is a grammar error in the section Determining consensus in the last line before Relisting. I can't correct it because I can't determine what the author really means. "...as long as soda can took through consensus and can be determined to be the actual long-standing title." Shhhnotsoloud (talk) 09:16, 11 April 2016 (UTC)

The text in question was introduced to WP:Requested moves/Closing instructions § Determining consensus by this 04:13, 9 April 2014 edit by Red Slash. The only change to that since it was (apparently boldly) added was by the same editor at 19:47, 5 April 2015. – wbm1058 (talk) 18:50, 11 April 2016 (UTC)

s/took through/took over through/. Dicklyon (talk) 19:48, 11 April 2016 (UTC)

 Done wbm1058 (talk) 01:48, 12 April 2016 (UTC)

Discussion to address contradiction between WP:RMNAC and WP:NACD

A discussion has been started at Wikipedia talk:Deletion process#Contradiction between WP:NACD and WP:RMNAC to address a possible contradiction between WP:NACD and WP:RMNAC in regards to when a non-administrator can close a move discussion to "move" when the move requires a page at the move destination be deleted before the move can be executed. Steel1943 (talk) 20:05, 12 April 2016 (UTC)

Marriott Hotel Rename | Niagara Falls

The wiki for Marriott Gateway on the Falls Hotel is currently out of sync with the name of the hotel as of March 2016 which is now Marriott on the Falls Hotel.

A redirect and renaming would help since there are many references still online to the name Marriott Gateway on the Falls Hotel that still apply in function but not name to the business and building located on the same property.

Kurtismccartney (talk) 15:15, 14 April 2016 (UTC)

 Done – wbm1058 (talk) 22:31, 14 April 2016 (UTC)

Proposed draft for new "Page mover" permission

Please see Wikipedia:Page mover for a proposed new userright that would have an impact on this venue, and leave any comments at Wikipedia talk:Page mover. –xeno^talk 01:32, 17 April 2016 (UTC)

• Now an RFC: Wikipedia talk:Page mover#RFC - Proposed: "Page mover" permission to be created. –xeno^talk 00:27, 19 April 2016 (UTC)

Hypixel

Moot

At Draft Talk: Hypixel, the nominator has deleted opposition to the move request [10] -- 70.51.200.96 (talk) 05:17, 7 May 2016 (UTC)

This seems to be in reference to this, which someone already reverted [11], so there's nothing to do.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:15, 8 May 2016 (UTC)

Requested moves/Closing instructions

RMCI probably needs to be updated to reflect the new page mover ( extendedmover ) user group. PaleAqua (talk) 02:17, 25 May 2016 (UTC)

Umm ... why?

If your reasoning includes search engine results, please present Google Books or Google News Archive results before providing other web results.

I can't for the life of me figure out why someone thought this was a good idea.

1. It takes what might be good advice for some RMs and not others and tells OPs that they should always do this if citing web results.
2. It is not always the best advice even using Google services: Google Scholar is neglected, as is adding quotation marks and, for instance, "site:.edu" (this latter is usually far better when dealing with scholarly topics than news and book searches).
3. It explicitly promotes the use of Google over other search engines.

I have opened a lot of RMs over the years, but I don't do so frequently enough that I don't have to copy-paste the template from this page every time, and I don't think I noticed this wording before today -- was it added recently?

Hijiri 88 (聖やや) 10:44, 31 May 2016 (UTC)

Hijiri 88, the text in question was most recently edited (other than adding a period to end the sentence) by PBS with this 29 December 2012 edit, so it's been stable for at least 31⁄2 years. wbm1058 (talk) 17:09, 5 June 2016 (UTC)

Stable, apparently, but I do have to agree with Hijiri that it isn't well phrased, for the same reasons he lists. While the idea, that one should do a more through analysis than just a quick Google test, is good, it's too specific in its advice, to the point of hurting neutrality. oknazevad (talk) 18:43, 5 June 2016 (UTC)

No argument with that from me. I don't think a lot of people pay too much attention to this. I just noticed that PBS neglected to make the same change to the identical advice for multi-moves, and as I don't see any reason that advice should be any different, I just updated that now, so at least the single- and multi-move instructions are consistent in this regard. – wbm1058 (talk) 21:02, 5 June 2016 (UTC)

Earlier versions of the text; not substantively different with regard to your concerns:

• If your reasoning is based on search engine results, please provide the results of searches using Google Books or Google News before providing any web results.
• If you use search engine results, please default to Google Books or News Archive before providing any web results.

It appears that the initial addition was by Fuhghettaboutit on August 8, 2012. Perhaps they can explain why, per their edit summary, "This is a constant issue". – wbm1058 (talk) 22:07, 5 June 2016 (UTC)