Wikipedia talk:Requested moves

can vs should

I made an edit to state that {{movenotice}} should be placed at the top of any page up for moving (vs can be placed). I believe all readers and editors of a page should be informed of an ongoing move discussion, in the same way we inform them of ongoing AfD, CfD, DR, etc discussions. There isn't any reason to allow move discussions to be seen only by those who happen to look at the talk page or who already were watching it. One way to address this would be to ask the bot to add these automatically, including linking to the correct rename title, and to the discussion.[--KarlB (talk) 18:07, 13 July 2012 (UTC) Signature restored, after the editor had inadvertently removed it earlier.]

I reverted the move (and would ask KarlB not to re-revert, per WP:BRD). I agree that in many cases it would be a good idea to add the template; I just don't think it should be mandatory. Compared to an article being put up for deletion, move requests are lower-stakes affairs, sometimes involving no more than a change in capitalization. I don't see why we need to require people to place a template on an article in all cases. Note: this change is proposed for the WP:Requested moves/Controversial transcluded subpage; I brought the discussion here for a wider audience. Dohn joe (talk) 18:24, 13 July 2012 (UTC)

and just as often, they are massive debates that take place over years. RM is for controversial or otherwise difficult moves; simple moves (like capitalization, spelling, etc) are just done automatically, or can be done using simple templates. These are moves that people are usually debating for some reason. While I'm sure exceptions will be made, IMO (a) the language should be more forceful and (b) the bot should be changed to add this automatically; if the template is *really* inappropriate it can always be removed - but I've added the template to several contentious discussions, where the proposers hadn't thought to add it. In any case, the language I added was should not absolutely must--KarlB (talk) 18:30, 13 July 2012 (UTC)

Any other thoughts? Again, the purpose of these changes is to encourage the use of these templates a bit more strongly, not mandate their use.--KarlB (talk) 14:50, 22 July 2012 (UTC)

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)

• 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)

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)

Yes, also known as success by exhausting the opposition. older ≠ wiser 05:48, 14 July 2012 (UTC)

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)

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)

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)

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)

Why not follow WP:RETAIN. --SmokeyJoe (talk) 09:12, 14 August 2012 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 that 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 consideration.

Bottom line: Time to grow up. Wikipedia is not our private sandbox anymore, our decisions have major implications outside of Wikipedia and it is 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)

"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)

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)

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)

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)

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)

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)

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)

Thanks, I'll keep an eye on it. MatthewHaywood (talk) 16:54, 19 July 2012 (UTC)

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)

I've added a note to /Current discussions to let the great unwashed know. Interplanet Janet, Esquire IANAL 16:15, 20 July 2012 (UTC)

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)

I've added a notice at Wikipedia:Village_pump_(technical)#RM_bot_inactive. MatthewHaywood (talk) 22:56, 20 July 2012 (UTC)

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)

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)

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)

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)

Is the code somewhere? I can make suggestions, but my PHP is rusty. -- 76.65.131.160 (talk) 08:55, 23 July 2012 (UTC)

FYI, the VP thread was archived to Wikipedia:Village_pump_(technical)/Archive_101 -- 76.65.131.160 (talk) 07:43, 5 August 2012 (UTC)

FWIW, the ANI thread was archived to Wikipedia:Administrators' noticeboard/IncidentArchive761 -- 76.65.131.160 (talk) 09:21, 30 July 2012 (UTC)

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)

Seemed like a good theory, but it didn't work. --Born2cycle (talk) 04:04, 23 July 2012 (UTC)

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)

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)

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

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

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)

The move and redirect at [2] probably blew its little mind. Dicklyon (talk) 06:50, 23 July 2012 (UTC)

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)

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)

My mistake. MatthewHaywood (talk) 12:17, 23 July 2012 (UTC)

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)

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)

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)

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)

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)

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)

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)

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)

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? --Nathan2055^{talk - contribs} 19:52, 3 August 2012 (UTC)

I would suggest pinging WP:Bot requests. --Izno (talk) 21:01, 3 August 2012 (UTC)

Wikipedia:Bot_requests#Need_new_operator_for_User:RM_bot--Aervanath (talk) 14:51, 4 August 2012 (UTC)

New bot request at Wikipedia:Bots/Requests for approval/RMCD bot -- 76.65.131.160 (talk) 07:40, 5 August 2012 (UTC)

RMCD bot (talk · contribs) -- 76.65.128.252 (talk) 04:36, 14 August 2012 (UTC)

Ho Chi Minh City IP setting up Miszabot archiving on RMs

Since these edits all seem to directly relate to WP:RM it seems necessary to note this here. At least since Feb 2012 a series of IP addresses in Ho Chi Minh City have been setting up Miszabot archiving on various controverted articles which are the location of multiple RMs. The IP sets the bot to archive the previous contrary/failed RM, coincidentally when the Miszabot clicks in, then a new RM starts. RMs more or less affected appear to include:

• Talk:Praha hlavní nádraží - immediately prior to recent no consensus RM2 - I have left a more detailed timeline there.
• Talk:Black Caviar - edit immediately prior to recent successful RM2 and move
• Talk:Inter Milan - set up to 90 days and reset to 60 days immediately prior to recent successful RM2 and move
• Talk:Lady Trieu - edit immediately prior to recent successful RM2 and move

I am not sure how many others are affected. In ictu oculi (talk) 05:53, 23 July 2012 (UTC)

In each case, User:Kauffner had lost an RM before and started a new RM after the archiving of the previous discussion. This certainly calls for a sock-puppet investigation. And there are more: This one shows a similar attempt to set up MiszaBot archiving where Kauffner had lost an RM, but as a subsequent editor noted, whoever set up autoarchiving was an idiot, they broke the existing archives!!!. And he's trying it again here. Kauffner keeps saying how incivil it is to point out his bad behavior, but this is too much. Dicklyon (talk) 22:49, 23 July 2012 (UTC)

OK, I have requested an investigation at Wikipedia:Sockpuppet investigations/Kauffner. I will go inform Kauffner now if a bot hasn't. Dicklyon (talk) 23:13, 23 July 2012 (UTC)

I have noticed that on several RMs, where someone sets up archiving, and previous RM requests get archived, and immediately after, a new RM appears. There's someone going around setting up archiving to leave 0 threads visible and a freshness max of only 15 days (I had to fix a very stupid bot archival where the person who set up the bot said use archive 1, when the archives already existed and went to 3... dumping new threads into a closed archive, so I went poking and found a few more, two months ago). -- 76.65.131.160 (talk) 03:15, 24 July 2012 (UTC)

Closure

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

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

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

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)

 Done by Jenks24.--Aervanath (talk) 14:50, 4 August 2012 (UTC)

User:Bananas Monkey

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)

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)

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)

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)

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)

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)