Jump to content

Wikipedia talk:Requested moves: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Y256 (talk | contribs)
Line 386: Line 386:
:If both sides make valid arguments why not just close as no consensus but still go with the majority? Surely, democracy has some benefits? [[User:Yaniv256|&rarr;Yaniv256]]<sup> [[User_talk:Yaniv256|wind]]</sup><sub> [[Special:Contributions/Yaniv256|roads]]</sub> 14:35, 23 August 2012 (UTC)
:If both sides make valid arguments why not just close as no consensus but still go with the majority? Surely, democracy has some benefits? [[User:Yaniv256|&rarr;Yaniv256]]<sup> [[User_talk:Yaniv256|wind]]</sup><sub> [[Special:Contributions/Yaniv256|roads]]</sub> 14:35, 23 August 2012 (UTC)
:: As [[WP:NOTDEMOCRACY|Wikipedia is not a democracy]].--<small>[[User:JohnBlackburne|JohnBlackburne]]</small><sup>[[User_talk:JohnBlackburne|words]]</sup><sub style="margin-left:-2.0ex;">[[Special:Contributions/JohnBlackburne|deeds]]</sub> 14:50, 23 August 2012 (UTC)
:: As [[WP:NOTDEMOCRACY|Wikipedia is not a democracy]].--<small>[[User:JohnBlackburne|JohnBlackburne]]</small><sup>[[User_talk:JohnBlackburne|words]]</sup><sub style="margin-left:-2.0ex;">[[Special:Contributions/JohnBlackburne|deeds]]</sub> 14:50, 23 August 2012 (UTC)
:::Quote:{{Quote|''It seems to me you are reading into the text something that is not really there, or that you are stretching WP:NOTDEMOCRACY into an extreme interpretation that forces is to clash with WP:NOTBUREAUCRACY. In real life debate does not always converge to consensus and decisions still have to be made. If we leave them completely to specialized experts that is a bureaucracy. If we leave them to vote counting that is a democracy. If we want to avoid both we have to pick some middle ground.''| Yaniv256|Yesterday}} And please try to avoid oneliners and over linking policy to experienced editors, as both are commonly seen as rude, in particular on top of that distinct touch of [[WP:HOUND]] fragrance to your interest here.[[User:Yaniv256|&rarr;Yaniv256]]<sup> [[User_talk:Yaniv256|wind]]</sup><sub> [[Special:Contributions/Yaniv256|roads]]</sub> 15:58, 23 August 2012 (UTC)


== RMCD bot Approved for trial ==
== RMCD bot Approved for trial ==

Revision as of 15:58, 23 August 2012


managing repeated "no consensus" decisions

I think the section on Determining Consensus currently is biased towards the status quo too much. It says:

lack of consensus among participants along with no clear indication from policy and conventions normally means that no change happens

and

if the closer feels that no consensus has been reached, they may move the article back to the most recent stable name

This is normally fine for a proposal that has never been made before, but if we're getting repeated proposal all ending in "no consensus", I suggest closers do often take more latitude, and this should be encouraged. The current wording discourages this.

In particular, in a case where a give move request has been made repeatedly, and each time ending with "no consensus", I don't think the closer needs to have "clear indication from policy and conventions" on which way to go. After all, if there was clear indication, there would probably be local consensus in support of that.

Further, I've seen many cases where those supporting the status quo can muster just enough opposition to each proposal to move away from that name to make it appear there is no consensus, but never enough to show clear support for the status quo name. With such a history, I don't think it makes sense to favor "the most recent stable name". Or, in other words, with such a history, a title which repeatedly cannot establish consensus support is arguably not a stable name. In such cases I suggest the guidance should encourage the closer to consider whether there is good policy reason to find consensus in favor of the proposed title, even without such indication necessarily being "clear".

The most blatant example of the problem I'm talking about has to be yogurt (yoghurt), in which there were eight RM discussion over nine years, all ending in "no consensus", until the article was finally moved and where it now sits clearly stable. Also there were repeated "no consensus" discussions at Cork (city) until it was finally unilaterally moved by an admin, and has been stable ever since. Jerusalem Day (Yom Yerushalayim) is another example. Also HO scale (H0 scale).

So, what I'm proposing is that specifically when there is a history of "no consensus" results for previous attempts to move a given article, that the current title be given less weight as "stable".

Specifically, I'd like to change this paragraph:

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.

to (splitting the existing paragraph into two and adding the third):

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.

Also, in cases where there is a history of repeated move proposals and discussions all ending in "no consensus", the current title should not be given the normal "stable" consideration, and the decision should be made accordingly. In other words, if this is the first proposal to move A → B, then clear indication of consensus is needed to move it. But the more previous proposals there have been that ended in "no consensus", then the consensus to keep the current title becomes more and more questionable, and consensus in favor of the move does not need to be as clear. After 2 or 3 "no consensus" results, it's probably a good idea to try the proposed title instead of keeping the existing title. Sometimes you can't determine what consensus really supports until the article sits at each title for a while.

Objections? Comments? Suggestions? --Born2cycle (talk) 01:48, 14 July 2012 (UTC)[reply]

  • It's the objective WP:RETAIN that needs respect, not the subjective "recent stable version". WP:RETAIN, like WP:ENGVAR, gives weight to original article writers, which is a good thing. --SmokeyJoe (talk) 02:23, 14 July 2012 (UTC)[reply]
I find this proposed language in B2C’s comment above Also, in cases where there is a history of repeated move proposals and discussions all ending in "no consensus", the current title should not be given the normal "stable" consideration, and the decision should be made accordingly. In other words, if this is the first proposal to move A → B, then clear indication of consensus is needed to move it. But the more previous proposals there have been that ended in "no consensus", then the consensus to keep the current title becomes more and more questionable, and consensus in favor of the move does not need to be as clear. After 2 or 3 "no consensus" results, it's probably a good idea to try the proposed title instead of keeping the existing title. Sometimes you can't determine what consensus really supports until the article sits at each title for a while. a bit sophomoric in that it essentially says if we don’t win our first RM, then just keep nominating it and the closer eventually has to discount those who oppose our position and we will win. It is language that is directly designed to accomplish this: [1] and thus would be very bad policy. --Mike Cline (talk) 05:27, 14 July 2012 (UTC)[reply]
Yes, also known as success by exhausting the opposition. olderwiser 05:48, 14 July 2012 (UTC)[reply]
You guys are misunderstanding. There is no evidence in any of those cases that suggests change finally prevailed because the opposition was exhausted. In every case, if the opposition ever had a strong case for retaining the original title, they could have mounted a request to restore the original title after the move. My point is that a history of "no local consensus" RM results often suggests that there is community consensus in favor of the move, and this can only be proven by actually moving the article to the proposed title. If, some time after the move, there is still strong support for moving it back to the original title, then it's truly a "no consensus" case. I'm not saying that's impossible, just that it's rare. Usually, it turns out that the proposed move actually did have consensus support, it was just obscured by the numbers that came out to defend the status quo. I see it time and time again. --Born2cycle (talk) 18:29, 16 July 2012 (UTC)[reply]
On the contrary I think you fundamentaly don't accede to the reality that you can lose a RM decision (based on your position) and that the resulting title is the right title for WP. A no consensus decision, whatever the rationale, is consistent with typical outcomes of RM discussions. That's part and parcel of the process. I don't think it is prudent to essentially say,Well when I lose an RM discussion to no consensus decision, we need to change the process to ensure I win. I suspect, and this can only a suspicion, that if you were on the winning side of an no consensus decision you would vehemently oppose any process modification that artbitrary put you on the losing side. If you are unsatisfied with the breath and depth of community consensus in a typical RM, then propose universal changes to the process that ensure all RMs (original and subsequent) generate the necessary consensus to represent the communities' position on the title. But, the idea that if I don't get my way, we to change the process so I do get my way is a non-starter. --Mike Cline (talk) 03:00, 17 July 2012 (UTC)[reply]
Please, Mike, try to be objective.

You're not distinguishing titles which have a history of repeated discussions all ending in "no consensus" with titles that don't have such a history. I'm talking only about the former, and proposing this only for those situations. Is that not clear from the proposed wording?

I'm baffled as to how you interpret a proposal to make an objective change to the process that has nothing to do with me winning or losing anything as, if I don't get my way, we [need] to change the process so I do get my way. Of course, this proposal to reduce bias that favors the status quo would apply equally in situations where I might favor the status quo. I understand that, and I still think adopting this change would improve WP - because I believe it would help us find true community-wide consensus sooner in more situations than not. --Born2cycle (talk) 20:58, 22 July 2012 (UTC)[reply]

How about if we at least decide to temporarily remove move-protection following a no consensus RM in the hope that a consensus may emerge that way? If that option was discussed in the past, as it must have been, I would appreciate the links to the key discussions. No concesus status que bias is a problem as it leads to bad names lasting for years and years. For the benefit of the project we must do something about it. →Yaniv256 talk contribs 05:46, 14 August 2012 (UTC)[reply]

Why not follow WP:RETAIN. --SmokeyJoe (talk) 09:12, 14 August 2012 (UTC)[reply]
I fail to see how the variety of English in use, i.e. American vs. British, is of much relevance to the discussion, but perhaps if you could offer more than one sentence I will be enlightened. →Yaniv256 talk contribs 15:46, 14 August 2012 (UTC)[reply]
I had forgotten that not all page-move long-running disputes are not dialect-based (most of them are). The principle of WP:RETAIN is that:

(from WP:RETAIN) When no [page name] has been established [as the default] and discussion cannot resolve the issue, the [page name] used in the first non-stub revision is considered the default

Why not use this principle wherever a page move request results in, and remains in, "no consensus"? It is a definitive tie-breaker, and non-arbitrary. It gives weight to original page-writers, which I think most would agree is a good thing. It is also a decision not locked in stone. A future discussion can always discover a new consensus based on new information or new reasoning. --SmokeyJoe (talk) 22:58, 14 August 2012 (UTC)[reply]
That also has the added plus of being consistent with Afd, where a no consensus results in a keep. Consistency in procedures across wp is a plus. KillerChihuahua?!? 23:03, 14 August 2012 (UTC)[reply]
How does that address the case where the repeated no consensus discussions are to overturn a previous move? Does the no consensus need to close as supporting the last move? Also one point on no consensus decisions. Consensus is in the eye of the reader. All to often there is no consensus and we have ~vote counting. Those on compounded by NAC decisions. Vegaswikian (talk) 23:17, 14 August 2012 (UTC)[reply]
Repeated “no consensus” should see the page moved back to its first non-stub title. The first “no consensus” decision should see the page moved back to its first non-stub title. Anything else encourages the bold page move as the first step of a WP:GAME.

Consensus, where not obvious, is the decision of the closing admin. NAC closes should be reverted where opposed, and reclosed by an admin. Contested admin closes should be sent to WP:Move review.

The only problem I see is where there is a consensus that the original non-stub title is inappropriate, but disagreement on what to move it to. Only in such as case should the admin feel that a “no consensus” close should be avoided, and where the case is closely contested, it should be sent to an RfC. However, I’m not aware of any such examples. --SmokeyJoe (talk) 23:34, 14 August 2012 (UTC)[reply]

This is actually an opportunity rather then an obstacle. Why don't we try to make policy only for the cases where wp:retain does not apply, because it is not a matter of English variety, and use it as a testing ground, postponing any reform of wp:retain to a later date when we are wiser about the outcomes generated by the policy innovation in non-wp:retain RMs. →Yaniv256 talk contribs 23:44, 14 August 2012 (UTC)[reply]

Can you point to any examples where "When no [page name] has been established [as the default] and discussion cannot resolve the issue, the [page name] used in the first non-stub revision is considered the default" could not, or should not, apply? --SmokeyJoe (talk) 23:50, 14 August 2012 (UTC)[reply]
I got it now. SmokyJoe, your use of square brackets to indicate where you changed the quote from the original to your novel policy suggestion was not clear to me, but I'll take the blame for that. So as I understand you now, you suggest that we take the policy motivated by the statement

"In general, disputes over which English variety to use in an article are strongly discouraged. Such debates waste time and engender controversy, mostly without accomplishing anything positive."

and stretch it all the way to situations where the name of an article could literally be a matter of life and death? I find the idea ill-advised, to say the least. Wikipedia is not a game anymore. →Yaniv256 talk contribs 00:16, 15 August 2012 (UTC)[reply]
The line that I quoted, stretched to apply to any page name whether ENGVAR or not, is the pseudo policy that is already applied by default. The principle is: If there is no consensus to move, you may not move; applicable retrospectively.
You wrote: “Situations where the name of an article could literally be a matter of life and death?”
Surely, such a case would be readily resolvable by discussion? Or are you seeking a formula that resolves life-and-death matters without discussion? Note that the WP:RETAIN line relies on “discussion cannot resolve the issue” as a premise.
Again, do you know of any examples where this could be a problem? Can you think of any? You reference to “life and death” suggests a BLP concern. Why would WP:BLP not be the applicable policy?
I see that you are currently upset by the RM close at 2007–2012 global financial crisis. The WP:RETAIN principle would see the “no consensus” close send the page back to Financial crisis of 2007-2008 (which I believe Fred Bauder chose, 19:11, 17 September 2008) unless there were a consensus against that title.
Also see Hard cases make bad law. The WP:RETAIN principle works well for the majority of pedestrian cases, such as yoghurt. --SmokeyJoe (talk) 01:23, 15 August 2012 (UTC)[reply]


My answer turned out to be rather long so please read it only when you have the leisure not to rush through. Look SJ, you asked me to give an example of a life and death name choice problem, but any such example I will bring would paint me as a drama queen, and derail the search for consensus by marking me as a problem editor. You do not mean to do that, I know, you did not consider that, but that would be the result. It is quite easy to think of ways in which a non-BLP, non-EngVar name discussion may turn out to be life of death for someone which is not a Wikipedia editor. But whether I can or can not come up with a reasonable example is irrelevant for three reasons.

The first is that my argument does not rest on the fact that it is life or death, only on the fact that it matters. Say that it matters, but only because someone loses their job. Will you be happy then with a policy that may yield arbitrarily senseless results?

The second reason is that when formulating policy we need to be forward looking and not backward looking. The question is not whether it has been a life or death decision in the past, but whether it may come to that in the future. And with the current status of Wikipedia I find a no answer to that one a complete non-starter.

The third reason is that as a matter of common sense, making policy on the basis of the assumption that results don't really make any difference is sensible only if you are absolutely positive that this is indeed the case. Otherwise, it is just not a prescription for good policy. Now, with EngVar cases I happen to share that perception with the authors of wp:retain. Indeed, it is hard for me to imagine anything other than the quality of service we provide hanging in the balance, and in the grand scheme of things that is not very important. However other than EngVar issues and stuff like San Francisco vs. San Francisco, California, I find it hard to imagine cases where the decision would not have some real world effects that we should take into considerationsee comment.

Bottom line: Time to grow up. Wikipedia is not our private sandbox anymore, our decisions have major implications outside of Wikipedia and it is (sometimessee comment) childish not to take these into account. Any policy that is inconsistent with that will get revised. Ideally, we will do so internally. Subpar, we will continue to do so only when forced by media pressure, BLP obvious case in point.

Last, in the overwhelming tradition of Wikipedia, every discussion must get ad hominen at some point, me. I have lost any interest in the future of the financial crisis page. It may be hard to believe that I will let go after working so hard, but it is exactly because I feel I did my duty there that I am free to move on. Others may follow or not, it is no business of mine any longer. The fact is that I joined Wikipedia not long ago to fix something really small, but every small thing I try to fix reveals a bigger problem. Unfortunately, my summer vacation will soon end and these happy days will have to be cut short. I just hope to beat some sense into you guys before that happens. And even though nobody asked, let me just get something out of the way. I am interested in policy reform but will never, ever, ever run for admin, even if they cancel the abomination of lifetime appointments, and beg me with puppy eyes, and I am under no impression anyone will ever ask. Has the ad hominen quota been filled? Would you mind if we make a commitment to talk about issues from now on?

While this post was too long, I hope it was not too boring and thank you for taking the time to read it. →Yaniv256 talk contribs 03:12, 15 August 2012 (UTC)[reply]

I should add one comment though. Unless real world effect are clear, such as in "pink slime" for example, we should not make any attempt to incorporate them into our decision making. Our best guide in that mine field of impossible computation is to pick a policy that maximizes the probability of finding the best encyclopedic name, as fast as possible, and provides stability thereafter. We are not to engage in speculation. Our focus should remain, as it was always, on professionalism and producing the best product we can deliver. My above rant should be read as a plea that we take that job seriously and avoid policy that may result in arbitrarily bad choices. That said, the title of an article is less important, in most cases, in my view, than its content, so some perspective is in order, and was lacking in my previous post. →Yaniv256 talk contribs 17:06, 15 August 2012 (UTC)[reply]

"No two consecutive no-consensus closes"

Another alternative I would like to put forward is that we set a rule suggesting that "no two consecutive no-consensus closes" should take place in the context of RMs. →Yaniv256 talk contribs 15:54, 14 August 2012 (UTC)[reply]

That's lovely in concept, but in application may prove impossible every now and again. I am concerned this may lead to an admin being forced to make an arbitrary decision merely to satisfy this directive and not because there is any consensus at all. I suggest instead phrasing be added to encourage avoidance of consecutive no consensus closes, if possible, or say nothing at all about it. KillerChihuahua?!? 22:55, 14 August 2012 (UTC)[reply]
I have no objection to a soft guidance in this vain. If fact, I think it is better than my suggestion in that it would do a better job at facilitating only these moves that are warranted in the sense that they would prove to be stable once executed. I expect it should be able to address the problem with a significant measure of surgical precision, i.e. with very little risk of unforeseen complications. →Yaniv256 talk contribs 23:30, 14 August 2012 (UTC)[reply]
Trying to retain the catch phrase factor, how about "Few two consecutive no-consensus closes"? It's kind of a teeth breaker, but I am not sure that it is such a bad thing. Quoting policy should have some price. →Yaniv256 talk contribs 23:53, 14 August 2012 (UTC)[reply]
And people will refer to it as FTCNCC anyway so what does it matter that it is impossible to pronounce. →Yaniv256 talk contribs 03:21, 15 August 2012 (UTC)[reply]
ARN might be better... shorter to type anyway. Avoid Repeat No-consensus (if possible.) But I still think that's fine-tuning too much. If it is nc, then (1st) back to first non-stub title, or if 2nd time thru and/or current name has had long term broad general support, then leave where it is, per RETAIN. I think this is being a bit too prescriptive and rules-creepy. KillerChihuahua?!? 17:10, 15 August 2012 (UTC)[reply]
Thanks, I agree. ARN is better. What you said afterwards was a bit too logically intricate for me to be sure I understood what you wanted to say. Would you mind tuning it down for me? →Yaniv256 talk contribs 17:27, 15 August 2012 (UTC)[reply]
Apologies, I didn't mean to be oblique. I'll try: More rules is bad, because confusing, too hard to follow, no room for common sense. Less rules is good because easier to know rules, follow them, use common sense. See WP:CREEP This is one too many rules, and addressing a problem which doesn't often exist, and when it does it is really already covered by current rules (RETAIN). When it does, deal with it one at a time. But like I said, if you're going to have it, make sure it has room for sense, doesn't contradict current rules, and is short to type. One puppy's opinion. KillerChihuahua?!? 17:33, 15 August 2012 (UTC)[reply]
I fully agree, expect for the part about stretching wp:retain to non-EngVar articles, where I believe a policy has been formed in practice. It was just so shameful that no one had the nerve to try and actually check if such a thing can muster a consensus, and put it into writing. Or, as an alternative, that the actual policy creep that we have seen, in fact never had a consensus, and had been growing in our back yard like a common weed. →Yaniv256 talk contribs 04:52, 16 August 2012 (UTC)[reply]
I'll be a bit blut now. In my Econ PhD class a reference to the "2007-2012 global financial crisis" is code for what a joke. And everyone knows what are you talking about. Could that be good for Wikipedia? →Yaniv256 talkcontribs 05:06, 16 August 2012 (UTC)[reply]

This entire discussion is somewhat problematic when view in light of WP:RMCI. There are only two alternatives when closing an RM. The article is moved to a new title or it is Not Moved to a new title. Whenever a title is moved, the assumption is that the closing admin judged that consensus and policy supported the move. Whenever a title is not moved, the assumption is that the closing admin judged consensus and policy did not support the move whether there was overwhelming or split opposition. Closing admins are not required to explicitly discuss their closing rationale, but merely required to document the move or not moved decision. The fact that many RMs are closed as Not Moved based on a balance of supports/opposes (especially when policy can be claimed by both sides) does not make them a special case as this thread suggests. And trying to end-run these types of decisions with a default policy is not good business. --Mike Cline (talk) 16:52, 16 August 2012 (UTC)[reply]

Exactly. It's creepy. KillerChihuahua?!? 17:57, 16 August 2012 (UTC)[reply]
This is very much instruction creep. -DJSasso (talk) 18:03, 16 August 2012 (UTC)[reply]
Mike, just to see if I understand your line of argument, would you then mind if we add in guidance that suggests that when support and oppose are more or less balanced then a move or not move close should be an equally likely result? For example, a closer that finds herself faced with balanced arguments for both sides may cite a flip of a coin as a valid tie-breaker, or decide on the outcome by whether the S&P 500 closed up (move) or down (don't move) on the last Friday, if that meets her personal taste?
And anyone who wishes to cite wp:creep here any further should consider that doing so would eventually get me to conclude that wp:creep is blocking the way of reform and switch to that talk page to deal with that bigger problem, and whether that might end up causing more damage to the status quo that they seem to hold so dear. →Yaniv256 talk contribs 18:37, 16 August 2012 (UTC)[reply]
It has nothing to do with status quo, it is that there is no problem here to be solved by this. Creating rules for the sake of rules often leads to more issues because situations become more rigid and less flexible. (for example you talk about telling people to just use a flip of the coin or whatever when things are equal. That is far more likely to cause extensive drama and thus harm the wiki than leaving a page at its current location because of a couple of no-consensus closes.) If there was a big problem where lots of articles keep hitting no-consensus over and over again then I could see the point where this could be helpful, but as it stands it very very rarely is an issue. A RfM is a consensus building discussion not a vote so its not a case of 50+1. Consensus is usually considered to be close to a 65% when people are talking numbers, but as everyone is aware its not about numbers but weight of arguments. So really to sum it up, there really isn't much to reform here because there isn't a problem here. -DJSasso (talk) 19:11, 16 August 2012 (UTC)[reply]
I did not mean to suggest coin flips. I think coin flips are ridicules and was using that to point to a flaw in Mike's argument. If when things are balanced we should be indifferent, then we might as well chose move instead of don't move. But since doing that always is just as biased as choosing don't move always I claimed that if what Mike had suggested was true and there was no systemic bias in the system as it is, then the state of affairs should not be changed by switching to coin flips.
Now clearly I do think that the current system has systemic bias and was trying to ask Mike to acknowledge that. His objection comes from a place that uses sterile theory to overlook reality. You, DJSasso, on the other hand admit the systemic bias, you just don't think it is important enough to justify the cost of having another rule to fix it. That is a different objection, that is argued from a place of personal experience. It is of course valid in my mind, even though what I have seen is different. I only ask you to consider that the fact that you never seen a black swan does not mean that they do not exist or are not important. Especially if I can point to two high profile ones at a blink of an eye.
→Yaniv256 talk contribs 03:29, 17 August 2012 (UTC)[reply]
At any rate, I am tired of trying to convince you guys, when it is obvious you are quite set in your positions, and I am dropping the stick. A round of applause please for consensus building: another glorious day put to waste. →Yaniv256 talk contribs 03:34, 17 August 2012 (UTC)[reply]

RM Bot not working

What's the deal?

Something wrong with the RM bot? I haven't seen a new listing in almost a day. Is it possible that we've finally reached perfection in article titling across all of WP? Oh, what a glorious day! Dohn joe (talk) 16:17, 19 July 2012 (UTC)[reply]

Nope, unfortunately not, I made a request yesterday which still hasn't been posted up. My post on the talk page (Talk:Replica Titanic) was modified by a bot though - is that RM bot at work? Bit worried I've crashed the bot somehow, I do seem to have the kiss of death with these things :) MatthewHaywood (talk) 16:36, 19 July 2012 (UTC)[reply]
Don't think it was you. I've notified the bot operator about the issue, so we'll see what they say. Dohn joe (talk) 16:45, 19 July 2012 (UTC)[reply]
Thanks, I'll keep an eye on it. MatthewHaywood (talk) 16:54, 19 July 2012 (UTC)[reply]
I came here to ask the same question. The most recent move request to show up on the page is now some 40 hours old. Nothing at all from yesterday or today, including a move request I posted to the article talk page yesterday morning. -- chris_j_wood (talk) 09:44, 20 July 2012 (UTC)[reply]
I've added a note to /Current discussions to let the great unwashed know. Interplanet Janet, Esquire IANAL 16:15, 20 July 2012 (UTC)[reply]


I've tried to find the request which has stopped the bot working, but haven't had any luck. The user running the bot, HardBoiledEggs has been inactive for months, although we've tried to contact them on their talk page. There's a notice here Wikipedia:Administrators' noticeboard/Incidents#RM bot inactive, but it doesn't seem to have attracted any help. User:Wbm1058 has been going over it, but doesn't seem to have had any more success than I have yet. Does anyone here know much about RM bot? MatthewHaywood (talk) 21:53, 20 July 2012 (UTC)[reply]

I've added a notice at Wikipedia:Village_pump_(technical)#RM_bot_inactive. MatthewHaywood (talk) 22:56, 20 July 2012 (UTC)[reply]
If this continues for another few days, we may have to temporarily go back to a manually updated page.--Aervanath (talk) 17:04, 22 July 2012 (UTC)[reply]
You mean manually sorting through CAT:RM? Don't envy that job... It has been suggested at WP:VPT that as the source code to the bot is available, someone else could take it over. Does anyone here have the technical expertise? MatthewHaywood (talk) 20:23, 22 July 2012 (UTC)[reply]
Caveat geek! The code at User:RM bot/requestedmoves.php is Harej's old version, vintage January 1, 2010. I think HBE has made several changes since then. I don't speak PHP (be it ever so part Danish), so I will abstain from volunteering. Favonian (talk) 21:08, 22 July 2012 (UTC)[reply]
Oh strewth, this really is a foul up. Is there really no-one here with any idea how to sort this? MatthewHaywood (talk) 01:27, 23 July 2012 (UTC)[reply]
Is the code somewhere? I can make suggestions, but my PHP is rusty. -- 76.65.131.160 (talk) 08:55, 23 July 2012 (UTC)[reply]
FYI, the VP thread was archived to Wikipedia:Village_pump_(technical)/Archive_101 -- 76.65.131.160 (talk) 07:43, 5 August 2012 (UTC)[reply]
FWIW, the ANI thread was archived to Wikipedia:Administrators' noticeboard/IncidentArchive761 -- 76.65.131.160 (talk) 09:21, 30 July 2012 (UTC)[reply]

I have closed the discussion on 18 July 2012 Damascus bombing as it is the last move to be processed by RM bot, and is suspected to have interfered with the bot due to its being moved during the RM process. The discussion can be reopened in due course of there is no effect on the bot. MatthewHaywood (talk) 21:16, 22 July 2012 (UTC)[reply]

Seemed like a good theory, but it didn't work. --Born2cycle (talk) 04:04, 23 July 2012 (UTC)[reply]
I found this edit 21:42, 21 June 2012‎ RM bot (talk | contribs)‎ . for Wikipedia:Requested moves (edit | talk | history | links | watch | logs) that is not documented in the contribution list for RMbot... that doesn't seem to make sense. -- 76.65.131.160 (talk) 09:03, 23 July 2012 (UTC)[reply]

I've added a query at BOTREQ since VPtechnical doesn't seem to be coming up with solutions yet. -- 76.65.131.160 (talk) 08:59, 23 July 2012 (UTC)[reply]

The request has been archived to Wikipedia:Bot_requests/Archive_49 -- 76.65.131.160 (talk) 09:18, 30 July 2012 (UTC)[reply]

I mentioned it in the upcoming issue of The Signpost. Guess we'll see what happens. Marcus Qwertyus 22:52, 23 July 2012 (UTC)[reply]

Manual updates?

I think updating WP:RM manually might just mess things up even more.

What we can see from the history of RM bot is that it stopped editing at 9:30 July 18, 2012. See: Special:Contributions/RM_bot.

Does anyone know what is supposed to trigger the RM bot to run? --Born2cycle (talk) 06:31, 23 July 2012 (UTC)[reply]

The move and redirect at [2] probably blew its little mind. Dicklyon (talk) 06:50, 23 July 2012 (UTC)[reply]
So what sorted it out? Surely it wasn't my closing the 18_July_2012_Damascus_bombing request? That's way too simple! MatthewHaywood (talk) 09:22, 23 July 2012 (UTC)[reply]
It's not sorted - User:P.T. Aufrette did some manual updating, that's all. RM bot is still AWOL. Interplanet Janet, Esquire IANAL 12:00, 23 July 2012 (UTC)[reply]
My mistake. MatthewHaywood (talk) 12:17, 23 July 2012 (UTC)[reply]
I don't see how manually updating could be worse than the non-updating we have now. We would have to change the instructions on the move templates so that people requesting moves would leave a note on WP:RM that they had initiated a move discussion. This is how we did it before the bot. Another alternative: create dated subcategories of CAT:RM, and change Template:Requested move so that it adds the talk page to the appropriate subcat.
However, both of those options are inferior to having the bot do all this for us; but if there is no progress on the bot front, we will have do SOMETHING.—Aervanath (talk) 13:34, 23 July 2012 (UTC)[reply]
IMO, from a computing perspective, manual updates should not be able to mess things up at all. I assume that before the bot was written, these things were manually maintained (with appropriate instructions on the move templates). -- JHunterJ (talk) 13:48, 23 July 2012 (UTC)[reply]
I don't know enough about the specifics about how the bot works, but I do know it has evolved over time, and everything is much more automated than it used to be. That means it's likely the bot is dependent on certain things being done a certain way, that we could mess up manually.

I also think manual updates make the situation more difficult to trouble shoot. Note that MatthewHaywood was already confused into thinking the situation had been resolved. I think it takes pressure off fixing the real problem (the bot), and perpetuates the situation.

One thing we desperately need is documentation of how the bot works. If there is any, I can't find it. Though I'm not a PHP programmer, I can read the PHP code, and make sense of much of it. But there are a few key missing pieces. It includes some files - where are they? It generates some output - where does that go? What causes it to run in the first place? It might be as simple as something or someone turned off the scheduling of the bot runs for some reason, and all we need to do is turn it back on. --Born2cycle (talk) 17:56, 23 July 2012 (UTC)[reply]

Agreed that documentation on the bot would be useful. But I'm with Aervanath on not waiting -- I don't think there's a risk of "taking pressure off fixing the real problem" -- the real real problem (IMO) is that the process evolved to the point where the undocumented bot processing got so good as to seem indispensable. -- JHunterJ (talk) 19:27, 23 July 2012 (UTC)[reply]
If it was properly documented so we could rely on it and figure out how to quickly fix it when there is a problem, it would be okay for it to be indispensable. In my lifetime cars have changed from things you can work on yourself to things you can't. So it is with RM processing, LOL. --Born2cycle (talk) 19:38, 23 July 2012 (UTC)[reply]
Agreed, and in the absence of that proper documentation the other recourse is to make it dispensable again. By manual updates. If and when the documentation is properized, we can again cease the manual updates. -- JHunterJ (talk) 16:33, 24 July 2012 (UTC)[reply]

Manual removal

I'd like to start by saying what a great job the manual updater(s) have done with the page - that work is much appreciated. I was wondering, though, about removing discussions from the page once they're closed. I'd be happy to help, if someone pointed me where to go. Maybe the closers could add that to the list of closing tasks until the bot returns? Thanks. Dohn joe (talk) 21:04, 26 July 2012 (UTC)[reply]

Thanks! Most of the Backlog are still open. I've been removing them from the list periodically, so there may be just a few on the list which have been closed—most have not! Those editors who normally close out these discussions are encouraged to continue to do so as they normally would to clear the backlog.—Wbm1058 (talk) 11:53, 27 July 2012 (UTC)[reply]

RMBot is officially dead

HardBoiledEggs hasn't edited since February, and I believe his TS account expired. The source is available at User:RM bot/requestedmoves.php. Can someone else compile it and set up a bot at least temporarily to update the backlog? --Nathan2055talk - contribs 19:52, 3 August 2012 (UTC)[reply]

I would suggest pinging WP:Bot requests. --Izno (talk) 21:01, 3 August 2012 (UTC)[reply]
Wikipedia:Bot_requests#Need_new_operator_for_User:RM_bot--Aervanath (talk) 14:51, 4 August 2012 (UTC)[reply]
New bot request at Wikipedia:Bots/Requests for approval/RMCD bot -- 76.65.131.160 (talk) 07:40, 5 August 2012 (UTC)[reply]
RMCD bot (talk · contribs) -- 76.65.128.252 (talk) 04:36, 14 August 2012 (UTC)[reply]

Closure

How and when will such a discussion be closed?--sicaspi (talk) 22:07, 23 July 2012 (UTC)[reply]

 Done Aervanath (talk) 23:13, 23 July 2012 (UTC)[reply]

Anyone fancy taking a look at Talk:S/2012 P 1#Requested move? 46.126.76.193 (talk) 20:25, 2 August 2012 (UTC)[reply]

Can I please second that request? Please put this out of its misery, particularly as public interest in the article's subject is higher now and will be dropping away. hamiltonstone (talk) 07:24, 4 August 2012 (UTC)[reply]
 Done by Jenks24.--Aervanath (talk) 14:50, 4 August 2012 (UTC)[reply]

Hello all. I think I need some help. Please see User talk:Bananas Monkey#Please stop all page moves. I don't think I've scratched the surface of all of this user's incorrect page moves (move log). I've spent over an hour cleaning up just a bunch from the front end of his contributions but there are many more. I don't know that they're all wrong, but just about everything I looked at was.--Fuhghettaboutit (talk) 00:56, 2 August 2012 (UTC)[reply]

Closure of talk page entries for a multi-move request?

When a multi-move request is approved, should a bot be closing the entries that were placed on all of the talk pages? Cf. Omega1 Aquarii. Just curious; it seems odd to leave inquiry messages dangling out there. Regards, RJH (talk) 22:21, 11 August 2012 (UTC)[reply]

Nah, I think most people who see them will look at the timestamp and realise the RM has probably been closed by now. Jenks24 (talk) 23:15, 11 August 2012 (UTC)[reply]
If we can get the damn bot ever working again, I think it's not a bad idea that it leaves a terse note like:
Automated note: the discussion has been closed.--User:RM bot 12:00, 10 January 2036 (UTC)[reply]
This is what I did in the past before we ever had a bot, and do now that we're manually updating. I don't think it's a pressing issue though.--Fuhghettaboutit (talk) 00:48, 15 August 2012 (UTC)[reply]

Please try to add one step to your closing checklist for the moment

We're doing okay so far manually updating (anyone have any update on if there's any movement on the getting-the-bot-working front?) I dropped a barnstar earlier today at User:P.T. Aufrette's talk page as he/she seems to be most responsible for listing new RM discussions here from the category. Anyway, for the past week or so I've been periodically removing all the closed discussions and given the quantity, it's clear a number of closers have not added this to their procedures or don't know what to do. It would be great if everyone who does closes would add this step to their normal closing routine until the bot is fixed. Very simply, step-by-step (and most of you will say duh, but...), after you perform a close:

  1. Copy the name of the page (highlight then ctrl/cmd+c);
  2. Go to Wikipedia:Requested moves/Current discussions and click edit this page;
  3. Use your computer's find function (ctrl/cmd+f; paste the text you copied ctrl/cmd+v, then hit enter/return;
  4. Remove the entire entry you just found and leave one line between the discussion above and below;
  5. You might use an edit summary such as "remove 1, now closed";
  6. Save the page.

Best regards to all.--Fuhghettaboutit (talk) 01:07, 15 August 2012 (UTC)[reply]

Action at WP:ANI concerning an irregular move proposal

Just a quick notification, colleagues: I have initiated an action at WP:ANI, concerning an unadvertised move proposal for Men's rights – a highly controversial article that had already been through a failed RM. Many will consider it quite irregular. But we'll see, right?
NoeticaTea? 12:57, 15 August 2012 (UTC)[reply]

You've seen, I trust. . dave souza, talk 20:55, 16 August 2012 (UTC)[reply]

RM contradicted by Article title policy

RM states "In some situations, the appropriateness of a move may be under dispute, and discussion is necessary in order to reach a consensus. It is not always necessary to formally request a move in these circumstances: you can start an informal discussion at the article's talk page instead." In the case discussed above, talk page discussion was advertised via an RfC, it was taken to ANi which concluded that ""An appropriate mechanism (RfC) was used, a clear consensus for move was achieved". Forcing all potentially contentious moves through RM rather than getting them resolved on article talk pages is, in my view, an unnecessary increase in bureaucracy. Please discuss at WT:AT#RM not required. . . dave souza, talk 20:55, 16 August 2012 (UTC)[reply]

It's not about all potentially controversial moves, but about moves known to be controversial based on a previous RM discussion, and an apparent intentional procedure to avoid RM as a way to get the result. Dicklyon (talk) 21:12, 16 August 2012 (UTC)[reply]
For clarification, AT policy states:

Any potentially controversial proposal to change a title should be advertised at Wikipedia:Requested moves, and consensus reached before any change is made. Debating controversial titles is often unproductive, and there are many other ways to help improve Wikipedia.

That says "Any", not just moves known to be controversial from previous RM discussion. Wikipedia:Assume good faith is a useful guideline. . . dave souza, talk 21:24, 16 August 2012 (UTC)[reply]
True. But I thought we were particularly discussing "the case discussed above", which is what my comments were about. Dicklyon (talk) 06:18, 17 August 2012 (UTC)[reply]
Ah, sorry for misunderstanding. The "case discussed above" established the principle that RfC is an appropriate mechanism for getting community consensus. We can recommend RM as having advantages, but not insist it is the only mechanism.
At WT:AT#Proposal for considering uncontroversial title changes there's suggested wording for bringing that into line with the RM page, and incorporating the suggestion that if editors "believe the move might be controversial, consider using the {{movenotice}} template" from WP:MOVE. The RM page currently states "It is not always necessary to formally request a move in these circumstances: you can start an informal discussion at the article's talk page instead." Using that template is helpful when starting such discussion, it would be good to bring RM into line with MOVE in suggesting the template. . . dave souza, talk 09:10, 17 August 2012 (UTC)[reply]
The new RMCD bot could always just add {{movenotice}} all the time, and remove it when an RM is closed... (say add a switch to move to indicate that the bot added it, so the bot can remove those instances when the linked discussion no longer has the move template on it) -- 76.65.128.252 (talk) 11:45, 17 August 2012 (UTC)[reply]
You say the case "established the principle that RfC is an appropriate mechanism for getting community consensus". I felt the opposite. There was some fair outrage about how the process circumvented the usual adverising of a controversial move. I think we should be discouraging that, not making like it's OK. Dicklyon (talk) 06:07, 20 August 2012 (UTC)[reply]
I would agree with Dicklyon here. A single decision at ANI does not in anyway establish principals that go against long-standing policies and practice.--Mike Cline (talk) 13:19, 20 August 2012 (UTC)[reply]
Policy and practice are unchanged, the aim in the linked discussion is to make AT clearer. It remains desirable for contentious moves to go through the RM process to get expert attention, and for uncontentious moves to be resolved by informal article talk page discussion. "Should" also remains advisory and not mandatory; as shown by the BBC "should" does not mean "must". . . dave souza, talk 15:42, 20 August 2012 (UTC)[reply]

RMCD Bot and long multiple moves

The new bot doesn't seem to post information notices for multimoves involving more than 9 source/destination pairs. See Talk:List of Dallas (1978 TV series) episodes (season 1) and seasons 10+ listed. -- 76.65.128.252 (talk) 05:58, 20 August 2012 (UTC)[reply]

 Done Bot was pattern-matching just single digits. I fixed it to match one or more digits. Bot test page User:Wbm1058/currentCompareWbm1058 (talk) 04:14, 21 August 2012 (UTC)[reply]

Of probable interest to the editors of this page

Wikipedia:Village_pump_(proposals)#Simplified_move_proposal_process

I didn't see it on this talk page, but I just did a quick scan, if someone has already mentioned this here, please simply delete this post, thanks. KillerChihuahua?!? 21:57, 20 August 2012 (UTC)[reply]

No consensus outcomes

If [an article title] 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.

(from Wikipedia:TITLECHANGES)

The above pertinent wording of Wikipedia:TITLECHANGES is surprisingly old and stable. It was written into policy 19:53, 19 September 2009 by PBS, and modifed 16:37, 22 September 2009 by Pmanderson. --SmokeyJoe (talk) 07:25, 21 August 2012 (UTC)[reply]

  • Jenks24, would you please explain your revert here. No consensus defaults to the status quo was rejected years ago. It seems that this backwater (RCMI) somehow never noticed. Defaulting to the status quo encourages non-productive gaming, as noted years ago. If there is a common sense reason against the first non-stub version, surely it will have been noted in the RM discussion?? If noted and agreed, of course the closer can and should follow consensus. --SmokeyJoe (talk) 12:39, 21 August 2012 (UTC)[reply]
(edit conflict) Hey Joe. Sorry to revert you, but I don't think no consensus closures are as black-and-white your change made it appear to be. Here is a scenario I'm envisaging that's problematic with just the text you added: article is created (as a non-stub) at "A" in 2005, moved to "B" in 2008 and remains there uncontroversially until it's moved without discussion to "C" in 2012. For whatever reason (possibly the redirect gets edited or the editor doesn't know about BRD), a RM is started to move it back. The RM ends as no consensus and no one in the discussion mentions "A" as a viable title. Admins should then have the discretion to move back to "B" if they feel it's appropriate. There are also plenty of cases where, for some reason or another, the first non-stub title is not viable. I don't see why some of the TITLECHANGES text can't be incorporated into the page, but I think admin discretion needs to remain and for first non-stub version to not be the only option. Jenks24 (talk) 12:50, 21 August 2012 (UTC)[reply]
I agree with Jenks24. A no consensus outcome at a single RM discussion should not necessitate going back to the ur-title. olderwiser 12:59, 21 August 2012 (UTC)[reply]
(edit conflict) I think I am in concert with Jenks24 here for the reasons he states, but because overtime consensus on the interpretation of policies, guidelines (especially MOS and naming conventions) may change in a way that renders the first non-stub version to be an improper title. I think admin descretion here is very important because in reality No Consensus is really Split Consensus where there is strong internal consensus among opposing groups of participants. Rarely does that split consensus ever go away unless there's been a major policy change one way or the other. --Mike Cline (talk) 13:01, 21 August 2012 (UTC)[reply]
Have to agree with Jenks here. There are a number of reasons as Mike mentions why going to the first version may be inappropriate. -DJSasso (talk) 13:02, 21 August 2012 (UTC)[reply]

You are all missing the point. It is not for the closer to unanimously decide that the first version was inappropriate. It is for someone in the RM discussion. If the closer can read this in the RM discussion, then he can move beyond the default. Sure, explain this better, but don't you see that there is a problem with no consensus closes that needs development. Also note that the previous version is contrary to policy and the contradiction needs to resolve somehow. Simple reversion is not the way forward. --SmokeyJoe (talk) 13:13, 21 August 2012 (UTC)[reply]

Jenks, black and white was certainly not my intention. --SmokeyJoe (talk) 13:15, 21 August 2012 (UTC)[reply]
I edited again. WP:TITLECHANGES needs mention, but of course admin discretion remains. The first version may be inappropriate. Preferably, for me, the evidence of this will come from the RM discussion. The question I was focused on is: What is the default, the original title, or the recent status quo. Long ago, 2005 or so, it was decided to prefer the original over the status quo, for reasons of reducing edit warring. But the "default" is not mandatory. Default means the one you use when there is not a good reason not to. --SmokeyJoe (talk) 22:48, 21 August 2012 (UTC)[reply]
How about adding "When it is unclear which title is the default, or the default does not have support among discussion participants, the closer is advised to resort to the title that is most widely supported among the discussion participants, and encourage the discussants to continue working towards consensus in a non-combative atmosphere."? →Yaniv256 wind roads 01:19, 22 August 2012 (UTC)[reply]
That would basically ignore the strength of the arguments. Vegaswikian (talk) 01:46, 22 August 2012 (UTC)[reply]
Right. So let's try to balance it evenly: "When it is unclear which title is the default, or the default does not have support among discussion participants, the closer is advised to chose a title factoring in both use evidence and majority view, and encourage the discussants to continue working towards consensus in a non-combative atmosphere."? →Yaniv256 wind roads 02:03, 22 August 2012 (UTC)[reply]

I am extremely uncomfortable with the language that's been created in this section of WP:RMCI [3]. First and foremost, WP article title decisions should be policy based, and reflect community consensus as to what policy interpretation is most appropriate for a given title. Now since our title policy is extremely conflicted and lacks real consensus on disambiguation, primary topics, MOS, diacritics, etc., using the wording in this section to make a title decision is non-sensical. What is and is not a stable title? Unless we define that, how can anyone judge whether a title is stable or not? Additionally, I think the idea of No Consensus in title changes is problematic. As I said above, its actually split consensus where there is strong consensus on both sides of the discussion for their version of the right title. The closer's job is to decide which side, which title proposition is best supported by title policy and community consensus as to which policy interpretation is most appropriate for the specific title. Although I realize WP:Title uses this phrase, the default title, I think that is aimed at editors, not admins closing RMs. We, the community, have allowed individual editors to make ill-concieved, policy ignorant, title decisions as long as there's no redirect that has to be deleted by an admin. This allowance causes no end of downstream problems. If we don't like the results of Bold title moves, then we should eliminate that option. If the default title is so easy to devine, then let's write a bot to change all titles to the default. But let's not create language that no body in their right mind can interpret, apply and be held accountable to just to cover up problems with our article move process. --Mike Cline (talk) 01:51, 22 August 2012 (UTC)[reply]

For those you supporting this language, is this Banh bo, now subject to an RM a stable or unstable title? What is the default title? and what policy/guideline basis supports the default title? There is currently split consensus at the RM [4] --Mike Cline (talk) 02:05, 22 August 2012 (UTC)[reply]
If there are issues with the original title of Banh ho, then these issues should be raised in the RM discussion. The closer can then close taking the issues into account. Why is that hard? --SmokeyJoe (talk) 06:47, 22 August 2012 (UTC)[reply]
You actually didn't answer the question. Is this title stable or unstable, and if it remains at the so-called "default", then what is the policy basis for that title? Those are questions a closer must evaluate if your language is adopted. --Mike Cline (talk) 10:37, 22 August 2012 (UTC)[reply]
I think I prefer “disputed” to “unstable”, although it takes a decent argument, not just one or two assertions, to reach the level of “disputed”. (kind of like how much dispute is required to make a {{disputed}} tag stick. Looking at the page history and the talk page, I’d call it obvious that the preferred page is disputed.
For Banh bo, the default page name is the title of first non-stub version. It was first called Bánh bò nướng, but was then tagged a stub and within 12 hours the sole author had renamed it to Bánh bò. It remained with that title for a couple of months when at 02:24, 1 August 2007, User:Katharineamy removed the stub tags. Therefore, the default, per Wikipedia:TITLECHANGES, is Bánh bò. The policy basis supporting this title is found at Wikipedia:TITLECHANGES.
Those questions, whether there is dispute, and what the first non-stub title was, should be considered facts. If those facts are not agreed on, then a discussion focused on those facts is required.
Let’s assume that there was a well participated discussion, well enough behaved.
The closer then must evaluate whether there is a consensus for a preferred title. If not, is there a rough consensus for a preferred title. These outcomes are easy. What if there is not even a rough consensus? The closer should then consider the default title. Was there a consensus or rough consensus ‘’against’’ the default title? If no, move the page back to the default title. What if there was a rough consensus against the default title, but no consensus for a preferred title? Here, the closer is stuck. I recommend that having got this far, the potential closer should then !vote and leave the close for someone else.
Now, sometimes you mention policy. If an admin examines a discussion with a view to closing, and finds that the participants have ignored and contradicted an applicable policy or guideline, then unless absolutely clear-cut, the admin should not close, but !vote raising the issue of the applicable policy. Another admin can then potentially decide that the !vote trumped all others and close accordingly. --SmokeyJoe (talk) 12:12, 22 August 2012 (UTC)[reply]


I looked at Banh bo and cast my !vote. I too don't like the idea of the default option, but as some of us clearly do, I think we should allow it as an option for the closer to consider. I think we might want to put precedent in similar cases as another consideration for the closer to consider. Giving the closer more options other than just resorting to the status que is good in my mind. In the case of Banh bo, calling upon the discussion participants to come up with Wikipedia precedents would seem to carry the benefit of fostering a uniform look-and-feel across the project. →Yaniv256 wind roads 02:33, 22 August 2012 (UTC)[reply]
So, my current suggestion is: "When it is unclear which title is the default, or the default does not have support among discussion participants, the closer is advised to chose a title factoring in use evidence, Wikipedia precedent in similar cases and majority view, and encourage the discussants to continue working towards consensus in a non-combative atmosphere." Your thoughts? →Yaniv256 wind roads 02:39, 22 August 2012 (UTC)[reply]
I see this as mob rule. You get more !votes and you move the page. No reason to write policies or use them to support a position. Vegaswikian (talk) 02:51, 22 August 2012 (UTC)[reply]
Sorry, I don't see what you mean. First there is default, then if that does not work there are three considerations, only one of which is majority view. How is this mob rule? Could you be more specific so I can try and factor your view in there too? →Yaniv256 wind roads 03:35, 22 August 2012 (UTC)[reply]
Your proposals are perceived to say that !votes are what matters. Policies and guidelines are not as important. Also, there can be no default titles. Vegaswikian (talk) 06:42, 22 August 2012 (UTC)[reply]
"There can be no default titles"? Nonsense. --SmokeyJoe (talk) 06:47, 22 August 2012 (UTC)[reply]

Hi Mike. I am not surprised that you are uncomfortable.

But aren’t you more unfortable that RMCI, which you (at WT:Move review) seem to regard as the preeminent authority covering RM discussions, has been explicitly at odds with Wikipedia:Article titles, which is tagged as official policy?

“Our title policy is extremely conflicted and lacks real consensus” Can you substantiate that? Where is the evidence for a lack of consensus. On the other hand, I have seen a lot of disrepect for RM closes, which is evidence for a lack of consensus support for the WP:RM process, and WP:RMCI included.

Looking at Wikipedia:Move_review/Log/2012_July_10, you essentially upheld Beeblebrox’s interpretation of RMCI. Did his close (a reflection of RMCI) have the support of the wider community? He was hammered for it at Wikipedia:Requests_for_bureaucratship/Beeblebrox. In comparison, the close of Yogurt/Yoghurt applied the principle of defualting to the first pre-stub version. Did you follow the subsequent comments on that close at Wikipedia:Requests_for_bureaucratship/28bytes?

I am becoming increasing confident that RMCI, particularly on the subject of no consensus, is a crock. You talk of language “aimed at editors, not admins”. Do you mean to say that in this area the project has slipped into a practice of being run by admins, not the community? RMCI is almost explicitly the domain of admins. It doesn’t even have a proper talk page.

Eliminating Bold moves? Yes, I’ve thought about that before. Maybe elimitating bold moves on many-revision articles would be a good idea. But maybe not. WP:RM is already backlogged, and this idea would seem to just load a whole lot more work onto WP:RM. Better, would be to improve policy towards something that works.

As previously, the first non-stub version is a good default, better than the previous status quo. Reference to the previous status quo encourages gaming. It encourages early, quiet bold page moving. In the event of “no consensus” (of anything) it is better to move back to the first non-stub version. It is not better to say “no consensus” means do nothing (i.e. cement the last page move). It is not better to say that “no consensus” is not a reasonable outcome, and therfore I must supervote.

Your problem seems to be that there are exceptions. Fine. Describe the exceptions. --SmokeyJoe (talk) 06:47, 22 August 2012 (UTC)[reply]

My problem is that in a lot of RMs, there are participants that don't actually care what community consensus on title policy is. They have a pet agenda--no disambiguation, natural disambiguation, primary topic, diacritics, no diacritics, caps, no caps, my sources are better than your sources, I don't think the title criteria apply to my pet agenda, there should always be exceptions to naming conventions (especially for my pet agendda), I don't like Ngrams, your google search is not as good as my search, I know what the readers want, you don't know what the readers want, I used to live there and know what people call it, its never been called that by the locals, your title is POV mine isn't, etc., etc. This kind of discussion generally isn't productive toward deciding a policy based title, and regardless of the outcome, 50% of the participants will be unhappy, even if that outcome is a return to the so-called "default". As I said above, if title "stability" and "default titles" is so easy to devine, then lets write a BOT to make title decisions. I think trying to legislate a cooking cutter a solution for RM discussions where there is split consensus is problematic. --Mike Cline (talk) 10:33, 22 August 2012 (UTC)[reply]
I understand and sympathise with what you say are the problems in many RMs. It was from browsing RMs that I became convinced of Sayre's law.
You say “50% of the participants will be unhappy, even if that outcome is a return to the so-called "default"”. Sure. Can I simplify to “50% of the participants will be unhappy”. There’s nothing that can be done about that? Actually, there is. People become unhappiest when they feel they were arbitrarily hard done by. When people fall foul of a well defined rule, they are much more prepared to take it on the chin. Failing that, if you have to make someone happy, and someone else unhappy, why not favour the original author?
Stability, or whether the title is in dispute, is a question of whether there is a consensus in support of the status quo. That should be easy to determine, usually. An RM on a stable, undisputed title, if participated, will usually see a consensus close.
The “default title” is well defined. It is the original title on the first non-stub revision. Sometimes, interpretation will be required. For example, the original author may have made a small typo in the title and not noticed before someone started stuff. We can handle that. --SmokeyJoe (talk) 12:35, 22 August 2012 (UTC)[reply]
Does "If no consensus can be determined on what the title should be, note that Wikipedia:TITLECHANGES advises moving back to the title used by the first major contributor after the article ceased to be a stub.[5]" work any better for you? --SmokeyJoe (talk) 12:53, 22 August 2012 (UTC) I feel like I am playing in the sand in a hole in the middle of the road[reply]
From my perspective, a big part of the problem is the section heading "No consensus outcomes". The guidance from WP:AT applies when the title has never been stable, or it has been unstable for a long time -- it is not very helpful guidance for most RM discussions that result in a no consensus outcome. olderwiser 12:57, 22 August 2012 (UTC)[reply]
That true. It is a problem, although I didn't think it big. As above, I don't think "stable" is the best choice of words. If a title is moved from its original, remains undisputed for years, and then becomes disputed, to the point of no concensus. Do you think it should go back to the original, or go back (remain at) to the long lasting title? I think it should go back to the original, regardless of the period of non-dispute. WP:Silence is the weakest form of concensus, and generally, there are no time limits. --SmokeyJoe (talk) 13:54, 22 August 2012 (UTC)[reply]
I unequivocally disagree with anything implying that a no consensus outcome should result in going back to the original title. The guidance provided in WP:AT is for exceptional situations of protacted disagreement and should not be the normal course of affairs for most no consensus outcomes. olderwiser 23:16, 22 August 2012 (UTC)[reply]
We disagree then. In a head-to-head contest between the first non-stub title and the current title resulting in no consensus, it should go back to the first non-stub title. (your position enables and requires me to create and maintain a protacted disagreement to get what I want)

However, that is actually a question for WT:AT, and I agree with you that this page should reflect the guidance of of the policy page. --SmokeyJoe (talk) 23:37, 22 August 2012 (UTC)[reply]

I'd say it depends. If the article title has been uncontested for years, a single no contest outcome should not mean going back to the original title. That would be an invitation for chaos (even more than usual). If there are a half dozen RMs in relatively short order, then some extraordinary resolution may be needed and that is where the quoted guidance from WP:AT applies (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). olderwiser 23:56, 22 August 2012 (UTC)[reply]
That is agreeable equivocation. It depends. I also disagree that older ≠ wiser, unless where talking about someone over the hill. --SmokeyJoe (talk) 00:31, 23 August 2012 (UTC)[reply]

Vegaswikian, using an argument such as being perceived does not make you any less cryptic. A good argument allows the discussants to pick it apart and examine its assumptions. I state majority view as one of three considerations which in whole are described to be no more than an advice to the closer, that he or she can draw upon in the specific case where 1) the notion of consensus rule proved insufficient as a guide. 2) the notion of the default option proved insufficient as a guide.

Furthermore, the fact that !votes without a supporting argument are more likely to be disregarded than not is well documented in other policies. By majority view I mean the majority after such discounting has been factored in. I can put that in explicitly if you wish but in my view that would make the language overly wordy for a general advice.

It seems to me you are reading into the text something that is not really there, or that you are stretching WP:NOTDEMOCRACY into an extreme interpretation that forces is to clash with WP:NOTBUREAUCRACY. In real life debate does not always converge to consensus and decisions still have to be made. If we leave them completely to specialized experts that is a bureaucracy. If we leave them to vote counting that is a democracy. If we want to avoid both we have to pick some middle ground.

Bottom line: it is hard for me to know how to fix what is only perceived but is not actually there. Could you offer something more constructive? →Yaniv256 wind roads 12:50, 22 August 2012 (UTC)[reply]


I have difficulty in understanding why the first line of the paragraph is being ignored in this conversation (it says "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.") That has to come before the second sentence ("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 second sentence is to be interpreted in context. Some of the hypothetical examples given here are ignoring the first sentence of the paragraph -- which is not surprising when the first sentence by way of an introduction to this section says "The above pertinent wording ..." and ignores the equally pertinent wording of the first sentence in the paragraph!

The first sentence is what makes changing names sticky and why the default is not to move. The type of argument the second sentence hits on the head is arguments over spelling "Orange (colour)" and words like gasoline/petrol Tram/Streetcar, Goods wagon/Freight car. It could also have been used for Yogurt and saved a lot of people a lot of time. -- PBS (talk) 21:27, 22 August 2012 (UTC)[reply]

I think you are maybe missing the context in which this discussion is taking place. Have a read of #managing repeated "no consensus" decisions. We have been implicitly focusing on titles that have come to be the scene of an endless tag of war, and we are just trying to be creative in seeking a solution to that problem. Stable titles are just not really in the scope. →Yaniv256 wind roads 21:45, 22 August 2012 (UTC)[reply]
Most of the examples I gave above were not stable, but became so because of this paragraph. There are times when an alternative is tried by the closing administrator, which does become the stable version, but it may just become another short lived title in the mix of alternatives. The point I am making is that the paragraph has to be read as a whole (which does not seem to have been happening in this section). Also think that it is time that the customary moratorium of at least six months between move requests should be explicitly documented in WP:RM (with the necessary flexibility to handle exceptions). -- PBS (talk) 22:07, 22 August 2012 (UTC)[reply]
Yes, but I think we are also implicitly excluding EngVar cases, as we have come to agree these are well handled by wp:retain. We should probably put something in to that effect too. →Yaniv256 wind roads 22:27, 22 August 2012 (UTC)[reply]
Done. →Yaniv256 wind roads 22:42, 22 August 2012 (UTC)[reply]
I was reverted. Before revertion the no consensus passage read

Titles that have been the focus of long disputes that go beyond the question of English variety do not enjoy the privilege of being the default. If no consensus can be determined on what the title should be, note that Wikipedia:TITLECHANGES advises moving back to the title used by the first major contributor after the article ceased to be a stub. When it is unclear which title is that, or that title does not have support among discussion participants, the closer is advised to chose a title factoring in use evidence, Wikipedia precedent in similar cases and majority view, and encourage the discussants to continue working towards consensus in a non-combative atmosphere.

→Yaniv256 wind roads 00:05, 23 August 2012 (UTC)[reply]
That gives undo weight to the first title and assumes that it was in fact correct and that the focus has not changed. NRHP created articles are prone to misleading titles, if not blatantly incorrect ones. Vegaswikian (talk) 00:21, 23 August 2012 (UTC)[reply]
I agree, but am working towards a compromise with SJ, which seems to favor that idea. →Yaniv256 wind roads 00:28, 23 August 2012 (UTC)[reply]
Vegaswikian, aren't NRHP created articles always created explicitly as stubs? --SmokeyJoe (talk) 01:07, 23 August 2012 (UTC)[reply]
No. I will say that some editors and maybe the vast majority are, but not all. I believe that the NRHP naming suggests that you use the name on the nomination. So if the building of a company was nominated, the article could be titled 'Foo Company' rather than 'Foo Company building'. So this would be an excellent example of why the first name is not always the wisest choice. Vegaswikian (talk) 01:28, 23 August 2012 (UTC)[reply]
What is NRHP? →Yaniv256 wind roads 01:37, 23 August 2012 (UTC)[reply]
NRHP I presumed. --SmokeyJoe (talk) 01:57, 23 August 2012 (UTC)[reply]
Vegaswikian, Did you misunderstand me to be saying that the default, or the first non-stub version, or anything formulaic, is the wisest choice? No. The default is only a wise choice with all else being equal. It is a tie-breaker, only implemented in the case of a tie. --SmokeyJoe (talk) 01:57, 23 August 2012 (UTC)[reply]
I was not responding to you on that, just making a general comment. The first choice is not always right, and it needs to be vetted before it has priority over other options. The NRHP cases I have seen proves this point. Now what I don't know is how valid the first choices are. I'll note that in many cases, articles are written using the best judgement about the name only to find out months or years later what the correct name is. Movies being one good example. Vegaswikian (talk) 02:13, 23 August 2012 (UTC)[reply]

Let's try this twick then:

Titles that have been the focus of long disputes that go beyond the question of English variety should not enjoy the privilege of being the default. Wikipedia:TITLECHANGES advises moving back to the title used by the first major contributor after the article ceased to be a stub. Alternatively, the closer may chose a title factoring in the evidence presented, Wikipedia precedent in similar cases and majority view, and encourage the discussants to continue working towards consensus in a non-combative atmosphere.

→Yaniv256 wind roads 00:39, 23 August 2012 (UTC)[reply]

Was reverted again with no talk page discussion. Would someone be so kind as to allow me some room to work with? →Yaniv256 wind roads 01:04, 23 August 2012 (UTC)[reply]
  • (edit conflict) No, it is not for the closer to chose their own title based on their own biases. As that's all it is: if the evidence and policies point towards a particular title then that should be resolved through discussion. If the discussion cannot resolve this, so there's no consensus for any particular title, then the page should not be moved. This should not be overridden by one editor's personal choice. As for 'long disputes'; like what? If the result is no consensus editors should accept that, and accept that redirects and disambiguation mean readers will still find the page, and move on. There are far more important things to do than argue again and again about the title of an obscure article. And stop changing the policy unilaterally in such a drastic way without first getting consensus for it.--JohnBlackburnewordsdeeds 01:10, 23 August 2012 (UTC)[reply]
    • Please read #managing repeated "no consensus" decisions as these are issues we have already come to agree upon. Or at least so I thought. →Yaniv256 wind roads 01:16, 23 August 2012 (UTC)[reply]
      • The last thing in that is you saying you are "dropping the stick", accepting that you've failed to convince others. So why are you back here now resurrecting essentially the same idea? And from that overlong discussion one important question you failed to answer: any examples of articles with "long disputes" over names that this would help? Even if this were implemented it would do nothing to stop "long discussions" as the outcome of "no consensus" would allow those unhappy with the outcome to start yet another discussion, hoping that this time the closer's would prefer their choice.--JohnBlackburnewordsdeeds 01:51, 23 August 2012 (UTC)[reply]
        • In case you did not notice in that debate I was mainly arguing against returning to the first non-stub name. Having dropped the stick on that issue I am working now to come up with language that would express the widest consensus possible, and includes that idea at least as an option. As for examples Born2Cycle has a few, to which I would add, Burma, Pink slime, and the one that got me here, 2007-2012 global financial crisis. As my experience is limited, I don't know if these are the best examples, but they fit the bill, if you ask me. →Yaniv256 wind roads 02:10, 23 August 2012 (UTC)[reply]

Why legislating No Consensus Outcome is problematic

Here's an RM Union Flag that could become subject to this new language. First this article has been moved trice before so I guess it is unstable. It apparently started at Union Jack and went back and forth to Union Flag. Looks like its been at Union Flag since 2007. Now it is at RM to go back to Union Jack. Given the state of discussion at this point, any RM closer could rightly (IMHO) assess no consensus (its 11:7) with good arguments on both sides. It really is a policy problem, but the arguments are all about COMMONNAME and our methods of devining commonnames are inconsistent. Both sides believe their version is the commonname (not unusual in RMs). Now if the close is made as a no concensus close and this new language was in-effect, wouldn't it mandate that the title go back to Union Jack because it was the first title? If that's the case, all editors need to do is drive No consensus discussions to get back the title they want. No admin descretion required and if the closer didn't move it back, would they be afoul of WP:RMCI?. --Mike Cline (talk) 14:07, 23 August 2012 (UTC)[reply]

I don't like the idea of mandating a move back to the first non-stub title for the simple reason that the first non-stub title may not be appropriate or correct (and, as a secondary reason, we're just going to end up with arguments on what was or was not the first non-stub version!). The current wording, which prefers the current title if it has been stable for a while, is the most workable because (a) it has been stable for a while and (b) that stability was likely the result of discussion on the talk page (and we don't want to let all that discussion go to waste). A "no consensus" decision is not definitive and merely means that the closing admin has seen insufficient reasons provided for the alternative title and it should be seen as the start of a new discussion. If, for example, there is evidence for support for moving back to the first non-stub version (or any previous version), then it is a fairly simple matter to file a new move request. --regentspark (comment) 14:22, 23 August 2012 (UTC)[reply]
If both sides make valid arguments why not just close as no consensus but still go with the majority? Surely, democracy has some benefits? →Yaniv256 wind roads 14:35, 23 August 2012 (UTC)[reply]
As Wikipedia is not a democracy.--JohnBlackburnewordsdeeds 14:50, 23 August 2012 (UTC)[reply]
Quote:

It seems to me you are reading into the text something that is not really there, or that you are stretching WP:NOTDEMOCRACY into an extreme interpretation that forces is to clash with WP:NOTBUREAUCRACY. In real life debate does not always converge to consensus and decisions still have to be made. If we leave them completely to specialized experts that is a bureaucracy. If we leave them to vote counting that is a democracy. If we want to avoid both we have to pick some middle ground.

— Yaniv256, Yesterday
And please try to avoid oneliners and over linking policy to experienced editors, as both are commonly seen as rude, in particular on top of that distinct touch of WP:HOUND fragrance to your interest here.→Yaniv256 wind roads 15:58, 23 August 2012 (UTC)[reply]

RMCD bot Approved for trial

See Wikipedia:Bots/Requests for approval. I will begin manual updates shortly. Cannot guarantee a set schedule for updates. Am looking into how to automate my bot. Feel free to continue manual updates if you can't wait—while I'm sleeping, etc.—for the next bot update. Wbm1058 (talk) 00:26, 22 August 2012 (UTC)[reply]

Great news. Thanks so much for taking this on. Jenks24 (talk) 11:28, 22 August 2012 (UTC)[reply]
Thanks. I noticed a glitch with how it handles titles or proposed titles with an embedded en dash. Looking into it. Let me know if you see any other issues. Wbm1058 (talk) 11:47, 22 August 2012 (UTC)[reply]