Jump to content

Wikipedia talk:Requested moves/Archive 25

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 20←Archive 23Archive 24Archive 25Archive 26Archive 27→Archive 30

No consensus outcomes (revimetasited)

This discussion is about Wikipedia:Requested moves/Closing instructions in response to the {{Disputed tag}} re-posted at WP:RMCI#Determining consensus by SmokeyJoe (talk) at 02:48, 11 December 2012, with edit summary: This section still contradicts policy WP:TITLECHANGES para 1
Archived discussion: Wikipedia talk:Requested moves/Archive 24#No consensus outcomes

I believe I could delete this tag, per {{Disputed tag}}: "If there is no active discussion, then the tag may be removed by any editor," but I'd like to take a fresh look. – Wbm1058 (talk) 18:42, 11 December 2012 (UTC)

I added a clarification per what I was saying in the section above and boldly removed the tag accordingly[1]. Hopefully this resolves the dispute, at least enough to warrant that. --Born2cycle (talk) 19:36, 11 December 2012 (UTC)
I reverted the new wording, which in my view as yet isn't supported by any consensus on this page. ignore arguments that support Status Quo - Really? --Mike Cline (talk) 20:11, 11 December 2012 (UTC)
I'm not sure the proposed wording is really necessary. Status quo arguments are just another argument and would, obviously, be tie-breakers if everything else is equal. The proposed wording actually appears to elevate status quo by giving it a special sort of status. Unless I'm missing something. --regentspark (comment) 20:23, 11 December 2012 (UTC) Just scanned the section above this one and I guess I am missing something :) Still, I'm going to let my comment stand. --regentspark (comment) 20:26, 11 December 2012 (UTC)
WP:TITLECHANGES and WP:RETAIN and some other precedents name "the first non-stub version" as the tiebreaker. RCMI says "status quo" is the tiebreaker. Which is it? --SmokeyJoe (talk) 22:09, 11 December 2012 (UTC)
(edit conflict)Mike Cline, reverting solely because you believe there is no consensus for a change is not helpful. Unless you personally oppose the change for some reason, and specify that reason when you revert, the revert does nothing to help us move towards consensus, if we're not already there.

The wording I added:

When evaluating arguments favoring and opposing a move, arguments citing retention of the status quo should be ignored, at least initially. Only when there is a tie between arguments independent of which title happens to be the current title should the status quo be given favorable consideration.

Mike, this doesn't say or imply ignore arguments that support Status Quo! There may be many arguments that support the status quo that should not be ignored! But that argument that should be ignored (except in a tie), is retain because it is the status quo. Don't you agree?

That said, I now see the wording could be clearer. Perhaps, "When evaluating arguments favoring and opposing a move, arguments opposed to the move based entirely on retaining the status quo should be ignored, ...".

RegentsPark, I'm glad we agree that status quo is a tie breaker "if everything else is equal". There is no elevation of status quo by giving it a special status; no more than it already has, and, I think we all agree, should have.

All I'm trying to clarify is that when deciding whether there is a "no consensus" tie, status quo consideration should not be part of that evaluation. That is, assuming actual numerical weights were assigned to arguments, if it's, say, 3 to 5 in favor of changing the title, and status quo is worth 2 points, you don't add the 2 points favor the status quo to the 3 points opposing change, producing a 5 to 5 "no consensus" tie. You find in favor of the move. Only if the argument weights come out to be 3 to 3 or 5 to 5, do you find a "no consensus" tie and then find in favor of status quo because it is the status quo. Does that make sense? I don't think this is clear to everyone, and this was repeatedly not followed in the history of Yogurt RM discussion evaluations, especially since RM #4 (of 8) where all the arguments were first laid out in a table[2] (see end of that section), showing that the only argument opposing the move was retaining the status quo. Yet, that one, and three more RM discussions after that, were all closed as "no consensus" with no move.

Are you opposed to including the wording? If so, why? --Born2cycle (talk) 22:19, 11 December 2012 (UTC)

SmokeyJoe, which is the tiebreaker depends on the context. If the issue is between the current title and some new title, the tie breaker is the current title. If the issue is between the current title and the original title, the tie breaker is the original title. I guess that's another way to look at it. --Born2cycle (talk) 22:30, 11 December 2012 (UTC)
Either way, a tie-breaker argument, citing either "retain status quo" or "revert to original title", should not be considered in weighing the arguments unless the weighing of the other arguments turns out to be a tie. --Born2cycle (talk) 22:55, 11 December 2012 (UTC)
Where your edit included "Only when there is a tie between arguments independent of which title happens to be the current title should the status quo be given favorable consideration", I think reference to the first non-stub version, is needed. There is policy and precedent in support of this, and it removes the gaming tactics of (1) making sneaky bold page moves in the first instance; (2) refusing to discuss due solely to "no consensus" against the staus quo; and (3) to maintain controversy primarily to demonstrate controversy. --SmokeyJoe (talk) 23:53, 11 December 2012 (UTC)
Gotcha. How about

When evaluating arguments favoring and opposing a move, arguments opposed to the move based entirely on retaining the status quo or returning to the original non-stub version should be ignored, at least initially. Only when there is a tie between arguments independent of which title happens to be the current title or original title should the status quo or original title be given favorable consideration. When the issue is between the status quo and original title and other arguments are equal, the original title should be favored.

Better? --Born2cycle (talk) 00:14, 12 December 2012 (UTC)
Not needed. Apteva (talk) 21:57, 12 December 2012 (UTC)

broken template

The "Technical requests" template is still broken and refuses to accept many URLs. For example, if you add the link www.collinsdictionary.com/dictionary/english/genoise?showCookiePolicy=true everything you write in the reason for move is replaced by {{{3}}} --Espoo (talk) 16:27, 16 December 2012 (UTC)

See Help:Template#Usage hints and workarounds:
  • An unnamed parameter cannot contain an ordinary equals sign, as this would be interpreted as setting off a named parameter. (This does not apply if the equals sign comes within another template call or other item which the parser handles separately.) To pass an equals sign in an unnamed parameter (for example in a URL with key/value pairs), replace the equals sign with the special template {{=}}, which returns an equals sign that will not be specially interpreted. Another method is to replace the unnamed parameter (and any subsequent unnamed parameters) with named parameters — the first unnamed parameter is equivalent to a named parameter with the name "1", and so on. So to call template {{done}} with the parameter "a=b", type either {{done|a{{=}}b}} or {{done|1=a=b}}.
    • {{RMassist|Génoise cake|Genoise}}
    • {{RMassist|Génoise cake|Genoise|MOS, see UK and US dictionaries, e.g. www.collinsdictionary.com/dictionary/english/genoise?showCookiePolicy=true}}
—Wbm1058 (talk) 20:07, 16 December 2012 (UTC)

need help

Having difficulty moving infor from Philip van Rensselaer (disambiguation) and Philip Van Rensselaer (disambiguation) to simply Philip van Rensselaer JGVR (talk) 02:20, 27 December 2012 (UTC)JGVR (talk) 02:24, 27 December 2012 (UTC) should not have (disambiguation) on the end JGVR (talk) 02:57, 27 December 2012 (UTC)

No consensus outcomes (another attempt)

I maintain that a root cause of the problem is the failure of the third paragraph of Wikipedia:Requested_moves/Closing_instructions#Determining_consensus to reflect the first paragraph of WP:TITLECHANGES. --SmokeyJoe (talk) 02:43, 11 December 2012 (UTC)

WP:TITLECHANGES, paragraph 1

Changing one controversial title to another is strongly discouraged. If an article title has been stable for a long time, and there is no good reason to change it, it should not be changed. If it has never been stable, or it has been unstable for a long time, and no consensus can be reached on what the title should be, default to the title used by the first major contributor after the article ceased to be a stub. This paragraph was adopted to stop move warring. It is an adaptation of the wording in the Manual of Style, which is based on the Arbitration Committee's decision in the Jguk case.

Wikipedia:Requested_moves/Closing_instructions#Determining_consensus, paragraph 3

If objections have been raised, then the discussion should be evaluated just like any other discussion on Wikipedia: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority). However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if the closer feels that no consensus has been reached, they may move the article back to the most recent stable name. If the most recent stable name is itself a matter of dispute, closers are expected to use their own judgment in determining the proper destination.

Wikipedia:Consensus#No consensus

  • In article title discussions, no consensus has two defaults: If an article title has been stable for a long time, then the long-standing article title is kept. If it has never been stable, or has been unstable for a long time, then it is moved to the title used by the first major contributor after the article ceased to be a stub.

Combining the first two, let's see if it's still coherent:

Look up stable or stability in Wiktionary, the free dictionary.

WP:CON "first default"

Changing one controversial title to another is strongly discouraged. If an article title has been stable for a long time, and there is no good reason to change it, it should not be changed. If objections have been raised, then the discussion should be evaluated just like any other discussion on Wikipedia: lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens (though like AfD, this is not a vote and the quality of an argument is more important than whether it comes from a minority or a majority).

However, sometimes a requested move is filed in response to a recent move from a long existing name that cannot be undone without administrative help. Therefore, if the closer feels that no consensus has been reached, they may move the article back to the most recent stable name. There was no good reason to change it; it should not have been changed.

WP:CON "second default"

If it has never been stable, or it has been unstable for a long time, and no consensus can be reached on what the title should be, default to the title used by the first major contributor after the article ceased to be a stub. If the most recent stable name is itself a matter of dispute, closers are expected to use their own judgment in determining the proper destination.

I'm pretty clear on the first two paragraphs, and don't see any material inconsistency. I believe the third paragraph is the sticky point. While I don't see any clear conflict between policy and guideline, neither is either completely clear to me. By "stable", I think it means the title has not been renamed for a relatively long time. A title which has remained unchanged for five years is more "stable" than an article which has been the same for only three years. Is the level of talk page chatter about the appropriateness of the title a factor to be considered in determining stability, or are move logs the only thing that is considered? The text is framed as if stability is a black or white thing. Never been stable? If a title changes once every three months, wasn't it at least stable for three months? "If the most recent stable name is itself a matter of dispute" implies to me that stability is measured by length of time at the top of the move log, and dispute means that while the name is "stable" it is subject to talk page discussion. Or is the dispute over which name was the last "stable" name? That's a dispute that will not be resolved without agreement on what a stable name is. If an article name is changed for the first time in eight years, how much time has to pass before the new name is considered the "most recent stable name"? Or is stability a matter of level of consensus? A title coming from an RM discussion where 9 of 10 opinions were in support might be more "stable" than a title which barely met the threshold for consensus, whatever the threshold is. Wbm1058 (talk) 13:14, 12 December 2012 (UTC)

Thanks Wbm. Yes, "stable" is a problem. I believe that talk page chatter has to be a consideration. The yogurt case may be informative. I recall that some contentiously asserted that the years-enduring title was stable. What if a title is stable for five years due to no one else noticing, and then a large number of editors become involved and half say that the original move from the first non-stub version was improper (maybe an editor has changed many backwater articles to his preferred spelling without advertising or discussion). I'd prefer to drop notions of "stability", thinking that if a RM discussion reaches "no consensus", then that in itself speaks to instability, of foundational consensus support. Also, if a period of apparent stability is an important factor, then it motivates agitators for change to engage in bold page moving and combative RM discussions to attempt to discredit the notion that the title has stability. --SmokeyJoe (talk) 20:20, 12 December 2012 (UTC)
I totally agree that a title unable to garner consensus support cannot be considered to be stable. It's worth clarifying that. --Born2cycle (talk) 22:09, 12 December 2012 (UTC)
If no title has consensus and there are more than two candidates we need to look at whether there is a rough consensus against any of them, but in such a case there will still be at least two for which there is neither consensus for nor against. At that stage IMO we need to just apply Andrew's Principle, and move on. Andrewa (talk) 02:44, 13 December 2012 (UTC)
Good principle. I added WP:CON policy above, which is consistent with the other policy & guidance. Wbm1058 (talk) 03:58, 13 December 2012 (UTC)
I reject User:Andrewa/Andrew's Principle. If there is one thing that really upsets people, it is an arbitrary decision freely made by a self-selected individual.
Definately agree with Born2cycle, but modified to say that "no consensus" in a well participated discussion implies "not stable". The numbers matter. Two proponents opposed by one defending the status quo is not enough to demonstrate instability. There also should be fairly robust arguments on both sides.
Also, as persuaded by Jenks, the discussion itself needs to at least mention the option of the first non stub version in contrast to the recent status quo, for the closing admin to so act. Nobody likes a closing admin blowing in and making a close to the surprise of of every participant, even if every participant is willfully ignorant of something. --SmokeyJoe (talk) 04:30, 13 December 2012 (UTC)
And I very much object to Born2cycle's approach. He is trying to get another tool to give himself power to change things to his way, to get away from a stable status quo by claiming it's not stable. Just ignore him. Dicklyon (talk) 04:36, 13 December 2012 (UTC)
Hmmm. Is there some antagonism amongst editors? Last time, I realised mid stream that this discussion was ill-timed due to raging controversy at Wikipedia talk:Article titles. I thought that now was a time of relative peace. --SmokeyJoe (talk) 06:03, 13 December 2012 (UTC)
But in the case of "Greek yogurt" I don't think he's getting his way, if, by his way you mean yogurt, not yoghurt. Strained yoghurt will stay that way under "second default" decisions, see 1st non-stub version, 1 July 2007. Yogurt cheese never made it past stub status. Unless the earlier use of the word in the 11 December 2002 yogurt first article (assuming not a stub) takes precedence over later "yoghurt" titled articles—but that's not what the guidance says as I'm currently reading it. Wbm1058 (talk) 13:50, 13 December 2012 (UTC)

I see from Wikipedia:Stable versions and Wikipedia:Stable versions now that there have been (failed) attempts to differentiate stable and unstable versions of articles. Can you have a stable article with an unstable title, or is title stability one of many prerequisites for article stability? WP:STABLE has been reduced in status from a {{shortcut}} to an {{anchor}} to the third paragraph of the Wikipedia:Manual of Style lede—which doesn't even use the words stable or stability, leaving me wondering why WP:STABLE links there. Wikipedia:Good article criteria says a Stable article "does not change significantly from day to day because of an ongoing edit war or content dispute." Still looking for a definition of a "stable title" or "stable name" and finding not much. Apparently lacking consensus on what a stable name is, all we have to fall back on is "closers are expected to use their own judgment". It's hard for me to see that the closing instructions conflict with WP:TITLECHANGES, when the latter can't define "stable name". Wbm1058 (talk) 17:33, 13 December 2012 (UTC)

Wikipedia talk:Article titles/Archive 17#Stability

the question "whether stability has existed, and when", is problematic. It is a bit like asking for what values of a discontinuous function is that function continuous. The answer can only be "everywhere except at the discontinuities". One might just as well argue that an article title is stable at all times except when it is being moved. Any attempt to come up with a more sensible definition of "stable" yields a question of interpretation, not "fact". Hesperian 05:59, 22 September 2009 (UTC)

Perhaps one could devise an article title "stability rating", analogous to a quarterback rating. Factors used to compute such a rating include:

  • number of months the article has existed
  • number of page moves over the lifespan of the article
  • number of months since the last page move
  • number of "no consensus" requested moves
  • degree of consensus in RM's resulting in moves

A perfect rating would be an article that was created the same month that Wikipedia was born, has never moved and has never been requested to move. Most articles would fall somewhat below that. Then, perhaps a minimum rating could be agreed on which, below that rating an article title would be deemed "unstable". An article with no titles above the minimum stability rating would default to the first non-stub unstable title.

Just brainstorming, and no, I don't have any plans to begin working on such a rating any time soon. Wbm1058 (talk) 19:06, 13 December 2012 (UTC)

I would have to say that it goes without saying that commonsense is the most important rule that is always present - we get a lot of articles that fly under the radar with strange names - and when they surface, being stable has nothing to do with them being wrong or right. We also get a lot of persistent edit warring that shows up in rm's. In that case, relisting or suggesting mediation might make more sense than making a choice. Or trying out a change and see if anyone wants it moved back - the yoghurt crowd wanted it kept there but would they have actively suggested moving it back? Theoretically we are supposed to be an encyclopedia, and choose the best names to use for articles, and take requests from the peanut gallery as to what to use, so moving names back and forth makes little sense. We have an odd one right now. The newspaper, the Sun Sentinel of south Florida, or is it Sun-Sentinel. The previous rm removed South Florida from the title, but said nothing of adding a hyphen, which the closer did without discussion, so now there is a second rm to discuss the addition. I tend to think of closers as nonparticipants, sort of like a jury, who has to only decide a case on the evidence that was presented, but that was a case of the closer having inside information (the printed copies of the paper use a hyphen), and using that to choose an unproposed title. Right now there are maybe as many as several hundred articles that were moved in the last year or two without discussion because of what I would call a failed interpretation of the MOS to always use endashes to mean something, even when not even one google result uses an endash - web, books, and news, and even when someone who seems to know a bit about comets argues vociferously that comets only use spaces and hyphens. Hopefully this dark chapter in wikipedia will come to an end soon, and the MOS will be corrected to recognize the wisdom of following common usage, but time will tell. Apteva (talk) 08:42, 15 December 2012 (UTC)

Any wording used has to discourage (not encourage) requested page moves just to show that there is disagreement over the name. The whole point of deferring to no move on no consensus is as is a time out between requested moves to encourage stability in names. Without these throttles the time sink and stress levels for editors rocket. Readers are faced with frequent changes to the lead, as editors rehash it to match the latest page move. -- PBS (talk) 18:52, 29 December 2012 (UTC)

Requested move → Suggested rename

The use of "Suggested move" in section titles for discussions would be more appropriate as the user is presumably not requesting attention from a user with higher powers as at technical moves. WP:Requested deletions? No, WP:Articles for Deletion. Also I take issue with it being called a "move." Moving is what I do when I change home addresses. A "Suggested rename" is more apparent in purpose for an outsider. This change is less important to me. Optionally this page could be renamed "Requested renames". Marcus Qwertyus (talk) 20:41, 25 December 2012 (UTC)

Using the term move rather than rename is consistent with WP:move, which redirects to Wikipedia:Moving a page... WP:Rename redirects to Wikipedia:Changing username, but {{subst:rename}} is a shortcut for {{subst:Requested move}}. Hovering over the ▼ (to the left of the "search Wikipedia" box) brings up a drop-down link titled Move, but hovering over that shows "Rename this page [alt-shift-m]"." So this usage of the term move is well-established in Wikipedia, and I'm not sure to what extent that WP:Requested moves should go against the grain. Editors are free to title a "requested move" section whatever they wish, with the restriction that there should not be two identically titled sections on a talk page, so placing a requested move in a section titled Suggested rename is fine. Perhaps documentation can be updated to show that title as the default suggested title. Template:Movenotice (which populated Category:Proposed moves) was deleted because consensus was that merely "proposing" or "suggesting" a move by that means wasn't working well–editors are advised to actively "request" moves at WP:RM, rather than just "proposing" or "suggesting" them, to get relatively prompt attention and action on their proposals/suggestions/requests. See Wikipedia talk:Article titles/Archive 38#The role of template:movenotice in title changes – Wbm1058 (talk) 14:33, 26 December 2012 (UTC)

I think that this is a bad change and I am reverting the edit that made it. It needs much input than a conversation between two editors to make such a major change. I thin that requested move is more appropriate as one is asking the community to agree to a move. It has positive connotation that suggested does not have and for anyone familiar with the development of the internet is an obvious word to use. -- PBS (talk) 18:29, 29 December 2012 (UTC)

I was ambivalent. I would be nice if contestable Requests Moves were preceded by informal Suggested Move discussions. A Requested Move initiates a formal procedure invoilving "Support"/"Oppose" voting. Maybe the RM instructions should advise consideration of the informal suggested move discussion first. --SmokeyJoe (talk) 01:34, 2 January 2013 (UTC)
One could argue that if the proper page title could be resolved on the talk page without a formal !vote, that is the preferred way. Vegaswikian (talk) 03:05, 2 January 2013 (UTC)
Yes, the proper page title should in general be resolved on the talk page without a formal !vote. The formal vote and rough consensus close through the RM process should only come about after the different camps fail to proceed to a common consensus. The bot-recognised formal page move request should come after the discussion, not before. I wonder if this is something behind the big RM backlog problem that could be fixed? --SmokeyJoe (talk) 03:14, 2 January 2013 (UTC)
(edit conflict)I think I may be being misinterpreted here. Requested move implies I want the move done by someone without any other input (WP:RM/TR), whereas Proposed/Suggested move move headers imply a discussion. So the preferred procedure in your case would be: 1. seven days at requests for speedy renaming/requested moves purgatory; if objections raised, seven+ days at suggested/proposed moves (FKA requested move). Basically what SmokeyJoe suggests but with the names switched. Marcus Qwertyus (talk) 03:30, 2 January 2013 (UTC)

The whole point of a RM is that it is not an informal process for pages where the move may be contested. If the page move is not controversial then a technical move can be requested. If it is controversial or potentially controversial then a requested move is the best way to involve others in the debate. If there is a common consensus then that will show up in the WP:RM request. As you are proposing 7 days anyway I fail to see the need for yet another procedure. -- PBS (talk) 02:57, 5 January 2013 (UTC)

Linked Moves To Barons De Ros To Be Discussed Together?

It's been suggested to me that I ask that the three moves now in the queue for Barons de Ros, and in particular the two linked moves, be discussed together. See [3]. Thanks for your help. NinaGreen (talk) 18:01, 30 December 2012 (UTC)

NinaGreen previously wrote at Talk:Baron de Ros:

According to The Complete Peerage, Vol. XI, pp. 96-7, the barony of Ros of Hemsley was created by writ with William de Ros (who is numbered in this Wikipedia article as the 2nd Baron). In Magna Carta Ancestry, Vol. III, p. 448, Richardson also uses this numbering. It thus seems likely that all the Wikipedia articles on the Barons de Ros should be renumbered. Comments? NinaGreen (talk) 19:39, 6 December 2012 (UTC)

To add to what I wrote above on 6 December, The Complete Peerage, Vol. XI, p. 95, states that on 24 December 1264 Robert de Ros was summoned to Simon de Montfort's Parliament in London, but according to a footnote on that page:

In 1616 the Barony was allowed precedence from this writ, a decision adopted by the Lords in 1806 (Round, Peerage and Pedigree, vol. i, pp. 249-50); but these writs, issued by Simon in the King's name, are no longer regarded as valid for the creation of peerages.

It thus seems necessary to renumber the baronies in this article, as suggested above, particularly since, in addition to the reliable sources cited above, the online source, Cracroft's Peerage, cited in this article, also states that William was the first baron. NinaGreen (talk) 01:26, 29 December 2012 (UTC)

Nina: It's ok with me as long as you cross your T's and dot your i's. However, you need to add your sources to the Baron de Ros article itself. Please add these sources as IN LINE cites to that article and also at William de Ros, 1st Baron de Ros. -- Ssilvers (talk) 23:32, 30 December 2012 (UTC)

As the two William de Ros article moves are linked (one is dependent on the other, and cannot be done without the other succeeding) these should be combined into a multimove proposal -- 70.24.248.246 (talk) 21:54, 31 December 2012 (UTC)
If someone will fix up the article content properly, it should be straightforward for an admin to do the moves. It seems to me that William de Ros, 2nd Baron de Ros is the guy who just got 'promoted' to being the first baron. Someone created a redirect from that name to William de Ros, 1st Baron de Ros. The guy who used to be considered the first baron is written up now in Robert de Ros (died 1227). So the position of 'second baron' is vacant and a series of moves are required to move the others down one. EdJohnston (talk) 16:25, 1 January 2013 (UTC)

Who can relist?

I don't want to name any names, but I ran across an RM where the original requester relisted the discussion—more than once, actually. In a previous discussion on relisting, an editor expressed an opinion that involved editors shouldn't relist. I agree, and this seems like common sense, but I don't think it's codified anywhere. Should we change that? --BDD (talk) 18:23, 7 January 2013 (UTC)

I think that allowing an involved editor to relist once shouldn't be much of a problem. That once applies to all editors involved prior to the relist, so another editor involved prior to the relist shouldn't be relisting again, as their "token relist" is used up. So subsequent new editors can also relist again under this condition. Any further relists for these no-longer-new editors must be asked for through a comment in the discussion (and evaluated, then done or turned down). -- 76.65.128.43 (talk) 01:46, 8 January 2013 (UTC)
Offhand, I don't see a problem with that. I will note that any second relisting is problematic in that some editors get upset with multiple relists. So it is probably best to not imply in any guidance editors can relist a discussion more then once. Vegaswikian (talk) 01:57, 8 January 2013 (UTC)
I see no reason to restrict relisting at all. What problem would such a restriction solve? --Born2cycle (talk) 05:02, 8 January 2013 (UTC)
Well, it could be abusive. If I have an RM that's failing six days in, or maybe seven and hasn't been caught by an admin yet, I could relist to give it more time to pass. Or conversely, maybe there's a consensual move where one dissenting editor relists before the move is closed. Now, you might say we should deal with such abuse when it happens and not worry about broadly restricting relisting. Perhaps, but this is a factor worth considering. Personally, I prefer limiting relisting to uninvolved editors. I've relisted a discussion or two where I made a neutral comment, but never a vote. --BDD (talk) 16:11, 8 January 2013 (UTC)
In the case where a proposal has apparently achieved consensus support, if someone who opposes the proposal relists it as a delaying tactic, that's really easy to catch and reverse, by anyone in the consensus, and therefore unlikely to ever occur. Has it ever?

Where the proposal is failing anyway, there is clearly no problem whatsoever. The worst case is that the inevitable result of no action is simply delayed. What's the difference between doing nothing now or doing nothing later? Nothing.

I call WP:CREEP. Strong oppose.

I would support clarifying that anyone, involved or not, can relist an RM discussion for good reason (e.g., has clearly not had much attention yet, or the discussion is still very active). In fact, the reason for the relisting is what matters, not who relists. --Born2cycle (talk) 18:20, 8 January 2013 (UTC)

Are any guidelines on relisting needed at all? When an RM reaches a natural conclusion it can be closed, no matter where it is in the list. Recently we had an RM in backlog from early November, two months old. It gets no more or less attention if it is relisted or left in backlog. The only reason for relisting, is to clean out the backlog for a move that clearly deserves more attention. If the original lister is relisting, I would question, for what purpose? To prevent it from being closed? There is nothing to stop an admin or anyone else from noticing that there has been a consensus long ago for the close and closing it no matter where it appears on the list. A huge number of editors treat RM as far more formal than it is, and treat it more like AfD, and often use RM when it is not needed. I would leave things the way they are. It says "If not, the closer may choose to re-list the request to allow more time for consensus to develop" (emphasis added) and since when does the initiator think that they are also the closer? Apteva (talk) 03:51, 9 January 2013 (UTC)
There are some proposals in the talk archive that seemed to have garnered support but were never implemented. I liked the proposal to relist if a move stays in the backlog too long (over a week in backlog) and to close as no consensus if relisted four times. (that means that moves remain open a maxiumum of 10 weeks or 3 months, though can be closed earlier as no consensus) -- 76.65.128.43 (talk) 05:09, 9 January 2013 (UTC)
It is rare for any to be relisted more than twice. What happens with titles that can not be decided for long periods is an RfC is used instead or on a busy talk page a subpage is created solely for naming discussion, or other dispute resolution methods are used. Apteva (talk) 03:33, 10 January 2013 (UTC)

I would tend to agree with BDD. At the least WP:RELIST should be a shortcut to some guidance. In ictu oculi (talk) 04:46, 10 January 2013 (UTC)

Important RFC at WT:TITLE

Editors will be interested in this RFC at Wikipedia talk:Article titles, to confirm the roles of WP:TITLE and MOS in determining article titles. The question affects the smooth running of many discussions on Wikipedia, including RMs. The more participation, the better.

NoeticaTea? 07:13, 9 January 2013 (UTC)

Talk:No Quarter (song)

At Talk:No Quarter (song), the nominator of the requested move at Talk:No quarter opened a second same move conflicting with the earlier discussion, with the same request content. Can someone close the new move request as a procedural close since it's already been requested previously by the same person a few days earlier at a different talk page? -- 76.65.128.43 (talk) 05:19, 14 January 2013 (UTC)

 Done --BDD (talk) 18:46, 14 January 2013 (UTC)

Relisting

See WP:RMCI#Relisting. Is there any way to comment that the best place to give a reason for relisting is in the edit summary, not after the word relisted? Most have been following the instructions that "Relisting simply consists of stating Relisted. ~~~~" but a few recently have been adding a reason, which to me is completely unneeded. For example "No reason is expected but can be provided in the edit summary." To me adding that would be misread too easily, and lead to more reasons not less. Apteva (talk) 07:43, 15 January 2013 (UTC)

RMs starting from the wrong (controversial/undiscussed move) end

see my own comment here on a current example. Has it ever been discussed to add a guideline that where WP:BRD is made impossible by a redirect lock (either automatic, or deliberate) a technical move request can (a) revert to status quo, (b) invite the mover to submit a RM. That way it is evident in the RM what is a new move and what is simply a restore? In ictu oculi (talk) 04:43, 10 January 2013 (UTC)

It's already in the guideline - see WP:RM#Requesting technical moves, where it says: "If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, request it below." You can't always convince someone to do it, but it's there. Dohn joe (talk) 06:01, 10 January 2013 (UTC)
Dohn Joe, yes, that's exactly my point.
The existing wording doesn't consistently put the onus on the person making the undiscussed move to submit an RM, it can just as easily put the onus on editors wanting to but prevented by redirect lock to have to submit RMs starting from the wrong end.
Hence my question, has such a guideline ever been proposed/discussed before? In ictu oculi (talk) 07:28, 10 January 2013 (UTC)
I think the current language covers your question - it's just a matter of bringing it to the attention of an admin. The current RM directions make it clear that if something is potentially controversial, an editor should take it straight to RM. If an editor thinks a move is not controversial, though, then they can make a BOLD move. An editor who wants to undo a recent BOLD move, but can't, due to a redirect, etc., should request it as a technical move (not as an RM) as part of BRD. Some admins fall into the trap of "if someone's objected, bring it straight to RM and let them sort it out there." But as it's written, a technical move request can be part of BRD. Maybe it can be made more explicit, though? Dohn joe (talk) 17:33, 10 January 2013 (UTC)

Perhaps the addition of:

If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, request it below using RM assist. In such cases if a new RM is initiated it should start from the status quo version. The user whose move without discussion has been reverted should be invited to submit a RM.

In ictu oculi (talk) 00:31, 11 January 2013 (UTC)

How about this:

If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, make a technical request below. If an RM has already been opened, and no comments have been made, the title should be returned to the status quo ante. If the RM is already underway, a "no consensus" result should return the page to the status quo ante title. (See Wikipedia:RM/CI#Determining_consensus.)

Dohn joe (talk) 05:50, 14 January 2013 (UTC)

Why is there no wording to allow for the request of an administrator to restore the original title?—Ryulong (琉竜) 06:21, 14 January 2013 (UTC)
Dohn joe,
That's a possible 3rd sentence but how does that wording help the first problem? That's a different issue. As per Ryulong, why is there no wording to allow for the request of an administrator to restore the original title? In ictu oculi (talk) 07:19, 14 January 2013 (UTC)
NB In case someone is concerned this would have retroactive effect that isn't the intention, the change making restores automatic would only affect restores going forward In ictu oculi (talk) 07:35, 14 January 2013 (UTC)

See the section below #RM/TR takes precedence over Consensus seeking discussions? -- PBS (talk) 02:07, 18 January 2013 (UTC)

Talk:2010–2013 Greek protests

Can someone fix the malformed multimove at Talk:2010–2013 Greek protests ? -- 76.65.128.43 (talk) 03:44, 17 January 2013 (UTC)

 Done Apteva (talk) 07:39, 17 January 2013 (UTC)

RM vs RfC

Would it be reasonable to add to the WP:RM#When not to use this page section, where an RfC is open, an RM should not also be used. A technical move request can be opened if needed after the RfC is closed. The reason for this suggestion, which can certainly be worded better, for example When an RfC is open - wait for it to close and make a technical request if needed, is that an RfC duplicates an RM, but typically lasts 30 days, while an RM typically lasts only 7 days, so in that respect, an RM is a specialized, and streamlined, version of the RfC. It is advertised in one place so that specialists in page naming can see it, whereas an RfC is topic sorted so that specialists in that topic area can weigh in. Apteva (talk) 19:20, 13 November 2012 (UTC)

Personally I would say something more like "if a RfC is already open a new related RM should have some support on the RfC, and the RfC should be noted on the RM" - RMs sometimes attract a more balanced selection of article-side contributors than an RfC, particularly if an RfC has turned into a troll fest. In ictu oculi (talk) 00:38, 17 November 2012 (UTC)
It really makes no sense to have both open at the same time, and instead of noting the RfC/RM, I would discourage the RM and defer to the RfC, regardless of which was opened first. Apteva (talk) 02:25, 17 November 2012 (UTC)
No it would not be reasonable to add to the WP:RM#When not to use this page section, "where an RfC is open, an RM should not also be used". This was debated at length, and is not done in practice, see my more detailed answer below in the section #Article Titles. To place this wording into this process page would contradict the discussions on that policy decision, and the intent of the wording on the WP:AT page. -- PBS (talk) 10:22, 11 December 2012 (UTC)
I'm working towards a response to you, but doing research first. The below subsections are a work in progress, please don't edit there until I sign it. Thanks, Wbm1058 (talk) 20:56, 5 December 2012 (UTC)

History of RfC

RfC is in Category:WikiProject Dispute Resolution
For an overview of Wikipedia:Dispute resolution (WP:DR) methods, see Wikipedia:Dispute resolution requests.
Wikipedia ad for Wikipedia:Requests for comment
Wikipedia adsfile info – #17

History of RM

RM is not currently part of a WikiProject – see Wikipedia:WikiProject Council/Directory/Wikipedia and Category:Wikipedia WikiProjects

— Belatedly signing. Glad to see someone else joining the discussion. Thanks, Wbm1058 (talk) 16:51, 11 December 2012 (UTC)

It is important to note that the original WP:RM process was set up for more than just technical moves and within 24 hours examples of "oppose move" existed on the WP:RM page (see 10 October 2004). -- PBS (talk) 10:18, 11 December 2012 (UTC)

Originally discussion was at wp:rm, then was moved to the talk pages, with just a pointer here, then later a bot was used to create the pointers. And then another when that bot stopped. I think the most recent addition is to add an WP:MRV process. Apteva (talk) 10:20, 19 January 2013 (UTC)

Article Titles

This subject was discussed in detail because of the wording of the Article Title Policy and an administrative decision Talk:Men's rights movement which some thought contravened that wording.

Overall the consensus was that it is preferable to use an RM for requested moves as it has the review process in place and that editors who have experience in the process tend to lurk around WP:RM, but it does no harm to advertise a move widely and one of those options is an RfC. There is also the question of move recommended in other consensus building processes such as AfD, which may recommend a move independently of an RM. So the advise at WP:AT remained as it was before the long debate: "Any potentially controversial proposal to change a title should be advertised at Wikipedia:Requested moves, and consensus reached before any change is made." (should and not must) -- PBS (talk) 10:18, 11 December 2012 (UTC)

Even should is too strong, because of the other methods. Apteva (talk) 05:49, 24 December 2012 (UTC)

Is there a minimum time on Technical Moves?

I thought I remember seeing somewhere a guideline of "give Tech RM min. 24 hr before actioning", did I imagine it or maybe it was just someone's talk comment. (subject just came up on Wikipedia talk:Criteria for speedy deletion under WP:LSD) In ictu oculi (talk) 02:21, 29 November 2012 (UTC) ‎

No. 24 hours is way way too long. I would give them 5 minutes, though. But the purpose is for moves that are obviously not controversial. The responding admin will often move them to disputed if they are. It is not possible to set a time limit for someone to respond. They either are controversial or they are not. Apteva (talk) 22:22, 30 November 2012 (UTC)
I don't see a problem with 24 hours, that would make sense, and stop weird moves that seem to be performed on speedies (like displacing a page "X" to "X/version 1" and replacing it with some user's sandbox, that's occurred several times in the past through speedy move). -- 70.24.250.110 (talk) 00:08, 1 December 2012 (UTC)

In ictu - I suggested that last year, and Jenks24 shot it down: Wikipedia_talk:Requested_moves/Archive_21#Time_for_contesting. Dohn joe (talk) 22:40, 30 November 2012 (UTC)

Dohn, yes that was it. Was that really 12 months ago? Doesn't time fly... Well, actually it sort of makes sense as a suggestion if only for a full turn of the globe to allow users in every time zone a look (if someone in whatever is the opposite Time Zone to New Zealand makes a weird TR to an article related to kiwi fruit you'd want the globe to turn back to when NZ editors are awake for example). But anyway Dohn that answers my question. Thanks. In ictu oculi (talk) 17:02, 1 December 2012 (UTC)
That was an opinion, not a shooting.

I think it should depend on the comprehensiveness of the request. If comprehensive, all information provided and clear cut, then there's no need for delay. If there is any ambiguity, or possibility of a bigger picture, then the request should be fulfilled only with care. "Care" doesn't mean a defined time period, but some time should be allowed for others to cooment. Ideally, if not clear cut, I think there should be a thread on the article talk page well before lodging the technical request. --SmokeyJoe (talk) 22:52, 30 November 2012 (UTC)

Some of the technical requests are like "I accidentally misspelled Food, can you fix Foos for me." Some of them are like "Please move Yogurt to Yoghurt", clearly controversial. What you will see is that admins allow TR's to sit around for a while if they do not know if they are controversial or not to allow anyone who knows to wander by and offer an opinion, by removing them to the contested section, or leaving them. It is impossible to set standards, and it is up to the admin who makes the move to either move it or put it into the contested section, or to wait to see if anyone contests it. And if it does get moved incorrectly it is trivial to open an RM and move it back. I do not see that any change is needed. I agree that it is always a good idea to check the talk page for any discussion, but I do not see any need for putting anything there for clearly uncontroversial moves, and yes if it is a potentially controversial move there probably will be something on the talk page. I often see things like, okay now that we have decided to move it how do we do that?
I routinely review new RM's to see if they are patently uncontroversial and move them there instead of making them go through the full RM process. Apteva (talk) 01:55, 1 December 2012 (UTC)
You can't fix the error I pointed out. We have several old histories hanging out in subpages because the usersandbox that replaced it acquired a live history the moment it was moved, so cannot be history-merged since they now have parallel histories. So, I don't really see a downside to a 24 hour wait time. -- 70.24.250.110 (talk) 19:17, 1 December 2012 (UTC)
Apteva, if WP:TR-MOVE moves and WP:LSD moves were given the turn of the globe to allow all time zones to see them would it result in an enormous list? Seems to me the WP:LSD moves is very small, the TR list would be much longer. I sort of view this as a wikt:more haste, less speed thing, but I can understand if an editor is waiting editing on a TechR or LSD then 24 hrs is a long time. In ictu oculi (talk) 00:36, 3 December 2012 (UTC)
I am less concerned with the length of the list as I am with the lack of need for waiting. Bear in mind that if it was not for an edited redirect being in the way, an editor would have just done the move themself immediatedly. Look at this as an example. Someone opened an RM to move 2012 Men's Kabaddi World Cup → 2012 Kabaddi World Cup, someone else just moved it, but moved it to 2012 Kabaddi World cup (cup instead of Cup). So I changed the RM to a TR, where it has been languishing. For what? I would have moved it myself if I could. There is nothing magical about allowing all time zones to see a proposed move. The fact is that some are obvious moves, some are questionable. Why wait even a minute for the obvious ones? Historically TR-Move has been essentially empty, with less than a few requests a day. Recently it has had as many as 60? requests, but that is historically rare. Apteva (talk) 03:35, 4 December 2012 (UTC)
"Obvious" is in the eye of the beholder, consider the move proposed at Talk:Saab AB, where the first couple of commentators thought it was as obvious as the proposer, but didn't think about other uses. This type of request has shown up at speedy. Several other instances of removing disambiguation, where the redirect was repointed to the article under consideration from a different topic also show up. Or because no other article uses the title, but it isn't actually the primary topic, because the primary topic is located at a different name. So, waiting 24 hours isn't such a great hardship. -- 70.24.245.16 (talk) 23:58, 4 December 2012 (UTC)
However I never either thought or suggested that Saab AB was uncontroversial. I categorized it as questionable when I saw it, but yes some could have categorized it as uncontroversial. But the point is that there are three categories, clearly uncontroversial to everyone, questionable, and clearly controversial to everyone. By definition if someone does not know which, then it is questionable. Are the boundaries/definitions the same for everyone? No, so there are an additional two categories - uncontroversial to some, and controversial to some (both are, though, subsets of the questionable category). But had I or anyone thought that the move was uncontroversial that does not impede anyone from making a move request either before or after it was moved to Saab. As a better example, Admins respond immediately to WP:CSD#G10 requests, but have no reason to respond immediately to move requests, even though it would be nice if it was sooner than later. Apteva (talk) 02:24, 5 December 2012 (UTC)
Hi Apteva
Re "Bear in mind that if it was not for an edited redirect being in the way, an editor would have just done the move themself immediatedly." - that isn't necessarily true. TR and db-G6 can also be used by editors who simply want to proxy admins into making moves that won't appear in their history.
And I would say that there is something magical about allowing all time zones to see a proposed move. What's the mad rush? In ictu oculi (talk) 01:21, 12 December 2012 (UTC)
Many editors have daily schedules, but it is more common for editors to have no schedule. If it is changing Foo to Foo (bar), it warrants giving the opportunity of having others reject the move, but if it is I created Foo Shool and accidentally misspelled school, no one needs to wait even a second. I would rather see admins use common sense than to give them rules to follow. We in fact have one admin who does most of these TRs and they tend to do them once a day, cleaning out all of them. Mostly they are pretty good at setting aside questionable ones, and often convert many of those to RMs. Hint to admins, if anyone thinks that the G6 request is being used to proxy, they can put the username in the edit summary of the move, foiling that. Apteva (talk) 03:19, 21 December 2012 (UTC)
Apteva, no suggestion at all that your G6 was used to proxy. From the last month of observing I would say 95+% of db-G6 templates have no intent to proxy. However the lack of guidance on this page to use WP:RM TR rather than db-G6 is still lacking, speed of WP:RM TR and db-G6 is still potentially problematic. But at least with WP:RM TR the history and name of requester are not erased, so WP:RM TR is a more self-policing tool. In ictu oculi (talk) 04:48, 28 December 2012 (UTC)
If "I created Foo Shool and accidentally misspelled school", and presuming "Foo School" didn't previously existing, then no admin function is required to do the rename, and anyone should boldly do the move immediately, even if it was listed at WP:RM/TM. Waiting periods (I like 4 hours) should only be required for articles with many versions or authors, or if a deletion is required. --SmokeyJoe (talk) 04:56, 28 December 2012 (UTC)
What usually happens is someone messes up the move, tries to move it back, ends up with a blocking edit at the target they want, and then have to ask for help. Apteva (talk) 10:14, 19 January 2013 (UTC)

RM and MRV

I was wondering if there's a need for MRV, if MRVs are closed if an RM is open, when the RM is disputing a previous RM that closed recently. Wouldn't RMs to reverse a recent previous RM be what MRVs are for, and thus a procedural close on the new RM to allow an MRV be the proper procedure? WT:MRV#riksdag & talk:riksdag#requested move 3 ; if opening a new RM to dispute a recent RM is what we do, what's the point of MRV? -- 76.65.128.43 (talk) 01:53, 18 January 2013 (UTC)

They serve different purposes with the same end goal. Reopening an RM simply invites new discussion on why the page should be moved. Opening an MRV invites discussion on the validity of the close. They are not for discussing the validity of the move itself. Apteva (talk) 04:39, 19 January 2013 (UTC)
  • A second RM should require new information or a new argument, new since the close of the last RM. A Move Review involves a failure of process or criticism of the closer's judgment and is not supposed to second guess the evidence discussed in the RM. --SmokeyJoe (talk) 05:17, 19 January 2013 (UTC)

RM/TR takes precedence over Consensus seeking discussions?

See Talk:Kyoto#Requested move 2

Copied from my talk page 76.65.128.43 (talk)

Kyoto

I noticed that you brought up there being an RM for this move. Someone has also requested a technical move. I have not checked to see who or when, but one thing I often do is scan all the new RMs to see if they really need any discussion and convert them to TRs if they are clearly uncontroversial. In this case I am guessing that after the move request reached the wp:snow close stage someone added the TR. There never needs to be both, and the TR always takes precedence unless challenged, in which case it reverts back to the RM. Make sense? Apteva (talk) 05:30, 14 January 2013 (UTC)

I would prefer someone snow the discussion instead of acting on a TR. I've seen TRs go through when there's been objections or other forms of non-assenting to the proposals, making a mucked up mess of things at RM. If I lodge an objection on technical grounds, then the TR will ensure to get the proper due care and attention, instead of a possible missed check of the talk page for open move discussions. TRs should never take precedence over the identical open requested move. (if the TR is not identical nor similar (ie. fix a typo, correct a capitalization, mostly unrelated to the open move request) then I can see how a TR can go through while a move request is open) Processing an identical TR over top of an open RM would be gaming the system. And violating WP:CONSENSUS seeking. -- 76.65.128.43 (talk) 05:36, 14 January 2013 (UTC)
Not much chance of that happening. There is a huge backlog at RM, and the priority of all closers is to clean out that backlog, not check for RMs that can be speedy closed. TRs always take precedence. I have no idea why that should not be clear. It is the responsibility of the admin doing the move to check the talk page for any discussion before making the move, and if there is any reason to not make the move, they decline. We really do have a very orderly process here. What an RM is is a request for input. What a TR is is a notice that I require an admin to help make the move because I can not just click move, for example in the case of an IPuser. They differ only and solely on the basis of is it controversial, and nothing else. If it is not controversial, it is by definition a TR regardless if someone opens an RM or makes a TR, and I regularly move RMs to TRs when that happens. Just now someone objected to a TR, by simply and without comment moving it to the contested section, which is fine - no reason is needed. The proposer or anyone else has two choices - forget about the move or open an RM. Apteva (talk) 06:09, 14 January 2013 (UTC)

Is this situation accurate? That the technical moves overrides open move discussions? I should think that a WP:SNOW closure should be done instead of a TR move if there is a open discussion underway. While functionally similar, the meaning is quite different, as one would usurp WP:CONSENSUS, while the the other would affirm WP:CONSENSUS. -- 76.65.128.43 (talk) 06:14, 14 January 2013 (UTC)

Wikipedia has "Bold, revert, discuss" to cover this. The problem with Kyoto was that the bold editor edited the redirect, making moves impossible. Moves to restore the status quo should be given priority, and the "technical request" section may as well be used to direct admins to ignore all rules and use the mop they were given to clean up messes. You're only opposing the move from a semantic standpoint so why block what should be done?—Ryulong (琉竜) 06:24, 14 January 2013 (UTC)
Not over rides, but replaces. There is never any reason to have both. Either there is possibly a disagreement in which case it needs to be an RM or there is no disagreement in which case the TR is more appropriate. Apteva (talk) 06:26, 14 January 2013 (UTC)
.43, I think the TR here ends up essentially being a request for a SNOW closure. ErikHaugen (talk | contribs) 07:20, 14 January 2013 (UTC)
This though also re Talk:Kyoto seems to be a slightly different discussion from above (hence new section?). In Talk:Kyoto User:Erik Haugen has (correctly) intervened before the RM goes the whole 7 days, but User:Funandtrvl should have been able to request an immediate and automatic TechReq over the redirect-lock in the first place. Then the editor wanting to move would then have have to think carefully whether to put in a RM. How could avoiding this sort of restore RM possibly do anything but reduce the backlog at RM? In ictu oculi (talk) 07:29, 14 January 2013 (UTC)

I had previously proposed in the disambig project that it should not be possible to make such moves for articles with large numbers of incoming links without a prior discussion. At the time, I thought a rule should be put in place to prevent this sort of thing, but the Kyoto experience reveals the potential seriousness and disruptiveness of such moves. I therefore think that there should be a technical limitation to moving pages with large numbers of incoming article links (I would propose 50 links to be a "large number" for this proposal), so that only an administrator can carry out such a move. That way, if a page has a large number of links, the person wishing to move the page would first need to engage in a consensus-building process, to be closed by an administrator. bd2412 T 01:35, 15 January 2013 (UTC)

I would up that to a thousand, and even then I am not sure it is necessary to move protect every page just for that reason - like this one if it gets moved accidentally it is likely to just be quickly reverted. Changing 50 or 100 links is not very time consuming. Mostly what editors need to realize is that moving a page is often not as trivial as just clicking move - and there is advise on that subject, that if the move involves a lot of subpages and archives it is best left to an admin, who can move up to 100 pages with a single click, as I recall. Apteva (talk) 07:56, 15 January 2013 (UTC)
The problem with this page was that it couldn't be quickly reverted - at least, only an administrator could revert it because the location from which it had been moved needed to be deleted. For a page that has already generated a good number of incoming links, such a move should not be possible (the issue is not the difficulty of fixing those links, but their presence indicating that editors expect this particular article to be at this location). bd2412 T 13:15, 16 January 2013 (UTC)

The person who moved it and locked out a move back through another edit has been told it was naughty and have said that they will not make such moves in future, without discussing it first.

I do not think that there is a need to change the guidance at the top of WP:RM "If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article." was put there to stop this sort of situation from developing. Before it was put in place some users would game the process if they thought that there might not be a consensus to move to their preferred option. They would pre-emptively move the page and then argue that a consensus was needed to move it back. The current wording was formulated to discourage such behaviour.

So to answer the question posed by 76.65.128.43 yes the move back overrides the requested move to stop the gaming of the process that I have described. Once the page is back at the stable name then if the perpetrator or someone else wants it to be moved to the new name the can initiate a WP:RM in the usual way and it is clear to both the participants in the discussion and the person who closes it what the proposed move is. Editors who repeatedly behave like this (particularly moving without consensus and then making a second edit only to prevent a move back) have in the past been blocked. -- PBS (talk) 14:13, 16 January 2013 (UTC)

PBS, #RMs starting from the wrong (controversial/undiscussed move) end above, the reason "If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article." is because it is completely useless to tell non-admin-tooled-up up editors they "may" do something which they cannot in fact do. As it stands the sentence is incomplete and unhelpful. All it needs is "(if the article has redirect-locked itself, or been deliberately redirect-locked, you may request an automatic TR)." This would remove the need for time-wasting RMs like the Kyoto one. In ictu oculi (talk) 05:42, 23 January 2013 (UTC)
Iio you have to read the advise in context. It is in a section called "Requesting technical moves" and the advise is "If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, request it below." (my emphasis) -- PBS (talk) 16:37, 23 January 2013 (UTC)
PBS, that is my point exactly, it is If you are unable to revert, request it below which needs improving: (a) the context is not clear since "request it below" could mean any of the 3 RM options, all of which are "below", (b) it doesn't say and should say, that the request will be automatic. At least several recent requests to restore by BRD have not been considered automatic by admins. We need to improve the wording. I cannot understand the objection to making what is meant by the sentence (if that is what is meant) clearer. In ictu oculi (talk) 00:45, 24 January 2013 (UTC)
Is clear by context. Both by the wording and the location of the wording. Which three? -- PBS (talk) 01:22, 25 January 2013 (UTC)
Well, to me the wording does not make clear whether such requests are automatic or not. Perhaps go back a step, are these requests automatic?
By the 3 RM options, all of which are "below", I meant:
(1){{subst:RMassist|old page name|requested name|reason for move}}
(2){{db-move|page to be moved here|reason for move}}
(3) full RM templates
Which of these 3 is intended by "below"? In ictu oculi (talk) 03:00, 25 January 2013 (UTC)
I think this conversation echoes my problems in the earlier discussion about {{RMassist}}: the documentation about technical moves is not at all clear. Maybe needs a flowchart or a set of yes/no questions to help a newcomer to the page to navigate and find their answer? PamD 09:58, 25 January 2013 (UTC)
This was not an isolated incident. As a disambig fixer, I regularly see novice editors unilaterally decide that a page with 20 or 50 or 100 incoming links is not the primary topic of a term, move that page to a different title, and then turn the base page into a disambig. As an admin, I can readily fix that, but not all editors can address such a situation. Furthermore, I sometimes come upon situations where I lack the expertise in a given field needed to tell whether the initial page really is the primary topic. bd2412 T 04:10, 17 January 2013 (UTC)
There have been more instances of the same kind just today. One editor decided, unilaterally and without discussion, to move Genji to Genji (era), while making the initial page into a disambig. Another editor decided to move Accent (linguistics) to Accent (dialect) while redirecting the former page to the disambiguation page, accent. Yet another editor decided to retarget IPO from redirecting to Initial Public Offering to IPO (disambiguation). Collectively, these edits have created thousands of new erroneous links which must now be fixed. bd2412 T 22:54, 19 January 2013 (UTC)
Here is another one: a few days ago, a user with little editing experience here unilaterally moved Hayagriva to Hayagriva (Hinduism), making a wholly unnecessary two link disambiguation page at the base title. This I have reverted because of the twodabs situation. bd2412 T 01:27, 20 January 2013 (UTC)
I was the one who moved Genji. I checked linkage to it and found this. The need to separate the obscure 1-year era from the other articles was obvious. The number of links was indeed somewhat over 100, but only 20 of those were from individual articles, the rest were all from Template:Japanese era name. Out of those 20 article links, half were wrong even before the move and actually needed correction, something BD2412 participated in.
So how exactly is this a good argument for preemptively blocking moves of articles with a few dozen non-transcluded links to it?
Peter Isotalo 02:53, 20 January 2013 (UTC)
Please do not take this personally. The problem is that large numbers of these moves happen, with some of them being good, and some being bad. The fallout from the bad moves is significant enough that it would make it much easier to clean up after the good moves if we didn't have to deal with the bad moves. Let me turn the question around here: what harm would it have done to have a discussion first, and give disambiguators a heads up that this move was coming? bd2412 T 13:02, 25 January 2013 (UTC)
I'm not taking it personally. You used my moving of Genji to Genji (era) as an example that supported your suggestion, despite its being a perfectly reasonable move, and I'm pointing that out. In my view, your suggestion to prevent moving articles for even as much as 100 incoming links consists of an excessive bureaucratic hurdle. Discussions about editing should be initiated when problems are identified, not because protocol demands it.
Peter Isotalo 08:00, 28 January 2013 (UTC)
Very well then, in the case of Genji, your move caused a large number of links to suddenly register as errors in the form of disambiguation links needing to be fixed. This could have been avoided had the links been directed to their appropriate targets before the page move occurred, which would also address the 100-link limitation that I have proposed. As you noted above, I helped to fix those links. It was a lot of work, which could have ended up being for nothing if the move had led to an objection which resulted in a discussion wherein consensus was against it. I am all for page moves that make clear the ambiguity of a word, but I would like to avoid having to do the work until there is certainty that such moves are supported by community consensus. If the person moving the page must also fix links in advance, that may influence their estimation of the appropriateness of the move. With Genji, there were a fair number of links intended for the clan instead of the era, which supported the determination of ambiguity, but that only became apparent to me during the link-fixing process. Right now, I note, there is an edit war going on over whether Arabia should redirect to Arabia (disambiguation), with over a thousand links in the balance. That is precisely the sort of thing which very clearly needs to be resolved before a mess is created that would require a far more extensive cleanup than Genji. bd2412 T 14:00, 28 January 2013 (UTC)
I still see Genji as an obvious contradiction to your suggestion. Something like half the ordinary links needed fixing anyway and some 80-or-so links were fixed by a single edit to one template. At worst, the whole thing could have been fixed by simply moving the original article back. An absolute technical limit of 100 inks (regardless of type) is way too low in my view. According to your suggestion, it would have meant at least a week of rather pointless consensus discussion (which would presume that the previous position was the status quo) instead of altering a few links. If this is actually necessary, the limit should be set at around 1000, not counting template linkage. After all, any admin can revert controversial move and block any further attempts to move the article.
Either way, demanding mandatory discussion for common sense moves for minor topics would likely create far more problems than it would ever solve.
Peter Isotalo 16:05, 28 January 2013 (UTC)
Perhaps there is an intermediate position. Rash and problematic page moves like Kyoto are often done by newer and less experienced editors. Suppose we could tie editing experience to the ability to move pages with increasing numbers of incoming links, on the theory that editors who have been here for a few years and have a few thousand edits under their belts will better understand the policies and procedures involved in such a process? bd2412 T 16:15, 28 January 2013 (UTC)
Seems to me that we would spend far more time discussing, formulating and enforcing such a rule than we would ever save from having on the books. Even the initial example of Kyoto did minimal damage and was easily reverted. In my view, all of this is already covered quite well with existing policy.
Peter Isotalo 17:51, 30 January 2013 (UTC)
Peter Isotalo 17:51, 30 January 2013 (UTC)
Peter, that's because Kyoto was brought up outside RM and fixed by ErikHaugen within 24 hrs. If Erik hadn't fixed it we would have had 7 days of wasted blather, or worse - Users who make controversial undiscussed moves and then object to WP:BRD and WP:RM applying will sometimes defend their controversial undiscussed moves to the teeth and we get what should be WP:BRD reverts hanging round the end of the WP:RM backlog a month later, headaches, close-review tantrums, etc. If someone wants to make a controversial move then per the overall tenor of WP:RM they should abide by the process for proposing controversial moves from the existing article status quo end, and the wording on WP:RM should clearly encourage this process to be followed. In ictu oculi (talk) 02:47, 4 February 2013 (UTC)

Talk:Cork GAA Junior Football Championship

Can someone fix the multimove request at talk:Cork GAA Junior Football Championship  ? -- 65.92.180.137 (talk) 02:15, 31 January 2013 (UTC)

{{db-move}} - could admins please make the followup move after the deletion?

If I want to move page Foo to title Foobar, but can't because Foobar is occupied (perhaps by a redirect to Foo which has previously been edited), I add {{db-move}} and wait for an admin to delet Foobar.

It would be very helpful if admins who do these deletes could follow up by moving the page - the template includes a link to make the move, but not all admins choose to use it. If the Foobar page is deleted but Foo is not moved there by the deleting admin, it relies on the requester spotting the deletion in their watchlist when they next look at it, and remembering what page it was that they meant to move to that title, and finding it, and doing the move.

The argument put to me by an admin was, roughly, that because any editor could move the page, once the admin had deleted as requested, it was a waste of their time to move it and they preferred to leave the page move to other editors. As far as I can see it would take very little of the admin's time to make the move, given that the link is provided in the template.

Could I suggest that it should be recommended to Admins (I don't know what documents, if any, guide their steps) that when deleting a page for a {{db-move}} request they should take the next step too and make the page move? PamD 20:07, 22 December 2012 (UTC)

Actually, making the request as a technical move is a better approach to what you are asking. Using {{db-move}} only ensures deletion of the old title, and not the obvious move implied as admins who routinely deal with requested deletions, may not be interested in making moves which can at times be a bit complicated. --Mike Cline (talk) 22:03, 22 December 2012 (UTC)
I used db-g6 (db-move) recently because there was a huge backlog at TR. I was surprised to see that I think with about one click the file was deleted and the requested move was made. It should be clear to anyone using db-move that it is not expected that the admin will also move the article though, no matter how easy it is. So I would leave things as is - if you want to make sure the file gets moved, use Technical Requests. If you are planning on doing the move yourself, using db-move is fine. One of our admins used to be about the only editor closing RMs, and this was before they were an admin, and they routinely used db-g6 to facilitate the move for themself. Apteva (talk) 04:04, 23 December 2012 (UTC)
Now this is confusing. I hadn't heard of a "technical move" before, and when I look at the page I'm not much clearer.
It says
"If the only obstacle to a technical move is a navigation aid (e.g., a redirect to the current title of the article to be moved, a redirect with no incoming links, or an unnecessary disambiguation page with a minor edit history)"... then use {{db-move}}.
"Otherwise to list new technical requests use the following code at the bottom of the sub-section "Technical requests" immediately below: {{subst:RMassist|old page name|requested name|reason for move}} "
Which seems to be telling me to use {{db-move}} in just the situation where editors are saying I should use "technical move", presumably the {{RMassist}} which I hadn't come across before. The documentation seems unclear, to put it mildly!
To put this into context, the latest example was moving Janine Thompson (tennis) to Janine Thompson, which was at that point occupied by an unnecessary dab page (the only other name-holder now being accommodated in a hatnote). PamD 20:07, 23 December 2012 (UTC)
I'm also puzzled as to what the "link to perform this move" is for, as the page has been deleted by the time the move could be made, so the link can't be found. Am I missing something here? PamD 20:17, 23 December 2012 (UTC)
Clarified wording. The link is for admins to make it easy for them to perform the move. Apteva (talk) 06:08, 24 December 2012 (UTC)
I reverted the change, because the two methods are not applicable to all technical requests. db-move is only for when there is a page in the way of a technical move. I reordered the paragraphs, so hopefully it's clearer that RM can be used for all technical moves. Dohn joe (talk) 16:07, 24 December 2012 (UTC)
We seem to be back at square one: if the only thing stopping me moving a page is that there's a redirect or unnecessary dab already at the target, I'm told to use {{db-move}} (although editors above have said not to). That template includes a link, which is "for admins to make it easy for them to perform the move", but I'm told not to expect the admin to make the move. Why not? Or why provide that link? Confusion. PamD 16:47, 24 December 2012 (UTC)
Does anyone know why the G6 method of doing moves is still recommended here? It seems to me that the technical move process is better. As an admin it would take me less time to judge the rationale for a technical move (and to carry it out) than to know whether a G6 deletion was correct. The only argument I could see is maybe there are more admins who patrol CSD than watch WP:RM/TR. EdJohnston (talk) 17:06, 24 December 2012 (UTC)
This an additional point parallel to my own question - the lack of transparency with db-G6 and self-erasing of history encouraging a very small number of users to abuse the template. Really the text on page-side of WP:RM needs to position WP:RM TR as very-probably-in-good-faith-uncontroversial-but-still-logged-and-publicly-displayed inbetween on one side full RM and on the other side 1001% totally obviously uncontroversial db-G6. The last month of edits seems to roughly show WP:RMTR is challenged about 1 time in 10. Wheras db-G6 is rarely challenged, unless by chance where a particular admin recognises a particular issue as having thorny history or a particular user as having history with using db-G6 to circumvent RM before. The db-G6 backdoor could benefit with being pulled an inch or two tighter on the text guidance between WP:RMTR and db-G6 here. In ictu oculi (talk) 04:55, 28 December 2012

(UTC)

No-one has yet replied to my post of 24 Dec above. If, today, I want to move Mange Tout (disambiguation) to Mange tout (currently a redirect to that dab page), what should I do? I've used G6, but some of you above have said that's wrong. Please explain. PamD 09:12, 4 January 2013 (UTC)
Hi PamD, good example, I doubt anyone cares about Mange Tout if that had been a popular culture item or an Indian ethnicity or something that could have been a very controversial move. The problem is shown by the edit summary: 10:45, 4 January 2013‎ RHaworth (talk | contribs)‎ m . . (368 bytes) (0)‎ . . (RHaworth moved page Mange Tout (disambiguation) to Mange tout without leaving a redirect) (undo) No hint of who really initiated the move (your good self), no way of tracking it, no display time on WP:RM technic moves {{RMassist}} would have been better. If it had gone via {{RMassist}} nothing would have been lost and transparency would have been gained (I appreciate that Mange Tout is just a non-controversial example). In ictu oculi (talk) 00:25, 11 January 2013 (UTC)
Thanks, that's helpful. Why have I not come across {{RMassist}} before? I'll try and remember to use it in future as it looks much more sensible than G6 in these cases. I think there may be some gaps in the documentation here. Now I know about it, I don't see the point of {{db-move}}. Should it exist? PamD 09:25, 14 January 2013 (UTC)

I have to chime in here, having just heard about this discussion, to say that the idea that the admin shouldn't move the page after deleting the blocking page is inherently ludicrous. Does the fact that the editor can do it himself make it okay to have a redlink for days or even weeks if the editor doesn't notice? If I use the {{db-move}} template to delete Jupiter to make room to move Jupiter (planet) there, then the admin deletes Jupiter without doing the move, and then I don't notice this, we have a very high-profile page of Jupiter as a red link for days of weeks. How is this acceptable? By deleting, the admin is stating that he agrees with the proposed move, and if he disagrees, he should decline the request, and if he agrees, he should move the page. If an admin can not be bothered to do such an easy, obvious and non-controversial task, he shouldn't be an administrator. Ego White Tray (talk) 13:23, 25 January 2013 (UTC)

I never delete db-moves unless I'm planning on moving the article for just this reason. ErikHaugen (talk | contribs) 17:09, 25 January 2013 (UTC)

I agree with In ictu oculi when he says above that db-move leaves no hint on the page history of who really initiated the move (when it's done by an admin instead), and no way of tracking it. I also strongly dislike the fact that it unnecessarily increases the number of our deleted contributions. But instead of using {{RMassist}} and all the bureaucratic process involved, I'd prefer a simpler solution: adding the move request to the page being moved instead of on the page being deleted, with a template like this:

  • {{db-moveto|page to be moved to|reason for move}}

This way everyone will be able to see on the page history who is the requester, and other editors will have the chance to challenge the move (before it's done) if they find it controversial for some reason. capmo (talk) 20:20, 3 February 2013 (UTC) Never mind, I just learned about the templates {{Requested move}} and {{RMassist}}, will start using them instead. —capmo (talk) 00:41, 4 February 2013 (UTC)

Good for you Capmo. But that still leaves db6 there still with db6 inviting misuse. In ictu oculi (talk) 10:03, 19 February 2013 (UTC)

Talk:Neve Şalom Synagogue

Question. Out of interest, hypothetically, now having pasted the section from WP:RM onto this Talk page, does that now mean I am involved and cannot implement what the WP:RM section says and revert the move per WP:BRD myself? Asking out of curiousity. In ictu oculi (talk) 14:58, 23 January 2013 (UTC)

The move back is now done and the RM is closed. You could have done it yourself and in my opinion your posting did not make you involved, however putting in a technical move back request onto the RM page and then stating that you had done so on the article talk page (with the quote you gave from RM as your reason) would have probably been a neater solution. If you had not posted here, it might have been days before an admin saw it and considered taking action, by which time there could have been dozens of contributions to the RM making the call more difficult to make if the revert was against what appeared to be the local consensus. So the speedier these BRD reverts are done the better for everyone involved. -- PBS (talk) 16:21, 23 January 2013 (UTC)
OK. That's an interesting solution. Can we add that to WP:RM instructions? (out of interest, was it redirect-locked?) In ictu oculi (talk) 00:37, 24 January 2013 (UTC)
It was not locked. -- PBS (talk) 01:19, 25 January 2013 (UTC)
Interesting, but in any case I wanted to be safe and ask first. Can we add your suggestion to WP:RM instructions? In ictu oculi (talk) 03:02, 25 January 2013 (UTC)

Following above discussion on Kyoto, Neve Şalom Synagogue, I would like to propose the addition of 14 words (in box) after "request it below": If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, request it below

+ ...using RMassist template with the reason for move given as "automatic revert per WP:BRD" "Revert of undiscussed move", .

In ictu oculi (talk) 00:40, 28 January 2013 (UTC) Just a procedural note that I mentioned this chunk of WT:RM to Skinsmoke, DrKiernan and Favonian to get some feedback from someone/anyone on above. Cheers In ictu oculi (talk) 02:58, 30 January 2013 (UTC)

Excellent suggestion that removes any uncertainty or misinterpretation. Skinsmoke (talk) 03:05, 30 January 2013 (UTC)
  • I'm not keen on adding mention of BRD to procedure or guideline documents. BRD is an essay which is intended as inspirational advice, not as a bright line. If you take the liberty of reverting someone's undiscussed move without having engaged in any new talk page discussion yourself, I'd rather see 'Revert of undiscussed move' in the edit summary instead of any mention of BRD. The word 'automatic' is also excessive, I think, suggesting that your own move is 100% justified and is not taking a liberty. EdJohnston (talk) 03:10, 30 January 2013 (UTC)
  • I agree with EdJ -- "Revert of undiscussed move" strikes me as being a more apt description and less likely to provoke than "automatic revert per WP:BRD". older ≠ wiser 04:08, 30 January 2013 (UTC)
Yes thanks both, those are both good points, this is why I asked for input. I have struck out and replaced with EdJ text.
Would an extra line ++[.., and leave a message at the article Talk page noting the revert.] be beneficial? Or is it getting too verbose? In ictu oculi (talk) 07:35, 30 January 2013 (UTC)

See Talk:Star Trek Into Darkness#Requested move (again) where there was a confusing mess over a move without discussion and then a discussion about that move. -- PBS (talk) 18:47, 4 February 2013 (UTC)

Which would be another reason for improving the wording as above. In ictu oculi (talk) 10:01, 19 February 2013 (UTC)

Archiving

If there are no objections, I'm considering changing the archives to yearly. That way we would have one for each year rather then grouping them across months. This would mean manually archiving the rest of 2012 and allow the bot to resume for 2013. Vegaswikian (talk) 21:57, 6 February 2013 (UTC)

Redirect page under RM

Can one of involved editors redirect the page during requested move process? --WhiteWriterspeaks 19:18, 26 January 2013 (UTC)

I asked on Wikipedia:Help desk --WhiteWriterspeaks 19:22, 26 January 2013 (UTC)
It is not recommended practice to make any move while the discussion is in progress and it is standard procedure to immediately restore any such move that is made, either directly or by requesting a technical move at WP:RM. Apteva (talk) 02:40, 24 February 2013 (UTC)

Touch (TV series)

At what point will an administrator take a look at Talk:Touch (2012 TV series)#Requested move? Thanks. -- Wikipedical (talk) 04:12, 20 February 2013 (UTC)

Unfortunately the backlog has continued to increase. We either need more admins or figure out a way to get the existing admins to spend more time closing RM's. Or find one admin who will take this on as a task. Hint hint. The backlog is at 139 requests right now. Apteva (talk) 04:28, 20 February 2013 (UTC)
Or have more people support making the policies and guidelines more helpful by being more deterministic in specifying what titles should be, so there is less ambiguity, less room for subjectivity and ultimately less controversy about titles... --Born2cycle (talk) 18:59, 20 February 2013 (UTC)
And have 4 million rules for how articles are named, one for each article? That would just shift the discussion, but not change the result. Apteva (talk) 23:29, 20 February 2013 (UTC)
No, fewer, but more concise, precise and much less ambiguous, general rules. For example, instead of simply listing the WP:CRITERIA and allowing precedence to be assigned on a case-by-case basis, we could specify what the precedence should always be. This would prevent each person in every RM discussion from being able to prioritize the criteria any which way they want in order to favor their preference. That's just one example of the type of changes in the rules I'm talking about.

The ideal would be to have general rules that unambiguously indicate a single title for every single article (but not separate rules for each article!). Of course that's practically impossible, but if there was consensus to move the rules in that direction, the goal of achieving this for all but a few exceptional cases here or there could be realized. --B2C 00:31, 21 February 2013 (UTC)

It has long been clear that there is no consensus to move toward more algorithmic titling. Dicklyon (talk) 01:25, 21 February 2013 (UTC)
(ec)Yes, that is part of the problem. Reducing many of them by providing a black or white decision is not really on the table since most cases are clearly a shade of gray. Vegaswikian (talk) 01:27, 21 February 2013 (UTC)
Most cases that make it to RM are shade of grey cases, but the vast majority of our titles are not. And those we see here are a "shade of grey" based on what exactly? The rules, of course. If the rules were less ambiguous, then there would be more black & white and less grey.

Cases don't exist in the absence of rules, whether those rules are written down or not, they exist and are followed. But if we are all using, interpreting, and weighing the rules differently, of course there will be a lot of "grey". If we reduce the amount of ambiguity in the rules, there will be fewer grey cases. I mean, that's the point of guidelines, isn't it? To reduce the number and intensity of grey cases and make more of them into black and white cases?

Thankfully, our rules are pretty good. Thanks to that, the vast majority of our article titles are black and white cases. But if the rules were loosened, say by taking out the to someone familiar with clause in Recognizability, suddenly there would be many times more grey cases. Similar changes could be made to move us in the other direction, reducing the number of grey cases. --B2C 21:54, 21 February 2013 (UTC)

Auto-signing the requested move template

There has been an ongoing problem with editors sometimes neglecting to sign their {{subst:requested move}} submissions with four tildes. RMCD bot does not currently handle these gracefully (see "Malformed requests"). Editors are also having trouble following these instructions to fix the problem, and frankly, the current bot algorithm is so lame at dealing with this that even I get a little frustrated with the difficulty of making this fix. See this recent example. I apologize to the editors and thank them for their persistence. I could work on a more sophisticated regular-expression pattern matching algorithm to solve this, but, to me the easier solution is to just modify the template syntax to automatically sign it, as the other two RM templates, {{subst:RMtalk}} and {{subst:Move-multi}}, already do. One of the benefits of substituted templates is that they can be auto-signed, unlike non-substituted (transcluded) templates. It seems silly to require subst: and then not automatically sign, and editors come to expect that if a substituted template needs to be signed, then the template coding will take care of that. I have a new version in the template's sandbox ready to go – see {{subst:Requested move/sandbox}} – feel free to try it out, by just including /sandbox in the template name. Oh, and the new syntax requires that the reason for the move be given as an unnamed second parameter. I don't know if anyone noticed, but some time ago I slipped in the option of either giving the reason in the second parameter or continuing to give the reason outside the template, just before the four-tilde signature. The auto-sign syntax will now require using the unnamed second parameter. Making this change live will require several near-simultaneous template and documentation page updates. With community approval, I can assemble the updates make it happen with a few rapid-fire mouse clicks. The only downside I see is that some may not notice the change in spite of whatever well-placed notices we install, and we end up with some double-signed requests. But it should be a lot easier to remove a redundant signature than to add a missing one. Anyone double-signing might also neglect to include the reason parameter, if they do, the template will display – Please put your reason for moving here. before the auto-signature. Then, both an extra signature and the boldface message need removed. One more thing: optionally, a named reason = parameter may be used instead of the unnamed parameter, which is consistent with the {{subst:move-multi}} syntax. Cheers, Wbm1058 (talk) 16:48, 16 January 2013 (UTC)

Since there's been no objections, I'll do this within the next day or two. Wbm1058 (talk) 19:45, 23 January 2013 (UTC)  Done Wbm1058 (talk) 17:21, 28 January 2013 (UTC)
I should note that this needs an option to not sign or provide reason. I sometimes fix wrongly substituted templates (like this) for bot parsing, and now it signs me and puts a reason placeholder. —  HELLKNOWZ  ▎TALK 12:56, 18 February 2013 (UTC)
Thanks for pointing this out. I believe in addressing problems at the source, and have installed a solution. Further attempts to substitute {{requested move/dated}} will generate this error:
Don't subst this template. See WP:RM/CM for instructions on how to request moves.
—Wbm1058 (talk) 19:26, 18 February 2013 (UTC)
Cool! I kind of assumed it had subst check already... and user edited it out or around or something, guess not. —  HELLKNOWZ  ▎TALK 20:08, 18 February 2013 (UTC)
When I find someone has not subst'd the template I just subst it and then delete all of the stuff it generates that is not needed, in a second edit. Apteva (talk) 23:34, 20 February 2013 (UTC)
Your reason text contained a web link with an equals sign in it. See the explanation here. Wbm1058 (talk) 22:09, 27 February 2013 (UTC)

RM template error

Tracked in Phabricator
Task T16235

Whenever you put an equals sign like here anywhere in the rationale, you'll get this (and lose your work). Anyone know why? Marcus Qwertyus (talk) 03:18, 13 February 2013 (UTC)

Probably similar to the ampersand restriction. Often if you "lose your work" you can click your browser's back arrow and recover it. Apteva (talk) 21:04, 17 February 2013 (UTC)
{{subst:requested move|Christopher Dorner|Only [http://www.foxnews.com/us/2013/02/12/fugitive-ex-cop-christopher-dorner-reportedly-may-have-had-help-fleeing-to/ one] of ten ([http://www.usatoday.com/story/news/nation/2013/02/12/christopher-dorner-ex-cop-los-angeles-mexico/1912553/] [http://abcnews.go.com/US/christopher-dorner-manhunt-sighting-leads-store-evacuation/story?id=18457978] [http://abcnews.go.com/US/christopher-dorner-manhunt-raids-tijuana-hotel-checks-california/story?id=18473202] [http://latimesblogs.latimes.com/lanow/2013/02/dorner-manhunt-investigators-pursuing-1000-tips-about-ex-cop.html] [http://www.cbsnews.com/8301-201_162-57568914/christopher-dorner-may-have-tried-to-cross-the-mexican-border-court-documents-show/] [http://www.huffingtonpost.com/2013/02/12/chris-dorner-manhunt_n_2672238.html] [http://www.politico.com/blogs/media/2013/02/dorner-shootout-could-affect-sotu-156815.html] [http://www.cbsnews.com/8301-505263_162-57568856/lapd-may-be-testing-christopher-dorners-word-by-reviewing-ex-cops-firing-expert-says/] [http://latimesblogs.latimes.com/lanow/2013/02/dorner-manhunt-sheriffs-officials-ask-all-press-to-stop-tweeting-.html]) news stories in my inbox use his legal name at first mention}}

The equals sign separates a named parameter from the name of that parameter. So, instead of an unnamed second parameter containing the reason why Christopher Dorner should be moved, you have a named parameter:

Only [http://www.foxnews.com/us/2013/02/12/fugitive-ex-cop-christopher-dorner-reportedly-may-have-had-help-fleeing-to/ one] of ten ([http://www.usatoday.com/story/news/nation/2013/02/12/christopher-dorner-ex-cop-los-angeles-mexico/1912553/] [http://abcnews.go.com/US/christopher-dorner-manhunt-sighting-leads-store-evacuation/story?id

with the value:

18457978] [http://abcnews.go.com/US/christopher-dorner-manhunt-raids-tijuana-hotel-checks-california/story?id=18473202] [http://latimesblogs.latimes.com/lanow/2013/02/dorner-manhunt-investigators-pursuing-1000-tips-about-ex-cop.html] [http://www.cbsnews.com/8301-201_162-57568914/christopher-dorner-may-have-tried-to-cross-the-mexican-border-court-documents-show/] [http://www.huffingtonpost.com/2013/02/12/chris-dorner-manhunt_n_2672238.html] [http://www.politico.com/blogs/media/2013/02/dorner-shootout-could-affect-sotu-156815.html] [http://www.cbsnews.com/8301-505263_162-57568856/lapd-may-be-testing-christopher-dorners-word-by-reviewing-ex-cops-firing-expert-says/] [http://latimesblogs.latimes.com/lanow/2013/02/dorner-manhunt-sheriffs-officials-ask-all-press-to-stop-tweeting-.html]) news stories in my inbox use his legal name at first mention

...and you see the message because the template didn't see either an unnamed second parameter or a reason = parameter. Workaround this by replacing each equals sign with {{=}} (Template:=), or better yet use the reason parameter:

{{subst:requested move|Christopher Dorner|reason=Only [http://www.foxnews.com/...
The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: just a demo. Wbm1058 (talk) 22:51, 17 February 2013 (UTC)

Wikipedia:Requested moves → Christopher Dorner – Only one of ten ([4] [5] [6] [7] [8] [9] [10] [11] [12]) news stories in my inbox use his legal name at first mention Wbm1058 (talk) 22:48, 17 February 2013 (UTC)

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

Anyone desiring to save a few keystrokes can also use 2 = reason for move, which works as well as reason = reason for move (giving the second unnamed parameter it's system-defined name). – Wbm1058 (talk) 19:34, 18 February 2013 (UTC)

Would it be easier to change the template so that it refuses to accept an equals sign and tells anyone trying to use one to add Reason= or change the instructions to explain this? No one is going to see this explanation after it gets archived. Apteva (talk) 04:20, 20 February 2013 (UTC)
Please do. I had the same problem (posted in #Auto-signing the requested move template). We may have simply traded one issue for another; I found this change disruptive (even if that's the nature of change). --BDD (talk) 07:09, 24 February 2013 (UTC)
Sorry about that. It's hard to think of every possible issue that might arise with changes of this nature. Documentation does need updated. Changing the template so that it refuses to accept an equals sign may not be a viable fix (template "programming" is kind of primitive). Probably the easiest fix is to change the documentation to instruct use of the reason parameter, "soft deprecating" the use of the unnamed parameter. But anyone could still use it if they wanted to and were aware of this "gotcha." – Wbm1058 (talk) 22:58, 27 February 2013 (UTC)
This should help, at least for the troglodytes like me that still copy and paste the example template most times. --BDD (talk) 23:08, 27 February 2013 (UTC)
It's funny that {{subst:RMtalk}} has long specified giving the reason in an unnamed parameter, and nobody to my knowledge has ever reported this problem with using it. Maybe it's just because that template is used much less often. I didn't add the reason parameter as an option there (although it could be done), so an RMtalk reason with such web links needs 2= in front of it. Wbm1058 (talk) 23:45, 27 February 2013 (UTC)

Head Over Feet by Alanis Morissette

Please move Head Over Feet (Alanis Morissette song) back to it's original title, Head Over Feet, because there's no other artist that created songs under the name "Head Over Feet". Thank you. Mr. Slinks (talk) 03:04, 28 February 2013 (UTC)

Requested at project page, see [13].--ukexpat (talk) 03:11, 28 February 2013 (UTC)
And has now been moved.--ukexpat (talk) 14:20, 28 February 2013 (UTC)

User:Biala Gwiazda and Rutgers University, Newark

This user moved Rutgers-Newark to Rutgers University, Newark claiming it was more "clean" and "professional" and compared it with how the University of California system articles are named. This move is entirely baseless and wrong. Obviously this user exhibits no knowledge of Rutgers and New Jersey--and assumes that just because it's a state university with satellite campuses, we should mimic California. This satellite campus in Newark is known as Rutgers-Newark or simply as the "Newark Campus." It has never been known as "Rutgers University, Newark", or as "Rutgers University in Newark." I have asked the user to revert his edits and the move. I would revert it myself, but I do not want to cause any logistical/back-of-house problems by doing so. If anyone could assist in this, it is much appreciated.--ColonelHenry (talk) 21:49, 2 March 2013 (UTC)

Can I close my own requested move (given the current backlog)?

Hello.

I have requested a multi-move on WP:RM. There's currently a huge backlog on page moves, so I am wondering whether I can perform the move myself. I saw this in the closing instructions:

However, it is fine for a discussion participant to close a requested move in the following circumstances:
If the discussion reaches a unanimous result after a full listing period (seven days).
If the nominator wishes to withdraw a proposal about which no one has yet commented, or which is unanimously opposed. In this case, the nominator may close the discussion as "withdrawn".
If the closer's participation in the discussion has been limited to clarifying questions, or is otherwise neutral with respect to the proposed move.

Does the wording allow for the proposer to perform the move? I mean, as the proposer, you might be viewed as more than a participant.

Only two editors have commented, but both are supporting the request – which has been there for more than the required seven days.

Also, am I, as a non-admin, able to perform a multi-move? Is there a lower limit in the number of pages (I saw that admins can move up to 100 pages at the same time.) I think there are 21 pages in my request: Talk:2008–09 Speed Skating World Cup/100 m Men.

HandsomeFella (talk) 20:04, 14 February 2013 (UTC)

At best, it's bad form to close your own RM proposal, especially if the result is to move. I would let this stand as a request for an admin to do it. --Born2cycle (talk) 20:34, 14 February 2013 (UTC)
The number of pages to be moved is increased if there are talk page archives to be moved as well. Unfortunately right now we just need more admins to be closing the RMs. Theoretically the backlog should always be empty. Apteva (talk) 00:15, 17 February 2013 (UTC)
I have no objection to an editor closing their own RM if consensus is overwhelmingly clear. bd2412 T 01:45, 17 February 2013 (UTC)
(general comment) It's important that all the talk pages, and any talk subpages, be moved. If there's a chance that a non-admin would be caught by the limit on the number of page moves, he/she should probably wait. — Arthur Rubin (talk) 16:13, 3 March 2013 (UTC)

Talk:Seoul Metropolitan Subway

In no way a criticism of the administering admin (happens to be Apteva but could have been anyone), a question on how WP:BRD applies to TR here. A passing look at history suggests that per WP:BRD this attempt to restore a stable article to an (invented?) Korean spelling should have been honoured at WP:TR rather than bumped to start an RM from the non-stable status. The disputed moving seems to start with (Frysun moved page Seoul Metropolitan Subway to Seoul Capital Area Electric Railway: rename per talk page) (undo) and then more moves by Frysun. Worth checking that I am reading move history correctly before any comments on the WP:BRD/TR issue. In ictu oculi (talk) 01:50, 4 March 2013 (UTC)

Correction - ignore section heading link - among user Frysun's moves the Talk page has become disconnected and non-redirect, the RM is at Talk:Sudogwon Electric Railway. In ictu oculi (talk) 01:56, 4 March 2013 (UTC)
Someone moved it back to TR, so the template on the talk page has been removed. This is a revert of a bold move. After it is restored to the previous title a new RM can be opened. Apteva (talk) 03:27, 4 March 2013 (UTC)

24-hour minimum for technical requests?

Dear colleagues, I've seen a few technical requests go through before editors in all timezones have a chance to run their eyes over them. I'd hate to think technical requests are being used to game the system.

So I wonder whether there's support for a simple 24-hour minimum before tech requests are acted on. Tony (talk) 12:26, 17 February 2013 (UTC)

While I don't disagree that there is a possibility some might use TRs to game the system, if there is in fact any controversy related to a TR, then by definition it is not a TR. For moves that truly qualify as TRs, I don't see any benefit to forcing them to wait. Perhaps there should be a provision that pages moved by a TR can be reverted and changed to a full discussion. older ≠ wiser 13:59, 17 February 2013 (UTC)
Is that not already implied in the current wording? -- PBS (talk) 19:12, 17 February 2013 (UTC)
Indeed, it is quite explicit. If the page has recently been moved without discussion, you may revert the move and initiate a discussion on the talk page of the article. (See also: Wikipedia:BOLD, revert, discuss cycle.) If you are unable to revert, request it below. I suppose the only issue may be that such moves might go unnoticed unless a moved page was already on a watchlist. older ≠ wiser 19:47, 17 February 2013 (UTC)
Exactly. Just move it back if it got moved inappropriately. If whoever wanted to move it wants to open a discussion they can. Apteva (talk) 20:59, 17 February 2013 (UTC)
Tony1, if someone is trying to game the system a better route is a db6, that has 2 advantages over TR - (1) no one in any time zone sees it, (2) the name of the mover is hidden, the db6 request is deleted from the requesters edit history, and it appears afterwards as if no request had been made and an admin moved it. At least TR may be seen by users in the same time zone. But I second your proposal of allowing a turn of the globe 24-hour minimum for TR. In ictu oculi (talk) 09:59, 19 February 2013 (UTC)
For the record, I see no reason for requiring a specific waiting period. Basically we should be thankful that someone is willing to make the moves, and leave it up to them as to when to make the move. Apteva (talk) 04:53, 20 February 2013 (UTC)

I posed the same question a while back, and the only answer was that the people who patrol the requests generally know when to move it to controversial. Which is probably pretty true. I think 24 hours would still be a good idea, but I also agree that the folks who patrol around here generally know what's what (and are open to suggestion when issues are brought to their attention). Dohn joe (talk) 05:46, 20 February 2013 (UTC)

Dohn, yes. A 24-hour limit imposes no extra work for admins, I think. I created this thread because I recall seeing a few highly questionable tech requests that were put through rather too quickly, without giving time for people in all timezones to notice. Tony (talk) 07:09, 20 February 2013 (UTC)
Yes it does create extra work. Say I close them once a day. Now I have the additional task of checking the time stamp instead of just cleaning them out. I still have to look at them to see if they are controversial so nothing is gained and a lot is lost if a 24 hour restriction is in place. As it is right now they get cleaned out once a day. If there was a restriction, and I was cleaning them out once a day, some would hang around for almost two days, and if they were blatantly obvious moves that would be pointless. Right now there is an annoying habit of editing redirects so that TR requests are more common than previously before the R from redirect edits were being made. Apteva (talk) 14:57, 20 February 2013 (UTC)
To me, it seems an issue of fairness. Either we should give everyone a fair chance to object to a TR, or we should give the closing editors full discretion. I'd actually be fine either way, but leaving this hybrid system in place, where "anyone can contest" as long as you happen to show up in the first 2 (or 7, or 18) hours seems unfair. I don't think it'd be too onerous to ask an editor to check the timestamp first - or maybe we could separate TR requests by date, as we do with regular RMs so it would be immediately obvious which TRs were ripe for moving. Dohn joe (talk) 18:21, 20 February 2013 (UTC)
Anyone can contest it at any time, even a week after it is moved. Many people do not look at Wikipedia every day. If it has been moved in a TR, just open another TR to move it back. Since it was just moved that is automatic, and does not need to wait another 24 hours, and can not be contested. Apteva (talk) 23:25, 20 February 2013 (UTC)
  • Oppose. This appears to be a solution in search of a problem. Without evidence showing that there is an actual problem with TRs that occurs sufficiently often to warrant something like this, seems to me this is just CREEPy. --B2C 00:34, 21 February 2013 (UTC)
@Apteva - no noone can contest it at any time, even a week after it is moved. Because unless the article is on your watchlist you won't know it was moved. Many people do not look at Wikipedia every day - but a 24hr guidance at least someone in the relevant time zone will see an article if it is TRed while the relevant country is asleep.In ictu oculi (talk) 02:51, 26 February 2013 (UTC)
WP:RM has a history, just like every page. All of the technical moves are in a subpage, and anyone who wants to know what was moved while they were offline can check the page history. But what about all the other page moves that do not require a TR? How is anyone supposed to know about all of those? Why is there a concern about the TR moves, when they can be checked when there is no concern about the moves that do not require a TR? Apteva (talk) 16:59, 26 February 2013 (UTC)
@Apteva, because moves that do not require a TR can be done without a TR. Which means (a) the user can do it, he/she isn't an IP or newbie. (b) such articles generally have a less complicated edit history, they have not self-locked by a build up of edits. Additionally there's still (c) that who initiated the article move isn't visible in the article history. In ictu oculi (talk) 04:43, 1 March 2013 (UTC)
@Born2cycle, there's a bigger problem with the backdoor nature of db6 than with TR, but the speed of TR is also a problem. And Wikipedia:Avoid instruction creep doesn't apply to a simple guideline to do New Zealand moves when New Zealand is awake. In ictu oculi (talk) 02:51, 26 February 2013 (UTC)
You keep asserting there is a problem but you won't say what it is. The premise of TRs is that admins can distinguish TRs from potentially controversial requests, and so no review or discussion over time is required. Do you not accept this premise? --B2C 19:57, 26 February 2013 (UTC)
@Born2Cycle
As previously discussed one extreme problem with db6 is that the db6 mechanism can be used to knowingly make controversial moves counter RfCs, related RMs, etc. leaving no indication of who initiated the move. More common problem is even good faith moves still do not show who initiated the move.
And as previously discussed a lesser problem with TR are as discussed above. That it does not give time for full regional participation, turn of the globe.
I am not aware of where it is stated that "The premise of TRs is that admins can distinguish TRs from potentially controversial requests, and so no review or discussion over time is required." if it is as you have stated then you would need to justify why are TRs even listed at all, and why is there on average 30min to 5hours during which objections can be made?
In ictu oculi (talk) 04:43, 1 March 2013 (UTC)
Maybe there could be a logging system like the one at WP:RFPP (see bottom of page) so that recent technical moves could still be viewed for a couple of days. This still won't catch the problem Apteva points out. A lot of moves are performed directly and don't go through WP:RM/TR. Judging from the move log there must be over 1,000 moves per day. EdJohnston (talk) 20:09, 26 February 2013 (UTC)
I would recommend against a logging system. The history should be sufficient for all purposes. I see no reason for adding overhead. Apteva (talk) 00:57, 27 February 2013 (UTC)
Apteva, you say that history is sufficient for all purposes - can you please link the last 100 TRs and last 100 db6 moves to see the history you refer to? In ictu oculi (talk) 04:46, 1 March 2013 (UTC)
Obviously I can not easily do the last 1 db6 move, but can trivially do the last 100 TRs. Apteva (talk) 04:52, 1 March 2013 (UTC)
Extended content

Last 100 TRs. I did not include the ones that were contested. One of the things that makes it easy to do this is the edit summaries. Apteva (talk) 06:22, 1 March 2013 (UTC)

Thanks for the demonstration, is there a rolling link which will update itself? In ictu oculi (talk) 07:41, 1 March 2013 (UTC)
No but as you can see it is easy to get them from the page history. Apteva (talk) 08:03, 1 March 2013 (UTC)
Sorry, I didn't follow what you clicked. Lets say I open page history here. Then what should I do? In ictu oculi (talk) 08:23, 1 March 2013 (UTC)
I clicked on history, and looked for the size reductions. I clicked the page before the reduction, and where needed clicked next to see what was done, or on the pages involved to see which were acted on and which were contested. The one you picked, if you click next, you will see was contested. Over the time that these 100 pages were moved, or closer to 199 with the talk pages (one request was just to move a talk page), an additional 24,203 were moved (including talk page moves). In January there were 44,163 page moves (1,425/day), and in February 36,436 (1,301/day). Apteva (talk) 19:41, 1 March 2013 (UTC)
How many times did you have to go through that process (look for a size reduction, look at the diffs of that version relative to the previous) to assemble the list of 100 last TRs above? That does seem like a cumbersome process. And looking at your nice list above is a lot nicer than looking at, for example, this list of 4[14]. --B2C 22:56, 1 March 2013 (UTC)
Who is going to use the list? It only is a sampling of one out of every 120 moves made. I would rather spend my time working on content. You can see from the timestamp that it took me less than an hour. In many cased I only clicked once, as I could tell from the edit summary that all were done in the next edit. It was only occasionally that I had to check to see if the move had been made or not. Apteva (talk) 01:30, 2 March 2013 (UTC)
I for one would use the list if it was a simple 'click.' If there is a bot-engineer who enjoys the time and pain of making new bots to contribute to en.wp, I think he/she should be allowed to do so. The way you just described doing it manually sounds a very cumbersome process, wheras a click is a click. In ictu oculi (talk) 02:06, 4 March 2013 (UTC)
  • I support a 24 hour minimum period for the automatic completion of a technical request to enable a rename. A major exception to this is where the action is performed by an admin who reviews the case, supports it on their own considered judgement, and is prepared to take responsibility in the face of subsequent complaints. In other words, a technical request must be reviewed and approved by an admin, or it must wait at least 24 hours to see if there are any immediate objections. I see this an sufficiently answering the perceived problem of half-baked technical requests, while not making life any harder for the few admins working in this area. --SmokeyJoe (talk) 23:41, 1 March 2013 (UTC)
    • Clearly a solution in search of a problem. If I see a speeling error in doing WP:RCP I fix it immediately. Why should I wait 24 hours just because I saw it at TR? It has already been vetted by someone else just by the fact that it is at TR. Seriously, if someone is worried that someone might make a TR to move say Pope Benedict XVI to Pope Emeritus Benedict XVI, I guarantee that someone is going to notice that and ask that it be moved back, and they are certainly not going to want to have to wait a day, especially if the move was to something a whole lot less polite than Emeritus. Apteva (talk) 01:30, 2 March 2013 (UTC)
      • Clearly you don't read clearly. If you can fix it, you can fix it immediately. If you are not an admin, and you can fix it, then it doesn't need to be a technical request because you don't need to request an admin to do it. If a nonadmin can fix it, he can just fix it. If you are an admin, you can fix it, but if exercising an admin function, think first and be prepared to take responsibility. (If you are an admin and don't like this, then you shouldn't be an admin). The rule I suggest applies only to a page move that cannot be done by a non-admin and is requested by a non-admin. It would say that an admin can't just mindlessly clear the backlog until the requests remain unobjected for 24 hours, and it allows for an admin to go into bot mode and grant all old requests not objected to. The problem already on the table (not looked for) is that in clearing the technical requests some half baked moves happen without anyone even thinking about it. --SmokeyJoe (talk) 15:37, 3 March 2013 (UTC)
I have to agree with SmokeyJoe - the list of 100 TRs you assembled manually doesn't contain a single article as notable as Pope Benedict XVI to Pope Emeritus Benedict XVI, most of the 100 are subjects none of us have ever heard of like Minki Visser → Minki van der Westhuizen (who?). In ictu oculi (talk) 02:12, 4 March 2013 (UTC)
In addition to those listed, which were moved, there were many others which were either contested or simply refused because the admin looking at them did not think they should be acted upon. I think the premise is that anything listed should be moved, but that is blatantly false. It is up to anyone who makes the move to think that the move is warranted. We all agree that if someone moves the pope to an article name that is horrendous it needs to be restored immediately, and the process for doing that is to list it at TR. We all agree that despite our best efforts errors slip in. Saying that we have to wait 24 hours except when we do not need to is not an actionable rule. And telling a non-admin that if they find a spelling error at TR they can not fix it for 24 hours but if they find it themself they can fix it immediately is ludicrous. Apteva (talk) 03:23, 4 March 2013 (UTC)
  • "I think the premise is that anything listed should be moved, but that is blatantly false."

    I think that anything listed and no objected to should be moved after a period of not less than 24 hours.

  • "It is up to anyone who makes the move to think that the move is warranted."

    So you think that an admin must actively review every non-admin's TR? No matter how long the backlog?

  • "We all agree that if someone moves the pope to an article name that is horrendous it needs to be restored immediately, and the process for doing that is to list it at TR."

    No we don't. If a bold page move is disagreed with, the auto-confirmed editor should move it back over the redirect.

    Note that bold page movers who do tricks to prevent easy move-reversals have been quickly and harshly dealt with.

  • "Saying that we have to wait 24 hours except when we do not need to is not an actionable rule"

    The actionable rule is that after 24 hours, an admin may preform all backlogged TRs "by default", and that before 24 hours, an admin may not use admin privilege to clear TRs unless he reviews the details and is prepared to take responsibility.

  • "And telling a non-admin that if they find a spelling error at TR they can not fix it for 24 hours but if they find it themself they can fix it immediately is ludicrous."

    I did not say this.

    If you (a non-admin) find a spelling error at TR that you can fix, you can fix it and remove the TR. No admin action involved. No suggestion by me (unlike by Tony) prevents it.

  • My point, in response to Tony, 12:26, 17 February 2013, is that I would say "Yes, but only for the TRs requiring admin action, ie the ones the requesters *couldn't* do, and that this rule doesn't necessarily apply to admins". I don't think you would disagree with this, but I see you disagreeing with all sorts of things not said. --SmokeyJoe (talk) 06:05, 6 March 2013 (UTC)
    The original request was to not act on any TR until 24 hours had elapsed, and it seems that the suggestion has morphed to a proposal to blindly act on all TRs after 24 hours if they have not been removed during that time? I would prefer that even after 24 hours a little common sense was applied, and that any questionable proposals be contested or converted to move requests, which seems to be current practice. A corollary is how long do contested requests stay listed? It seems that practice varies between deleting them after a week and converting them to move requests within 24 hours. Both to me are fine. Apteva (talk) 01:50, 9 March 2013 (UTC)

Modifying open RMs

Am I allowed to modify an open RM that I initialized? Based on comments and further research, I think that a new target for the HD 82668 RM is necessary, but since someone has already voted, am I still allowed to change it? StringTheory11 (t • c) 03:46, 6 March 2013 (UTC)

I wouldn't change the actual nomination, but you certainly can make appropriate comments in the flow of the discussion that would indicate what changes you are proposing. --Mike Cline (talk) 03:49, 6 March 2013 (UTC)
Yes, that is the normal procedure. It is expected that anyone closing the request will read the entire section and see if the consensus is to use a different name than was originally proposed. Apteva (talk) 23:48, 8 March 2013 (UTC)

Talk:1971_Bangladesh_genocide#Requested_move

Could an uninvolved admin please take a look at this. The situation is that one editor moved it from 1971 Bangladesh atrocities a few days ago and a second editor objected. I misread the history and thought that the first editor had moved it back to the stable title[15] and the second editor, on my advice, started the RM discussion (with a third title). On further investigation, it turns out that I was wrong and 1971 Bangladesh atrocities is the stable title ([16]). In other words, I messed up. I'm reluctant to take any action myself (bigger hole!) so if someone else can decide whether the current discussion should continue or whether the move should be reverted, that would be great. --regentspark (comment) 22:21, 7 March 2013 (UTC)

Time between RMs

Is there a guideline or rule about the minimum period of time that needs to pass between the closure of an RM with a 'not moved' result and the resubmitting of the same RM? I can think of reasons why a RM may be validly resubmitted even after a short period of time e.g. the situation regarding the topic has changed, new sources of information have become available or there is consensus that the previous closure was not done correctly. But what about closed RMs where none of these circumstances apply? --Wolbo (talk) 12:31, 12 March 2013 (UTC)

No, but it is usually better to discuss opening a new RM first, on the talk page of the page to be moved, to see if there is any support. Apteva (talk) 21:44, 12 March 2013 (UTC)


I wrote a little piece of advice on the related question of renominating for deletion, here. I had in mind the non uncommon situation of a latecomer to the discussion unhappy with the close or convinced that most of the participants arguments are refutable.
In short, I recommend that "no consensus" results should be left for at least two months and a finding of consensus should not be challenged for six months. I consider that exceptions are fairly obvious. Exceptions may involve substantial and important new information, or an invitation in the close with advice on how to better focus the discussion.
For RM discussions, I think it would be better in all cases, including resubmissions, if the rename were proposed informally on the talk page before the formalisation of the discussion with the addition of the RM template. --SmokeyJoe (talk) 02:41, 14 March 2013 (UTC)

WP:BRD prevented by auto-lock

A WP:BRD restore on Basilica di Santa Maria Maggiore is needed.

(cur | prev) 22:32, 1 March 2013‎ Aunva6 (talk | contribs)‎ m . . (48,513 bytes) (0)‎ . . (Aunva6 moved page Basilica di Santa Maria Maggiore to Basilica of Santa Mary Major: this is the ENGLISH wikipedia.) (undo)
(cur | prev) 02:09, 2 March 2013‎ INeverCry (talk | contribs)‎ m . . (48,513 bytes) (0)‎ . . (INeverCry moved page Basilica of Santa Mary Major to Basilica of Saint Mary Major: i misspelled on the move) (undo)

The move was undiscussed and an editor has tried to restore but it has auto-locked. Therefore a TR is needed. In ictu oculi (talk) 07:32, 17 March 2013 (UTC)

FYI Salix commented on the article Talk page to go with full RM now. (which leaves the RM coming from the "wrong end" but whatever)
For the record the reason I did not follow the suggested procedure at Wikipedia talk:Requested moves#Talk:Neve Şalom Synagogue above was that the discussion above did not seem to have concluded with a firm consensus, it seemed safer to notify here. Salix' comment necessitates full RM. Talk:Bohemian Crown Jewels happened in the interim more smoothly. In ictu oculi (talk) 13:26, 17 March 2013 (UTC)

Seoul Metropolitan Railway

Can someone examine Talk:Seoul Metropolitan Railway ? It seems like it should be a WP:BRD technical speedy revert, instead of keeping it at its new name and discussing a move back to the old one. -- 65.92.180.137 (talk) 21:34, 18 March 2013 (UTC)

I should have notified you earlier

People involve in WP:RM may be interested in the discussion at Wikipedia_talk:Naming_conventions_(people)#RFC-birth_date_format_conformity_when_used_to_disambiguate.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 12:35, 24 March 2013 (UTC)

Establishing a WP:PRIMARY within the brackets

Wikipedia talk:Disambiguation#Establishing a WP:PRIMARY within the brackets. In ictu oculi (talk) 06:11, 25 March 2013 (UTC)

Request Move Section titles

(I think I may have suggested this before, but am not sure).

I think that bot-completed formal RM proposals should involve the bot naming the talk page section title, not "Requested move", but "Requested move, Month Year".

This is because talk pages often contain multiple RMs, and they, especially links to them, easily confuse. If there is only one RM, it does not harm. It would be nice to see from the top of the talk page the date for one or more RM sections in the contents box. --SmokeyJoe (talk) 06:12, 6 March 2013 (UTC)

That is not a common occurrence. Having said that, if the bot could detect multiple listing and modify the heading would work for me. One other issue is the archives. There may only be one on the talk page, but one or more in the archives. This would not be addressed by my suggestion. So, I see some merit to your suggestion leaning to "Requested move, yyyy, mmmmmm" (minor format change, but not a show stopper). If this were done, it would be really nice to have auto generated links to older discussions. But that is more difficult to implement due to multiple page moves and multiple places for a discussion. Vegaswikian (talk) 06:48, 6 March 2013 (UTC)
If it doesn't happen often, it happens often enough. --SmokeyJoe (talk) 08:59, 6 March 2013 (UTC)
I support this suggestion. Great idea with lots of upside potential. --Mike Cline (talk) 11:07, 6 March 2013 (UTC)
Oppose. It is easy enough to change one of the duplicate headings, when they do occur. Lately it has become more common to have two RM's created in the same month. Apteva (talk) 00:18, 9 March 2013 (UTC)
And how does this help in the archives? If we have two in the same month, the bot can address that. Vegaswikian (talk) 00:47, 9 March 2013 (UTC)
Apteva, I can't understand why you would oppose modifying a bot to add the date in favour of having editors manually add a date to every RM section heading. Note that most RMs are submitted by non-RM regulars who simply use the template and would have no reason to think of modifying the resulting section heading.

As for when there are two RMs in the same months: Firstly, I think this should be against the general rule, and secondly, when it does happen, as an exception, in this situation editors should be expected to be experienced and to alter the heading to something more explanatory.

Oppose. A better disambiguator would be "Requested move to ...name...", or in case of real multiple confusors, "Requested move from. ... to ...". — Arthur Rubin (talk) 02:15, 9 March 2013 (UTC)
To name has problems in that it is often duplicated. Vegaswikian (talk) 03:20, 9 March 2013 (UTC)
Arthur, do you mean to oppose disambiguating by date, to have all RM requests have the same generic section title, unless we agree to your preference? Another problem with the "to name" option is that in the course of the discussion it can easily happen that the proposed target is agreed to be modified. And further, often the target name has those funny character or dash things that simple editors have trouble recognising/typing. I had quickly dismissed the idea of putting a target in the section title due to section titles being preferably not-for-editing. --SmokeyJoe (talk) 04:29, 12 March 2013 (UTC)
I like "Requested move, YYYY, mmm". In the relatively unusual cases of multiple move requests in same month, perhaps the bot can add "(2)" to the second. older ≠ wiser 09:51, 11 March 2013 (UTC)
older ≠ wiser, I wouldn't even ask for the bot to check, as I think it an extremely rare need for the complication for the bot writer. If there are two RM section titles with the same month-stamped section title, so be it. At least you can tell immediately from the table of contents and from direct links what their ages are, which is a major motivator for change here. The only time I have seen two RMs for the same page in the one month, they were both open simultaneously. These sort of things shouldn't happen. --SmokeyJoe (talk) 04:29, 12 March 2013 (UTC)
SmokeyJoe, yeah, I agree it should happen only extremely rarely. I guess it depends how OCD the bot-writer wants to be. older ≠ wiser 12:41, 12 March 2013 (UTC)
It really just seems simpler to leave the default at Requested move, and in the rare cases that there is a second one, just change the old one, or the new one. Apteva (talk) 05:26, 12 March 2013 (UTC)
Except that it is not all that "rare" to have multiple RMs on the same talk page. Most talk pages are not auto-archived and might have several years worth of RMs. Besides, I think having the month year in the heading provides good information for those who might come across that discussion at a much later time and mistakenly think it was recent. Is there a downside to including year and month? older ≠ wiser 12:41, 12 March 2013 (UTC)
And actually, most talk pages are not archived, having very little content. There are maybe only a few thousands that are active enough to be archived. For example, I clicked random article ten times, and of those only three had any content other than headers on the talk page, one with only one short section, and two with two short sections. We probably have about a hundred to a few thousand perennial move requests that are forever contested. It would actually be worth listing those WP:Persistent disputes. Apteva (talk) 21:56, 12 March 2013 (UTC)
Apteva, even if a page has not yet been archived, and there has been no previous proposal to rename, how does it hurt to put the month and year in the section title? --SmokeyJoe (talk) 01:51, 30 March 2013 (UTC)

Lost RM discussion

This discussion appears to have been "lost". That is, it's no longer listed here, but does not seem to have been closed.

Talk:Brand New (disambiguation)

--B2C 21:28, 25 March 2013 (UTC)

Fixed. Someone made the mistake of subst'd the /dated template, instead of first deleting /dated, and subst'ing Requested move.[17] Apteva (talk) 00:34, 26 March 2013 (UTC)
Thanks, that's interesting. I was participating in that discussion and hadn't even noticed that 29 January 2013 edit. It seems per their edit summary the editor misunderstood what was meant by the template message "Do not use {{requested move/dated}} directly." I fixed {{Requested move/dated}} to not allow substitution with this 18 February 2013 edit. As of 18:11, 3 March 2013, anyone who substitutes the /dated template will land the talk page in Category:Pages with incorrectly substituted templates. – Wbm1058 (talk) 20:42, 27 March 2013 (UTC)
They may have seen me do it a hundred times and not realize that I was deleting /dated each time. Apteva (talk) 16:07, 28 March 2013 (UTC)

Add section title for adding automatically

I propose add section title (==Requested move==) in Template:Requested move, for adding automatically. Like I did. — Preceding unsigned comment added by Vivaelcelta (talk • contribs) 18:21, 28 March 2013‎ (UTC)

{{subst:RMtalk}} is an alternative template which automatically creates the section title "Requested move," but it also gives you a formatted discussion section. I'd like to retain the flexibility of letting editors name the sections themselves. Right now we have a variety of section titles, such as:
Note that the last one links to a WikiProject page. This brings up another issue, which is discussed above in the section Request Move Section titles. Unique links are required to distinguish multiple RM discussions on the same talk page, whether separating a historical discussion from an active discussion, or multiple active discussions—which could become a bigger issue if discussing multi-moves on project pages becomes popular. We also have the issue of editors sometimes inserting a move tag without creating a new section for it. I would like to create a robust solution to these issues which changes the current bot algorithm for locating discussion sections to link to. I currently envision the move templates creating unique {{anchor}}s that the bot then keys off of. Perhaps "Requested move" can be the default section title, which can be overridden with something like parameter |section = Suggested move – editors should be given some warning of such a change to minimize creation of redundant section headers. Give me some time to come up with a solution. Thanks, Wbm1058 (talk) 14:20, 29 March 2013 (UTC)
Ok. Thanks you. --Vivaelcelta {talk  · contributions} 19:35, 29 March 2013 (UTC)
  • I would recommend against creating an anchor. I see absolutely no reason for standardizing the section headings. There is a slight preference for Requested move, as everyone knows what that means, but there is certainly nothing wrong with all of the variations. It is probably best to keep things the way they are, with one template creating the section headings and one not. Apteva (talk) 01:22, 30 March 2013 (UTC)
    • An anchor wouldn't be anything editors would be concerned with, it would just be something visible only when editing a talk page, and I could comment there that it was only for the bot's internal use and please just leave it be so as not to disrupt the bot. Its purpose would simply be to provide a unique link in the event that human editors created non-unique section titles such as two sections both titled "Requested move." But first, there is a fundamental issue with the bot's algorithm in that it stops looking after it finds the first {{Requested move/dated}} tag. First I need to modify its logic to process all /dated tags on a single talk page. If I can't do that, then the rest is moot. It's worth doing, if only to report an error when more than one is found, if the consensus is to not allow multiple active discussions on a single page. Oh, and if there is a section with a closed discussion but a non-unique section title, then the bot needs to ignore that one. I suppose an alternative might be for the bot to change section titles somehow to force them to be unique. – Wbm1058 (talk) 14:14, 30 March 2013 (UTC)
    • See {{subst:Requested move/sandbox}} for my suggested change to accommodate the desire to have a default title, while allowing all of the variations through use of a parameter to specify a non-default title. Comments on that suggested syntax, please (Coordinated edits to {{subst:RMtalk}} would be needed to implement this). Feel free to try it out. – Wbm1058 (talk) 14:14, 30 March 2013 (UTC)
  • None of that is needed. Getting to the right page is close enough. Most of the RM discussions are at the bottom, and if there is a dup someone will probably fix it. Apteva (talk) 22:22, 30 March 2013 (UTC)
    • An assumption that is not a good one. Yes, I did commonly fix these in discussions that were open for several days and not one seemed to care. No harm is done by generating more unique headings. And then we have the clear advantage in the archives where headings are probably rarely changed. So we have a solution that avoids issues or one that has shown to regularly cause issues. Which is the better one? Vegaswikian (talk) 22:40, 30 March 2013 (UTC)

Talk:Antisemitic canard

Is there any possibility of a passing admin shutting down this single-edit User's RM. At the very very generous end of possible interpretations it's an experienced past/current editor of some sort making light of antisemitism. In ictu oculi (talk) 17:33, 1 April 2013 (UTC)

And yes I'm aware that making fun of antisemitism is funny on April 1st. In ictu oculi (talk) 17:48, 1 April 2013 (UTC)

Just curious

A question I have asked at WT:AT... How many new articles start off using Title Case and have to be retitled to conform to Sentence case? I figured if anyone could answer this, it would be the regulars at RM who probably deal with this sort of thing all the time. Blueboar (talk) 17:57, 16 April 2013 (UTC)

Those tend to get fixed quickly without coming to RM. Dicklyon (talk) 22:50, 16 April 2013 (UTC)
If you look at Special:NewPages, you'll see most capitalized, appropriately, since most new topics are proper names. And you see a few proper names that should be capitalized and are not. Do you see any generics in Title Case? Probably there are a few. Dicklyon (talk) 22:53, 16 April 2013 (UTC)
Yeah, I see a few, but not many. Most of the inappropriate Title Case capitalizations seem to be done by new editors who may not have been told that Sentence case is our standard. (which in itself is something I have to ponder). In any case... thanks for the link. It does help to answer my question. Blueboar (talk) 01:26, 17 April 2013 (UTC)

Long-period variable

A BRD speedy revert (RM/TR) was converted to a discussion without reversion at Talk:Long-period variable. Shouldn't this be the other way around, reverting to Long period variable, and then opening a discussion? -- 70.24.250.103 (talk) 03:26, 18 April 2013 (UTC)

Yes, it should have, but it's hard to reverse course once a discussion gets going. If, however, the discussion closes as "no consensus," it should return to the prior version. I noted that at the talk page. (I also !voted for the hyphenated version, though, as I see it more supported in sources.) Dohn joe (talk) 16:43, 18 April 2013 (UTC)

Verbosity

The move instructions have quite a long suggested text:

"Place here your reasons for the proposed page name change, ideally referring to applicable naming convention policies and guidelines and providing evidence in support where appropriate. 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."

What it actually should point out somewhere is that if the move suggestion can not be summarized in one or two sentences it should be separated with a separate signature, one inside the template and one outside, so that what appears on WP:RM will be a short summary. If it can not be easily summarized, simply use (see talk page) ~~~~ and add the full information outside of the template with a signature. WP:RM does not need any of the details, just a very brief indication of the reason for the move. Apteva (talk) 05:18, 7 October 2012 (UTC)

How about:

"Place here a brief reason for the proposed name change."

And outside of the curly brackets add:

"After making the RM request please add a detailed reason for the proposed page name change, ideally referring to applicable naming convention policies and guidelines and providing evidence in support where appropriate. If your reasoning is based on search engine results, please provide the results of searches using Google Books or Google News with links before providing any web results. No Internet links should appear in the above brief reason sentence or sentences."

A lot of what I am having to fix are 1) huge long summaries and 2) no summary at all appearing on WP:RM. The above will fix both of those problems. Apteva (talk) 08:57, 13 October 2012 (UTC)

Requesting a single page move

(If your proposal involves moving more than one page—for example, if you will need to move one page, such as a disambiguation page, to move another page to that title—please use the process for "Requesting multiple page moves" below.)

To request a single page move, create a new section at the bottom of the Talk page of the article you want moved. Format it like this:

First edit to talk page:

== Requested move ==
{{subst:requested move|NewName}} Place here a brief reason for the proposed name change. ~~~~

Second edit (if needed) to talk page:

A detailed reason for the proposed page name change, ideally referring to applicable naming convention policies and guidelines and providing evidence in support where appropriate. If your reasoning is based on search engine results, please provide the results of searches using Google Books or Google News with links before providing any web results. ~~~~

--Apteva (talk) 21:35, 15 October 2012 (UTC)

Update:

To request a single page move, create a new section at the bottom of the Talk page of the article you want moved. To keep the summary which appears at WP:RM short, format it like this:

== Requested move ==
{{subst:requested move|NewName}} Place here a brief reason for the proposed name change. ~~~~


If needed add a detailed reason for the proposed page name change, ideally referring to applicable naming convention policies and guidelines and providing evidence in support where appropriate. If your reasoning is based on search engine results, please provide the results of searches using Google Books or Google News with links before providing any web results. ~~~~

And for multi moves:

==Requested move==
{{subst:move-multi
| current1 = Current title of page 1 with the talk page hosting this discussion
| new1 = New title for page 1
| current2 = Current title of page 2
| new2 = New title for page 2
| reason = Place here a brief reason for the proposed name change. Do not sign this.
}}


If needed, add detailed reasons for the proposed page name change, ideally referring to applicable naming convention policies and guidelines and providing evidence in support where appropriate. 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. Do sign this. ~~~~

--Apteva (talk) 03:14, 2 November 2012 (UTC)

I appreciate the concern here, but I don't see long RM submissions as necessarily bad - I like knowing what the proposal is about before going to the talk page. I also think that splitting out the RM summary from an initial comment is potentially confusing (one you sign, one you don't; refer to policies in the comment - does that mean don't do so in the RM summary?). In addition, we do already have the note to proposers about additional comments below the sample requests. I'd be fine with simplifying the sample request to say: "Place here a concise but supported rationale for the proposed title change." I'd also be okay with moving the sentences about guidelines and search result evidence to the note to proposers. I'd leave the basic structure as is, however. Dohn joe (talk) 16:09, 2 November 2012 (UTC)
The main point is that we want the proposers to be as verbose as they need to - but just do not want it to fill up the WP:RM page. Another solution is to make the bot truncate everything at say 40 characters, but I would rather do it this way, suggest a short summary for WP:RM and if needed a longer detailed explanation. Some of them can go on for half a page, and include images, and it makes it much harder to scan through the list if all of that gets copied to WP:RM. I agree that it is helpful to know what the reason is before clicking on the discussion link, but not at the expense of taking up a lot of space - if it does not fit onto one or two lines, you really are not going to know anything about it without reading the whole proposal, and that can be done just as easily on the talk page. The sign/don't sign only comes into play if either of the RMsubst: templates are used - and I doubt that the current suggestion would generate any confusion. Apteva (talk) 23:05, 2 November 2012 (UTC)
Do you have an example or two of current RM listings that are too long? I only see a couple that go more than 4-5 lines on my screen, and they don't seem excessively wordy. Sometimes you need 4-5 lines to get the gist across. I agree that sometimes there are poorly written requests or ones that go on too long, but frankly, I think the kinds of people who write those requests won't be deterred from doing so just because the template says to keep it short. Dohn joe (talk) 23:40, 2 November 2012 (UTC)
  • Thiruvananthapuram → Trivandrum – Per WP:COMMONNAME. Thiruvananthapuram isn't listed in many English dictionaries or other sources that do not include native names, and when it is listed, no English pronunciation is provided. Ask yourself: How is Thiruvananthapuram to be pronounced in English? If you can't answer that with the references that an ordinary reader is likely to have access to, then the article does not belong under that name. How would an audio version of this article be created, for example? Trivandrum, on the other hand, is well established in English, and the English pronunciation is readily available.Dict.com, for example, defines Thiruvananthapuram as "the local official name of Trivandrum", while it defines Trivandrum as "a city in and the capital of Kerala state, in S India: Vishnu pilgrimage center. 409,761." For Trivandrum it provides an English pronunciation ([trih-van-druhm], /trɪˈvændrəm/); for Thiruvananthapuram it only provides the Malayalam (ˌθɪruːvəˈnæntæˌpuːrɑːm, no English pronunciation respelling). MW lists Trivandrum but not Thiruvananthapuram. Etc. — kwami (talk) 04:28, 13 November 2012 (UTC)
  • Brazilian Jiu-Jitsu → Brazilian jiu-jitsu – Per MOS:CAPS and WP:AT. This is English, not German; we do not capitalize random nouns and noun phrases. The [non-trademarked] names of sports and games are not proper names and are not capitalized. Cf. jiu-jitsu, chess, snooker, basketball, etc., etc., etc. The real name is jujutsu, anyway, and we don't capitalize after the hyphen in English, so "Jiu-Jitsu" is wrong three times over. A case can probably be made for moving this article to Brazilian jujutsu, but I won't raise that issue now (it would be a debate between proponents of "proper" usage of historical martial arts terminology vs. proponents of following populist but often historically ignorant sources; it is an argument I WP:DGAF about in this case. I'm only after fixing the silly "Capitalization Because I Really Like It A Lot And Think It Is Super-Important"). This is arguably a speedy case as a simple typo correction, but the WP:SSF essay exists largely because aficionados of any particular special interest are liable to argue pretty close to the point of death over capitalizing whatever it is they are especially interested in. PS: See also Wikipedia:Categories for discussion/Log/2012 November 13#Brazilian Jiu-Jitsu and subcategories. — SMcCandlish Talk⇒ ɖ∘¿¤þ Contrib. 02:12, 13 November 2012 (UTC)

Compare these with the typical two or three line entries. What I would suggest is changing the instructions per the above suggestion and see if it has any impact. If none, then it can just as easily be reverted. Apteva (talk) 19:46, 13 November 2012 (UTC) This is what it used to say.[18] Apteva (talk) 19:52, 13 November 2012 (UTC)

It is fairly tedious collecting data, but there is a recent abrupt increase in the average number of words from about 52/entry to about 73/entry. Apteva (talk) 06:00, 15 November 2012 (UTC)

Any objections to trying a version that would encourage shorter summaries at wp:rm? Apteva (talk) 08:04, 15 December 2012 (UTC)

New proposal:

To request a single page move, create a new section at the bottom of the Talk page of the article you want moved:

== Requested move ==
{{subst:requested move|NewName}} Place here a brief reason for the proposed name change. <u>Do not sign this.</u>

And for multi moves:

==Requested move==
{{subst:move-multi
| current1 = Current title of page 1 with the talk page hosting this discussion
| new1 = New title for page 1
| current2 = Current title of page 2
| new2 = New title for page 2
| current3 = Current title of page 3
| new3 = New title for page 3
| reason = Place here a brief reason for the proposed name change. <u>Do not sign this.</u>
}}
Expand as needed for up to 33 similar page moves in one request.

--Apteva (talk) 18:42, 14 January 2013 (UTC) Updated. Apteva (talk) 05:12, 12 February 2013 (UTC)

Not counting the page to be moved and the signature, some requests have only five words, or less, but we have one now with over 400 and two others with over 100. The average is about 73, which is higher than it has been before. Apteva (talk) 09:35, 11 March 2013 (UTC)

Anyone else interested in this? Apteva (talk) 19:02, 12 April 2013 (UTC)

  • Oppose. The biggest problem with RMs is not reading and citing policy and guideline, and most pertinently, not supplying evidence and using web search results only when it is supplied (even with the current language in place). If there was some way to make this more prominent and persuasive, I would be for it. I don't see much harm in some sort of automatic truncation on the display at WP:RM, though I don't actually see it as a problem at all. The way the list works, it's incredibly obvious where one entry begins and ends. What you suggest here would largely make citing policy and guidelines and supplying evidence a sidenote, that should only be done in rare cases, when we should strive to emphasize the opposite.--Fuhghettaboutit (talk) 15:59, 5 May 2013 (UTC)
    • How about a fairly generous automatic truncation, say 1000 bytes? Something that will eliminate the problematic entries and have no affect on the vast majority? Apteva (talk) 02:54, 6 May 2013 (UTC)

This is what 1,000 bytes looks like (the original was 2,825, another recent request was 5,966 bytes):

  • (Discuss) – Berlin Philharmonic → Berlin Philharmonic Orchestra – As a title in English, "Berlin Philharmonic Orchestra" is obviously the best. I have never seen BPO's records, CDs, DVDs, and MP3-sites written only "Berlin Philharmonic" in unfinished English. They are all credited "Berlin Philharmonic Orchestra" in decent English (below/above "Berliner Philharmoniker" in German). Apparently "BPO" is an abbriviation for "Berlin Philharmonic Orchestra" in English, not for its old official name " de:Berliner Philharmonisches Orchester ", in spite of the explanation in the header of the article. It seems that German people has been mistaking selfishly, though it may be only the result of edits of English persons who are not familiar about how popular Furtwängler BPO(VPO) and Karajan BPO(VPO) have been all over the world. For example, BPO and VPO conducted by Furtwängler and Karajan have been more and more highly evaluated in Japan and still now selling overwhelmingly and constantly more than other conductors and orchestras.Berlin Philharmonic what? Vienn NPThomas (talk) 20:24, 2 May 2013 (UTC), 22:36, 2 May 2013 (UTC)
As I said, I don't actually see a problem, but don't see harm either (especially with 1,000 bytes) and so I'm neutral on that.--Fuhghettaboutit (talk) 03:27, 6 May 2013 (UTC)

For comparison, this is what 256 bytes looks like:

After a little bit of experimentation I see that truncating is not a good solution – for example, if a link to an external URL gets truncated, say because the post was 1200 bytes, and the URL was much of that, the rendered text could actually be longer, not shorter if it was truncated. Also if formatting is included, like <small>, if the closing tag is lost, that formatting can extend to other entire listings. So instead of truncating, I would recommend automatically replacing all long posts with (see talk page). Right now I think the signature is not parsed separately so that would be lost, although the time stamp should be able to be retained, as I believe the parsing does isolate the time stamp for the purposes of sorting. Apteva (talk) 16:30, 10 May 2013 (UTC)

If I have no targeted name change how do I start a discussion?

I am not sure what protocol is on this matter. I am not sure if the names associated with the following templates are correct. Should we nominated these just to reconsider their names: {{The Sandman}}, {{Sandman}}, {{Sandman navbox}}. I am not sure what to propose as the correct destinations or whether anything needs to be moved.--TonyTheTiger (T/C/BIO/WP:CHICAGO/WP:FOUR) 21:08, 3 May 2013 (UTC)

Hey Tony. As to the technical issue, just use a question mark in place of a new name: {{subst:requested move|?|reason=}}. As to the substantive issue, why do you think there's any problem with the current template names? (There must be something behind why you are thinking of questioning them.)--Fuhghettaboutit (talk) 16:10, 5 May 2013 (UTC)
Have a non-RM discussion on the talk page(s) to find out what the appropriate (consensual or conventional) target name would be, and then start the RM. -- JHunterJ (talk) 17:03, 5 May 2013 (UTC)

Converting technicals to RMs

Can we ask editors to refrain from creating content-free RMs, neither explained nor supported nor opposed, from contested technicals? That would give the original proposer a chance to think about whether they really want an RM, and if so what rationale to use. We've been seeing a rather of these lame RMs in recent months, which could either go away or become sensible proposals, either of which would be better than what some editors have been doing. Dicklyon (talk) 02:51, 6 May 2013 (UTC)

This is modus operandi for some of us. Others (like me) just delete these after a week. For me either method is acceptable. Bear in mind that there is always a time span between the time that someone has contested the TR and when it gets converted to an RM. I certainly can not imagine a scenario where any delay would make any difference – all RM's by default last 7 days, which in my opinion is plenty of time for anyone to come up with a convincing "rationale". To me it is like a student raising their hand in class, there are no "lame" questions. Apteva (talk) 03:18, 6 May 2013 (UTC)
I know it's your modus operandi, and I know you believe there are no lame questions, but I didn't want to mention you by name. So can you please just stop it; or at least notify the proposer and give them time to make a proper RM first? Dicklyon (talk) 19:57, 6 May 2013 (UTC)
Actually, I may have been confused about exactly how some of these came about, but the problem is the content-free nature of the RM proposals such as: Talk:Vienna_Philharmonic#Requested_move (which seems to also be open at the other multi-RM) and Talk:Jean_Gordon_(Red_Cross_Donut_Girl)#Requested_move. If your usual process is to just delete them after a while, thank you for that. Dicklyon (talk) 21:45, 6 May 2013 (UTC)
I agree threadbare requests shouldn't be made into RMs. I have boldly created {{Contested technical RM}} to make this easier. Please feel free to tweak the language.

Wherever we might memorialize this, I have a tangent issue. Technical requests are often made into RMs without any indication that it started as a technical request. This often would and does leave the protest, which was geared at the technical request, nonsensical or a bit odd seeming at the RM. For example, Talk:United States v. Windsor#Move?, where I added the note that says "Moved from technical move requests, with the above text." Something instruction like this would work: "Upon making a contested technical request into a requested move discussion, please indicate at the end of the text you are moving that it was moved from technical requests. We suggest :<small>Moved from technical move requests, with the above text.--~~~~</small>"--Fuhghettaboutit (talk) 04:20, 6 May 2013 (UTC)

The problem with that template is it puts the burden on creating an RM on the proponent. Right now almost all of these RMs are created by someone else, and leaving a template and having someone else create the RM creates confusion. If nothing else I would change the wording to add "unless someone else already has". I will note that we are overtemplated already, and personal messages are much better than templates, so I would recommend just deleting this new template as not needed. What would be useful, though, is a "nosign=yes" option to the Requested move template, that would remove the sig and the sentence about put your reason here. Right now I am subst'ing the template and then deleting all that stuff. Apteva (talk) 03:18, 7 May 2013 (UTC)
I don't understand what you mean at all. This template is for use by responders who are not creating the RM from the technical request because it was empty. It works like this: the person who reviews the technical request that's been moved to contested, instead of creating an RM with an empty rationale beause one wasn't provided (as has been happening, and what Dicklyon was talking about), instead removes the technical request and does not create an RM, because empty RMs=bad. Instead, the decliner tells the user who made the request that they've they've declined the technical RM, and that if the person wants to pursue it, to make a formal requested move and points the person to the instructions.--Fuhghettaboutit (talk) 04:57, 7 May 2013 (UTC)
Oh. I see nothing wrong with "empty" RMs. Someone will either come up with a reason for the move or it will get closed as "no move" soon enough. These are not a problem in any way. But if someone wants to clear out the contested section sooner than a week without converting the request to an RM, and wants to notify the proponent to come up with a valid RM, that is better done personally than with a template, and will help with editor retention, as one of the things that drives editors away is over use of templating. Apteva (talk) 15:02, 7 May 2013 (UTC)

It would be nice to have an easier way to convert a TR to an RM, for example, by adding an optional |nosign=yes parameter to Template:Requested move, for those editors who are doing it for someone else. Apteva (talk) 20:06, 21 May 2013 (UTC)

Recent WP:BOLD move of Electorate of the Palatinate, despite previous controversy

User:Hansmccx moved this page from Electoral Palatinate on 13MAY2013 despite there being several controversies in the past discussed on the talk page. His only reasoning given was "per WP:TITLE" which offers no insight into the reason for the move action. I've advised him to comment on the talk page and hope that someone here would be willing to sort through this offering a third opinion.--ColonelHenry (talk) 16:51, 13 May 2013 (UTC)

Move request procedure at Berlin Philharmonic

Has the move procedure changed recently? I remember we used to put a move banner at the top of the article page. This wasn't done for the requested change at Berlin Philharmonic, but when I looked I couldn't find the banner tag.

Another problem is that the request for Berlin Philharmonic was linked to a different one for Vienna Philharmonic. How can I ask for the discussions to be separated? I tried to start a talk topic at the latter page but it was deleted (twice) [19]. I'd appreciate some procedural advice. Thanks. --Kleinzach 00:10, 4 May 2013 (UTC)

Is it possible you are thinking of WP:Merge? That involves tags on the article page. Green Giant (talk) 23:55, 4 May 2013 (UTC)
The move tag has been on the talk page almost forever. There is a multimove for those two pages, to consolidate the discussion in one place. If it is more practical, they can be separated into two discussions. It tends to get messy to change after editors have already commented. Right now the two pages are very messy. Apteva (talk) 02:20, 6 May 2013 (UTC)
Split into separate discussions. Best of luck. Apteva (talk) 02:29, 6 May 2013 (UTC)
Thanks (belated!). --Kleinzach 02:23, 23 May 2013 (UTC)

NFUR images and page moves

I've noticed some bureaucratic musings at NFCR that images with FURs linked to redirects to pages fail NFCC 10c because the page indicated is not the the image is being used on. As this is the case that happens after a page is moved, would a necessary step be to inform the person who moves the page to correct the fair-use rationales on file pages to point to the new pagename? -- 65.94.76.126 (talk) 08:31, 8 May 2013 (UTC)

Yes, and this is in the closing instructions at Wikipedia:Requested moves/Closing instructions#Fixing fair use rationales. Thanks for bringing this up, though. Apteva (talk) 15:24, 8 May 2013 (UTC)

Why not just rephrase NFCC 10c to say that linking a redirect to an article is just as good as linking directly? And/or advise anyone who sees such a situation to update it, rather than to regard it as a violation? Dicklyon (talk) 02:46, 22 May 2013 (UTC)

Already says that, but it clearly is not as good as an actual link. The text says "acceptable". Misspelled words, and many other nuances, such as the error of using British English for an article about say San Francisco, are also "acceptable", but are best corrected (editors are not prohibited from adding content that contains spelling errors). Apteva (talk) 19:24, 22 May 2013 (UTC)

Straw poll: Requests without discussion

After I recently relisted an RM that had gone a week without comments, Apteva took issue and contacted me on my talk page (discussion). Apteva contends (please correct me if I'm misrepresenting) that such requests should be considered non-controversial, like technical requests, and moved as requested. This position is supported by wording at WP:RMCI. In practice, however, such requests are often relisted, with this process only followed after another week without input. I don't think I'm the only one who does this, though I could be mistaken. Since RM is a consensus-building process explicitly for potentially controversial requests, I think this single relist is prudent and does no harm. But on the other hand, we do have a backlog. And for what it's worth, multiple relists very rarely seem fruitful. So what do you think? If an RM has run for a week without support or opposition, should an administrator or qualified non-admin editor close or relist? --BDD (talk) 18:20, 7 May 2013 (UTC)

  • Relist. We are in no rush. No reason not to wait another week to give anyone a chance that may be against the move to comment. For all we know the most frequent contributor to the article, who thinks the current title is correct, is on vacation.oknazevad (talk) 18:26, 7 May 2013 (UTC)
  • Judgement call. If the talk page is relatively sparse and there is no sign of anything controversial, just move it. Otherwise relist it. --regentspark (comment) 18:32, 7 May 2013 (UTC)
  • By default move unless there are policy or guideline reasons to hesitate (close with a consensus to move), or if the closer object to the move (close with a no consensus) My arguments are based on the assumption that this is not like a AfD, pages are often moved boldly, and if someone comes along later and wants to move it back they can always put in another RM. Silence equals consent. -- PBS (talk) 18:59, 7 May 2013 (UTC)
It's hard to see how a no consensus close would be anything but a WP:SUPERVOTE. If the would-be closer disagrees with the move, he or she should register an oppose vote and leave it to someone else to close. --BDD (talk) 19:53, 7 May 2013 (UTC)
Agree. But if there is a conflict with a naming convention, there is no reason to relist: cite the reason instead of calling it a "no consensus" close. Note: Many RM proposals do violate naming conventions, and editors often cite conflicting ideas of how a title violates this or that guideline. Basically our closing instructions for no comment proposals say, do it unless there is a violation of a naming convention, just as no matter how many votes there are for something, a move result can be chosen by the closer citing a conflicting convention that requires or precludes the move. Apteva (talk) 21:38, 7 May 2013 (UTC)
  • Move, unless there is a naming convention violation. WP:RM is cluttered enough, and there is no reason to go through another cycle. A week is plenty of time for anyone to comment if they want to. I often do not comment even though I agree, because I trust that the article will be moved per WP:RMCI. Apteva (talk) 19:31, 7 May 2013 (UTC)
  • Agree with regents, this is a judgement call issue. If the admin sees no issue with the move rationale, they're well within their purview to move. They are equally within their purview to relist and wait for more input if they think that will be productive. While they need to consider that leaving articles in the backlog for weeks may not be productive, they are by no means required to move a page simply because no one has objected.--Cúchullain t/c 20:04, 7 May 2013 (UTC)
  • Judgement call defaulting to move. Listing originally verses boldly moving was already a judgement call. That no one responded supports the notion that it is not controversial. The value on relisting seems pretty low to me. If you have already read through the discussion and decided it is not ready to close, surely you can make some contributing statement to the discussion as a new !voter. If you are the lister, and you are hesitant on boldly moving, I suggest a poking statement along the lines: "If there are no objections in the next few days, I will perform the move" --SmokeyJoe (talk) 02:28, 8 May 2013 (UTC)
  • I'm with regentspark and the others - there is no "one size fits all" answer to this. But, usually, I would think closing and moving is appropriate. Only if there is a good reason to not move as requested should there be a relist, or possibly even a no consensus close. --B2C 23:24, 21 May 2013 (UTC)
  • Relist once then move two weeks of discussion isn't doing any harm, and the nom should be allowed to ask for a RM/TR if there is no discussion after 1 week, shortening the second week. -- 65.94.76.126 (talk) 05:40, 24 May 2013 (UTC)

South Florida (Miami) State Road article naming

I'm creating this thread here in what I hope is neutral but relevant territory for what I can see is a conflict of interest in article naming between WikiProject:U.S. Roads, WikiProject:U.S. Streets and WikiProject:Miami. I hope this is acceptable for those who run WP:RM and that I'm doing the right thing.

As I've been editing Florida State Road articles over the past couple of months, I've noticed some inconsistencies with the names of some articles of those State Roads located in the Miami metropolitan area. Generally, according to the "Major thoroughfares" section of the Template:Greater Miami table, the named roads will link to their corresponding State Road articles, e.g. West Dixie Highway → Florida State Road 909, Biscayne Boulevard → U.S. Route 1 in Florida#Miami-Dade County, etc. Despite this, there are some articles that link to a named road in lieu of a (typically) partial State Road designation. These articles (from what I could find) are listed below:

All of these roads have State Road designations for a partial but what appears to be significant portion of their total length. While it would seem that this would be the precedent, a competing precedent has been set by other State Road articles that only run for a portion of the length of the named roads. These include examples such as Florida State Road 989, the article name of which refers to the majority of Allapattah Road/Southwest 112th Street, and Florida State Road 990 which describes the entire Killian Drive/Killian Parkway despite only referring to less than a quarter of the road's entire length in its article name.

Given that the rest of the Major thoroughfare articles in Template:Greater Miami link to a Florida State Road article where appropriate, I propose that these eight articles are renamed to their State Road counterparts with their current names acting as redirects. Renaming the articles as such would align with the standards set at WP:USSH.

As an alternative method (playing devil's advocate here), I refer to Red Road (Miami), which has two partial State Road designations along its length with their own articles: Florida State Road 959 and Florida State Road 823. The State Road and street name sections have been broken into two separate articles here, and may work as a compromise; however, I see two problems with this:

  • Splitting the two sections of street name (entire length) and State Road length into separate articles may result in the creation of more stubs, something that I know WP:USRD is seeking to avoid as much as humanly possible. It would create a lot of work to break the articles apart and then even more work to bring the articles up to their former standards. In some cases, it may be very difficult for the articles to be standalone, especially where the length of the State Road is quite a short portion of the total length.
  • Secondly, the Red Road article appears to be a special case, especially as Florida State Road 823's designation goes beyond Red Road's terminus (and thus suitable coverage by a Red Road article).

I have already opened discussion on Kendall Drive as of writing this discussion post, with the other seven articles to follow as soon as I post this thread, and Kendall Drive's reasoning to be linked here.

Please feel free to discuss in replies below. -DyluckTRocket (talk) 11:37, 26 May 2013 (UTC)

I checked a few of these articles. As written, the ones I checked should retain the named designation. For example, Flagler Street is mostly city maintained with only a portion having a state designation. As such it would not be accurate to title the article by the state designation, when the article covers parts of the roadway that extend beyond the state's limits. I would not advise to split the article into two unless both article about the state highway and the city street could be improved to B class and not be redundant with each other. (I.E. I do not support splitting an article into two if one or both are guaranteed to be perma-stubs).
IMO, in the case of where the named and numerical designations are identical (i.e. one is not longer than the other) the criteria over weather the article should be titled by it's numerical designation verses its named designation should be based on primarily which is the official name? If both are official, which is more commonly used in both popular and official sources?
For the record, there is precedent for having two articles for the same roadway, however I would only support this for given my above criteria that both can be improved to B class or higher. Some examples I'm aware of are Arroyo Seco Parkway (a named segment of California State Route 110) and Nevada State Route 604, a portion of the roadway much more famously known as Las Vegas Blvd. Dave (talk) 02:41, 28 May 2013 (UTC)

Unreal7 (talk · contribs)

Per Wikipedia talk:Requested moves/Archive 23, User:Unreal7 is again breaking requested move bot pickup with improperly formed nominations. I've noticed 3 in the last week, the same problem as last year. -- 65.94.76.126 (talk) 01:04, 28 May 2013 (UTC)

My apologies. I just didn't know how they were properly formed. Unreal7 (talk) 11:02, 28 May 2013 (UTC)

Move before consensus

The nominator has moved the article here before any consensus: Talk:The_Big_City_(1963_film)#Requested_move --Tito Dutta (contact) 18:51, 28 May 2013 (UTC)

I reverted their move. -- JHunterJ (talk) 18:56, 28 May 2013 (UTC)

Can "no consensus" mean "move"?

In a case where an article is at an ambiguous base name, and the proposal is to move it to a disambiguated title and move the dab page to the base name, what if there is "no consensus"?

Does the closer close it without moving as in any ordinary RM? Or does the closer find lack of consensus for the topic of that article being the WP:PRIMARYTOPIC, and thus move as proposed?

Specific example: Talk:Avatar#Does_.22no_consensus.22_mean_.22move.22_in_this_case.3F.

--B2C 19:54, 26 May 2013 (UTC)

  • Yes. Two examples: (1) In a contest between the first non stub version and something else, no consensus should favour the first non-stub version. (2) No consensus on a PrimaryTopic should be taken as meaning that there is no PrimaryTopic. --SmokeyJoe (talk)
    • That make sense. I wonder if regular RM closers agree. Perhaps something about this should be added to the closing instructions? --B2C 03:05, 27 May 2013 (UTC)
    • "First non-stub version" is sometimes not very satisfying. If an article has been long-stable at a title, and there's no consensus to move it, then why move it so arbitrarily? Dicklyon (talk) 04:36, 27 May 2013 (UTC)
      • If the contest is between the first non stub version and something else, meaning that the first non stub version and the something else are both directly addressed, then points about problems with the first name and stability will have been raised, and if direct discussion reaches no consensus, then the move will not be arbitrary. It will be the reversion of a rename subsequently decided to not have consensus. Note that the question of "long-term stable" is also subject to interpretation and consensus. Is a page long-term stable if it have been move-protected for the long-term? I agree, as pointed out by Jenks24 (see here), that defaulting to the first non stub version doesn't make sense if it wasn't even discussed. --SmokeyJoe (talk) 04:58, 27 May 2013 (UTC)
    • No consensus for a change in primary topic (from one topic to another, from no primary to primary, or from primary to no primary) should result in no move. If there's currently a primary topic and in an RM to move the disambiguation page to the base name if there's no consensus to change to no primary topic, then the closing admin shouldn't close the requested move as "no consensus" and then move the disambiguation page to the base name, obviously. -- JHunterJ (talk) 13:41, 27 May 2013 (UTC)
      • In the case of Avatar, however, there never was a consensus for a primary topic, yet the last RM was closed as move. It's hard to understand why; but it ought to be fixed given that there never was a consensus for a primary topic. Dicklyon (talk) 15:03, 27 May 2013 (UTC)
        • The case at Avatar might be handled specially then (and I would prefer the dab page at the base name in this case, as I've !voted). That's different than the question being asked here, though. If there's no consensus for a move (even if the reason is to change from a primary topic to no primary topic), then the result is not "move". If an earlier move was mishandled, there's move review. -- JHunterJ (talk) 15:34, 27 May 2013 (UTC)
          • JHJ, what I'm suggesting is that in cases where the proposal is to move an article with an ambiguous term to a disambiguated title, to move the dab page to the base name, even if there is "no consensus" for the proposed move, this should be recognized as "no consensus" for the article topic at the base name being the primary topic, and so the move, as proposed, should be made. --B2C 19:23, 27 May 2013 (UTC)
            • No because "no consensus" means "no consensus to change status quo". -DJSasso (talk) 20:49, 27 May 2013 (UTC)
            • What you're suggesting is that in cases where there is no consensus for a move, the move be performed anyway, because ambiguity. I'm observing that that's not a valid reason to perform a proposed move when there's no consensus for it. "Recognizing" no consensus for the move as no consensus for a primary topic is not "recognition" at all, but "reinterpretation". -- JHunterJ (talk) 21:37, 27 May 2013 (UTC)
Per WP:NOCONSENSUS: "In article title discussions, no consensus has two defaults: If an article title has been stable for a long time, then the long-standing article title is kept. If it has never been stable, or has been unstable for a long time, then it is moved to the title used by the first major contributor after the article ceased to be a stub." Applied to the example provided above (Avatar), "no consensus" would not mean move. ╠╣uw [talk] 23:27, 27 May 2013 (UTC)
B2C, the simple answer is "no". In the case of Avatar, there is a request to move. There is no consensus to move. So we don't move. Omnedon (talk) 02:16, 28 May 2013 (UTC)
  • Given that the detail of things can be complicated, perhaps it should be taken that where a "no consensus" would appear to imply a "default move" instead of a "no move", that the arguable default move should be formalized by a follow-up RM focused on that question.
    In cases where a RM has ended with a finding for "no consensus" for a PT, the follow up RM question "As there is no consensus for the PT, the following page move should be made". These cases involve clearly sequential decision making, and i for one prefer to not debate what would happen if the current discussions ends as "no consensus" while I am trying to steer the discussion into a particular consensus.
    This method would see the idea of a "default move" tested every time, which appears appropriate given the disagreement above, and it maintains the closer's role of implementing "no move" if there is no consensus. --SmokeyJoe (talk) 06:17, 28 May 2013 (UTC)
    Yeah. I'm not necessarily looking for having this apply in the case of Avatar. In general, maybe we could have a special type of RM request, called something like "Requested Move - Primary Topic Challenge" with a canned heading:
    The treatment of this article topic as being "primary" is challenged in this RM proposal. If the proposed move is supported or not clearly opposed by consensus ("no consensus"), the result is "no primary topic" and the move should be made as proposed.
    What do you think? --B2C 07:02, 28 May 2013 (UTC)
    I think the questions should be sequential. The result of the first should be assumed fact for the second. --SmokeyJoe (talk) 08:19, 28 May 2013 (UTC)
    I think it's wrong. If you need a "primary topic challenge" discussion, it's wouldn't be a move request. If the "primary topic challenge" results in consensus that there's no primary topic, the subsequent move request should have the same consensus that the disambiguation page gets moved to the base name. If it doesn't, well, editors are strange, yep. No special handling is needed, and if there's no consensus for changing the status quo, then there's no consensus for changing the status quo. -- JHunterJ (talk) 11:09, 28 May 2013 (UTC)
    JHJ, if the "primary topic challenge" results in consensus that there's no primary topic, the situation is a no-brainer. The issue is about what to do when there is no consensus that the topic of the article at the term is primary for that term. In other words, if there is no consensus that a given article topic is primary for a given term, what is the basis for leaving that article at the base name of that term? --B2C 15:17, 28 May 2013 (UTC)
    Born2 makes a good point... let me make another... in any consensus deliberation, we have to pay close attention to exactly what was being asked. If the question was: "Should X be considered the primary topic?" then a no consensus result would mean X should not be considered the primary topic... However, that deliberation does not answer the more basic question: "Is there a primary topic for this?" After all, something else might be the primary topic. Blueboar (talk) 15:34, 28 May 2013 (UTC)
    I think this avenue may be the most fruitful. First a non-move RFC asking the question, "Is there a primary topic for X"? It may be help to avoid confusion to also ask those replying "yes" to indicate which topic is primary. Then, the outcome of such an RFC might provide basis for a subsequent RM. But I also agree with JHJ's observation that sometimes the editorial collective can be fickle, and it is possible that an RM might fail even if the RFC did not establish a primary topic. older ≠ wiser 15:52, 28 May 2013 (UTC)
    The basis for leaving the article at the base name of that term is that there's no consensus to move it from the base name of that term. Also a no-brainer. You're trying to find a "new consensus" where there is "no consensus". I understand the goal, but this is not the path there. -- JHunterJ (talk)
    Again... what a "no consensus" actually means all depends on what question was asked, and where we started from... a no consensus when the question is: "Should X be made the primary topic?" will have a different result from a no consensus when the question is: "Should X remain the primary topic?" Both determinations indicate that we should retain the "status quo", but the "status quo" will be different in each scenario. Blueboar (talk) 17:30, 28 May 2013 (UTC)
    And again, whatever the question actually asked, "no consensus" for X will never yield "new consensus" for Y. If you want consensus for Y (e.g., moving the dab page to the base name), you'll need consensus for Y. -- JHunterJ (talk) 18:40, 28 May 2013 (UTC)
  • In the case of the specific example given above, Avatar, with the exception of a five month period between September 2010 and February 2011, the article has been stable as the Hindu concept since its origination in 2002. The current Request for Move has resulted in a survey count of 13 supporting and 13 objecting. So there is no consensus to move. The policy for this is clearly stated here. If an article title has been stable for a long time, then the long-standing article title is kept. Dazedbythebell (talk) 14:31, 29 May 2013 (UTC)
    Is it possible that cases like this - where the primary topic of an article currently located at a base name is challenged - was not considered in the writing of that policy? For an article to have a term which is ambiguous with other uses on WP as its title is a big deal. Paris comes to mind. Shouldn't we have consensus that the topic of such an article is actually the primary topic for that term for it to remain at that title? --B2C 18:46, 29 May 2013 (UTC)
  • If there is no concensus that the topic is the Primary Topic, and then no consensus that the topic should not remain at the undisambiguated title, then it must mean that PrimaryTopic, whether the guideline or the concept or both, is not very good. --SmokeyJoe (talk) 13:45, 31 May 2013 (UTC)
    "must" is wrong there. It could mean that the editors involved in the consensuses didn't understand the Primary Topic guidelines, concept, or both. -- JHunterJ (talk) 14:07, 31 May 2013 (UTC)
    If editors don't understand the Primary Topic guidelines, concept, or both, then minimally there is fault with the guideline. A guideline should be measured by how well it guides in practice. So I'll stick with "must". All is not well. If editors can follow the guideline and come up with contradictory results, then something is wrong. It's not reasonable to blame editors for failing to understand. --SmokeyJoe (talk) 20:50, 31 May 2013 (UTC)
    The contradictory results discussed here can't come from following the guidelines. However, editors can and do edit while ignorant of some guidelines and while knowing-but-ignoring others. So I'll stick with "must" is wrong there. -- JHunterJ (talk) 22:02, 31 May 2013 (UTC)
    Are you on the side of "editors must follow the guidelines" and against " guidelines must reflect actual practice"? --SmokeyJoe (talk) 22:51, 31 May 2013 (UTC)
    I have to say, there is widespread misunderstanding about the meaning of "primary topic" among editors. Many seem to conflate "primary" with "most important", which it was never intended to mean in this context. But at least the wording used to be clear on that. However, enough interpret it that way that the relatively recent "historical significance" criterion was added, which muddled the meaning even more. It seems that we have far more disagreements centered on PT since the addition of that caveat than we ever did before. --B2C 22:59, 31 May 2013 (UTC)
    Are you on the side of WP:CONSENSUS or WP:LOCALCONSENSUS? -- JHunterJ (talk) 23:11, 31 May 2013 (UTC)
    Where a local consensus appears to be at odds with a wider consensus (both misnomers, consensus is a process not a result), the onus is on those aware of the wider consensus to educate the others, and reference to a rule is not good enough. --SmokeyJoe (talk) 02:46, 1 June 2013 (UTC)
    I am not aware of that onus. Apparently it is up to you to educate me as to where that is detailed, and explain it until I agree. -- JHunterJ (talk) 11:18, 1 June 2013 (UTC)
    The onus is in my belief of ideal behaviour. (You appeared to be asking me of my views)
    You could continue to regard the ordinary confused editor as stupid, and enforse the rules as per your interpretation (closing against LOCALCONSENSUS per the GUIDELINE), or you can explain to the confused editor what the guideline means and why it is a good idea, or you could improve the guideline so that the non-initiated can understand and agree with it. (assuming that the intended meaning of the guideline is good)
    My question of 22:51, 31 May 2013 was sincere. You appear to have a very long association with titling practices. Could you please attempt to give some answer. Feel free to not read it as binary, and to soften the word "must". --SmokeyJoe (talk) 12:13, 1 June 2013 (UTC)
    My statements are my beliefs of WP behavior, and attempts to clarify the guidelines have met with resistance from the minority, and attempts to make the guidelines agreeable to the minority have met with resistance because they then become too convoluted. Your sincere question has a false dichotomy. I'm not on only one side. Guidelines should continue to be improved to reflect the consensus; and individual editors should follow the guidelines on the assumption that they do reflect the consensus, or should improve the guidelines to better reflect the consensus, or should build a new consensus and change the guidelines. Editors shouldn't, but sometimes do, disagree with the consensus, ignore guidelines that reflect that consensus, and revert changes to the guidelines that improve the guidelines' reflection of the consensus. I do not regard those editors as confused or stupid. -- JHunterJ (talk) 12:28, 1 June 2013 (UTC)
    If you are explaining why you have given up trying to clarify the guidelines, I understand. Stupid may be a poor word, overstrong, but I often see editors confused, and admit to being confused myself. At the moment, I consider the discussion at Talk:Avatar to be incompatible with the current guideline WP:PRIMARYTOPIC, and have no good ideas of what could be done about the incompatability. --SmokeyJoe (talk) 12:39, 1 June 2013 (UTC)
    I've left off attempts to introduce improvements; because of my long history and expertise with the disambiguation guidelines, editors who disagree with the consensus have painted my edits as self-serving (even when I was one of the editors who disagreed with the consensus but still introduced language to clarify that consensus). I'm a hobbyist here, so I left off the parts that hold no fun for me. The perception problem at Talk:Avatar continues to be conflating "no consensus to change from the current primary topic" and "consensus that there is no primary topic". The stable state is a primary topic; to change from that, a new consensus is needed. None of that is incompatible with WP:PRIMARYTOPIC, even if I individually agree with the non-consensus opinion that there is no primary topic. I would love to change the WP:PRIMARYTOPIC guidelines to use stronger terms for the criteria, but there is no consensus for those changes, so results like those at Talk:Avatar are consistent with the breadth of possibilities within the current guidelines. -- JHunterJ (talk) 13:02, 1 June 2013 (UTC)

There was a recent attempt to revert "GameCube" back to "Nintendo GameCube" when someone unilaterally renamed the article to "GameCube" last year that violated the 2009 consensus. However, the latest consensus prompted the nominator to withdraw the request. If the discussion resulted "no consensus"... could they have reverted the title back to "Nintendo GameCube"? --George Ho (talk) 12:41, 1 June 2013 (UTC)

I think, "yes". The first non stub has precedence over a bold rename, where it is genuinely no consensus. Note that the recent attempt was not headed for a "no consensus", but a consensus support for the GameCube, and certainly a very easily defended rough consensus. --SmokeyJoe (talk) 12:57, 1 June 2013 (UTC)

Help to move some articles.

Ive noticed there is a large backlog of moves, I would like to help get through some of them, but Im unsure whether there is a requirement that the "movers" here have admin status. --- Nbound (talk) 23:08, 28 May 2013 (UTC)

No, they do not have to be admins, but non-admin closers should (i) be very careful with determining consensus, since any non-admin closure can be contested, so that it might be good to start with obvious cases; (ii) either should not perform closures where deletion of a target is required, or after closing such a request as move ask an admin to delete (for instance, put a CSD notice with detailed explanation and keep it in the watchlist). Thanks for helping out.--Ymblanter (talk) 06:57, 29 May 2013 (UTC)
Where are the non-admin close instructions? We just had a non-admin close a contentious RM over objections, which if I recall correctly is something that should be left for an admin. Dicklyon (talk) 02:23, 1 June 2013 (UTC)
WP:RMCI. Do your own homework. -Nathan Johnson (talk) 02:32, 1 June 2013 (UTC)
The first requirement listed for a non-admin close at RMCI is: "The consensus or lack of consensus is clear after a full listing period (seven days).". In this case the !votes were evenly divided. Whether there is a consensus or lack of consensus is not clear at all. It's the quintessential case requiring careful reading, judgment, explanation of decision, and, thus, an admin to close. --B2C 02:41, 1 June 2013 (UTC)
No. As discussion in an above section makes clear. There was clearly no consensus. -Nathan Johnson (talk) 02:45, 1 June 2013 (UTC)
@User:Nbound, don't do it. All you get is bitching. -Nathan Johnson (talk) 02:39, 1 June 2013 (UTC)
I wouldnt be moving any pages that werent unanimous anyway. Or those where there was a potential COI either. Ill leave the admins to do the tricky/controversial ones ;) -- Nbound (talk) 02:54, 1 June 2013 (UTC)
Very good strategy.--Ymblanter (talk) 08:08, 1 June 2013 (UTC)
Unanimous decisions tend to get closed pretty quickly. ;) -Nathan Johnson (talk) 14:54, 1 June 2013 (UTC)

Non-admin closures of controversial RMs

The appropriateness of the non-admin closures of two recents RMs has been questioned at this AN/I:

The larger question at issue (also briefly discussed above) is whether non-admin closures of controversial RMs (no clear consensus either way) are appropriate in general. --B2C 03:30, 1 June 2013 (UTC)

Continued

Continued from Wikipedia:Administrators'_noticeboard/Incidents#Non-admin_closures_of_controversial_RM_discussions_-_appropriate.3F

Jayron32, your post surprised me, but no, I am not "wrong". Admins do have a special role in closing some types of discussion, especially XfD. For RMs, I guess you are not up to speed with Wikipedia:Move review, why it was created, etc. Let's take this to WP:RM.

At WP:ANI, this began with my statement "Any admin may revert any NAC for any reason or no reason" and continued to Jayron32's reply:

I'm sorry Joe, but there's no simpler way to say this than "you're wrong". Admins do not hold a hierarchical position above anyone else with regards to reading and interpreting consensus in any form, and that includes undoing bad closures on the part of others. Admins have access to additional technical tools, but that access only gives them the privilege to use those tools, and in any action that does not directly involve the use of their tools, they do not have extra privilege. Moving articles do not require admins because any user may move an article. Undoing a bad closure also does not require an admin, though users should not battle back and forth over the matter, as edit warring is a blockable offense, and THAT would require an admin at that point. --Jayron32 16:37, 1 June 2013 (UTC)

There is a heirarchy. or a sorts. Admins have a role in closing discussions, not just where admin function is required, especially where the close is non-obvious and involves invoking a WP:Rough consensus or calling "no consensus" where the "no consensus" serves to end the discussion. Admins are challenged on this at WP:RFA, and admins are broadly expected to meet higher behavioural standards, such as WP:CIVIL, being well aware of WP:INVOLVED requirements, and being available and forthcoming with explanations if queried.

A little while ago, at WP:RM, things were paraticularly bad. WP:RM closes, which didn't, and don't, require admins to close, was suffering from frequent lack of respect for closes. After some discussion, WP:MR was set up. WP:MR, despite the small number of cases, has had a dramatic effect on respect for RM closes.

Conventionally, WP:RMs are closed by admins, but there is no requirement for admins if they are not required. So, non-admins may perform WP:RM WP:NACs. Is a non-admin RM NAC an ordinary editorial action? If yes, then it means that any other editor may revert, may modify, and may outright reject. This would not be OK. It's what we had before and it is not satisfoactory. Consequently, WP:RM closes are expected to have some degree of formality. If you have a problem with a close, you should approach the closer, and if unsatisified, you are pointed to WP:MR. Alternatively, it is reasonable that if the close is a bad close, an admin should be free to revert and replace with their own close. We don't want to see WP:MR filled up with simple WP:NAC complaints.

With respect to User:Nathan Johnson's closes at Talk:Avatar and others, this is academic. Note that no admin has reverted his close, and no one has lodged at review at WP:MR, and Nathan has improved his close since the original complaints. In the absence of admin conflict, or complaints of admin action (such as an objection to a admins modification of Nathan's close), the complaint about the RM NAC closes did not belong at WP:ANI.

I have some reasonable experience with WP:DRV, and as much as anyone elses at wP:MR, and I have learned from these places that people like to have some formality to closes of contentious discussion. This means that objections have an option of a formal review, and that where NAC closes are at play, they are nominally reviewable by any admin. Reveiwable by any admin means that any admin by set aside an NAC close, and it means that non-admins may not unilaterally set aside NAC closes.

I am hoping for some comment on whether this should be the way we do things, and documented accordingly. --SmokeyJoe (talk) 03:08, 2 June 2013 (UTC)

Admins generally close XfDs because the results of those discussions require deletion. Technically, admins are only required to close those discussions where the result is delete, because a result of keep would not require the use of an admin tool, so non-admins can close those. Double technically, a non-admin could close a discussion which required a delete, and then just ask an admin to actually perform the delete. You are not going to convince me that admins are needed to close discussions, especially ones that don't require any admin tools, and I will continue to argue with you and any other person who asserts such ridiculousness. If people are insisting on this, then it represents a drastic culture shift at Wikipedia that I am not comfortable with. Conventionally, admins close discussions because they are experienced users, but it's their status as "experienced users" as in "I've been here a while and I know what I am doing" that accords them that; the presence or absence of the admin flag means diddly squat in these cases. If a close is a bad close, ANY editor may revert it; admins are not required. Again, if you think they should be, you should start a formal RFC to ask for a change to Wikipedia policy, because there's nothing that says anything like that now. I think you'd be sorely disappointed in the result, but you are quite free to test the community and see if there is consensus for your proposal to limit non-administrator's rights at Wikipedia. --Jayron32 04:05, 2 June 2013 (UTC)
Somehow, you are reading my intended statement completely wrong. I am NOT arguing for "only admins close discussions", but for the existing well defined process for XfD contested NACs to be broadened to include RM NACs, which are currently not well defined except for going straight to WP:MR.
"If a close is a bad close, ANY editor may revert it" is an invitation to edit war to dispute a close. Who decides that a close is a bad close? --SmokeyJoe (talk) 04:22, 2 June 2013 (UTC)
No, if there's an edit war, we'll hand out some blocks. Bad closes are decide the same way everything else is, by consensus. WP:MR serves the same function as WP:DRV, which is to say that if a deletion is a bad deletion, DRV exists to review it. If a move is a bad move, WP:MR can do the same. That is, if there is a bad close, an alternative to merely undoing it is to start a discussion at WP:MR. How is that onerous again? --Jayron32 05:02, 2 June 2013 (UTC)
It's not onerous; it's just a dysfunctional venue, where challenged closes sit unheeded for a month. I was hoping to avoid going there by getting an admin to do the close. Sometimes improper closes are worth an immediate revert to reduce ongoing trouble. In this case, with an non-admin closer reverting the revert, I abandoned that hope of a simple solution. Actually, WP:BRD suggests that after his bold close and my revert, some discussion would have been in order. Dicklyon (talk) 05:10, 2 June 2013 (UTC)
Jayron32,, I think you are saying that you think every bad RM close should be taken to WP:MR? That might be OK, but are you aware of standard practice that a bad XfD close is voidable by any admin, even without any uses of admin privileges? --SmokeyJoe (talk) 05:24, 2 June 2013 (UTC)
As I said, it is voidable by any non-admin either. Admins tend to do these things because they're frequent visitors to the venue, and experienced editors. Summary reversals of this type are not necessarily the purview of admins, and it's not written anywhere that I am aware that "Only admins may undo a bad closure of a discussion". I've certainly never seen that. If you're seeing that mostly admins are doing these reversals, that's just because admins are frequently closing stuff anyways at XFDs anyways, not because there's any rule that says only they can do it. If WP:MR is languising, then WP:BRD is the next best guidance. The first closure is bold, if someone disagrees they revert, and then everyone gets together to discuss. Multiple back-and-forth reverts get people blocked, and that is something only an admin can do. And will. --Jayron32 05:36, 2 June 2013 (UTC)
Sorry, my mistake. You support any editor being able to revert a bad RM close, per WP:BRD. I get that. I don't agree that WP:MR is languishing. --SmokeyJoe (talk) 05:49, 2 June 2013 (UTC)
Yeah, Dicklyon said that MR was a dead end, and I was responding to what he said. No, BRD rules all. I know it's labeled an "essay", but its a damn fine essay, and provides excellent guidance for how to handle when ANYTHING goes wrong. If you see something done in error, undo it, then the two people discuss it, bringing in extra discussion if need be. That guidance applies to any action at Wikipedia. --Jayron32 05:53, 2 June 2013 (UTC)
It's such a backwater that even my "Horseshit!" remark didn't get much attention there. Dicklyon (talk) 06:07, 2 June 2013 (UTC)
It was seen. A bit heavy handed a response to an opinion not based on extensive research. Binksternet may have been offended and may be less likely to venture into MR again. It's a backwater, yes. Languishing, no. Has teeth, yes. Has been seen to use teeth, no. However, like DRV, being dragged into review has corrective effect on dodgy closers. --SmokeyJoe (talk) 06:37, 2 June 2013 (UTC)

This is still going on? My thoughts: RfA does not vet users for their ability to close discussions. At most, RfA is an institution that grants rights to users bases on some ill-defined idea of "trust". Most non-admins do not close discussions because there is a fallacious institutional memory that only admins can close discussions. Admins are simply users with additional technical tools that they may or may not use correctly. With respect to closing discussions, admins and non-admins should be treated exactly equally. The first step should be to discuss on the user talk page. If that leads nowhere, then [wherever] review. Nowhere in the process should a close be reversible because of the administrator or non-administrator status of a user. If a non-admin close can be summarily overturned, it should be for the exact same reasons that an admin close can be summarily overturned; as an example, gross ignorance. This should apply to all discussions: AfD, RM, RfC, VP, ANI, wherever. -Nathan Johnson (talk) 15:26, 2 June 2013 (UTC)

I agree with this. --B2C 23:31, 2 June 2013 (UTC)
I don't entirely agree, but mostly do. RfA is supposed to try to vet users for their ability to close discussions. A history of bad NACs will see you fail. Definitely agree that non-admins should be encouraged to close RM discussions, if they feel confident, were not INVOLVED, etc. A tricky point is deciding between a rough consensus and a no consensus. In this, admins are traditionally allowed admin discretion. Maybe "closer's discretion" is just as acceptable. When someone feels a rough consensus versus no consensus went the wrong way, they can try again later, with a better posed argument, although I feel that a nominal time period (2 months) should be allowed to pass. --SmokeyJoe (talk) 00:25, 3 June 2013 (UTC)
RfA is supposed to vet uses who will be able to be trusted with the admin tools. It's been hijacked by people who like to play kingmaker and carry their personal battles from other parts of Wikipedia and torpedo their perceived enemies. That's how it works in practice, but ideally, it is designed to merely assure that admins will be promoted who won't misuse their tools. --Jayron32 03:59, 3 June 2013 (UTC)

Propose merging {{mrv}} with {{MRVdiscuss}}

Template:Mrv has been nominated for merging with Template:MRVdiscuss. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. Wbm1058 (talk) 15:23, 9 June 2013 (UTC)

See Template talk:RMassist for details. – Wbm1058 (talk) 13:05, 19 June 2013 (UTC)

Yogurt Rule - delete?

Please see Wikipedia:Miscellany for deletion/Wikipedia:Yogurt Rule for a discussion about whether to delete WP:Yogurt Rule, an essay that interprets WP:RMCI (among other policy/guideline pages). --B2C 21:04, 24 June 2013 (UTC)

Several articles

List of Big Brother 1 housemates (UK) through to List of Big Brother 14 housemates (UK) to be moved to List of Big Brother 1 housemates through to List of Big Brother 14 housemates, where do I go to suggest they all be renamed? It seems pointless to have a delineator there and it not be needed. Even if it is a case of keeping the redirects.--Launchballer 10:39, 30 June 2013 (UTC)

That is done with a multi-move. The discussion is in one place and the bot puts a notice on all the other talk pages. Apteva (talk) 14:27, 30 June 2013 (UTC)

Time Traveler (1980 video game)

Please move Time Traveller (video game) (wrong spelling with 2 LL's) to Time Traveler (1980 video game). Hippo99 (talk) 03:50, 3 July 2013 (UTC)

You need some sources to show the one L as both the links given in the article have two LL's. CambridgeBayWeather (talk) 05:32, 3 July 2013 (UTC)
The correct title is spelled with ONE L. (TraveLer) Hippo99 (talk) 05:43, 3 July 2013 (UTC)

References:

Done. CambridgeBayWeather (talk) 05:57, 3 July 2013 (UTC)
Thanks for the quick fix. Hippo99 (talk) 06:07, 3 July 2013 (UTC)

Cultural Center Historic District (Detroit, Michigan)

Can someone close talk:Cultural Center Historic District (Detroit, Michigan) ? This was an poorly merged move discussion, that left this section hanging, when the entire consolidated request was closed. This should have been closed at that time, but wasn't. -- 76.65.128.222 (talk) 05:30, 4 July 2013 (UTC)

 Done Yes, I probably should've done that sooner. I misread the situation. --BDD (talk) 06:03, 4 July 2013 (UTC)

WP:SUBPAGE problem

Please see Wikipedia talk:Article Incubator/Artpop, where related articles edit histories were all moved into subpages of Artpop Special:PrefixIndex/Artpop (2013 Lady Gaga album) , but per WP:SUBPAGE, no subpages should exist in articlespace... now there are three, instead of none. It fails subpage disallowed uses point 3, since these are meant to be permanent reservoirs of edit history. -- 76.65.128.222 (talk) 00:35, 5 July 2013 (UTC)

Does "no consensus to move" mean "consensus to not move"?

I suggest there are three following basic RESULTs from an RM discussion:

  1. Consensus is to move
  2. No clear consensus either way
  3. Consensus is to not move

It has been claimed [20] that "no consensus to move" is different from #2, suggesting it means #3. Does it?

In any case, I think the following RESULT phrases should be avoided in closes, because they are ambiguous as to whether the outcome is #2 or #3 in the above list:

  • "No move"
  • "No consensus to move"

Instead, I propose using any of the three above RESULT phrases (or anything equally unambiguous).

What about adding something to this effect in the closing instructions?

Thanks. --B2C 23:10, 10 June 2013 (UTC)

The result of an RM is either "move" or "don't move". If there is consensus to move, then do it; otherwise, not. Moving without consensus (whatever the basis, including a necessarily subjective analysis of the strengths of the various arguments) is a recipe for increased chaos and conflict. Omnedon (talk) 23:28, 10 June 2013 (UTC)
Agreed. I'm just saying if the result is to not move, to be clear about whether that's because there is no consensus, or because there is consensus to not move. --B2C 23:58, 10 June 2013 (UTC)
That's going to be subjective too. There are frequently disagreements in which some will claim there is consensus and others will claim there is none. The result, move or don't move, is objective. Omnedon (talk) 00:09, 11 June 2013 (UTC)
  • I agree with B2C, and do not approve of closing a discussion with a mere "moved" or "not moved". A discussion is only properly closed with a finding of consensus or no consensus. Without referring to the consensus, if any, it makes the discussion look like a vote. If the closer can't distil a consensus or declare no consensus, he should not be closing. --SmokeyJoe (talk) 09:26, 11 June 2013 (UTC)
I never said that a move should only be closed with the words "moved" or "not moved". I'm saying that the perception of consensus is subjective, and that each editor has his/her own interpretation of the word "consensus". I certainly would not agree that the phrase "no consensus to move" should be avoided, if that's what describes the situation. Omnedon (talk) 12:15, 11 June 2013 (UTC)
Omnedon, I hadn't meant to address your comment, but if I did I might point out that a RM is concluded by a closer reading the consensus, and summarising if needed, and that the "result" obtainable from the move log is not a sufficient closing statement. --SmokeyJoe (talk) 02:29, 26 June 2013 (UTC)
  • You're right, B2C. Moved means consensus to move. Not moved means consensus against the move. No consensus means just that, usually resulting in no move but possibly reverting per WP:BRD at the admin's discretion (IMO it's a bridge too far for a non-admin closer, but it may depend on the circumstances). That's how I close, anyway. I interpret No move as Not moved and No consensus to move as No consensus. --BDD (talk) 18:38, 24 June 2013 (UTC)
  • I, for one, wish you wouldn't use Not moved as short hand for "consensus to not move". Many unfamiliar participants in RM discussions, and aren't we agreed that more would be desirable, won't know to come here to read your key. A mere "not moved" can read as weak or ambiguous English passive voice and a euphemism for "no consensus" without detailed explanation. --SmokeyJoe (talk) 02:25, 26 June 2013 (UTC)
I didn't just make that up; those are terms that have been used by plenty of other editors. In practice, there's rarely a difference between a no consensus and not moved result anyway. --BDD (talk) 05:38, 26 June 2013 (UTC)
  • No consensus always defaults to the status quo. It is not en endorsement of one option or another, but a recognition that there is no consensus to change what already exists. --Jayron32 03:32, 26 June 2013 (UTC)
  • User:Jayron32 - where do you get this policy from? My understanding is that no consensus means that the long standing or original version should take precedence. The status quo may have arisen due to any combination of bolds, reverts, edit wars, protections etc. and should not normally be assumed to have any higher right than another version. Thanks  — Amakuru (talk) 11:51, 8 July 2013 (UTC)
While I broadly agree with Jayron, I hope he understands that blind adherence to that principle would be an open invitation for gaming the system, allowing a user to make a contentious move and have it win out over a stable title just because consensus couldn't be reached in a subsequent RM. No consensus should almost always mean no move, but a closer should exercise judgment in such circumstances. --BDD (talk) 16:28, 8 July 2013 (UTC)
I tend to agree with Jayron32, with the following sort of workaround sometime times needed, as per yogurt. In a fresh discussion, acknowledge the established no consensus on the merits of each side, stop discussing the merits of each side, and explicitly consider a meta-principle such as WP:RETAIN. Consensus depends on the question being asked. --SmokeyJoe (talk) 22:05, 8 July 2013 (UTC)
I also tend to agree with Jayron, as long as WP:CONSENSUS is properly determined through an analysis of the arguments made, including a policy-based weighing of the arguments, rather than by counting !votes.

What seems to happen all too often is that this analysis is not made if there is no obvious majority of !votes in favor or opposed to the proposal. Just because the !vote results are approximately 50/50 does not mean there is no consensus. Only an analysis of the arguments - which should be explained in the closing statements - can determine whether there is consensus. If one side is dominated by policy-based arguments, while the other side is dominated with JDLI arguments like "no good reason to move" (without explaining why the stated reasons are not good), then consensus should be found in favor of the former side. --B2C 22:20, 8 July 2013 (UTC)

This is a pretty deep problem with Wikipedia procedure. If a closer is lucky, discussion is one-sided. In the example you mention, sure, it's easy to come down on the side that's making policy-based arguments. But in the great majority of discussions I've seen, both sides are making policy-based arguments! (Say, for example, COMMONNAME vs. MOS:TM. Hypothetically.) So there ends up being a really, really fine line between judicious weighing of votes and supervotes. A cynic might say it's entirely in the eye of the beholder. I'm not agitating for Athenian democracy or anything, but in practice, many discussions are a vote. If we could just be honest about that, I think it could go a long way to cooling some heated discussions. Is it just me, is MRV much more active than it used to be? --BDD (talk) 00:05, 9 July 2013 (UTC)
Per BDD, the only people who ever argue that "It's not a vote" are people for whom the close did not result in the ends they wanted themselves. You are correct, it isn't a vote, and you are correct that arguments matter, but there is also an important reminder that arguments for the opposite position are not automatically invalid. People too often discount the rationales for arguments because the consider the rationales soundness to be based solely on the conclusions. That is, people a priori invalidate (in there minds) any rationale which is proposed by someone who votes the opposite as they did. While it is true that there are sometimes discussions where there are a bulk of bad rationales on one side, and only good ones on the other, in my experience the existence of individual examples of those kinds discussions like that is not statistically significant over all Wikipedia discussions. Almost always, a 50/50 discussion is going to be validly closed as "no consensus". The fact that one can find individual examples of some that shouldn't doesn't mean that nearly all of them shouldn't also. --Jayron32 02:39, 9 July 2013 (UTC)
There are certainly genuine no consensus discussions! I'm sure they comprise the majority of those closed as no consensus. And of course everyone is subject to bias and sometimes doesn't see the validity of the other side. But often there really is nothing, or almost nothing, on the other side.

I'm sorry to bring up Yogurt again, but it really is the quintessential example. Over 9 years 7 different RM discussions were closed as "no consensus" even though since the first one the same arguments that ultimately prevailed and resolved the situation were present, heavily favoring Yogurt over Yoghurt in terms of policy. Yet 7 different closers, trying to be fair, I'm sure, went with 50/50 !vote counts. I don't doubt they genuinely believed neither side was stronger, but their analysis was flawed, seven times in a row!!!.

Look at the very first discussion[21], from 2005. From the outset they argued "the original location of this page was at Yogurt" and "[Yoghurt spelling] is internationally uncommon". More notably, not a single Oppose argument says anything substantive in support of Yoghurt over Yogurt. Nothing. Each and every RM discussion subsequent to that was essentially no different. Proper analysis of each should have resulted in the same result: consensus favors moving. --B2C 04:21, 9 July 2013 (UTC)

Again, as I noted, the existence of individual examples does not in anyway invalidate the idea that the bulk of such discussions closed as no consensus properly deserve to be closed as such. Since tough cases make bad policy, there's nothing to be gained in using the oddball case as a means to indicate that any change to policy or practice is needed. People behaving silly cannot be ameliorated by any policy changes, unless the silliness is widespread. No evidence has been presented as such. The yogurt case is useful for nothing more than a good shrug of the shoulders and a dismissive shake of the head, not as an indicator that any substantial changes need to be made to the way move discussions are handled. --Jayron32 04:44, 9 July 2013 (UTC)
I'm not suggesting there is anything wrong with the bulk of discussions closed as no consensus. But I do believe that Yogurt exemplifies a significant number (10%? 5%? 20%? 2%? I don't know) of such closes. Remember, it's not like Yogurt was closed one or twice as "no consensus"... that happened 7 times in a row. Dismissing it with a "good shrug of the shoulders" is blaming the participants in those discussions, without holding the closers responsible for their lack of analysis in each of those 7 closes. And even in the final/8th RM, when it was finally determined that there was consensus favoring the move, it was largely because a majority of those participating favored the move ("As there is strong consensus for the move in the discussion, ..."[22]). So it's not clear that even the final RM was a result of a proper analysis of the arguments. If that time a sufficient number of opposers posted the JDLI !votes to prevent a majority in support, I'm quite confident the result would have been once again "no consensus", even though, as in all of the other RMs, the strong policy-based arguments favoring the move were there, and those opposing the move were absent.

Decisions that find "no consensus" due to a !vote count despite consensus support per argument analysis are a minority, I'm sure (if nothing else because often when the participants are 50/50 so are the arguments), but still all too common. The most recent notable one I can think of is the reverse of Hillary Clinton at the move review[23], which demonstrated virtually no evidence of argument analysis (in stark and ironic contrast to the outstanding well reasoned RM close decision that it reviewed and reversed), and seemed almost entirely based on !vote counting. --B2C 05:34, 9 July 2013 (UTC)

Your steadfast support for the supervote close at HRC RM5, and disdain for the review is clear evidence that your views are at odds with the community, which for all useful purposes means that you are "wrong". HRC is not like yogurt. For HRC, the better quality sources, on academic and high reputation of publishing measures, sees a predominating usage of "Hillary Rodham Clinton" in titling and initial introductions. --SmokeyJoe (talk) 06:41, 9 July 2013 (UTC)
B2C, a closer has to be very careful performing "an analysis of the arguments made". Analysis of others' arguments is am important job for the discussion. If a closer performs an argument analysis that is outside the content of the discussion, it is a supervote, a contribution that is better made as an ordinary participant. If he is right, his !voting makes the close so much more convincing by a later closer. The applicability of various policies, their ambiguities, their poor writing (see WP:COMMONNAME today), their susceptibility to self-selected biased policy editors, are all things best discussed explicitly and not ruled by a self-selecting closer. Consensus is a process, and when it is achieved, "analysis" is not required to see it. --SmokeyJoe (talk) 02:27, 9 July 2013 (UTC)
Yes, analysis must be done very carefully, and should not stray outside the content of the discussion (except sometimes the application of applicable non-controversial policy/guideline which is assumed to be the expression of community consensus).

I agree consensus is a process, but it is not limited to the actual relatively tiny minority of the community involved in any one discussion. The agreement of all five people in a given discussion who have no idea what the relevant policy/guideline/conventions are do not a true consensus make. This is why "The closer is there to judge the consensus of the community, after discarding irrelevant arguments: those that flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, those that show no understanding of the matter of issue." [24] --B2C 04:21, 9 July 2013 (UTC)

It is the participants who should highlight weak arguments. Often, weak arguments turn out to be strong arguments poorly stated, when challenged and supported. Participants should be encouraged to assess and critique others arguments, not the closer. --SmokeyJoe (talk) 06:41, 9 July 2013 (UTC)
With the caveat that irrelevant does NOT mean "that which I disagree with". --Jayron32 04:46, 9 July 2013 (UTC)
Of course. WP:JDLI is a pretty apt description of what qualifies as irrelevant arguments. --B2C 05:08, 9 July 2013 (UTC)
WP:JDLI seems to be frequently used to deride opposing positions, pretending they have no substance. --SmokeyJoe (talk) 06:41, 9 July 2013 (UTC)
B2C, you seem to be saying that the first seven yogurt RMs were closed incorrectly, which I think is a dubious claim. Your analysis of the arguments showed one thing; others' analyses were different. I am not saying it is easy to respect arguments with which one disagrees -- but it's certainly problematic to just dismiss anything that disagrees with one's own position. Yes, some positions are truly JDLI -- when someone clearly states "I don't like it" and offers no substantiation. But when reasons and arguments are given, they will come in various forms from various editors. Everyone thinks and expresses differently than everyone else. That doesn't mean their arguments can simply be brushed aside. Omnedon (talk) 13:57, 9 July 2013 (UTC)

SmokeyJoe, can you provide any examples of arguments that were based well in policy/guidelines that were characterized as JDLI in order to deride them? You claim it happens frequently, so examples should be easy to find. I ask because I can't recall ever seeing that.

Anyway, even if it does happen, that's besides the point, as characterizing solid arguments as JDLI is not what I was talking about. I'm saying that if one reads WP:JDLI, he should get a pretty good idea of the difference between relevant and irrelevant arguments. --B2C 17:19, 9 July 2013 (UTC)

I refer to your own use of JDLI assertions referring to other's arguments. While JDLI arguments should be avoided, so should the labelling of opponents arguments as JDLI. JDLI is far to easily ascribed to an argument that you personally don't value. It is far better to try work out why someone doesn't like some something. Often, there is a good reason requiring further discussion, not administrative rejection. JDLI should be avoided by all on both sides. If someone did not use those exact words, you should not assert that their words amount to JDLI. Closers should be very hesitant to label arguments as JDLI, unless obvious and the point is to point newcomers to the essay for their educational benefit. --SmokeyJoe (talk) 04:17, 10 July 2013 (UTC)
Yes, Omnedon, I'm saying the first seven yogurt RMs were closed incorrectly. The arguments were the same from the first RM. Nothing relevant changed to any significant degree. There was no substantive difference between the arguments presented in the first 7 RMs than in the 8th RM. The opposition never had a single policy-based point except "maintain the status quo" - it was WP:Status quo stonewalling, pure and simple. The analysis of the same arguments in each of the 8 RMs should have produced the same result: consensus is to move.

The problem is that there was no analysis. Instead, whether they realized it or not, each of the closers simply looked at the approximate 50/50 distribution of the !votes and concluded there was no consensus. If there was any argument analysis going on, they certainly did not leave any evidence of that in their closing comments. --B2C 17:19, 9 July 2013 (UTC) I'm not done analyzing all 8 of the RMs yets, but I can already see I want to refine some of my statements above, which I will strikeout here, and add an update below when I'm finished (did 1-5 so far). --B2C 19:54, 12 July 2013 (UTC)

Well, B2C, you are entitled to your opinion on that. I certainly have not analyzed the "yogurt" history and so will not try to get into the details of it. It just seems unlikely that 7 closers in a row would come to the same conclusion and all be utterly wrong. There are various ways of viewing this issue of "no consensus", as evidenced by the long discussions on the issue in various places. You have a very strongly-held view, but it's not the only one. Omnedon (talk) 17:28, 9 July 2013 (UTC)
In theory, it's certainly possible for consensus to develop and move one way or another from "no consensus" over a series of discussions like that. So I don't mean to imply that that alone proves those closes were wrong.

Why does it seem unlikely that 7 closers in a row would come to the same conclusion and all be wrong? In each of those discussions, there was no majority supporting or opposing the proposal. How often do you see a closer determine consensus favors a move when a majority of those participating in the discussion don't support the move? Talk about unlikely! But that's the problem. Of course it's perfectly appropriate in the 90% (?) of cases in which there is no majority support or opposition, and no consensus in terms of weighing the arguments, to determine there is no consensus. But the problem is in the 10% (or whatever) in which although there is no majority support or opposition, there is consensus in terms of argument analysis. That 10% (?) is a problem because closers are inclined to close those as "no consensus" as well.

My contention is that all 7 of the first 7 Yogurt RMs fall into that category. I mean, you don't have to go through the whole history. Just look through the first RM[25]. What does your analysis of the arguments there tell you? Keep in mind what closers are supposed to do: "The closer is there to judge the consensus of the community, after discarding irrelevant arguments: those that flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, those that show no understanding of the matter of issue." [26] --B2C 23:41, 9 July 2013 (UTC)

B2C, I find it interesting that you would put forward the first yogurt RM as an example of "JDLI on one side and policy-based arguments on the other". There were reasons given on both sides, fairly briefly in all cases (as was requested: "an optional one-sentence explanation"). Some both sides had no explanation at all; some on both sides had cogent explanations. It seems a clear case of "no consensus", and the result was valid. This only underscores my assertion that there are various ways of viewing "no consensus". Omnedon (talk) 12:29, 10 July 2013 (UTC)
It can look that way at first glance, but if you take a close look it's quite different. To that end, I added a detailed analysis of RM #1 to the yogurtspellinghistory page. In summary,
  • 12 of the 30 !votes were of the JDLI variety
  • 4 were nonsensical (I explain why for each)
  • 12 supported the move to Yogurt with a citation of primary author/original use argument, and/or the COMMON NAME argument
  • only one person opposing, jguk, even hinted about relying on policy (but ignored the original author/original use argument presented in the proposal). Well, you can argue Derek Ross did too, in that he noted that "Yoghurt" was popular on Google/Yahoo (arguably trying to rely on COMMONNAME), but Tony Jin countered by noting that "Yogurt" was even more popular there, and this was not challenged.
Even if you generously count both of these !votes that favor the h as strong policy-based reasons, they are overwhelmed by the 12 !votes backed by policy-based reasons in support of Yogurt.

By the way, I also have found similar results in the analysis of RMs #2[27] and #3[28].

I would appreciate it if you looked these over. If you think I'm overlooking something significant, please let me know (or revise the analyses accordingly). Thanks! --B2C 20:18, 11 July 2013 (UTC)

Yesterday I reviewed #4[29], which I think obviously should have been closed with consensus in favor of "Yogurt". Not only was that the majority result of the !votes for the first time, but the argument analysis was, again, overwhelmingly in favor of "yogurt".

I also just finished my analysis of RM #5[30]. In my view that was the first one properly closed as "no consensus", entirely because of a then-new (2009) Arbcom ruling (regional variant ceasefire) that finally gave the Opposers some basis in policy. But there were also valid questions about that decision's applicability in this particular case, not to mention other considerations. Still, this is the first time where I can say the closer's "no consensus" decision was obviously reasonable, and closing it any other way would have been highly questionable. --B2C 19:51, 12 July 2013 (UTC)

B2C, you automatically assume that all I did was glance at it. I did not. I simply disagree with your analysis. The responses were very short, as was typical of the process at that time, and your claims of "policy-based" reasons are questionable. As I've said before, not everyone will come up with the same analysis, and this definitely seems to have been a clear "no-consensus" situation. Omnedon (talk) 12:19, 15 July 2013 (UTC)
I assumed nothing about what you did, as I have no idea, as you gave no indication. You make declarations without explanation, like "this definitely seems to have been a clear 'no-consensus' situation". I understand that is your opinion. But while I provide a detailed explanation for why my opinion is what it is, you provide absolutely nothing to explain why your opinion is what it is, except to note that the responses were short and that was typical at the time, suggesting you assigned equal (or near equal) weight to the following actual responses in determining consensus.
  • Oppose. Proteus (Talk) 12:10, 12 May 2005 (UTC)
  • Support: primary author (as per PBS) and more common name rubric (per MoS) seem to point in the same direction in this case. This article was Jonathunder 02:22, 2005 May 12 (UTC)
Is that not basically ignoring reasons and simply counting !votes? --B2C 15:51, 15 July 2013 (UTC)

B2C, you continue to make wrong assumptions. I said I had looked at it, and found no consensus. I don't tend to go into the hugely detailed explanations and defenses that you do. But since you gave examples, here are two counter-examples:

  • Oppose. Article is in British English and should use the most common spelling in Britain. It's also the original spelling (as the article notes at the bottom), jguk 22:00, 12 May 2005 (UTC)
  • Support. violet/riga (t) 20:59, 13 May 2005 (UTC)

You really need to accept that others are going to have different views than you. You tend to dismiss others' views unless they satisfy your demands for extensive support. I repeat: I have looked this over in some detail, examined the reasons, and see a clear no-consensus situation. Omnedon (talk) 16:53, 15 July 2013 (UTC)

I know and accept that others have differing views. But what I want to understand is why, and, in particular, how sound the reasons are.

If you think your counter-example is a counter to my point, you're missing my point, entirely. In my analysis, I did not give the violet/riga Support !vote any weight for the same reason I did not give the Proteus !Oppose vote any weight: these are pure JDLI expressions of preference without basis in anything, much less policy. That JDLI category was comprised of 12 of the 30 !votes (9 oppose and 3 support).

As to the jguk reasoning, I accounted for it as follows in my analysis:

The only other substantive policy based argument was offered by jguk:
* Oppose. Article is in British English and should use the most common spelling in Britain. It's also the original spelling (as the article notes at the bottom), jguk 22:00, 12 May 2005 (UTC)
But this ignored the original author/original use argument, though nobody explicitly pointed this out.
Even if you give the jguk Oppose !vote considerable weight, the support side is still overwhelming after the 12 blatant JDLIs like violet/riga and Proteus, and the four nonsense !votes, are discounted.

That's why I continue to wonder how you or anyone else could actually find "no consensus", if not by giving all !votes equal weight, including the ones that say nothing except express their preference, and the ones that are nonsensical. That is, are you discarding irrelevant arguments per Wikipedia:Closing_discussions#Consensus, or not? --B2C 21:55, 15 July 2013 (UTC)

Yes, you wonder how anyone else could ever come up with a decision that disagrees with yours on this. That is the basic problem here -- not the meaning of "consensus", but the fact that you refuse to accept alternatives to your own view. You keep claiming "policy-based arguments/reasons" in RM#1, but I see few direct references to policy on either side. Nevertheless, there were some respondents on both sides did provide cogent reasons. A few gave the reason that the argument to move was very weak; that's perfectly valid, since the default position in a move request is to leave it where it is unless consensus is reached to perform the move. Several others opposed the move based on common use. Since no consensus was reached, the article was not moved. You really must learn to accept that other perspectives exist and may be valid -- not just yours. This is the ongoing problem with almost any discussion in which you are involved. Omnedon (talk) 01:46, 16 July 2013 (UTC)
I understand that you disagree that, based on evaluating the arguments in RM #1, there is clear consensus to move. What I still don't understand is how you are evaluating the arguments to come to that conclusion. You give reasons, but they don't seem to hold up to the lightest of scrutiny.
  • "I see few direct references to policy on either side"
    • Me too, but I presume we agree (correct me if I'm wrong) that an indirect reference, like "the primary author used Yogurt" is just as valid as a direct reference, as in:
      My reference to the MoS was based on Wikipedia:Manual of Style#National varieties of English, where one bulleted point states, "If an article is predominantly written in one type of English, aim to conform to that type rather than provoking conflict by changing to another." Further support is the final bulleted point, which suggests "following the spelling style preferred by the first major contributor".
    In my documented analysis I listed 11 instances of references to policy in support ("primary author/original use argument, and/or the COMMON NAME argument") that were indirect if not direct. The ONLY reference to policy, direct or indirect, made by the oppose side was by jguk, unless you also count Derek Ross's statement about popularity on Google/Yahoo, in which case you also have to give Tony Jin's reference equal or more weight. So that's either 11:1 or 12:2. Does your analysis differ in this regard?
  • "there were some respondents on both sides did provide cogent reasons."
    • Yes, 11 (or 12) in support, and 1 (or 2) in opposition, provided cogent reasons. I listed them. If your count is much different, please identify those you believe to be cogent on both sides, and, if your list is substantially different from mine, what is not cogent about those on my list but not on yours, and vice versa?
  • "A few gave the reason that the argument to move was very weak; that's perfectly valid, since the default position in a move request is to leave it where it is unless consensus is reached to perform the move."
    • Really? Don't you think that simply stating the fact that the default position in a no consensus discussion is to not move is not itself a valid argument to be weighed in deciding what consensus, if any, there is in that discussion? I mean, that fact determines the consequence of what to do in the case of "no consensus"; it is not relevant to determining IF there is consensus. Right?

      Also, how does simply declaring one's opinion that an opposing argument "seems very weak", without explaining why it is believed to be weak, not pure JDLI? In fact, WP:JDLI#Because I say so describes precisely such "statements of opinion that the editor expects to be accepted as fact" as being JDLI.

      (By the way, I realize I am often accused of expecting my opionions to be accepted as fact, but that's not true. To the contrary, I explain the reasons and reasoning for making my statements to the extent that I'm also often accused of being tendentious, but I abhor my own unexplained statements of opinion as much as anyone else's, so that's why I tend to err on the verbose side. Further, I am always willing to explain any statement I have made per request when I did not initially provide it, probably because I assumed it was not required. I do not expect my opinions to be taken as fact; I expect them to be evaluated and assessed.)

  • Several others opposed the move based on common use.
    • Back to Derek Ross and jguk. Again, the only 2 arguably policy-substantive !votes in opposition.
  • Since no consensus was reached, the article was not moved.
    • Whether consensus was reached is what we're discussing here. The closer declared "no consensus" based entirely on counting !votes: "There are 14 "Support" votes (plus 1 for the proposer) which is equal with 15 "Oppose" votes. No one side has at any stage been more than two votes ahead. It's a tie - ...".

      That's determining consensus by counting !votes, not by evaluating the arguments.

Determining consensus in RM #1 by evaluating the arguments clearly shows strong support for moving. --B2C 18:54, 17 July 2013 (UTC)
You sound like a broken record. I've heard all of this from you before. Even by evaluating the reasons given on each side, there was clearly no consensus, and so the article was not moved. As has been asked of you many, many, many times in the past (by many, many editors) -- please acknowledge that not everyone will come to the same conclusion, and please stop stating (essentially) that anyone who disagrees with you is wrong. Omnedon (talk) 19:11, 17 July 2013 (UTC)
I'm not stating or thinking anything like that. Only you are operating at the personal "YOU/I are/am RIGHT/WRONG" plane.

Of course I acknowledge others may reach different conclusions, but what conclusion any given PERSON (you, me or anyone else) reaches is irrelevant; what matters, and where the focus of any discussion like this should be, is how well a given conclusion is or is not supported by the various arguments being presented. As long as the focus remains on who believes or concludes what, it's very difficult to make progress.

Now, to that end, with respect to the argument you presented above and how well it supports the "no consensus" conclusion, you've heard my explanation of how the reasons you just gave above for the first time don't support that conclusion, before? Or is this an excuse to avoid further discussion on whether the "no consensus" conclusion is well supported by those reasons? --B2C 20:30, 17 July 2013 (UTC)

Really? What about your statement above -- "That's why I continue to wonder how you or anyone else could actually find "no consensus"..." That is absolutely dismissing any view other than your own. Please stop doing that. You have pledged to do so before, been warned to do so many times, yet you will not stop. Omnedon (talk) 01:35, 18 July 2013 (UTC)

Going back to the original question here. As I see it, there are actually more than three Determinations possible in any RM discussion:

  1. Consensus strongly supports move
  2. Consensus weakly supports move
  3. No consensus can be determined.
  4. Consensus weakly supports not move
  5. Consensus strongly supports not move

Hell, you could probably come up with modifiers that range between all these.
However, no matter how many variations you come up with, there are only two outcomes that stem from those determinations:

  1. The page is moved
  2. The page is not moved.

The simple fact is, some people will not be happy with either outcome, no matter how it was determined. When the consensus is strong, the "losers" usually accept the outcome with some degree of grace. When the consensus is weak, they usually do so grudgingly. And when there is no consensus it is very difficult to accept. Everyone on both sides is sure that their arguments were better than those of the other side. Closers need to remember that when writing up their rational. It is helpful to acknowledge which arguments on both sides influenced your decision... so that those on both sides will at least understand that their arguments were understood and paid attention to. Blueboar (talk) 22:55, 17 July 2013 (UTC)

It's complicated even more by the fact that although we say consensus is determined by argument evaluation, closers often are reluctant to against the majority or find in favor when the !votes appear to be about evenly split, no matter how much stronger the arguments may be on one side.

So if you look at

!vote count result, consensus per argument analysis, likely outcome
The possibilities are:
STRONG SUPPORT, STRONG SUPPORT, MOVE
STRONG SUPPORT, WEAK SUPPORT, MOVE
STRONG SUPPORT, NO CONSENSUS, ???
STRONG SUPPORT, WEAK OPPOSE,???
STRONG SUPPORT, STRONG OPPOSE, ???
WEAK SUPPORT, STRONG SUPPORT, MOVE
WEAK SUPPORT, WEAK SUPPORT, MOVE
WEAK SUPPORT, NO CONSENSUS, ???
WEAK SUPPORT, WEAK OPPOSE, ???
WEAK SUPPORT, STRONG OPPOSE, ???
NO CONSENSUS, STRONG SUPPORT, ???
NO CONSENSUS, WEAK SUPPORT, ???
NO CONSENSUS, NO CONSENSUS, NO MOVE
NO CONSENSUS, WEAK OPPOSE,???
NO CONSENSUS, STRONG OPPOSE, NO MOVE
WEAK OPPOSE, STRONG SUPPORT, ???
WEAK OPPOSE, WEAK SUPPORT, ???
WEAK OPPOSE, NO CONSENSUS, ???
WEAK OPPOSE, WEAK OPPOSE, NO MOVE
WEAK OPPOSE, STRONG OPPOSE, NO MOVE
STRONG OPPOSE, STRONG SUPPORT, ???
STRONG OPPOSE, WEAK SUPPORT, ???
STRONG OPPOSE, NO CONSENSUS, NO MOVE
STRONG OPPOSE, NO CONSENSUS, NO MOVE
STRONG OPPOSE, WEAK OPPOSE, NO MOVE
STRONG OPPOSE, WEAK OPPOSE, NO MOVE
STRONG OPPOSE, STRONG OPPOSE, NO MOVE
Personally, I advocate ignoring the first column. That would get rid of the question marks. --B2C 23:24, 17 July 2013 (UTC)
Consensus is *NOT* determined by argument evaluation. If analysis is required, it is not consensus. A consensus is obvious without analysis. While consensus doesn’t mean that everyone agrees with the result, it does mean that everybody agrees that it is the consensus.
Consensus is a process, and achieving consensus in difficult situations requires as much refinment of the question as of negotiation and analysis of positions. B2C’s approach, that a consensus can be determined by analysis, and according to defined rules is not consensus, nor WP:Consensus. It is even outside of reasonable interpretations of Rough consensus and WP:Rough consensus.
The other thing B2C doesn’t seem to appreciate is that an important part of these discussions is mutual learning and education. If multiple people don’t get your argument, it is not OK to dismiss them.
Arguments presented here, that even in a “no consensus” there is a consensus to do something, must be rejected. --SmokeyJoe (talk) 23:49, 17 July 2013 (UTC)
On your first point, you seem to be using the dictionary definition of consensus (consent of all participants) rather than the WP:CONSENSUS meaning used on Wikipedia. On WP, consensus is determined by evaluating the arguments. Remember, the closer of a discussion is not determining the consensus of the discussion participants, but the consensus of the WP community based on the arguments presented in that discussion. Per Wikipedia:Closing_discussions#Consensus:

The closer is there to judge the consensus of the community, after discarding irrelevant arguments: those that flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, those that show no understanding of the matter of issue.

In order to discard irrelevant arguments, argument evaluation is absolutely necessary, so determining consensus is done by evaluating arguments. There is no requirement that everyone must agree the consensus determined by the closer is the consensus. You totally made that up.

I have no idea what you're talking about when you start referring to "according to defined rules". I've never argued that, and certainly haven't here. You seem to make up stuff in your head about what I'm saying, and reply to that. Very difficult to have a coherent discussion under those terms... Please address what I'm saying with my actual written words in this and all of our discussions. Thank you. --B2C 21:22, 18 July 2013 (UTC)

"evaluation" is a grand word to describe "discarding irrelevant arguments", etc.
"Analysis" is definitely going beyond the role of a closer.
While it is true that an obstinate participant does not have the right to veto the rest, the rules of rejecting participants are not codified. They are probably not codifiable without creating more problems than addressed. Apart from rejecting some participants, the others must be capable of agreeing with with the consensus of the group, because the consensus is obvious and plain to see.
Agreeing that the group consensus differs from your opinion is difficult.
"According to defined rules" seems to be your approach of assume that perfection is found in the words of policy. You seem to overrate the significant of the current version of written policy. You seem to think that the answer to everything lies in policy, and are not concerned that the policy writters are biased and did not consider the current examples being discussed. --SmokeyJoe (talk) 13:48, 19 July 2013 (UTC)
On further thought, and reviewing usages, I think: "Evaluation" is appropriate/expected of a closer; "Analysis" is going too far. The closer evaluate the arguments, for relevance to the question; consistency with policy; personal bias; logical contradiction etc. The closer evaluates the discussion as a whole. "Evaluation" sounds about right.
"Analysis", however, sounds like the closer may be putting considerable personal input into the process, and thus is too going far. The meaning of the word varies with usage, but in formal usage it tends to mean much more than an evaluation of what is actually present. It suggests deconstruction of what was actually written, a study of underlying motivations, and heavy reference to material outside the discussion. --SmokeyJoe (talk) 12:57, 20 July 2013 (UTC)

In reply to the (rhetorical I think) question asked, no. They mean different things.

In reply to the underlying question, What should we do when there is no consensus?, see discussion below under When can a new RM be initiated after a controversial RM is closed?. Andrewa (talk) 20:37, 22 July 2013 (UTC)

Straw poll: Moves involving dab pages

I found my last straw poll helpful for gauging how you expect RM administrators to behave, so I'm posing another question. Well, more like a scenario. A fairly common type of move involves an established WP:PRIMARYTOPIC that is judged to not be a good primary topic. I just moved Shade to Shade (shadow) (and Shade (disambiguation) to Shade), for example. Generally when I've done this in the past, I've gone through the incoming links to what has become the dab to fix them. But that can be really time consuming, and in the case of the Shade move, I let an uncontroversial RM sit around for a while because I wasn't ready to follow through on the incoming links. It occurred to me recently, especially considering the backlog, I should just tag those new dabs with {{dablinks}} {{incoming links}} and move on. So it this an efficient way of not trying to do everything myself, or is this a cop-out, a shortcut to avoid an appropriate workload? Should I fix the links or tag the page? Thanks for your input. --BDD (talk) 21:53, 20 June 2013 (UTC)

If you don't fix them, they will fall to the dab project where there are more bodies to follow up. Since the cleanup does generally not require an admin this seems like a reasonable compromise. When I was doing closes there more regularly, I would just default closes with a lot of cleanup to the DAB team. While some would argue that is not nice, sometimes the allocation of resources needs to be considered. Vegaswikian (talk) 23:00, 20 June 2013 (UTC)
Gotta comment on that, because lately I'm getting dabbot notices like crazy because "someone" went and moved a whole bunch of articles from primary-topic titles to unnecessary disambigs....all without discussion, and all without fixing links on pages linked to the previous primary-topic title (and who would fight tooth and nail on an RM that tried to reverse his changes, but doesn't lift a finger even to amend ledes and doesn't care what the consequences to category and template names are); so many I won't bother listing them, but it does make me wonder given what you've said how many of those unresolved redirects can be determined to be the result of given, specific editors doing such things.....making work for others by chair-shuffling seems to be way too common a practice......Skookum1 (talk) 05:09, 12 July 2013 (UTC)
Might as well be specific - Mi'kmaq and Coast Salish (among many others) were originally primary topics about those peoples; they are now disambig pages for non-primary usages because of the undiscussed blanket imposition of "FOO people" on ethno-group articles, and the contention that the names of the languages are as primary as the people whose language they are. Which is just not the case. Unless your only interest is linguistics, I suppose....if someone's so hot-to-trot to impose such sweeping unilateral changes but doesn't give as s**t about effects on the articles that link to them, it means other people (and DabSolver) have to pick up the slack....and it's getting tiresome to find these things all the time, and no sign at all from the perpetrator(s) about making any effort to clean up after themselves.Skookum1 (talk) 07:10, 12 July 2013 (UTC)
On behalf of the disambig project, please do not leave links unfixed with the idea that someone else will come along and clean up your mess. We have around 285,000 disambig links needing to be fixed right now, from over 63,000 disambiguation pages, and that number is now steadily going up. Furthermore, the people who argue for page moves should have a better idea of what's going on with those links than disambiguators who have not been party to that discussion. bd2412 T 21:54, 11 July 2013 (UTC)
@Skookum1: and @BD2412: – I hear you loud and clear, and really sympathize. Some of these zealots may need to be reigned in... the ones that haven't retired yet. Wbm1058 (talk) 16:29, 19 July 2013 (UTC)
  • This is a tough one that I have some experience with over at talk:Brand New. I opposed the move of the band off of primary topic, largely over concerns about fixing the links being, as you say, really time consuming. Admittedly, I know of no policy or guideline that takes into account allocation of scarce gnome-editor resources in deciding RM's so I don't expect that my argument was given much consideration. I was hoping that at least one of the zealots squealing about the band having "hijacked" the primary topic would help me fix the links, but other than some token effort by one, I didn't really get any help. However unlike wp:WikiProject Merge, which is at best treading water to keep from getting drowned by a years-long backlog, Wikipedia:Disambiguation pages with links is well-staffed and seems to do a reasonable job with keeping the problem in check. I couldn't really request a move review on Brand New as there was a numerical majority supporting the move, and determining whether the bar of "consensus", which I believe requires more than a simple majority, was crossed is a subjective call. Though in my opinion this was really close to the bar, the closing admin didn't violate the spirit of the instructions. I griped about this issue on their talk page, and that is the one single edit of my 13,000+ edits that I most regret. Just need to say how stressed I've been over Jenks24's near three-month absence from Wikipedia, and publicly hope, pray and beg for their return soon. OK, I've got that off my chest. I'm keeping my emotions over this issue bottled. BTW, Shade/Shade (shadow) are interesting because they don't involve some pop-culture phenomenon taking PT away from something of longer-term significance, which is where I think we more often run into this issue. Wbm1058 (talk) 13:54, 27 June 2013 (UTC)
  • I would recommend tagging, on the talk page, some sort of {{Move cleanup needed}} tag. Apteva (talk) 21:24, 28 June 2013 (UTC)

Bot error or my error?

I edited the entry at Talk:Ibiza Town#Requested move last night to relist it, by putting "relist" and my signature before the proposer's signature. However, the bot doesn't appear to have picked this up and it is still located near the bottom of the list on WP:RM. Thanks!  — Amakuru (talk) 18:04, 17 July 2013 (UTC)

The bot looks for the string "Relisted". Your edit used "Relisting". – Wbm1058 (talk) 15:38, 19 July 2013 (UTC)
OHO! I've fallen into that trap too! Now all is explained. Andrewa (talk) 00:33, 23 July 2013 (UTC)

reversions of undiscussed speedies needed - NOT more RMs

Well, seems like old habits die hard. Despite all efforts to prevent reversion to the correct, most common modern names by someone who insisted his out of date linguistics references were "most common" (in his field, maybe), the Ktunaxa, St'at'imc, Nlaka'pamux, Secwepemc and Tsilhqot'in articles got moved back to where they belonged, despite furious and often nasty resistance from the editor who had moved them without discussion or citation. And some haven't been reverted though should be = Dakelh was started by the most prominent scholar in that field, but was moved to Carrier people by the same editor, also long ago. I don't want to have to RM all these, I shouldn't have to, they were moved undiscussed and without good cause, by someone who doesn't care what the people choose to call themselves or what accepted modern standards and norms are. The one that's stuck in my craw today is the just-moved Oowekeeno people, which had been at Wuikinuxv people and originally at Wuikinuxv, with the "most common" claim easily put the LIE to by the UBC Museum of Anthropology book just added as citation, vs the 1978 old-skool linguistics texts which apparently is where "most common" came from...though no citation was provided for that really, that reference was already there....I'm not an admin so can't revert these, there's redirects in the way, but ahem isn't it about time "someone" was scolded/disciplined for continuing things like this....or is it just spite and drama for not getting his way in the RMs that also shouldn't have even had to be, as they all resulted from his unilateral, undiscussed speedies. Speedies should only be done if a subject is not controversial Indigenous nomenclature is always controversial, language is highly political in the modern aboriginal world, pretending that dusty old linsguitics texts are all that matters if academic chauvinism. Teh Wuikinuvx are a small but very proud people; for someone from afar to say "you have to be called this because it's what I say is most common" and pays no attention to their own website or publications.....that's more than questionable, that's not acceptable.Skookum1 (talk) 09:13, 25 July 2013 (UTC)

I'll come up with a list of all other such moves that were done by the same editor, for the same spurious reasons, and without discussion. All should be rolled back.Skookum1 (talk) 09:15, 25 July 2013 (UTC)
These moves should have been discussed beforehand. Consensus was definitely not sought or established in any of these moves. -Uyvsdi (talk) 17:03, 25 July 2013 (UTC)Uyvsdi
Inclined on first look to agree with this. Andrewa (talk) 19:10, 25 July 2013 (UTC)
Skookum1, as with the last several times controversial moves and moves against RM results by User:Kwamikagami came up, this is a matter for ANI it's evident from I DIDN'T HEAR THAT the only thing that will work is a move-ban, forcing User:Kwamikagami to use RMs, and abide by RM results. In ictu oculi (talk) 05:41, 26 July 2013 (UTC)
Obiwankenobi in one of the RMs suggested that a template or hidden text be included on such categories and main articles advising that they not be moved without discussion and/or that they are fixed and not to move them. "Ever again" I'd add ;-).Skookum1 (talk) 06:32, 26 July 2013 (UTC)
NB it's not just him, though he's the worst offender. Came across another a little while ago this morning, can't remember just what right now - oh yeah Taino people that was Tainos was moved by someone else. See Wikipedia:WikiProject_Indigenous_peoples_of_North_America/Name_issues#FOO_people_issues. I think all indigenous articles should be moved back to just "FOO" which was (more or less) the not-quite-consensus that evolved when many of these were being made and I was, with others, trying to organize the BC/PacNW categories. In some cases e.g. Palouse people, the older Palus is preferable. Yakama has now become Yakama Nation, but that's technically a government article, though an "ethnic group" redirect/category could in many cases be put on the FOO title (Yakama). I also don't see why the "FOO people" thing evolved, apparently for African peoples, was applied to North America and elsewhere. The human condition is not homogenous, Wikipedians of a certain ilk should stop pretending that homogenization and standardization is what should be the iron-clad case. Each to his own. In some cases e.g. Mohawk people (which had been Mohawk nation) it's much simpler to have simply Mohawk, which is necessarily the usage because the endonym is not as well known as the English term; in more obscure cases where the exonym/anglicization is not so well know, the endonym should prevail, especially if it is a recently-evolved endonym now desired as common usage by the people in question, which is the case with Wuikinuxv. In Dakelh's case, part of the reasoning for that is that the Babine-Witsuwitin (however that's spelled) are not Carrier, but Northern Carrier, and "Dakelh" is a term including all people of that type, not just Carrier per se; I found an article on "the status of First Nations language studies" by Bill Poser somewhere which explains that; though he does also use "Chilcotin" and "Lilloet" [sic] and other anglicizations, his explanations of the distinctions of some terms such as "Dakelh" and "Carrier" are worth reading. Back with that when I find it again.Skookum1 (talk) 06:29, 26 July 2013 (UTC)

Hm Palus is about India, Palus (tribe) redirects to Palus people but the previous instance above doesn't work...because of the lower-casing silliness (as I think it constitutes given confusions of "tribe" vs "federally-recognized Tribe", as also happened with Cree nations for First Nations governments, as if "nations" were the generic and specific plural of "First Nations", which it's not.......some tidying out there all over the place.....which is why the effort long ago to bring order to this; but now with agendas from other WikiProjects such as the "+people" one confusing things further, all the more important to not just stop such moves, but to codify why the names are what they are and why they have to remain as such.Skookum1 (talk) 06:37, 26 July 2013 (UTC)

Move reinstated?

Should the move on Aaron Johnson (actor) for Aaron Johnson not be reinstated as per the requested move result on the talk page? Tanbircdq (talk) 03:30, 30 July 2013 (UTC)

You should ask Jafeluv (talk · contribs). The close was long ago, October 2011, but the closer seems active. --SmokeyJoe (talk) 03:53, 30 July 2013 (UTC)

When can a new RM be initiated after a controversial RM is closed?

The case that raised the question is 2013 Egyptian coup d'etat. A RM was closed at 15:11, 11 July 2013 [31] on the grounds that 1) it was a coup, 2) the sources use the term, which makes it a WP:POVTITLE, and 3) the proposed alternative was also POV. A new RM was opened on 22:12, 12 July 2013, suggesting a title that (the proposer reasonably believed) was NPOV. A new argument was raised at 01:34, 14 July 2013, that the title is a descriptive phrase and POVTITLE applies only to names.

At 20:50, 14 July 2013, the RM was speedy-closed, on the grounds that any new RM was disallowed for a substantial period -- a "couple of months" was mentioned -- after a previous RM had closed.

It seems to me that the right standard is to allow a new RM to be opened immediately, as long as either the grounds for closure do not apply because of the newly-proposed destination, or a plausible new argument is raised that would (if accepted) suffice to reverse the basis for closure; and that speedy closure is inappropriate if a significant new argument is presented in the new RM, even if it was not raised when the new RM was opened. But I haven't found any guidance in the guidelines.

For what it's worth, I'm not seeking to open a new RM for that page, at least for now, because I don't have an acceptable destination to propose (and for other reasons, but that one is sufficient). --Dan Wylie-Sears 2 (talk) 04:53, 19 July 2013 (UTC)

You raise some good points/question. More precise guidelines are needed. My name is Mercy11 (talk) 13:04, 19 July 2013 (UTC), and I approve this message.
This probably comes down to a judgement call over whether the second proposed title Overthrow of Mohamed Morsi was adequately discussed and debated in the first RM, which is already buried in the second of three talk archives opened in a single month. What's with the 7-day auto-archiving there? That seems a bit excessive to me. The word overthrow is used several times, and Overthrow of Morsi a couple times, but the specific title Overthrow of Mohamed Morsi was never proposed in the first RM. Note in contrast the early closure at Talk:Boise State–Nevada football rivalry. Since the discussion of alternatives was short-circuited in that RM, I believe there would be sufficient grounds to open a new RM for an alternate title there. The Morsi situation is somewhat more muddled as to whether a new RM is merited, however. You might consider an appeal of that second close at WP:Move review and ask for it to be reopened. – Wbm1058 (talk) 16:03, 19 July 2013 (UTC)
As to the 7 day archiving, it appears to be a pretty active talk page, so 7 days is not particularly short. Apteva (talk) 04:54, 31 July 2013 (UTC)
I sympathize... but I have to urge caution... the terms used to describe this event are both political and controversial, and the previous RM engendered strong emotions on both sides. Ask yourself whether people are really calm enough (yet) to step back and look at your new suggestion with objectivity. I am concerned that others have become so locked into their stated opinions that they are not ready to consider any alternatives... even good ones. You may find that if you wait a month or so, everyone will be more receptive to your suggestion. In short, you may be shooting yourself in the foot if you start a new RM so soon. Blueboar (talk) 17:55, 20 July 2013 (UTC)
Exactly. Or even 6 months or a year. Apteva (talk) 04:54, 31 July 2013 (UTC)

We develop consensus through discussion. If there is no consensus, that suggests we need more discussion. If there is consensus and a decision, then a moratorium on discussion makes sense. But after a discussion is closed "no consensus"? Interested parties should not be prevented from discussing further, whether informally or as part of a new RM proposal. --B2C 21:48, 20 July 2013 (UTC)

No, interested parties should not (and cannot) be prevented from discussing further. But a new RM soon after a previous RM has been closed is unlikely to be helpful, especially if the closed RM involved extensive discussion. People understandably become weary of discussing the same subject over and over. We've seen this many times recently. Omnedon (talk) 14:28, 21 July 2013 (UTC)
There is no reasonable argument against further discussion based on becoming weary of discussing anything - no one is forced or required to discuss anything. If one participates in a discussion to the point that they grow weary of it, they have no one to blame but themselves. At most, if one feels compelled to participate in every RM on a given title, they can make one short summary of their argument, or refer to someone else's !vote that did that. If someone is too weary to even do that, they might consider a Wiki break. But thanks for bringing our attention to another status quo stonewalling tactic... Wikipedia:Status quo stonewalling#Arguing against more discussion due to weariness. --B2C 21:16, 21 July 2013 (UTC)
Does that mean that you think that raising an identical RM immediately after one is closed as no consensus is OK? That sounds very inefficient to me. It can work, but it would be far better to just not close the RM in the first place. The argument that others can just walk away is invalid, as admins are (collectively) responsible for processing all RMs listed in the Backlog section, so we're not quite as free to walk away as other contributors are, see my comments below (which preceded yours above, note).
If RM discussion is to be allowed to continue indefinitely without consensus (whether by not closing the RM or by allowing an endless succession to be raised) then I'd suggest we need a mechanism to remove these no-consensus RMs from the Backlog section without closing them... perhaps automatically if after two days (say) in the Backlog, no admin has been prepared to close as either move or no move. They could then stay (perhaps indefinitely) in a new no consensus section of WP:RM until one of the participants thinks there is enough of a consensus to relist. As I said, that can work. But we need to tweak the system a little if it's to work well. Andrewa (talk) 00:52, 22 July 2013 (UTC)
Yes, I think there should be no rule against opening an RM right after another is closed as "no consensus". But any such subsequent RM should be allowed to run its course, with no closing until at least a week of no discussion (or consensus is reached). If discussion has ceased for a week, I suggest closing as "no consensus" is unlikely to trigger another opening.

Also, in such a discussion what I called the WP:Yogurt Principle should be applied. That is, closers should be especially mindful in such a situation that they are determining community consensus about the title based on the arguments presented; that they are not determining consensus of the small sample of self-selected participants. Often in such cases there is no consensus among the participants, but there is a community consensus, because one side is supported by policy significantly better than the other. --B2C 16:21, 22 July 2013 (UTC)

While not wanting to comment on this particular case, I'd like to comment on some of the issues raised. In my (perhaps radical) opinion a new RM based on a previously rejected similar RM should only be raised (ever, no time period) if there is rough consensus on the article talk page to do so, and I'd back any admin who speedy-closed such an RM raised without supporting discussion on the talk page and a rough consensus there to take it back to RM. This is just based on practicalities, as observed by a fairly regular RM-clearer. It's pointless to take it to RM if you can't get consensus on the talk page, isn't it? And even more so if there has been a previous convoluted RM discussion, strongly suggesting that the new RM will be just as convoluted. Raising such pointless RMs wastes an enormous amount of admin time, and I really can't see what they achieve.
There is scope within the RM process for raising alternative names, and for relisting, and anyone can relist prior to closure. And if there are good alternative suggestions, relisting at the time these are made to allow a full discussion period for them is a good course. You don't need to wait until the RM falls into the "Backlog" and closure is imminent.
Yes, discussion is good. It should be directed at reaching consensus rather than disempowering the opposite view, and part of the incentive for this should be that RMs that have no chance of consensus (as demonstrated by a previous similar RM and no subsequent consensus to go back to RM) should just be speedily closed, to save everyone's time. This isn't policy AFAIK but should be.
Note I'm not saying that controversial RMs should not be raised once, or that convoluted RMs can be avoided. They are inevitable, and time well spent, and I'm happy to wade through them when the discussion period expires. It's just the reruns that I'd like to avoid. Andrewa (talk) 18:54, 21 July 2013 (UTC)
"... new RM based on a previously rejected similar RM should only be raised (ever, no time period) if there is rough consensus on the article talk page to do so".

Radical, indeed.

First, if there is a rough consensus on the talk page, arguably an RM is not even needed.

Second, often the only way to get reasonable discussion about a title is with an RM; without an RM it's sometimes difficult if not impossible to get any kind of reading on consensus.

Third, consensus can change and develop through discussion. Without RM, you are likely to not get the kind of discussion through which consensus changes.

Fourth, we're not even talking about cases where an RM had been rejected (your term) - we're talking cases where there was "no consensus" about an RM proposal. And, remember, what we're trying to determine is not whether there is consensus among the self-selected relatively small and insignificant sample participating, but whether there is community consensus regarding the title. The only way to do this is through the presentation of arguments evaluated based on how well they are based in policy. Again, often discussion prompted by an RM is needed to flesh all that out.

Finally, given the way closers often mistakenly evaluate WP:LOCALCONSENSUS, usually coupled with opposers' effective use of WP:Status quo stonewalling tactics, to conclude an RM discussion is "no consensus" simply because both sides are about equally supported in number, it often takes several RMs to establish that only one side is well supported in policy. This is the point of WP:Yogurt Principle. See also WP:Yogurt Title History for an extreme example of how repeated RMs are often needed to finally get to a decision that actually reflects community consensus. (NOTE: last three references to essays here are to essays for which I'm the primary author). --B2C 21:37, 21 July 2013 (UTC)

(Apologies if this stringing isn't quite right, it seems to be a bit confused below) I'll just say that I don't think you have addressed any of the points I made despite quoting one of them, and leave others to judge whether this is an accurate assessment.
Now, I will comment on one little quibble: The question of whether or not an RM has been rejected (my term) when it's closed without consensus and without a move doesn't concern me greatly, so I'll ask, what term would you prefer? Andrewa (talk) 02:09, 22 July 2013 (UTC)
A "no consensus" result is equivalent to when a jury deadlocks and is unable to produce a verdict. Referring to "no consensus" as "rejection" of a proposal sounds much more decisive than it is. I suggest deadlock or stalemate as being more accurate. --B2C 16:35, 22 July 2013 (UTC)
B2C, you continue to tout the yogurt situation as a positive example, and to throw around the word "consensus" in a way that's questionable. In any case, it's quite simple: if there is a discussion on a move request, and there is no consensus to move, then we don't move, and we don't need to go through the whole process again for a while. A freshly-opened RM on the heels of a closed RM is most likely going to be disruptive and not well-received by the community. Omnedon (talk) 01:13, 22 July 2013 (UTC)

Let me raise an example of a situation where a new RM was appropriately held very soon after an old one closed... take a look at the various RMs at Talk:Deadmau5. In the first RM there was a consensus (but not a very large consensus) to move the page. However, this move resulted in a very vocal backlash. A lot of new editors spoke up who had not participated in the first RM... all objecting to the move and, more importantly, giving new policy based arguments for returning the page to the original title. It quickly became clear that, had all these editors participated in the original discussion, the result would have been very very different. Not quickly holding a second RM would actually have been more disruptive than holding it. Blueboar (talk) 03:23, 22 July 2013 (UTC)

I've had a look at the archives... IMO my "radical" suggestion above would have handled this situation perfectly... a discussion on the talk page would have quickly resolved to raise a new RM, the new RM would link to that discussion, and any admin who thought of speedy closure would see that discussion. And in fact that appears to be exactly what happened, perhaps not quite as quickly. So what's the problem? Andrewa (talk) 15:35, 22 July 2013 (UTC)
Again, it is highly unlikely that that kind of discussion will occur without the framework of a formal RM being in place to motivate people to participate. I may have seen such discussion occur without an RM maybe once or twice, but it's very rare. Here again WP:Yogurt Title History provides good examples. Between the eight RMs, there was some discussion, but it was always very relatively limited compared to what occurred during the actual RMs. Certainly a rough consensus was never achieved outside of an RM. --B2C 16:35, 22 July 2013 (UTC)
It seems to me an excellent example of a waste of everyone's time, but I can't see any way that the yogurt/yoghurt discussion could support the wisdom of raising repeated RMs. It does however support a more general and possibly even more radical proposal of mine, which I call Andrew's Principle: If no consensus really is possible, then it doesn't matter which way we go.
The project here is to write an encyclopedia. It's not a debating club. Andrewa (talk) 20:29, 22 July 2013 (UTC)
Agreed, in part. Some editors do spend a great deal of time debating and little time editing. But if we make a change in a situation where there is no consensus to do so, then that's worse than doing nothing. That's why some degree of inertia in the system is helpful. There needs to be good reason to move an article. Omnedon (talk) 20:33, 22 July 2013 (UTC)
Exactly. And further, we don't want to discourage healthy discussion, and some editors are probably better at discussion than at working on articles, and we want to welcome them to the project too. But we also want to particularly encourage those who are working the coalface (remembering that the whole point of the project is the article or main namespace) to bring their experience there to the discussions, where it's a lot more valuable than any amount of theorising would be. It's a balancing act in some ways. Andrewa (talk) 20:49, 22 July 2013 (UTC)
The yogurt title debacle demonstrates the problem with Andrew's principle - closers judging the consensus of the participants rather than the community consensus as reflected through policy and applied to the case in question. That is, people are too quick to assume " no consensus really is possible". Community consensus as reflected in policy was not only possible at Yogurt, it was clear in RM #1.

While self-selected participants often cannot achieve a consensus among each other, the application of policy is usually much more clear. That was the case at Yogurt from RM #1 (of 8), and demonstrated by the closer of RM #2. But the idea that there must be a "consensus of the participants" prevailed in RM #3, which reversed the sound finding in RM #2, and lead to #4, #5, #6, #7 and, finally, #8, where participants finally agreed with policy.

In fact, it was the insistence that it was silly to continue debating the issue that was largely responsible for prolonging it. People assumed "no consensus was possible", and so concluded debate was silly, and did not take the arguments seriously. Even when it was repeatedly shown that moving the article as proposed would result in a title with an unassailable basis in policy (what we have now with it at Yogurt), it was largely dismissed.

To be clear, your principle is sound in theory, but is likely to fail in practice because of premature findings of "no consensus" based on !vote counting rather than argument analysis. --B2C 20:55, 22 July 2013 (UTC)

I interpret this data differently. What (in hindsight) was clear right from RM #1 was that no meaningful consensus could be achieved. Some appearance of consensus was eventually achieved through a process of attrition, which is likely to have discouraged some valuable editors, and achieved absolutely nothing. Andrewa (talk) 21:05, 22 July 2013 (UTC)
Yes, and similar interpretations are at the root of many problematic "no consensus" results that are actually supported by community consensus as reflected in policy.

Attrition? What evidence do you have of that? Especially since RM #8 had almost 50 participants, perhaps a record. Besides, you are again concerned with WP:LOCALCONSENSUS rather than community consensus as reflected in policy.

You deny that the Yogurt is unassailable in terms of policy-based argument and that hindsight was not necessary to see this before the article was moved? --B2C 21:45, 22 July 2013 (UTC)

B2C has a poor appreciation of WP:Consensus and others would be well advised to not trust his interpretations if it. --SmokeyJoe (talk) 21:56, 22 July 2013 (UTC)
See my personal interpretation at User:Andrewa/creed: I believe in consensus. I don't know what it means either, but I'll try to make it work anyway. Andrewa (talk) 00:29, 23 July 2013 (UTC)
No, I don't deny that the Yogurt is unassailable in terms of policy-based argument. I haven't commented either way and don't intend to. But I do claim that this was a lose/lose result, and that it would be good to avoid processes such as this.
Nor am I concerned only with local consensus. I have no idea what gave you that idea.
There is much concern about retaining editors. We do from time to time get sniping from outside of Wikipedia claiming that Wikipedia is inaccurate, but even these skeptics (who presumably are too old to have learned critical reading at primary school, if they are from my area) rarely if ever criticise our article titles, and nor should they. The article title is merely a handle. We try very hard not to say that just because we spell or style an article title in a particular way, that everyone therefore should, and we have non-judgemental redirects from other spellings.
But we do still have endless and vigorous debates about which title is correct. Whether these are just in terms of policy (which does include WP:IAR remember) or include other evidence, they don't do a lot to improve Wikipedia. If we could somehow curb these, it would be a big step towards retaining editors, in my opinion. Andrewa (talk) 00:22, 23 July 2013 (UTC)

Well, we see and seek to solve the same problem: needless bickering about titles. You seem to advocate "walk away". I don't believe advocating "walk away" is a practical or effective solution to this problem because we'll never get everyone to walk away, and it only takes very few to continue a conflict, sometimes only two.

So, I seek something else: policy-based resolution to such conflicts. There are two main prongs to this approach:

  1. Doing better at recognizing when one side in such conflicts is clearly supported better by policy than the other, and changing titles accordingly, even if there is no consensus of the small self-selected sample of contributors that happen to be participating in the discussion. We can do this as participants in RM discussions (e.g., my contribution to Talk:DNS today[32], or as RM discussion closers (e.g., Tariq's close of that discussion [33]).
  2. Improving title policy through an evolving process that gives ambiguous guidance as to what the title should be in fewer and fewer cases. For example, my attempt to clarify the meaning of WP:PRIMARYTOPIC today[34].

I believe that this is the only practical and effective way to greatly reduce the amount of bickering about titles. So, you will see my commitment to this approach in every edit that has to do with titles, whether it's about a specific title on an article talk page, an edit to a policy page, or discussion about such edits. I'm constantly trying to improve with respect to either #1, #2, or both. Will you join me? --B2C 01:50, 23 July 2013 (UTC)

I entirely disagree that the consensus of those participating in the discussion should be disregarded. Doing so will in no way reduce "bickering" (see Hilary Rodham Clinton). Moving when the discussion has not produced a clear consensus is problematic. And in terms of "walking away" -- you have repeatedly suggested that those who do not wish to continue discussing should "walk away". In any case, I agree with Andrewa that much time and energy is spent on titling, and while the general issue is not unimportant, it does seem to be the source of much of the contention that I encounter. Omnedon (talk) 01:59, 23 July 2013 (UTC)
I note that the edit to which you refer above regarding the primary topic guideline has been reverted [35], and that another editor has applauded the revert [36] in the following terms: Could B2C avoid putting his own, untested views into the guideline, please? Interested to see how that discussion proceeds.
But I'm afraid you don't seem to understand what I'm proposing. Speedy close of repeat RMs raised without supporting talk page consensus was my immediate, practical suggestion above. To describe this as a walk away solution is s bit bizarre. Andrewa (talk) 07:13, 23 July 2013 (UTC)
Omnedon, I'm glad you "disagree that the consensus of those participating in the discussion should be disregarded". But who are you disagreeing with? I, for one, never said, implied or even thought that. I don't know if you've read WP:Yogurt Principle, but the reason a key aspect of having a history of no consensus findings before the principle applies is because of not disregarding participant consensus (or lack thereof). But, ultimately, a more accurate indication of community consensus is not the consensus view of a relatively small self-selected group of participants, but an analysis of their arguments in terms of their basis in policy, which reflects community consensus. This is especially true when a number of RM discussions have made it likely that all significant arguments have been presented.

At Yogurt I argued for years that the bickering would end once the title clearly better supported by policy was selected. No one believed me there, but I was proven to be right, at least in that case. I am predicting the same regarding HRC/HC, for the same reason: once an article is moved to solid policy-based ground, the reasons for moving evaporate. It happened with Yogurt, and it will happen with Hillary Clinton. But as long as it remains on weak policy-based ground, which was the case with Yoghurt, and is the case with Hillary Rodham Clinton, instability, controversy and bickering will reign. Sure there will be periods, months, maybe even a year or more, of quiet, but sooner or later someone (perhaps someone who today has not even edited WP yet) will realize that there is good reason to change that title, and they'll bring it up, someone else will agree, and there will be another RM. How is this not obvious?

Andrewa, I apologize for misunderstanding. I thought you promoted "walk away" somewhere. But I did not mean to characterize your speed close proposal as that. I don't think you've addressed my objections to it. First, requiring talk page consensus before opening a new RM is impractical because often without an RM the kind of discussion required to motivate people to participate and develop consensus is not possible without an RM. But perhaps you see that as a good thing? Second, this does not resolve anything - at best it delays resolution. Finally, there are two very different types of cases to consider. In the first case both sides are truly well supported by policy. That is, policy supports the status quo just as strongly as the proposed alternative. I suggest these cases are rare, and, when they exist, indicate a problem with policy. The point of policy and guidelines is to provide guidance - when the guidance tells you its fine to go in either direction, that's not guidance. In such cases closers should suggest the relevant policies be reviewed. In them more common cases one side is clearly better supported by policy, yet the split among the RM participants is still 50/50, and, so, closers are reluctant to "find consensus". I suggest closers grow a pair. Finding consensus is ultimately about determining what community consensus is on the topic. When one side is supported by the policies that have community consensus, and the other side is most JDLI rationalization, the closer should find in favor of the policy-supported side, and such decisions should be supported in RM reviews (contrary to the debacle at the RM review of HRC/HC). --B2C 23:30, 23 July 2013 (UTC)

B2C, here's what you promoted: "...changing titles accordingly, even if there is no consensus of the small self-selected sample of contributors that happen to be participating in the discussion." Absolutely inappropriate. If one participates in a discussion, then that matters. You are saying that in some cases an action should be taken even if there is no consensus among the participants to do so. That's entirely wrong-headed by any definition of consensus-based decision-making. Omnedon (talk) 01:00, 24 July 2013 (UTC)

In the case of HRC, the current title is supported by policy. There are policy-based arguments for HC as well, but the key point with that situation is that one RM was opened (by you) just months after the previous one was closed, which some felt to be disruptive and counterproductive. I believe there should be a delay between RMs. Titles are important, but because of redirects and searches and the like, they are not as vital as content, as long as the content is easily located and the title is not clearly "wrong". Once again, titles are important -- but we spend too much time and energy on discussing them. Improving articles is far more important than debating for years and years over "yoghurt" versus "yogurt". Omnedon (talk) 01:25, 24 July 2013 (UTC)

Some of what you say above is true. But much of it, including your objections to my speedy close proposal, is pure speculation, and I don't think any other answer is possible or necessary.

You are still assuming that the result at yogurt was a good one. It wasn't. I hope nobody wants to reopen that debate, the current title is acceptable. But the process that produced it was horrendous, and the benefit to the article namespace trivial at best. As you've stated, a significant benefit of the eventual decision was to stop the endless discussion. It seems to me that this was the main benefit, and that indicates to me a very poor result, and a problem with the process.
But RM works reasonably well. In my opinion it would work even better under my proposal. You disagree; You like raising repeat RMs rather than building consensus first. There seems little support for this view, but you're entitled to it, and under the current guidelines there seems to be little to stop you from raising as many repeat RMs as you like. (I suppose eventually WP:POINT might be attempted, but I don't think it really fits.) Andrewa (talk) 12:41, 24 July 2013 (UTC)
Yes, Andrew, I think the final result at yogurt was a good one. A stable and non-controversial title on solid policy-based ground. A consensus of RM participants finally confirmed what community consensus about that title really was. As far as I know the applicable policies and guidelines did not change significantly from RM #1 to RM #8. In analyzing each of the RMs, it is obvious that the same basic arguments were made over and over. There is no evidence that community consensus changed over that period - so if it supported Yogurt in the end, it must have supported it in the beginning. That indicates any reading of community consensus to be anything but favoring Yogurt was a misreading of community consensus.

We agree the process that produced the final result was horrendous. I'm unclear as to what you believe was the root cause of that horrendousness. Although there were 8 RMs, that was over 7 years, and so often there was a considerable time between most proposals (e.g., over 2 years between RM #4 in 5/07 and RM #5 in 7/09). I believe the root cause was poor reading of community consensus in most of those RMs. A notable exception is the closing of RM #2 by Mets501 (talk · contribs) [37] in which he correctly observed that "there is clearly a majority who support the move with proper reasoning, so the article will be moved." That that decision was overturned, without consensus, and without proper reasoning, in RM #3[38], is probably the most extreme example of poor reading of community consensus. That particular proposal was even explicitly presented as a vote... "The vote is about ...", even though even the version of WP:CONSENSUS at that time explicitly said: "Precise numbers for "supermajority" are hard to establish, and Wikipedia is not a majoritarian democracy, so simple vote-counting should never be the key part of the interpretation of a debate."

What made the yogurt process horrendous was repeated interpretations of the successive RM discussions in which vote-counting was not only the key part, often (as in RM #3) it was the only part. --B2C 17:05, 24 July 2013 (UTC)

Andrew, I also agree that RM works reasonably well, but it could be improved. But I don't agree with your characterization that I like raising repeat RMs. I do believe that a repeat RM - when previous RMs were closed as "no consensus" - is often the only effective way to produce the types of discussion with the arguments necessary to establish where consensus actually lies. Can you produce any examples where an RM was ever closed as "no consensus", and then consensus was established on the talk page before another RM was proposed? Like I said, I don't doubt that it's possible. I'm just saying it's not very often. The closest one I can think of is regarding the great Sega Genesis/Mega Drive debacle (see Talk:Sega Genesis/FAQ). But even there it was a straw poll that produced what seemed to be a strong consensus, but it still took a formal RM to get enough participation to confirm. Most title discussions, without an RM proposal, simply attract far too few people, not to mention such discussions being heavily biased with people to have an interest in that particular article. Even achieving a consensus of such a self-selected group is not likely to reflect community consensus very well. --B2C 17:33, 24 July 2013 (UTC)

But we aren't talking about discussions without an RM proposal. We're (explicitly) talking about discussions that have already had an RM... perhaps just minutes previously, or perhaps once every quarter on average over a period of two years. That was the original question above. Andrewa (talk) 20:57, 24 July 2013 (UTC)
Agreed, Andrewa (talk · contribs). And that's what I'm addressing. My statements apply to discussion about titles that have already had an RM. Once the RM is closed, it's often very difficult to get discussion going again with even a fraction of those involved in the RM, without starting another RM. How do you develop and establish consensus without getting people to talk. I hardly ever see exceptions to this.

By the way, this is especially true where there is some WP:Status quo stonewalling going on. That is, the defenders of the status quo have no motivation to even get involved unless the status quo title is at risk of being changed, and that's only going to happen within the framework of a formal RM. So once an RM is closed as "no consensus", they see that as a victory (after all, their preference, the status quo, is preserved - never mind that it did not have consensus support, not in terms of !vote counts or in terms of stronger policy based arguments), and have no reason to discuss the issue further. You have to open another RM to make them present arguments based in policy (if they have any) that support the status quo. --B2C 23:05, 26 July 2013 (UTC)

Omnedon, when referring to "consensus" in these discussions it's important to be clear on whether we're talking about consensus, or WP:CONSENSUS. In particular, the difference between a consensus of those participating in a discussion, and what the community consensus is about the issue being discussed, needs to be understood and appreciated.

Any given discussion on Wikipedia, even the relatively large RfCs involving dozens, is comprised of a small (relative to the whole WP community) self-selected (not random) sample of the thousands of WP editors that make up the community, and is by no means guaranteed to be a representative sample of the much larger community. This is why determining consensus among the participants of a discussion is not an effective way to determine community consensus about the question at issue. For example, if half of, say, twenty participants favor a proposal and half oppose, that result tells us there is no consensus among the participants, but very little if anything about whether there is community consensus about the proposal, and, if so, what it is. We have to look at and evaluate the arguments to determine that.

This is why discussions closers on Wikipedia have the duty to determine WP:CONSENSUS by evaluating the arguments in terms of how well they are based in policy (which reflects community consensus), rather than by determining what, if anything, is the consensus of the self-selected participants.

You might think this is a radical view, but it's the well-documented view of the community. It is reflected at Wikipedia:Closing_discussions#Consensus, for example, which says:

The closer is there to judge the consensus of the community [not of the discussion participants], after discarding irrelevant arguments: those that flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, those that show no understanding of the matter of issue.

Also at Wikipedia:Deletion_guidelines_for_administrators#Rough_consensus:

Consensus is not determined by counting heads, but by looking at strength of argument, and underlying policy (if any). Arguments that contradict policy, are based on opinion rather than fact, or are logically fallacious, are frequently discounted.

This idea is also reflected at Wikipedia:RMCI#Determining_consensus:

Consensus is determined not just by considering the preferences of the participants in a given discussion, but also by evaluating their arguments, assigning due weight accordingly, and giving due consideration to the relevant consensus of the Wikipedia community in general as reflected in applicable policy, guidelines and naming conventions.

And of course, WP:CONSENSUS says so too, at WP:CONSENSUS#Determining consensus:

Consensus is determined by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy.

So, yes, per all of the above policies and guidelines (not just my opinion) when when one side in a title conflict is clearly supported better by policy than the other, WP:CONSENSUS about the title should be determined accordingly, even if there is no consensus among the small self-selected sample of contributors that happen to be participating in the discussion. --B2C 18:57, 24 July 2013 (UTC)

B2C, you are inferring something in your first quote that isn't there. In context, it is clear that "the community" refers to participants in discussions; it in no way says that the participants can be ignored. You really should stop talking down to people in these discussions as if they have no idea what you're talking about. I know that we are talking about consensus in terms of Wikipedia; please stop quoting these things to us over and over. Even after your lengthy response, I still entirely reject the notion that, as you put it, titles should in some cases be changed even if there is no consensus among the discussion participants. That is precisely why we have discussions: to come to consensus. If you are going to proceed without that consensus having formed, then you are operating against the way Wikipedia works. Omnedon (talk) 20:04, 24 July 2013 (UTC)
Let's try another tack. What we seem to be discussing is how to help the admins to better do their job of closing RMs. I think that we do pretty well, but that we could do better if there were a better restriction on raising repeated RMs after one has already closed (which was the original subject of this discussion), to avoid wasting time on repetitive arguments, and also to avoid the temptation not to even read these arguments, or at best not very carefully. Andrewa (talk) 20:57, 24 July 2013 (UTC)
  • Comment - I would leave this up to editors per WP:CREEP. If there was In my view 1,2,3 months for a case where there is a significant reason (naughtiness, new evidence, changed circumstances,non admin close, closed against policy, closed majority of editors, supervote close by admin known for POV on the subject). 12 months for a rehash of old story against consensus against. There are enough active RM contributors to penalize a too-quick relist for no good reason to need to regulate. And speaking of which, has everyone here made a substantial contribution to article space today? In ictu oculi (talk) 05:32, 26 July 2013 (UTC)
Hear-hear. Omnedon (talk) 23:47, 26 July 2013 (UTC)
So, what you're both saying is that it's better under those circumstances to raise a new RM, rather than to start an informal discussion on the talk page?
I'd have to say I still disagree. There seems no good reason not to start a talk page discussion. If there are good reasons for a new RM and the RM has any chance of success, then we'd expect at least a rough consensus on the talk page to raise the RM. Or, in the event of no response at all, after contacting those involved in the previous RM and/or other discussions (which isn't canvassing provided both sides are contacted), then I'd be happy for an RM to be raised based on the silence. But to clutter WP:RM with moves that have no demonstrated support and are repeats seems silly to me. Andrewa (talk) 09:23, 28 July 2013 (UTC)
Generally it is recommended to start a talk page discussion before opening a new RM for a proposed move that has already been discussed. Apteva (talk) 04:54, 31 July 2013 (UTC)
If an RM closes and those that disagree want to discuss it further, then a talk page discussion would be preferable to immediately opening a new RM. When I said "hear-hear" above, it was mainly in support of the idea that we each ought to try and make contributions to the article space as well as to these discussions. Discussions are important; but ultimately it's all about the content. There is, and will be for the foreseeable future, much to be done. Omnedon (talk) 12:18, 31 July 2013 (UTC)

How can I get outsiders' opinions?

It has been requested that the article about Mathilde of Belgium be moved to Queen Mathilde of Belgium despite the fact that the article about her husband is titled Philippe of Belgium rather than King Philippe of Belgium. Such discrepancy can only make sense to Wikipedia editors who have edited royalty-related articles for years. Ordinary readers, for whom articles are written, can only be confused and misled by such a practice. Usually people seek the opinion of those interested in the subject but in this case I believe it would be beneficial to get opinions of "outsiders", users who do not edit articles about royals. How (or where) can I "advertise" the discussion to get opinion of such users? Surtsicna (talk) 21:49, 21 July 2013 (UTC)

Note this RM is already advertised at Wikipedia:WikiProject Royalty and Nobility – perhaps what you would call an "insiders" noticeboard. In theory, WP:RM, where it is also already advertised, is a more general noticeboard, which is watched by many editors with a general interest in page naming conventions and page moves. That should be sufficient, and interested "experts" are usually best at making page naming decisions. However, if you still want to solicit more uninvolved editors, you could try a request for comment, as I discussed in the previous section, there is a small "alternate universe" of page move discussions using that venue. An RfC about a page move should just link to a requested move discussion, in my opinion, and not a to a fork of such a discussion. Wbm1058 (talk) 01:21, 22 July 2013 (UTC)
Clarification. An RfC replaces an RM, and is just a way of discussing for 30 days instead of for 7 days. They are advertised in different places though, by default, and in the same places, such as relevant wikiprojects. RM templates can be removed when an RfC is open. Apteva (talk) 04:38, 31 July 2013 (UTC)
IMO all the "King" and "Queen" article titles should follow a standard format throughout the encyclopedia. If we have Philippe of Belgium and Juan Carlos I of Spain then, for example, Elizabeth II should be titled Elizabeth II of England and not merely have a redirect such as it currently has (namely the Elizabeth II of England (redirect)). Whether such article titles have "King"/"Queen" in them or not should not matter during a first attempt to standardize, but for Christ's sake let's at least start by making all such titles consistent! My name is Mercy11 (talk) 14:42, 24 July 2013 (UTC), and I approve this message.
  • As our Article titles policy notes, choosing the best title for an article involves balancing five key principles. Article titles should be Recognizable, Natural, Concise, Precise, and Consistent ... however the policy also notes that sometimes we can not achieve all five at the same time. In which case we may have to choose between them. If a mindless adherence to consistency results in a title that is not recognizable or natural (for example) we should (and usually do) toss consistency out the window. Blueboar (talk) 14:01, 25 July 2013 (UTC)

Missing instructions

I can find nothing in the instructions about the situation where you want to start a discussion about a name, but you don't know for sure what name you want. I just had to solve this problem at Talk:Prince Harry of Wales. Is there a particular method that should be used? W. P. Uzer (talk) 07:39, 30 July 2013 (UTC)

Use a question mark. I fixed Talk:Prince Harry of Wales for you. This is documented – expand the collapsed Template usage examples and notes by clicking [show] to the far right on that collapsed template bar. It's also documented in the template:Requested move documentation and at Wikipedia:Template messages/Moving. But perhaps it should also be given a mention in the main instructions. – Wbm1058 (talk) 14:21, 30 July 2013 (UTC)
Thank you! I just added it to the instructions. W. P. Uzer (talk) 09:20, 31 July 2013 (UTC)

Template:Disputed title

In the alternate universe of Dispute templates there is a somewhat obscure one regarding titles, which tags articles themselves rather than their talk pages. Currently it's transcluded on just five pages:

These seem like they should use requested moves to resolve their "disputed titles". Rather, they bypass the normal procedure for (potentially) controversial or disputed title moves by using WP:RfC or other discussion alternatives. Is there any good reason for them to bypass WP:RM? Should the requested moves procedure document {{Disputed title}} as an optionally used template for providing article notification of requested moves? Wbm1058 (talk) 17:57, 19 July 2013 (UTC)

In the not-too-distant past, there was a mainspace template notifying of ongoing RMs on a corresponding talk page. I think it got deleted. This might be an issue for TfD, but I'd be happy to see this one deleted. It too easily lends itself to drive-by tagging, because as you say, RM is the process for this. Or we could just slap this tag on that's the subject of repeated RMs.</badidea> --BDD (talk) 16:57, 24 July 2013 (UTC)
Added to WP:TfD. Apteva (talk) 04:31, 31 July 2013 (UTC)
@BDD: Right, see Wikipedia talk:Requested moves/Archive 24#Template:move notice, which links to several other discussions. {{Movenotice}} was the mainspace tag from the now-deleted parallel universe of category:Proposed moves. Its cousin {{Move header}} (now userfied in my space) was also deleted. I intend to post my opinion at Wikipedia:Templates for discussion/Log/2013 July 31#Template:Disputed title after I sort this out, and I hope you give yours too. Wbm1058 (talk) 15:47, 2 August 2013 (UTC)
The discussion was closed with no consensus while I was still analyzing usage of the four mainspace tags:
Perhaps all four templates should populate Category:Wikipedia title cleanup, which is the only category exclusively dedicated to titles. The other three categories bury the few title-related articles under a mountain of non-title-related issues. All four of these templates tend to linger on articles for months and years. – Wbm1058 (talk) 19:29, 9 August 2013 (UTC)
I did change the templates so they also populate Category:Wikipedia title cleanup. Vegaswikian (talk) 20:13, 9 August 2013 (UTC)
Thanks for your bold endorsement of my idea. I tweaked the templates to send a parameter to {{Ambox}}. After some wp:Null edits, Category:Wikipedia title cleanup should be fully populated with all the articles tagged with one of these four title-related templates. Maybe you can think of an NPOV title for Misconduct in the Las Vegas Metropolitan Police Department Wbm1058 (talk) 21:22, 9 August 2013 (UTC)
That article has more problems then the title. Vegaswikian (talk) 21:50, 9 August 2013 (UTC)

Backlog

While it is nice to see the backlog gone, and discussions can be closed at any time that consensus is reached, there are normally still discussions in the last date listed that have not reached a full 7 days (opened after the current time). Are we getting a bit over-enthusiastic? Apteva (talk) 21:11, 31 July 2013 (UTC)

Apteva, I see that your eagle eyes have detected that the bot's backlog logic isn't working right. It's not a piece of code that's had much exercise lately. Please give me some time to figure out how it works and debug it, by leaving up the backlog notice for now. I have an off-line project to do right now, hopefully I'll get the bot fixed later today. Thanks, Wbm1058 (talk) 18:33, 1 August 2013 (UTC)
That was a long time ago. I had not even noticed the backlog notice. I had previously been trying to trouble shoot that, but not recently. Apteva (talk) 20:58, 1 August 2013 (UTC)
Right, it was a month ago, relatively not that long, but nobody told me about it and I didn't notice. Anyhow, it's  Fixed now.
There are actually eight days listed, and after seven days of discussion, on the eighth day the administrators close requests, lest they join the backlog on the ninth day. Thus anything on the last day in the list is fair game for closure. – Wbm1058 (talk) 22:39, 1 August 2013 (UTC)

Deletion of DAB pages

Coming here from Wikipedia:Miscellany for deletion/Grouping (disambiguation)

I am fairly sure that DAB pages have been supposed to be discussed at AfD. However, I don't seem to find any explicit instruction to that effect.
Having played around in a few XfD places, it occurs to me that deletion of DAB pages might be better discussed at WP:RM, because DAB expertise/experience/interest is much more concentrated at WP:RM. I don't think that DAB page get listed for deletion very frequently. An idea. What do people think? --SmokeyJoe (talk) 07:30, 15 August 2013 (UTC)

Talk:Masjid_al-Haram

Can someone fix Talk:Masjid_al-Haram ? I've tried twice to fix the bot pickup problem with the rationale, but keep getting reverted by rybec (talk · contribs) -- 76.65.128.222 (talk) 15:24, 18 August 2013 (UTC)

As I explained in my edit summaries and on your talk page, you have been inserting text into another editor's comment, and I restored the comment to its original state [39]. Furthermore, this page should not be moved right now because discussion of the move has resumed, with someone giving an argument against it. —rybec 15:31, 18 August 2013 (UTC)
It has nothing to do with moving the page (shorting the discussion), it has everything to do with listing the page at the WP:RM list. User:RMCD bot expects a certain format for RM requests, when it doesn't find it, it will not interpret the nomination properly. Most frequently, this misinterpretation will make it not find the rationale. The fix I put in lets RMCD find a more normally formatted request, and it will pick up the rationale. -- 76.65.128.222 (talk) 15:36, 18 August 2013 (UTC)
I think Mr. Appleyard just forgot to substitute the template. Having the request inside his comment looked a little odd. I should have moved it above his comment, rather than deleting it. Sorry. —rybec 16:36, 18 August 2013 (UTC)

Community consensus (again)

I have asked B2C to explain this edit. In particular, amongst all the recent discussion, is there a consensus for it? Andrewa (talk) 18:54, 3 August 2013 (UTC)

Absolutely not. The concept is right, but the wording is horrible. By referring to relevant policy and guideline in weighing arguments, the closer is choosing the consensus of the community, and we do not just count votes, so yes the concept is right, but it is not properly worded. Apteva (talk) 19:45, 3 August 2013 (UTC)
I would agree that B2C's wording was poor. This is a very tricky issue, and we need to get it right. For one thing, I don't think it is quite accurate to imply that closers should ignore numbers... those do matter. We also need to remember that policy/guidance can occasionally get out of sync with community consensus. If there are lots and lots of people at an RM (or other RFC type discussion) all saying that we should do X ... but policy or guidance says to do Y... there is at least the possibility that all those X votes represent a shift in the community consensus ... and that the policy/guideline page no longer accurately reflects the real consensus of the community, and needs to be amended. Blueboar (talk) 21:45, 3 August 2013 (UTC)
Exactly. Consensus can change.
There are two ways to change policy and guidelines to reflect changing consensus. One is to propose a theoretical change to the rules, citing examples preferably. The other is to establish consensus that the rules do not deal well with particular cases, and then update the rules to accomodate these cases. Both ways are valid and do occur, but the second way is the more productive in my experience. Andrewa (talk) 00:52, 23 August 2013 (UTC)
And the best way to be sure that consensus has changed is to have the policy or guideline updated. Vegaswikian (talk) 00:58, 23 August 2013 (UTC)
Exactly, and important. I think I'll incorporate that comment into User:Andrewa/Types of consensus, if you don't mind. Andrewa (talk) 01:19, 23 August 2013 (UTC)
No problem. Vegaswikian (talk) 01:28, 23 August 2013 (UTC)
Done. [40] [41] Andrewa (talk) 01:39, 23 August 2013 (UTC)

Nominators of rename requests challenging closures?

I requested dropping "The" out of the title, The Star Wars Holiday Special. One administrator closed it. Since I requested the move, I couldn't challenge the closure. Someone else boldly added back "The", so I requested protection and revert move. Unfortunately, another move request was made. In order to prevent something like this again, shall I, the nominator, challenge the closure of a request that I made? --George Ho (talk) 16:49, 22 August 2013 (UTC)

@George Ho: Firstly, I'm not aware of any rule saying that the requester of a move can't challenge the closure. But in this case, it's not the closure you want to challenge but the bold reversion. Secondly, on the issue itself, I personally think the move back was not legitimate. I have commented to that effect at Talk:The Star Wars Holiday Special. Thanks  — Amakuru (talk) 17:04, 22 August 2013 (UTC)
What about the next time I made? --George Ho (talk) 19:51, 22 August 2013 (UTC)
I'm afraid I don't understand your question, there...  — Amakuru (talk) 19:55, 22 August 2013 (UTC)
I'll rephrase: If I, the nominator, disagree the move, shall I challenge it? --George Ho (talk) 21:48, 22 August 2013 (UTC)
FYI to all – I believe this issue has been resolved now. Someone made an undiscussed move that was contrary to the outcome of a move request that had just closed a few days earlier. That is what George Ho was complaining about. I reverted that unilateral action, so George is now satisfied. If someone doesn't like the outcome of the recent move request closure, they should submit it for a move review – or, if something new has happened, submit another move request. They shouldn't just make a unilateral move that is contrary to the consensus that was just formally established. —BarrelProof (talk) 00:40, 23 August 2013 (UTC)

Very overcomplicated page

Can I just leave some feedback that this page is very complicated and confusing. People don't have endless amount of time to read through so much instructions and text. Please just give main, straight to the point instructions at the top. I have a headache. Lesion (talk) 17:00, 24 August 2013 (UTC)

Requesting to move or delete

I can't figure out how to request this, so I'm requesting it here:

Would like to move The Cliff's Edge Derby Trial to Derby Trial Stakes.

Reason for move: Duplicate.

Stylteralmaldo (talk) 13:56, 25 August 2013 (UTC)

Neither move or delete applies to WP:DUPLICATE articles. There's another process called merging. I put the appropriate tags on the articles for you. So what is "The Cliff's Edge"? A sponsor that bought naming rights to the race? That should be explained in the article. – Wbm1058 (talk) 18:11, 4 September 2013 (UTC)

Determining consensus - last line about "no consensus" make no sense

The last line of the "Determining consensus" section at WP:RMCI says something other than what it is supposed to mean. These are the last two lines:

Therefore, if the closer feels that no consensus has been reached, they may move the article back to the most recent stable name. If the most recent stable name is itself a matter of dispute, closers are expected to use their own judgment in determining the proper destination.

How can the "most recent stable name" not itself be a matter of dispute? It's the subject of an RM - it's a matter of dispute by definition.

I think this is supposed to say that if there is no recent stable name (no recent title is stable), then closers are expected to use their own judgment. I've clarified accordingly[42].

If I am missing something, go ahead and revert, along with explaining what this is all about. --B2C 03:35, 26 August 2013 (UTC)

Upon further analysis, I just made it consistent with policy as stated at WP:CONSENSUS#No consensus [43], which states:

In article title discussions, no consensus has two defaults: If an article title has been stable for a long time, then the long-standing article title is kept. If it has never been stable, or has been unstable for a long time, then it is moved to the title used by the first major contributor after the article ceased to be a stub.

So the instructions here now say this:

Therefore, if no consensus has been reached, the closer should move the article back to the most recent stable title. If no recent title has been stable, then the article should be moved to the title used by the first major contributor after the article ceased to be a stub.

--B2C 04:05, 26 August 2013 (UTC)
In my opinion, these changes make it more difficult for (we) admins, for no possible benefit to the reader. Andrewa (talk) 02:17, 7 September 2013 (UTC)

Clarification needed.

The recent Bradley Manning/Chelsea Manning naming dispute has raised some ambiguities that should be addressed with respect to requested moves, which were raised at Talk:Bradley Manning/August 2013 move request#Meaning of "no consensus" in this case?. It was readily apparent to the closing administrators examining this dispute that the "default" title for the article was the title that it had prior to any of the moves being made. I was, quite frankly, surprised that any editors would suggest that a page being moved and then move-locked by an administrator would have any effect on this. This should be spelled out here, specifically that if a move is contested, then a consensus is required to move that page from the title that it had prior to the contested move being made, irrespective of the title at which the page sits while this consensus is being sought. Furthermore, it should be established that in cases where a reasonable editor can make a case that the default title is a BLP violation, the article may permissibly be kept at the proposed new title for the duration of the discussion. bd2412 T 16:41, 1 September 2013 (UTC)

Note: according to Wikipedia:Consensus#No consensus:


I will add this to this page now, as it is already established policy. bd2412 T 18:28, 1 September 2013 (UTC)

Although unusual in its notoriety, I think the Chelsea/Bradley Manning case illustrates why it's important that when titles are so controversial the article has to be locked, the stable title must be restored as well.

When that page was locked, the title should have been restored to Bradley Manning right away, along with speedy closing the Chelsea Manning → Bradley Manning RM proposal, to allow for a specific Bradley Manning → Chelsea Manning RM proposal and the presentation of an argument in favor of moving that article to Chelsea Manning.

If we leave the article at the new title, people will and do get confused about what the default is. Explaining that in some obscure policy is not going to really address that problem because it's counter-intuitive. People are used to the current title being the default, and that's understandable. Making it policy that the stable title needs to be restored in such cases will address the problem, because not everyone will have to be aware of it - only one admin does.

So, I think this should be our policy in general, but I don't know where exactly to put it.

I also don't think a controversial BLP argument should create an exception (and the need for a page lock demonstrates it's controversial). If there is consensus of a BLP situation, that's one thing. But there clearly was no consensus about that in this case from the start, for good reason. --B2C 19:32, 1 September 2013 (UTC)

I think spelling out "the title used by the first major contributor after the article ceased to be a stub" is a bad idea. Sometimes that would be dredging up ancient history irrelevant to the issue at hand. Do we really need to start algorithmetizing these decisions? Dicklyon (talk) 04:55, 2 September 2013 (UTC)

The less clarity there is in policy, the easier it is to rationalize basis for just about any position with wikilawyering. Do we really want to encourage wikilawyering?

In the mean time, restoring to "the title used by the first major contributor after the article ceased to be a stub" is an effective and reasonable way to break an impasse created by ambiguous rules which open the door for either side to be reasonably supported by wikilawyering policy in some situations. --B2C 05:23, 2 September 2013 (UTC)

Nonsense. Wikilawyering is encouraged by more rules, not by letting editors work it out. And where does this new proposal say it's only for use in "impasses"? Or is that what you're redefining a lack of consensus in an RM to mean? Dicklyon (talk) 05:59, 2 September 2013 (UTC)
The "ceased to be a stub" language is irrelevant to the Manning dispute (and probably to most disputes); the straightforward key language is, "If an article title has been stable for a long time, then the long-standing article title is kept". bd2412 T 19:56, 4 September 2013 (UTC)

Renaming for more namespaces

See WP:VPP for a proposal to extend WP:RM to cover two more namespaces (file(talk) namespace). -- 70.24.244.158 (talk) 07:26, 4 September 2013 (UTC)

The discussion is in the section titled File naming policy and renaming activity. – Wbm1058 (talk) 18:39, 4 September 2013 (UTC)

Should closers indicate their reasoning when closing?

RM discussions are typically closed as "Moved", "Not moved", or "No consensus". Optionally, closers can also provide reasoning for how they reached their decision. I think this reasoning should be provided in most cases. Just being in RM means the proposal is controversial - not cut and dried. So unless the discussion is unanimous, there are likely to be good reasons on both sides. So how did the closer decide? This should be explained.

Habitually explaining reasoning may reduce the number and kind of complaints, maybe not. But if it does, that would just be a bonus.

The important thing is to explain. If certain arguments were dismissed because they were refuted or blatant JDLI, it helps to point this out because it should cause people to leave substantive arguments in the future (or, better yet, not bothering trying to defend a position that can't be defended substantively). If certain arguments are highlighted as being particularly persuasive, that should encourage others to try to form such arguments in other RMs, if possible. Good closer explanations should help raise the quality of RM discussions. That's the point. If you just close with "moved", or "not moved" or "no consensus", there is no feedback. The improvement process is short-circuited.

Finally, specifying the reasoning should help put aside suspicions that the closer is simply super voting per his or her own personal preferences.

And, I'm not talking about a big long explanation in every case (though sometimes that may be appropriate). In most cases a few sentences should be quite adequate... at least enough to demonstrate that the closer gave the discussion the serious consideration it deserved.

Any objections to putting guidance to this effect at WP:RMCI? --B2C 19:43, 4 September 2013 (UTC)

I think it depends in part on the close. If a proposal is met with a flood of support or opposition, or if the response is clearly 50/50, there is really no need for the closer to expound on that fact. It is only where the discussion is close, or where a substantial proportion of arguments are discounted for being clearly off-base, that a closer really needs to address them. I do agree, however, that it is good policy for a closer to explain why erroneous comments are erroneous. Cheers! bd2412 T 19:49, 4 September 2013 (UTC)
Even if the responses are lopsided or 50/50, the weight of the arguments does not necessarily follow. I mean, a discussion could appear to be 50/50, but what matters is the distribution of policy based arguments and JDLI variants. Since that is almost always somewhat subjective, the closer can and should explain why and how the arguments were considered and weighed, don't you think? I mean, "the discussion is about evenly split and both sides had solid arguments - I recommend looking into resolving the conflicts between policy P and guideline G" would be a helluva lot more helpful and useful than, "no consensus". --B2C 20:55, 4 September 2013 (UTC)
We do our best. I close most (but by no means all) of the RMs I close with the default results of moved and not moved, and as a result I can then get on with other RMs. There is normally a backlog, and backlog is just what it says... it has been at least an extra day since the RMs on it could and ideally would have been either closed or relisted.
With some foreboding, I'm afraid I have to ask you, are there specific instances where you feel a longer closing comment would have been helpful? Preferably ones I've done, but any diff would do. Only then can we see whether this suggestion is itself helpful.
But frankly my gut feeling is that any guideline along these lines will just risk busting what ain't bust in the hope of fixing other things that ain't bust either. On the other hand I think I see what you're getting at. How can we do better...
Personally, I often resist the temptation to close an RM (controversial or no, strong consensus or no) where some (or in a disappointing number of cases, all) of the discussion completely ignores the relevant policy, so as to instead point this out, by myself exercising a vote or by initiating discussion or both. Do you think we should encourage admins to do this more often? It again risks increasing the backlog, of course, but it seems to me to be a better way of addressing the issues you raise. Andrewa (talk) 02:30, 5 September 2013 (UTC)
I disagree that being in the backlog indicates the request has been open longer than ideal. Many could benefit from much more discussion than 7 days. Some take 7 days to get rolling. That said, I think relisting is probably a bit better than allowing a request with ongoing discussion to languish in the backlog.

I agree it's often better to participate in order to point out the vacuity of policy-based reasoning one one side (or both), than to close and point that out. And also agree that should be encouraged. --B2C 20:20, 6 September 2013 (UTC)

The stringing seems to indicate that this is replying to me, but what do you disagree with? I never said that being in the backlog indicates the request has been open longer than ideal. I said it has been at least an extra day since the RMs on it could and ideally would have been either closed or relisted (my new emphasis). You seem to agree with all of this, or have I misunderstood you? Andrewa (talk) 00:56, 7 September 2013 (UTC)

Here is an example of a good closing. Instead of simply saying "no move", Tariq explained his reasoning:

The result of the move request was: no move. As noted a number of times, the redundancy mentioned in the request doesn't truly exist; one would know Virginia Beach is in Virginia because they know it's there, not because it's in the name of the city. No compelling reason has been provided as to why WP:USPLACE shouldn't apply here. -- tariqabjotu 21:48, 4 September 2013 (UTC)

I, for one, appreciate Tariq's effort here. --B2C 23:37, 5 September 2013 (UTC)

Agree it's an excellent closing comment (without having looked at the RM itself). But so what? The discussion here, as I understand it, is not whether these extended comments should be banned or discouraged (perish the thought, I make them whenever I think it helpful) but rather that they should be expected in more cases than they are now.
An example of a good closing comment proves nothing about this proposal. What we need for a start is just one where you think that the discussion would clearly have benefited by the admin taking more time to provide a longer comment than the default, but they didn't do it. We can avoid any suggestion of personal attack here if (as I suggested above) you can find one of mine to criticise. Literally, I'm asking for it. I close lots of RMs with the default close comment.
But if it can improve Wikipedia for me to provide more details, I'm eager to learn. And if it can improve Wikipedia to incorporate some encouragement for longer comments into guidelines or policies, or even into the bot which currently provides the short default, let's do that too. But you need to provide some (relevant) evidence.
A related matter is that admins often close an unopposed RM as moved where there has been no valid rationale provided for the move, without any further comment. I would need to dig a bit to get to the previous discussion and examples, but my criticism of this approach was soundly rejected in the past.
I think that where these moves are done, the admin should provide a sound rationale, and that otherwise they should be relisted, with an oppose vote if policy is clear on this, and a comment criticising the rationale (or lack of it) otherwise. Your thoughts? Andrewa (talk) 02:00, 7 September 2013 (UTC)
  • B2C, I understand where you're coming from, but I strongly oppose any changes along this line. The last thing RM needs is another requirement to bog down the process. You've seen the backlog lately. Other venues like AfD get along just fine without this sort of requirement. --BDD (talk) 17:17, 18 September 2013 (UTC)
  • I'm also concerned that closing reasons can turn into signing statements, essentially just legitimizing garb for supervotes. Closing rationales are usually unnecessary because an outside party should be able to look at the decision, look at the discussion, and have no complaints. I still think that accurately describes a great majority of RMs. They're just not as noticeable because they don't agitate us as much. --BDD (talk) 17:39, 18 September 2013 (UTC)

Trying to Move a Page for the first time

Any help?? - This is the first time I have ever needed to move an article, so I am having trouble. I am trying to move the page The Awakening of Flora or Le Réveil de Flore to Le Réveil de Flore. I am unable to do this myself because the page Le Réveil de Flore is currently a re-direct page to the article in question. I tried to request this move on the main project page per the instructions given by using the template for technical moves, but it kept turning out incorrectly - when I preview it, it shows me the following message in bold red -

Must create [[]] before requesting that it be moved to [[:]]

The reason for this move is that the work is known simply as "Le Réveil de Flore" and does not require the double title is has.

--Mrlopez2681 (talk) 18:11, 12 September 2013 (UTC)

@Mrlopez2681: It looks to me like you tried to use {{subst:RMassist||}}, which resulted in the error message:
You need to specify three parameters as documented at Template:RMassist, like this: {{subst:RMassist|The Awakening of Flora or Le Réveil de Flore|Le Réveil de Flore|The French-language title is more commonly used in English-language sources than the English title "The Awakening of Flora".}} if that reason is accurate, which will give this:
Be sure to do this by editing the page Wikipedia:Requested moves/Technical requests. I suppose I should enhance that template's edit validation to make sure the current pagename is given. I f you leave out the reason, this is what you'll get:
thanks! - added request to page! :) --Mrlopez2681 (talk) 20:52, 12 September 2013 (UTC)
You're welcome. But I just did a Google search that seemed to indicate that The Awakening of Flora was more common. Though it's interesting to see how many of the links mirror Wikipedia's current title! Well, just wait to see it that's accepted, if not it will go to the (potentially) controversial moves process... Wbm1058 (talk) 20:57, 12 September 2013 (UTC)

Requested move 15 September 2013

Request was improperly placed here. It was moved to: talk:Weltevredenpark --Mike Cline (talk) 15:15, 15 September 2013 (UTC)

Question about titles protected from creation

I tried to move Jason steed to Jason Steed or Fledgling Jason Steed, but received an error stating:You do not have permission to move this page, for the following reason: You cannot move a page to this location because the new title has been protected from creation. Where can I see why these titles have been protected? Thanks! GoingBatty (talk) 13:50, 17 September 2013 (UTC)

The page was originally deleted under CSD:A7; then recreated and deleted per Wikipedia:Articles for deletion/Jason Steed; then recreated again and deleted under CSD:G8. The last recreation led to the salting. bd2412 T 15:24, 17 September 2013 (UTC)
Since the article topic is now covered by two AfDs (Jason Steed and Fledgling Jason Steed) the safest way to proceed is most likely a WP:Deletion review. Those wanting this article kept should find evidence that Mark Cooper's fictional work has been reviewed or at least commented on in mainstream media, not just on web sites such as fictionreviewer.com. If there is no effort at a DRV, then the Jason steed article risks being deleted per WP:CSD#G4. EdJohnston (talk) 16:44, 17 September 2013 (UTC)
Aha! When I visit Jason Steed or Fledgling Jason Steed, I can see links to the deletion discussions. It would be nice if the move failure error would contain a link to the appropriate discussion (or at least generic directions on how to find it). Thanks for the info! GoingBatty (talk) 17:02, 17 September 2013 (UTC)

Simpler way to start a requested move

Yair rand has come up with a nifty way to start a requested move. See User talk:Yair rand#Simplified move proposal process. Yair's javascript allows editors to use the "Move page" special page to auto-generate requested moves on the appropriate talk page. Please feel free to test and use this script to request moves. Enable it by creating a common.js subpage in your user space, or editing that file if it already exists. Put the following line in your common.js page:

importScript("User:Yair rand/ControversialMoves.js");

For an example, see User:Wbm1058/common.js. See also : Wikipedia:WikiProject User scripts/Scripts.

Here's an example demonstrating how it works:

Just start moving the page per Help:How to move a page:

Enter your reason for proposing the move, and check the "Do you think this move might be controversial?" box. Clicking on Propose moving the page results in an auto-submitted requested move. After successful testing and positive feedback, we may propose that this script be made a gadget so that editors may install it by checking an option in their preferences rather than needing to edit their common.js page. – Wbm1058 (talk) 16:49, 18 September 2013 (UTC)

Modest proposal: Require QPQ participation

It likely hasn't escaped the attention of many RM-watchers that the backlog has been especially long as of late. And despite all these active requests, many are attracting low participation. I, for one, have been trying to find consensus as best as I can in these low-participation discussions, but this seems to just upset those who end up on the wrong side of the discussion. But as I said at a recent MRV, you make closes with the arguments you have, not the arguments you might wish to have. I don't want to sound like a whiner, but put yourself in the shoes of a closer: decisions need to be made, but the decisions are hard, and making them upsets people. Small wonder that so few admins stick around here.

How to solve this? Well, I have a modest proposal. Sort of. I haven't quite decided how serious this is. I want to take a page from the WP:DYK playbook and institute a quid pro quo requirement, say you need to give your opinion on X number of other RMs before proposing one of your own. Maybe X can be a lower number if you focus on the backlog. The most sensible objection I see to this is that among RM regulars, many editors already meet this requirement anyway. But maybe we can scale the requirement accordingly. We could also peg the number to the size of the backlog somehow, so this doesn't create an unnecessary burden in leaner times. So, any better ideas? --BDD (talk) 17:35, 18 September 2013 (UTC)

Sigh. As recently as August 1, the backlog had been eliminated, I assume through some concentrated effort and energy. But there wasn't enough energy to keep the process backlog-free for more than a day. Wbm1058 (talk) 18:27, 18 September 2013 (UTC)

Implied move of a DAB

In the last few days I've seen two RMs which were technically malformed because they proposed removing the disambiguator from a title, but there was already a DAB at the target. So what was intended was a multi-move, with the DAB to be qualified with (disambiguation). In both cases I think WP:snowball will be applied and the process not delayed, but it's been complicated a little. And as noted several times recently, the admins on RM patrol are kept at least busy enough.

Here's my proposal: In such a situation, the move of the DAB is implied. That doesn't mean we'll knock back multi-move requests, it just means that a single move request would also be accepted as properly formed, and if there's consensus to move the page then the DAB should simply be moved too with no further comment. Which I think in practice is what often happens now.

That means of course that there won't necessarily be a heads-up on the DAB's talk page. The more I think of this, the more logical that becomes. It's not really the DAB that is affected, that's only a navigation device, the place the heads-ups are required if they're to be useful are on the talk pages of the other meanings, and we don't currently put them there. So if we can do without those, I think we can do without the DAB page heads-up too.

Not sure exactly how to put this into the closing instructions, and I don't think any change is required to the instructions for opening an RM, because the old way should remain valid anyway. Don't fix what ain't bust. But first I thought I'd seek consensus that the implied move of the DAB is actually a good idea. Andrewa (talk) 16:42, 26 September 2013 (UTC)

  • Agreed, and I think this is essentially just validating existing practice. These so-called malformed requests that don't result in a bot notification on the dab are, IMO, equivalent to taking an article to AfD without notifying the creator. It's not the best etiquette, but absent evidence of ill intent, it's really not a big deal. I doubt many dabs get on watchlists anyway. --BDD (talk) 19:20, 26 September 2013 (UTC)
  • I'm not completely in agreement. I have a large number of disambiguation pages on my watchlist and it is often disheartening to see one moved after a discussion on some other page involving only a few participants and there was no notification on the disambiguation talk page. If the only persons who notice such a discussion are those who already have the affected article on their watchlist, there may well be a selection bias in the participants that would tend to lean towards favoring that article as the primary topic. I don't think it is necessary to close the first discussion and start a new one, but I think it would help if the requests could be more easily reformulated to be a multi-page move with appropriate notifications. The move templates are a little fiddly though. I'd be willing to leave some discretion to the closers as to whether the discussion has had wide enough participation to fairly determine a primary topic. There should be an option to relist after reformulating as a multi-page move (or at least after notifying any other affected pages). older ≠ wiser 19:36, 26 September 2013 (UTC)
    • OK, I have never had more than a very few DABs on my watchlist and any article likely to be proposed as primary meaning would have been on the watchlist too at the time, so that's valuable input about how others work and exactly the sort of input I was after. Andrewa (talk) 23:01, 26 September 2013 (UTC)
  • This conversation reminds me of a request BDD made on my talk page. It's still on my back-burner to make it easier to convert single move requests to muti-move requests. Sorry I'm easily pulled off in other directions, so much to support. And then there's a related conversation at Wikipedia talk:Article alerts/Feature requests#Multi-page move notifications that was started by older ≠ wiser. – Wbm1058 (talk) 22:31, 26 September 2013 (UTC)
    • Yes, closely enough related to be the same topic IMO. I've posted a heads-up at the project talk page you mentioned [44]. I guess there's no need for one on your talk page (;-> or on BDD's either but thanks for that link too, very interesting. Andrewa (talk) 01:17, 27 September 2013 (UTC)

It's not hard to relist, nor is it hard to manually add the heads-up to the DAB talk page, and I've always done that rather than reformat an open RM as a multi move for fear of what the bot might do in this unusual situation... perhaps this fear is groundless (no offence intended to our wonderful bot coders!) but it seems unnecessary to involve the bot at that stage. The other question is the timing. The discussion period should restart at the time of providing the DAB talk page heads-up, regardless of whether the heads-up is provided manually or by the bot. Malformed requests are often noted only at or towards the end of the discussion period, and if there's little or no discussion period left then there's little or no point in the heads-up anyway.

The other side of this is, if the DAB talk notification is important, then should the bot crawl the DAB and provide heads-ups at all the affected talk pages? This is the other extreme, but would it be helpful? It seems more logical than just flagging the DAB as is the present system.

Or there's a third possible course of action, and that's to tweak the closing instructions in the opposite direction to my suggestion above, so implied moves of DABs are banned or at least discouraged. Then older ≠ wiser and editors of similar habits will get the heads-ups that they want. I'm guessing that they often miss out at present, and BDD's comment above supports my guess. Andrewa (talk) 01:28, 27 September 2013 (UTC)

I'm not sure I'd go so far as to ban them. High profile cases usually attract a pretty wide cross-section of participants. I'm mostly concerned with discussions that take place on more obscure topics where there might only be a few participants, all of whom have an interest in the one topic but have little cognizance of the other topics on the disambiguation page. I'd be happy if at least the affected disambiguation page were notified and the discussion relisted for another round. Ideally, the Article Alerts bot would be able to pick up such a notification and add it to Wikipedia:WikiProject Disambiguation/Article alerts. older ≠ wiser 02:12, 27 September 2013 (UTC)
But whether we say that assuming consensus carries over to the implied move of the DAB should be banned or at least discouraged, or whether we say the affected disambiguation page should be notified and the discussion relisted for another round, it amounts to exactly the same thing in practice. Or have I missed something?
High profile cases which leave out the fate of the DAB at the target are generally changed to valid multi-moves within a few minutes of posting. They're not the issue. Andrewa (talk) 15:02, 27 September 2013 (UTC)

A good solution, in my opinion, would involve changing the way move requests are automatically processed. It is obvious that if something has been named as the destination target of a move request, that target will be affected if the request is successful. The solution is that the bot should detect whether the destination name in a move request is already the location of a non-redirect article (regardless of whether the destination is a dab page or anything else) and if that situation is detected, it should automatically put a move discussion notice on the corresponding Talk page. This would not only provide the necessary notifications for implied moves of dab pages, but also provide useful notices for other types of malformed multimoves. There is already a bot that adds similar notifications to the pages that are requested to be moved by a properly formed multimove request, so it seems like some of the necessary processing capability already exists. —BarrelProof (talk) 19:42, 27 September 2013 (UTC)

Agree. Good analysis and good proposal. Interested in other views on it, of course. Andrewa (talk) 21:03, 27 September 2013 (UTC)

For more evidence that something should be done see these diffs. The proposer assumed that the DAB would automatically move, and if this did take place (which seems unlikely in this case, as there's not a lot of support for the move anyway) then people like older ≠ wiser would not get the heads-up that they would like. Andrewa (talk) 07:36, 29 September 2013 (UTC)

I see nothing wrong with that. A disambiguation page is not a substantive article, it is a navigational device, like a hatnote. Moving a disambiguation page in favor of a primary topic should require no more notice or discussion than changing the content of a hatnote. bd2412 T 00:29, 30 September 2013 (UTC)
That's roughly my view too, and is I think our practice at present but is not supported by guidelines or policy, and see this opposing view above. Andrewa (talk) 10:01, 1 October 2013 (UTC)
I don't agree. It makes no difference that a "disambiguation page is not a substantive article". It is precisely because it is a "navigational device" that notification of editors interested in the disambiguation page is important when a proposed move affects that page. All too often, there may be a long history to a disambiguation page and some local consensus at a backwater article determines there is a new primary topic and the closer fails to examine the disambiguation page or its history to see if the move might be more controversial than the participants in the discussion realize. It would be far preferable in my opinion if all the pages directly affected by a proposed move be properly notified (and ideally, the article alert bot could then alert interested wikiprojects). older ≠ wiser 16:36, 5 October 2013 (UTC)
Addendum: for example, a proposal to move Joe Schmoe (footballer) to Joe Schmoe that did not notify the disambiguation page might attract the attention only of fans of the footballer. And if the move closer only considers the opinions of the participants, might conclude that there is consensus to move. Again I think the overall conclusion from such a discussion is stronger when there is broader participation, one avenue for which is ensuring all directly affected pages are notified (and perhaps articles other than the disambiguation that might also realistically be the primary topic). older ≠ wiser 16:45, 5 October 2013 (UTC)
Agree with older ≠ wiser. Although posting a move notice on a dab page probably doesn't put very many people on notice, it is better than nothing. Obviously, if someone has put a dab page on their watch list, they want to be informed about actions that could affect that page. Something that I am watching shouldn't just be pushed aside without any warning as the result of a "local consensus at a backwater article". —BarrelProof (talk) 17:09, 5 October 2013 (UTC)
However, we must also consider the fact that a move over a disambiguation page will not necessarily be a "multi-move". In a TWODABS situation, one article may be deemed primary, and the disambiguation page wiped out altogether when the move is done, leaving only a hatnote on the page of the moved article. bd2412 T 20:15, 5 October 2013 (UTC)
True enough, I suppose – but in such a case, it would still be desirable for the dab page watchers to be notified that this might happen before it actually happens. —BarrelProof (talk) 20:39, 5 October 2013 (UTC)
See Wikipedia talk:Requested moves/Archive 21#Notifications of Requested Moves for another brief discussion of essentially the same point. older ≠ wiser 18:10, 5 October 2013 (UTC)

Note to closers

The same VPN-hopping sock who took five bites under 5 different IPs against WP:NCM/WP:PDAB at Talk:Thriller (Michael Jackson album) also had three bites at Talk:Britain in the American Civil War. This activity looks like it is increasing - rather than bothering to create new named socks each time. So closers need to click IP edits on RMs to distinguish our real IP users from this activity. In ictu oculi (talk) 00:07, 30 September 2013 (UTC)

Evidence

The move instructions say to provide "evidence in support where appropriate". The problem is that a reader may assume the evidence was meant to be neutrally selected, whereas the presenter of evidence may have deliberately excluded evidence that does not support the move proposal. In other words, the reader may mistakenly think the evidence in a move request is like a Request for Comment (RFC) which is required to be neutral.

So, I would suggest something like this:

Place here your rationale for the proposed page name change, ideally referring to applicable naming convention policies and guidelines, and providing evidence in support where appropriate. If your reasoning includes search engine results, please present Google Books or Google News Archive results before providing other web results. If your evidence was not selected neutrally then do not leave the impression that it was. Do not sign this.

This suggestion is based on my experience in the past (e.g. Manning), unrelated to any pending move request.Anythingyouwant (talk) 13:51, 9 October 2013 (UTC)

  • Oppose Despite our ideals of neutrality, an editor proposing a move is advocating a specific position which others may contradict. This isn't a courtroom, and I don't like the idea of burdening users with presenting more evidence than they care to. There have been plenty of times that I've been writing an RM, come across strong evidence supporting the current name, and simply given up. Other times, perhaps my preferred title predominates in a general Google search and Google Scholar but not Google Books, and I'll variously either note the discrepancy or just present the evidence that supports my position. It's up to others to gather contrary evidence. What you recommend is good practice and courtesy, but bad policy. I understand the concerns of those who wanted the recent Manning RM to be presented more neutrally, but the simple fact is that most RMs are not, any more than AfDs are. --BDD (talk) 16:52, 9 October 2013 (UTC)
I'm fine with not presenting evidence neutrally. But readers ought to be made aware that it's not being presented neutrally.Anythingyouwant (talk) 17:04, 9 October 2013 (UTC)
I think that's only the case if people are assuming it's neutral. Apologies, but I think a majority of editors know this. --BDD (talk) 17:07, 9 October 2013 (UTC)
I agree with you that a majority knows it, but that would still leave room for 49% who don't.Anythingyouwant (talk) 18:06, 9 October 2013 (UTC)
Talk pages are not in article space so the NPOV requirements do not apply. The audience for the move are editors not readers, and editors have to assume good faith so presumably no one is going to propose a move unless they thing that there is a good reason to do so. I think that the instructions on how to move a page should be brief and restricted to help page instructions (this is how you do it) not guideline instructions (this what you ought to do). -- PBS (talk) 09:01, 10 October 2013 (UTC)

2013 Mediterranean Sea migrant shipwreck requires urgent attention please

Hello, sorry I don't know what the right channel is. Feel free to delete this section but please action. 219.79.91.36 (talk) 01:11, 13 October 2013 (UTC)

Does WP:RMTR apply to Categories?

The reason I'm wondering is because it looks like any "technical" reason to move a category from one name to another is covered in WP:CFDS. If this is the case, I propose that instructions be added to WP:RMTR to request that any category move requests go to WP:CFDS with the exception of cross-namespace move requests. (I was going to add the instructions boldly, so I have an idea how to do it, but I realized that it might be controversial.) Steel1943 (talk) 17:52, 7 November 2013 (UTC)

RM from userspace draft of existing article

I'm working on a few total rewrites of stubbed and unsourced start-level articles, and greatly prefer to work on them in userspace so as to build from scratch and not need any of the prior material. I don't see anything written on this topic and I'm not sure how to handle it. Would the protocol be to write up until a point where it is clearly better than the current article and then RM from userspace (for delete and move)? Or something else? Would this overwrite the previous article or would it just necessitate a history merge mess? Wanted to check before getting in too deep. czar ♔ 14:33, 5 November 2013 (UTC)

I found #Displacing edit histories and #See #Displacing edit histories section above: probably a similar case, which discuss similar situations and recommend copy-pasting solo final drafts to the main article as a repeat personal contribution. Requested move discussion and delete+move still seems to be the smarter solution unless the previous (and unrelated) edit history is necessary to preserve, but I'll go with the Jan 2012 consensus for now. czar ♔ 14:51, 5 November 2013 (UTC)
You mean something like this? I always make a request to Anthony Appleyard for those types of moves. DragonZero (Talk · Contribs) 03:02, 6 November 2013 (UTC)
When I'm around, I am also glad to make such moves, as requested. Cheers! bd2412 T 03:10, 17 November 2013 (UTC)

The standing question is whether small articles with few citations are ever wiped out for a userspace draft (delete then move draft). I'm assuming "no" per my post above (and that admins would perform a history merge instead, I suppose to keep the obsoleted edit history), but I wanted to clarify for archive posterity. czar ♔ 04:57, 19 November 2013 (UTC)

If you start from a draft of the article being rewritten, it really doesn't make much of a "history merge mess" to combine them, so long as no major rewrite of the target article has been undertaken while your draft was being revised. bd2412 T 20:36, 19 November 2013 (UTC)

Bizzarree reliance on google

Why does the RM template contain the following line:"please present Google Books or Google News Archive results before providing other web results". That seems to be giving Google a lot of prominence and is saying it is a more reliable source than other equally reliable sources. That line should either be reworded to remove references to Google only or dropped entirely. Sport and politics (talk) 10:11, 1 November 2013 (UTC)

Google Books search results and Google News Archive search results tend to be more useful that other web results (such as Google web search results). We could take "Google" out and use "search engine book search results or search engine news archive search results", if the issue is whether to use Google Books vs. Amazon, or Google News vs Bing News? -- JHunterJ (talk) 10:41, 1 November 2013 (UTC)
Indeed I have no issue with using search engine news or search engine books, it just seems odd to promote Google in this way so I strongly support removing Google. Sport and politics (talk) 20:42, 1 November 2013 (UTC)
It's good to have a standard to resolve edge cases objectively. Otherwise, in edge cases, people will cherry pick among search engines to find the results that best support their position. In edge cases, it doesn't matter which search engines is selected as the standard, so choosing the most popular make sense. In other cases, it doesn't matter as the results should be the same no matter which search engine is used. --B2C 00:05, 17 November 2013 (UTC)
No, it's silly to pretend that there can be a standard for such things. Search engines are for finding things, not for settling disputes. I agree that Google book search and scholar search and such are very useful, but to try to use them in an algorithm for making naming or style choices would be ridiculous. Dicklyon (talk) 00:56, 17 November 2013 (UTC)
I would agree that there is no firm algorithm ... Choosing an appropriate title for an article is an art, not a science. However, examining search results do (and should) play an important part in any discussion about article titles. The number of hits any name or stylization gets tells us a lot about how recognizable it will be. Of course the discussion does not (or at least should not) end with raw hit counts. The step after compiling raw hit counts is to examine the quality of each of those hits.
Getting back to the language of the guideline, however... I agree that we should be more generic. Specifying Google over Bing or other search engines is wrong. In fact, I would go a step further and ask editors to explore multiple search engines... after all, if you get significantly different results using different search engines, that would be a fact that should be discussed and explored further. Blueboar (talk) 02:26, 17 November 2013 (UTC)
Well, but is there a resource out there beside Google Books (or Google Ngram) that compiles the same depth of information? I don't think Amazon is a comparable source. Please correct me if I'm wrong, but that's my impression. If so, I think we should keep the recommendation on using at least Google Books. If there are multiple reliable news compilation sites, then the guidance could be changed to give a couple examples: "Use news sites (such as Google News, Bing News, etc.)". Dohn joe (talk) 02:54, 17 November 2013 (UTC)
Blueboar (talk · contribs), let's say we're trying to decide between title X or title Y for some article, both of which are commonly used to refer to the subject, but neither is the obvious choice over the other for any reason. Further, search engine G suggests X is more commonly used, while search engine B suggests Y is more commonly used. You say this means the issue should be discussed and explored further. That would be true, if it really mattered whether the title was X or Y. I say toss a coin go with search engine G results, and be done with it, so time and energy can be spent on issues that do matter. --B2C 05:27, 17 November 2013 (UTC)
Yes, a simple coin toss can break a tie when all else is equal... but that assumes that all else actually is equal. My point is that using just one search engine may not give you a true picture of source usage. You need to look at several. And, in addition to examining raw hit counts, we need take a look at the quality of sources that each engine gives you. If two search engines (X and Y) give you contradictory results in terms of raw hit counts, but the hits given by engine X are of higher quality than those given by search engine Y, then that higher quality is a better tie breaker than simply flipping a coin. Blueboar (talk) 14:37, 17 November 2013 (UTC)
First, I intentionally struck out "coin toss" because in this case the "coin toss" result is not random. Second, "all else" does not have to be exactly equal, just close enough so that neither choice is obviously best.

It's true that one search engine might not give you a "true picture of source usage", but, again, that would only be relevant if it was important to select the title that is truly more commonly used. In such a case, when neither is obviously it, what difference does it make? So the Google results indicates it's X by a small margin, but per the "true picture" it's Y by a small margin. The Google results are definitive. They are what they are. They say it's X, period. The "true picture" is subject to interpretation, and argument, and change depending on who is involved in the discussion. All to make a decision in which both choices are fine (neither X nor Y problematic). Why not just follow the Google results? Why bother with trying to determine the ephemeral "true picture"? --B2C 23:28, 17 November 2013 (UTC)

There is nothing definitive about Google hit counts, (Books or otherwise). That initial number that it shows on the first results page is not an actual count of the actual results in any way. It's an estimate unrelated to the number of results found. People treat it as an actual number because it looks so official up there at the top of the page. But it is never correct. Never. It's not even right by the order of magnitude. Google finds results but it shouldn't be used as any kind of census. __ E L A Q U E A T E 16:59, 18 November 2013 (UTC)
Google can prove a term exists but it can't prove it's more popular than another term. Anyone wishing to fall down a rabbit hole of disillusionment can look here, here, and here. __ E L A Q U E A T E 17:08, 18 November 2013 (UTC)
The WP:GOOGLETEST is the best approximation tool we have to determine relative popularity. Again, in obvious cases the answer is obvious. In edge cases the answer doesn't matter; either choice is fine. Let's let WP:GOOGLETEST pick one, "right" or "wrong", and move on. The alternative is pointless hand-wringing and bickering that often seems to go on without end. --B2C 03:04, 19 November 2013 (UTC)
Google results can show if a term has any popularity. It is not useful when comparing two different popularities. As an example, try Google searches for "hamburgers" vs "hot dogs". Guess which one is more wildly "popular"? It's useless to compare two wild and incorrect estimates as if it's telling us anything. You're asking Google a question it can't answer for us. __ E L A Q U E A T E 13:51, 19 November 2013 (UTC)
That's a pointless example since "hamburgers" and "hot dogs" don't refer to the same topic.

So, we agree Google can tell us if each of two actual candidate terms for being the title of a given article has any popularity. Say they both pass. That qualifies both as titles for the article. So, why not use the same Google results, right or wrong, to tell us which one is more popular, and just use that? Since it really doesn't matter which one we use, why depend on much more subjective methods to make such an unimportant decision? Methods which are subject to endless and pointless debate? --B2C 20:22, 19 November 2013 (UTC)

Use the results no matter if they're "right or wrong"? "It really doesn't matter which one we use"? "Unimportant decision"? These are very nihilistic concepts. Just because two terms may have similar bogus "popularities" doesn't mean they'd both be great article titles. The policies, guidelines, and general practice seem to point to chewing our food a little, evaluating what we find before we act on it, and not accepting a source mindlessly, including when that source is the all-powerful Google itself. And sure, maybe instead of writing articles we could just list the top five links provided by Google; that would save a lot of "pointless debate" too. I hope this doesn't seem unkind, but I really don't know how to respond to advice to ignore that something isn't true for the purpose of saving time and avoiding discussion. The answer to your question is that part of what Google reports is not verifiable or neutral truth, it has systemic biases and failures, and that includes those hit estimates. It's weird to suggest basing the article content on something known to be incorrect. And really, this is all covered in WP:GOOGLETEST. __ E L A Q U E A T E 21:22, 19 November 2013 (UTC)

I also question the "right or wrong" phrase. As has been pointed out, this seems to be a use of Google results for which those results were not designed. They are what they are, but for this application they present difficulties. I also find it interesting that B2C decries pointless debate in light of the long battle over "yoghurt" versus "yogurt". Omnedon (talk) 22:00, 19 November 2013 (UTC)

Let's keep the discussion in context, folks. If there are other good reasons based in policy/guidelines to clearly prefer one title over the other, by all means. Of course.

The relevant situation here is when all else is equal (more or less)... when policy/guidelines don't give us a clear indication of which title to prefer over the other, both are equally "right", by definition. Yes, in such a case, whether the search results are "right or wrong" doesn't matter, because the "wrong" choice is not really wrong. There is no wrong. Either title is "right". That's why it doesn't matter which one we use. That's why the decision about which one to use is unimportant. That's the context in which I made those statements, Elaqueate (talk · contribs); please don't take them out of context. --B2C 00:28, 25 November 2013 (UTC)

I understand the difference between flipping a coin to settle or avoid an argument, and flipping a coin to settle an argument while making an explicit claim that the coin is somehow "expert testimony" and "knows which side is better". That's the only part that's "wrong". The "unimportance" of the decision being settled doesn't mean the numbers given by Google should be represented as honestly comparable, that's all. Flip a coin, tie the names to hamsters and then race them, whatever, but don't tell people you're really doing is comparing popularity if you really aren't. I understand your desire here to settle arguments that you think are pointless quickly, but that has nothing to do with advising people to believe unbelievable numbers. (I think your hypothetical situation where it's a low stakes decision will work out without dragging Google into it anyway, even if people have to do it by a little bit of talking.) __ E L A Q U E A T E 01:04, 25 November 2013 (UTC)
No one is talking about advising people to believe unbelievable numbers. Why are you bringing that up?

This is about making an unimportant decision decisively and consistently that cannot be readily made decisively and consistently any other way.

The problem with flipping a coin is that every time you flip it you have a relatively high chance (50/50) of getting a different answer. That's not consistent. Ignoring the difficulties of flipping a coin in the context of a WP discussion, if we make a title decision based on that, what's to prevent someone from arguing a coin should be flipped again the following month? It doesn't settle anything.

Generally, if Google results indicate X is used more often than Y, it will give you, and everyone else, the same indication (especially if &pws=0 is added to the search string to eliminate personal search bias) every time it is asked. In that sense it's like a verifiable coin flip. So if it tells us the "right" answer is X, it's likely to tell us the same thing next month, and next year. It's not for sure, but better than any other method I know. And it has been used for this purpose countless times in RM discussions, and quite successfully in most cases so far as I can tell.

As to the situations where it's a low stakes decision being hypothetical... have you looked at WP:RM ever? Probably 90% fall in that category. --B2C 05:34, 25 November 2013 (UTC)

Results vary when a search is done from users in different places. Results vary over time, a short amount of time. And Google can be wrong about which term is more "popular". Your argument is to ignore that the results don't say anything meaningful, because you believe they say the same meaningless thing consistently. I understand your argument, but mindless acceptance of bad data isn't better than discussion between editors, just because it might be quicker, and even if it's been done in other cases. If you find you want to dismiss those conversations as pointless, maybe just don't get involved in them? __ E L A Q U E A T E 08:57, 25 November 2013 (UTC)
Adding &pws=0 to the search string eliminates regional bias as well as personal search bias.

You say discussion among editors is better? Discussion about what, exactly? I remind you, we're talking about cases where both titles meet policy/guidelines approximately equally; there is nothing wrong with using either title. There is no clear indication from policy/guideline about which title to use. The only reason to prefer one to the other is personal preference. What is there to talk about? It's dueling WP:JDLI arguments. It's mental masturbation. It's not healthy. It's not productive. It's not good for the encyclopedia. It takes away time and resources from efforts that are good for the encyclopedia.

The only exception is when the situation is taken as an example for changing the relevant policies/guidelines so that they do provide an indication for how to resolve such a case (e.g., by using WP:GOOGLETEST). Now that is worth discussing. Hey! That's what we're doing. --B2C 22:54, 25 November 2013 (UTC)

Adding &pws=0 does not completely eliminate regional bias, nor does it address what makes the estimates wildly inaccurate. It's a good goal to want to settle disputes, but this is an ineffective and inaccurate method.

And how do you get to the knowledge that two choices "meet policy/guidelines approximately equally" without discussing them? Do you have any specific examples of a move that should be decided by Google's faulty estimates rather than discussion? Or is this a "perfect case" scenario? __ E L A Q U E A T E 11:49, 26 November 2013 (UTC)

That's news to me, and would defeat the purpose if true. Please show me a search that returns different results in different regions even when you use &pws=0.

Discussion is often necessary to get to the point where it's clear to at least those involved that the two choices in question "meet policy/guidelines approximately equally", though it's often the case for requests at WP:RM. After all, any case where one choice clearly meets policy/guidelines better than the other should be uncontroversial and shouldn't even have to go through that process.

In any case, once you're at that situation -- both choices "meet policy/guidelines approximately equally" -- is when further discussion becomes pointless, either choice is fine, and any arbitrary mechanism, including a "wildly inaccurate" result from Google, is fine to resolve it. --B2C 19:28, 26 November 2013 (UTC)

Um... I agree that if both choices "meet policy/guidelines approximately equally" then either title would be acceptable... but at that point we don't need an arbitrary mechanism to resolve the decision - we have a non-arbitrary mechanism to resolve the question... we default keep the article at the current title. Blueboar (talk) 19:57, 26 November 2013 (UTC)
1. Blueboar is completely right here. It's silly to have an arbitrary decision maker based on inaccuracy, just to settle something that settles itself. and 2. as far as &pws=0 goes, I was tempted to just tell you to Google it regarding its waning effectiveness, but SEO people have understood it doesn't work that well for awhile now. Here's somebody who used &pws=0 with other depersonalizing techniques: It's interesting to note that, no matter what method I used and how radically I cleared my history, ever method still localized me to the Chicago area (even the IronKey incognito). and stuff like this.
Okay, and that would be relevant if WP:GOOGLETEST was really an arbitrary decision maker based on inaccuracy. If it were truly arbitrary, it would still give us the right answer half the time. We can argue about how often it is inaccurate (tells us that A is more popular when it's actually B), but, frankly, I bet it's right at least 90% of the time.

My point is that in a case where other policies/guidelines do not indicate which of two titles we should use, if Google results indicate one is more popular than the other, we should go with that decision, not arbitrarily, but per WP:COMMONNAME. Yes, once in a while we might end up with the title that is actually less popular, but so what? Since that title meets the all WP:CRITERIA as well as the other, what difference does it make? Let's just accept the result and move on. Looking at Bing and Yahoo and who knows what else can at best only result in giving grounds to use the other title, resulting in a stalemate, and probably endless discussion over something that is truly unimportant. --B2C 04:28, 27 November 2013 (UTC)

You're just repeating your argument here. You haven't said anything new that shows that Google's hit counts are accurate for the purpose you're suggesting, or accurate at all. It's a type of "a stopped watch is right sometimes, so let's keep using it so we don't argue" kind of argument. Google doesn't eliminate the need to do our own thinking. You keep adding the guidelines, but WP:GOOGLETEST describes using Google for specific tasks while respecting its technical limitations, and WP:COMMONNAME does not mean using something because it's majority popular among non-reputable sources. Maybe if you understood how inaccurate Google hitcounts are, you'd quit pushing them, but right now you seem to be missing the point. __ E L A Q U E A T E 07:38, 27 November 2013 (UTC)
The context set in the first post in this section limits us to appropriate searches in Google Books and News, not general Google searches. I assumed that context was understood. I've seen heavy reliance on such searches for years, and know of no problems that resulted from it. What problem with such searches do you believe actually exists, and do you have even one specific situation that demonstrate the problem? --B2C 19:47, 27 November 2013 (UTC)

Record of Technical Moves

I came back to check on the progress of some technical moves I requested and I don't see them listed and I can't find an archive or log of any changes. I was working on a mass, manual revert project and I don't recall the page names. I assume you could say that if they are no longer listed, I can consider them done. But, I don't know, I might not have filed the notice correctly so I'd like to double check.

Where can I find this information listed? They were reverts of pages that were mistakenly moved and had to be moved back over a redirect. Thanks for your help. Liz Read! Talk! 01:51, 19 November 2013 (UTC)

@Liz: Hey Liz. You have to either remember what it was or search your contribution history, or in this case, look for yourself in the history of WP:RMTR. It's very easy to do so using the external tool linked at the top of any page history under the title "User edits" From that I located this edit by you. Cheers.--Fuhghettaboutit (talk) 13:44, 3 December 2013 (UTC)
@Liz: The above link was for a 4 September 2013 edit. I'll assume you were looking for more recent edits. I prefer an internal search to that external tool. Click on "Contributions" in the upper right corner of your browser window. Here we have a search of your last 500 contributions to Wikipedia namespace (use the drop-down menu), dating back to 27 September 2013 (you can go back even farther to find that Sept. 4 edit by directly increasing the "limit=500" number in the URL). Searching that for "requested" with the web browser's "find" tool finds two 18 November 2013 edits: (1)(2). From there you can look at the page histories to see that all four requests were completed. – Wbm1058 (talk) 16:46, 3 December 2013 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Requested_moves/Archive_25&oldid=1182862962"