This is an archive of past discussions with User:RMCD bot. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
After all that investigation/analysis I'm still not sure I've found the real problem. I just made this edit to the redirect Movement for Democratic Change – Zimbabwe and will see if the bot handles that any differently. I'm thinking the bot may need to strip leading or trailing spaces from such redirects. – wbm1058 (talk) 13:56, 16 March 2018 (UTC)
...which means it knows not to post a notice to that page.
This is along the lines of changes I made last September to "uppercase first letter before comparing target talk page titles" and "replace underscores with spaces before comparing target talk page titles". The bot should also strip leading and trailing spaces before comparing target talk page titles. – wbm1058 (talk) 14:10, 16 March 2018 (UTC)
Wow, sorry for that. (Leading spaces... that's what you get from copying the page title out of the request.) I'll be more careful. And thanks for fixing everything. Dekimasuよ!17:15, 16 March 2018 (UTC)
There was one more step involved, by the way. After the original version, the edit at [1] was supposed to tell the bot not to read everything past the en-dash that's part of the requested title as the rationale, after this. I don't know how common it is for requests to be malformed enough that they don't include the links in any form. Dekimasuよ!18:00, 16 March 2018 (UTC)
Oh, apologies for messing up the templating. I should have just used the proper template, but I didn't want it starting as a fresh RM and thought short-cutting in the /dated would work. Will know better next time. Thanks — Amakuru (talk) 22:00, 16 March 2018 (UTC)
@Pppery: I consider fixing that "problem" controversial, considering that I don't see it as a problem. The visible space helps to separate the discussions on the page. That, and I don't like how this looks: The separate nominations look conjoined together. Steel1943 (talk) 23:27, 17 November 2016 (UTC)
Not when the nominations look like they are bleeding together. Either way, I think the only way your WP:INDENTGAP suggestion could work while addressing my concern is for the bot to proceed the nominations with a line that consists of one asterisk for single page nominations and 2 asterisks for grouped nominations. The problem with that suggestion, though, is that it doesn't take into account the human error aspect if someone were to use the multiple=yes parameter on {{Requested move/dated}} on a single page nomination somehow. Steel1943 (talk) 23:50, 17 November 2016 (UTC)
It's my theory about how what trigger the bot may be need to perform this task. This was the only idea I could think of that triggers the bot to put 2 asterisks to list the grouped move requests on Wikipedia:Requested moves/Current discussions instead of one asterisk. (The bot may be coded to figure that out differently than I think; again, this is just a guess/theory.) Steel1943 (talk) 00:27, 18 November 2016 (UTC)
No, I actually hadn't read that page before you mentioned it. It does cause problems for me, but the only way I can think of to fix them would be to make a raw HTML list with <ul> and <li>, but that could cause its own issues. Graham8706:13, 19 November 2016 (UTC)
Looking at the current discussions report as a numbered rather than a bullet list helps to see whether separate lists are being started. HERE is what it looks like with all the list asterisks changed to pound signs (diff). You can see the issue because each RM is starting a new list numbered with "1".
Simply replacing all the blank lines with a line that just has one "#" at the start of the line fixes the listgap... see the properly numbered list HERE (diff).
It's hard for me to see the significant difference in spacing that Steel1943 sees. I can see a very slight difference over the full length of my high-res widescreen if I line up "before" and "after" windows at the top and compare the bottom of the windows, but it's a rather small difference. Maybe this varies by browser or screen resolution and is more noticeable to some users. Maybe inserting a <br /> at the end of each line makes a difference. Compare THIS PAGE to the one without the breaks.
OK, now that I've demonstrated the issue and possible solutions using numbered lists, back to the bullet lists.
Is VERSION 1 which uses the "Extra * trick" an adequate and acceptable solution for everyone?
Is VERSION 2 which in addition to the extra * adds a break before that line even better, or not an improvement?
Partly donein version 6.58 – Graham, I made the WP:LISTGAP fix in the Wikipedia:Requested moves/Current discussions (alt) report. That's the older, page-link-first format version of the list. It doesn't get near the page views of the main version of the report, so I doubt anyone will complain about any change in spacing. It was a simple change to the code to do this, I just added a single asterisk character to one line of the program. Have you ever learned how to write programs? When I worked as a professional programmer in the 1980s and 1990s there were two blind programmers working in the same building as me. One of them was in the same department as me for a while. I was amazed at what they could do based on just what they heard. Those were the "before Internet" days, when the systems were text-based. But even now I use Microsoft Notepad to edit my bot code, not any fancy graphics-based tool. – wbm1058 (talk) 20:07, 23 March 2018 (UTC)
Thanks, sounds good. I've done some programming ... though I did it a lot more when I was younger. I mostly used BASIC (and the JAWS Scripting Language, and these days I dabble in a bit of Python. I use a Notepad replacement to do programming. Graham8705:23, 24 March 2018 (UTC)
Edit war between bots at DYK
There has been a proposal to move some pages in DYK, one of which is Template talk:Did you know/Approved. The Approved page is effectively controlled by WugBot, which adds dates and transcluded DYK nomination templates to the page and then deletes them when the nominations are promoted to the DYK prepare areas.
The problem is that WugBot, not recognizing the material added by the RMCD bot, removes it on its every-other-hour run. (It may be doing a complete regeneration of the page; the bot owner, Wugapodes, will know just what the bot is doing.) RMCD bot, 15 minutes later, comes along and reinserts the notice. This has been going on for three days, since 15:30, 10 April 2018.
I'm not sure what ought to be done here, but I thought you should be aware. Is there any way to keep the bot from posting to the page? Or if this something that needs to be addressed from the WugBot side of things? Thanks. BlueMoonset (talk) 16:27, 13 April 2018 (UTC)
I'm on mobile at the moment but I'm 90% sure I know what the issue is and that it can be fixed on WugBot's end. I'll take a closer look once I'm back at my computer. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]16:59, 13 April 2018 (UTC)
@BlueMoonset: I've applied a fix that should prevent the edit war between the bots while the move discussion is open. However it's not a robust fix and another edit to the bot will need to be made when the discussion closes and the template removed. I'm keeping an eye on the discussion though so hopefully there won't be too much of a lag between when it closes and when I notice it. Wugapodes[thɔk][ˈkan.ˌʧɻɪbz]18:08, 13 April 2018 (UTC)
Modules are coded in Lua, which is a different language than Wikitext. I tried adding the notice manually and got the message: Error: Lua error at line 1: unexpected symbol near '<'.
Hence, the bot doesn't tag pages in Module namespace. If you want to manually put a notice on Module:IndianPremierLeague/LeagueProgression/doc you can do that, but remember to remove the notice after the requested move closes.
I fixed a bug in the bot's code. An oversight of mine, really. Surprised that this wasn't pointed out to me sooner; I suppose modules must not be requested for moves very often. – wbm1058 (talk) 15:40, 15 June 2018 (UTC)
I am starting to think we shouldn't do module moves through RM, given the inability to leave redirects behind; if there are widely used modules nominated for moves, it is almost impossible to switch everything over in a reasonable fashion (either the invocation has to be broken before performing the move, or they have to remain broken until they are all fixed manually after the move). Dekimasuよ!20:36, 23 June 2018 (UTC)
Thank you for this. I assume the option to leave a redirect is left inactive for a reason, however. Might this workaround create other problems? Dekimasuよ!16:22, 24 June 2018 (UTC)
Again, though, this isn't a problem with the bot per se. The requested move template assumes from the start that it is going to be placed on the talk page of the page to be moved, and I would advise against changing that, since discussions generally should only go on the talk page of the page to be moved. Putting them elsewhere might lead to disputes about the status of consensus yielded by the discussions. I'd still suggest breaking the redirect and notifying the template talk page; when the discussion is closed, the whole section can be moved back to the template talk. Dekimasuよ!19:28, 22 June 2018 (UTC)
Is there any reason to think the move request is controversial? If this is an uncontroversial change, maybe no use of the template is even necessary. Dekimasuよ!19:30, 22 June 2018 (UTC)
Again, this doesn't seem to be an issue unless you intend to leave Template:Db-meta (and all the other Db-templates, of which there are a lot) where it is despite moving Template:Db. Wouldn't a multimove request work fine there? ...But I'll back off and let Wbm1058 reply for himself. Dekimasuよ!20:13, 22 June 2018 (UTC)
I'm on vacation and making my first-ever smart phone edit so nothing I can do about the bot at the moment. But see the template:rm documentation. You can use parameter current1 to host a discussion on a page that is not requested for moving. Was envisioned for Wikiproject use but I think it could work for templates hosting module discussions. wbm1058 (talk) 06:20, 25 June 2018 (UTC)
That only works for multi-moves. What if I want to move exactly one page whose talk page redirects to a different page? {{3x|p}}ery (talk) 14:32, 27 June 2018 (UTC)
@Pppery, Hhkohh, and Dekimasu: This issue was also recently raised on my talk page. I edited the sandbox for Module:Requested move to allow single page move discussions hosted on another (shared) talk page... except in mainspace, which doesn't support subpages (diff, diff from before my original implementation supporting WikiProject-hosted multimoves). We should keep the mainspace restriction to prevent nonsense such as hosting a discussion to move Palestine on Talk:Israel. But that change exposes a limit of {{Requested move/dated}} – that template assumes that the single page proposed for move is the one hosting the discussion (perhaps Pppery figured this out when trying to make related edits to Module:Requested move). Perhaps |multiple=yes could support single-page requests – it would check to see if |current2= was specified to determine whether it should still say "It has been proposed in this section that multiple pages be renamed and moved." Module:Requested move would write "|multiple=yes" when it detected this scenario. We're limited by a system design that didn't anticipate this scenario, and the need to coordinate substantial design changes with other bot and tool writers. This work process is intended to primarily support discussions about moving articles. I'm not sure this is worth the trouble, especially given Dekimasu's easy work-around. wbm1058 (talk) 19:20, 16 July 2018 (UTC)
To test the changes, I've submitted a test RM: Wikipedia talk:WikiProject Deletion sorting#Requested move 16 July 2018. The syntax used is the "multi" syntax, but it's been modified to support a single page move request submitted on a different (shared) talk page in any namespace other than article space. I don't think any bot code changes will be necessary, but won't know for sure without testing this. If my changes are acceptable, I can make them go live, and then one of you can submit a real RM on a shared page and I'll monitor the bot to confirm it works OK. – wbm1058 (talk) 21:13, 16 July 2018 (UTC)
So I just found that per mw:Extension:Scribunto/Lua reference manual, it was decided that the function print() should be omitted in favour of return values. I guess there's a difference between a sandbox and a "debug console"? It's a pain to have to abort processing just so you can return the value of a variable, just to see what's going on internally in the module.
OK, per Wikipedia:TALKCENT split lists are an accepted use of shared talk. Though it's hard to imagine a scenario where one would want to move a single page such as List of aircraft (J) without moving any other pages. I still see solutions looking for problems, with the potential for creating problems or allowing them to be created. I'd rather wait for a valid use scenario to be raised, but this isn't worth fussing over any more at this time. – wbm1058 (talk) 10:47, 19 July 2018 (UTC)
I tried yesterday, but says Request to move a single page must be placed on that page's talk error message when I preview Hhkohh (talk) 15:53, 14 July 2018 (UTC)
Happened while I was sleeping. I had to do a hard reset of my machine this morning to get it to respond. Weird behavior from my Win 7 OS. Maybe something open in my browser caused it to freeze? I close all my open programs (except bot, of course) when I leave my place for an extended time, but not every night. wbm1058 (talk) 11:00, 28 August 2018 (UTC)
I invested about a month into figuring out how to run this on my Windows machine. It wasn't easy to figure out all the details. It would probably take me another month to figure out how to run it on "the cluster" and I have more important things to do than transfer a working process from one platform to another. wbm1058 (talk) 23:20, 28 August 2018 (UTC)
I seem to recall there have been times when all the bots on the "cluster" were down, but my bots were still cooking. wbm1058 (talk) 23:25, 28 August 2018 (UTC)
I actually agree, I invested quite a bit of time into it and realized it was p intricate. Advantage of running it in the cluster is you get to save on your personal resources but if your system is more reliable/efficient, there's no reason to ofc. --QEDK (後 ☕ 桜)17:14, 29 August 2018 (UTC)
Request for minor adjustment to bot updates of Wikipedia:Dashboard subpage
Yikes, I just noticed that Merge bot hasn't edited since December 13... about a week! Now this bot, oddly enough my third bot is still cooking. I'm sure the tech people will tell me that they gave adequate warning of coming changes, in their usual cryptic and subtle way...
Well, using the rather cryptic "Special:BotPasswords" I have given my bot a new password. The bot is now editing under my own account. This will cause a relapse in my editcountitis as I run up the WP:EDITS list while I sleep. I don't think that is what they intended. But when the instructions leave you guessing, you just have to keep guessing until you get it right. I'll come back and resume guessing how I'm really supposed to implement "bot passwords" in the morning. I'll admit that the new password they assigned for the bot is way longer and thus more secure than the one I was using. Not that the one I was using wasn't secure... it was long enough. wbm1058 (talk) 04:29, 21 December 2018 (UTC)
I noticed that. {{rofl}} Right, this isn't a social media site ;o) Notice how Help:Creating a bot § Logging in has an {{update}} template dating from September 2016 noting that because action=login generates a deprecation warning the documentation needs to be updated to tell people looking for help what to do about said warning. I'm going to login to my bot for the first time in a long time, I'm sure there are lots of pings to it waiting to be cleared. I'll try running Special:BotPasswords from inside the bot account. – wbm1058 (talk) 11:34, 21 December 2018 (UTC)
mw:API:Login#Method 1. login says the login action may be used with bot passwords. mw:Manual:Bot passwords isn't much of a manual. That "manual" was created in February 2016, about seven months before the {{update}} template was put up on our local help page. After logging into Special:BotPasswords, I see this message:
Bot passwords allow access to a user account via the API without using the account's main login credentials. The user rights available when logged in with a bot password may be restricted.
If you don't know why you might want to do this, you should probably not do it. No one should ever ask you to generate one of these and give it to them.
Note: OAuth is more secure than bot passwords and should be preferred whenever the bot supports it.
I think I've been there before, and my reaction to "If you don't know why you might want to do this, you should probably not do it." was "OK, I guess if this is important to me, then someone will let me know about it". Heh. wbm1058 (talk) 12:05, 21 December 2018 (UTC)
The "Bot passwords" user interface prompts me to enter a Bot name: without explaining what they mean by that. Is that the User ID? Well, maybe not. My first guess was to say "User:RMCD bot", then I got the message back:
The bot password for bot name "User:RMCD_bot" of user "Wbm1058" was created.
I think I was assuming this system was more intelligent than it actually is. It seems that it did not connect my personal account with my bot account. – wbm1058 (talk) 12:26, 21 December 2018 (UTC)
Self-troutYour password is not valid: Passwords must be at least 10 characters.
Please choose a new password now, or click "Skip" to change it later.
Sorry boss, I thought that eight was enough. I liked having a password with the same number of characters as my user name. You could never remember it, and always had to ask me what it was. OK, enough excuses, I'll change it now. – RMCD bot (talk) 13:28, 21 December 2018 (UTC)
So it turns out that the [reason] in the error message I saw on my bot's console was just a head fake. The real issue was the bot's two-character-too-short password, and since this happened on WP:THURSDAY I have egg-on-face for paying insufficient attention to the Tech News weekly summaries for 2018, week 50 (Monday 10 December 2018):
New accounts will need passwords that are at least 8 characters long. Admins, interface admins, bureaucrats, oversighters, CentralNotice admins, global renamers, check users, stewards and some other user groups will need passwords that are at least 10 characters long. This is because an attacker could cause damage to the wikis if they took over these accounts. [4][5]
So bots are one of the "some other user groups".
So while failure to use Special:BotPasswords wasn't the issue this time, I suppose it might be a good idea to voluntarily implement that some time before I'm forced to. – wbm1058 (talk) 14:52, 21 December 2018 (UTC)
Yikes, I just noticed that Merge bot hasn't edited since December 13... about a week! Yep, the 13th was also a WP:THURSDAY. So they're moving this out in phases, and that bot's pw requirements were changed in the first weekly rollout, while this one's weren't changed until the second weekly rollout. wbm1058 (talk) 15:38, 21 December 2018 (UTC)
I think I know why Merge bot got tagged a week before RMCD bot. It's an admin-bot (authorized to history-merge categories, an item still on my to-do list). Administrators went first, then in week 2 they added (normally-privileged) bots. My third bot already conforms with the 10-character minimum, so no need to fuss with changing its pw at the moment. wbm1058 (talk) 18:07, 21 December 2018 (UTC)
Actually, it's not programmed to recognize any time zone other than the default (UTC). Note HERE that before it was relisted, it was skipping right by the (CET) timestamp and using the timestamp of the first response, which was BrownHairedGirl's question. I'm surprised this hasn't been noticed and reported before now; it's been like this "forever". I suppose reflective of the infrequency of anyone using timestamps in anything other than UTC. I'll run a test with this and see how it works. – wbm1058 (talk) 22:34, 3 January 2019 (UTC)
Oh, yuck. I can't stay up all night to try to find a way to keep a request like the one at Talk:Carl Zimmermann from sending the bot into a loop, and my attempts at a quick patch just made things worse. wbm1058 (talk) 05:45, 6 January 2019 (UTC)
Well now we see the risk from introducing the increased complexity of all the bot's notices. When something goes wrong the bot can start spamming the notices. I think my edit to Talk:Carl Zimmermann got the updates back to normal going forward, but the problem is that anyone making a similar malformed request can make the bot behave this way again! It recongnized that the request was malformed, but didn't handle that robustly enough. wbm1058 (talk) 06:12, 6 January 2019 (UTC)
Thanks for getting it back to work. I certainly didn't notice the error, but I'll keep an eye out if this happens again. Maybe it's best to remove the link to what caused the issue? WP:BEANS and all that. Dekimasuよ!06:28, 6 January 2019 (UTC)
Well, if we were that concerned with spilling beans then I wouldn't post the source code. No, the answer is to fix the issue in the code so that it won't be possible to make it happen again. Especially since this was, assuming good faith, simply a user error and not an attempt to disrupt the bot. This is best addressed when my brain is fueled by coffee rather than beer (like right now). Here is the bot's edit history during the window when the problem was happening. The initial move request was fine, but then a manual edit was made that bypassed the usual scrutiny for syntax errors done by Module:Requested move. It was that edit, which added another page to the request, that gummed things up. Last September I enhanced the bot to accommodate removal of item(s) from a multi-move request, so that this doesn't result in the request being deemed as "malformed", as occasionally editors remove a single page from a lengthy multi-move request. Before that enhancement there was a tedious requirement to renumber all the pages after that in the request, to maintain an unbroken sequential numerical sequence. That enhancement added a new check for malformed requests that reported "Counts aren't equal". This latest incident was flagged by that error check, but the flagging needs to be made more robust so that the script doesn't get thrown into a loop when it reaches the sorting by timestamps stage in processing. Thanks for reverting the bot's spam to Talk:Segway PT; that was caused by my tired brain's attempt to make a quick fix last night, without taking time to do better analysis first. wbm1058 (talk) 15:53, 6 January 2019 (UTC)
Your bot, it seems, keeps adding to Tonight at 8.30 a message that says a proposal has been made to move the page to where it already is. If you are responsible, would you be so kind as to remove this excrescence post haste? Thank you. Tim riley talk18:10, 25 January 2019 (UTC)
Problem was caused by the initial request, which put the section header on the same line as the Template:WPAFC. Inserting a newline fixed the section header, but the bot won't fix bad article notifications. I reverted the article notice, and after that the bot posted the correct notice. wbm1058 (talk) 02:07, 7 March 2019 (UTC)
But, the bot didn't actually re-post the article notice until after the problem reported in the next section was resolved. I know a thing or two because I've seen a thing or two. wbm1058 (talk) 02:13, 7 March 2019 (UTC)
Sorry, an edit to remove an item from a multimove list in another RM had thrown the bot into a processing loop. This edit took the bot out of that loop, but I still need to fix the code so that similar edits can't cause infinite loops in the future. –wbm1058 (talk) 02:19, 7 March 2019 (UTC)
Fixed in V. 6.71 – the bot will now report removal of an item from a multi-move request as malformed if the parameter isn't removed as well. wbm1058 (talk) 16:26, 8 March 2019 (UTC)
Fixed in version 6.86. I've seen this before. The redirect at Talk:Detective Conan#REDIRECT [[talk:Case Closed]] had a lowercase "t" which needed to be uppercased so that it would compare equal to "Talk:Case Closed". Underscores in redirects need to be changed to spaces and spaces at the end need to be trimmed too. I'd fixed the most common instance of this before, but they found one of two other places in the code where I should have made the same fix. (Yes, the code is looking a bit less elegant now)
@Goodd-002:RMCD bot is a bot (as most editors with names ending "bot" are). The bot re-added the header template to the top of the article because {{Requested move/dated}} is still on the article's talk page; you can fix this by removing that notice. You should also read Wikipedia:Requested moves; it's not recommended to close a discussion you initiated, though in the case of moves it can reasonably be interpreted as a normal undiscussed move. eπi (talk | contribs) 19:37, 20 May 2019 (UTC)
Add category to talk pages
With multi move requests, the bot leaves talk page messages that notify page watchers. Good. What I suggest it should also do is to add Category:Requested moves to the talk page as it's that category entry that triggers the move discussion to be included in Wikipedia:Article alerts. It's a known "bug" and was first reported in 2012 but I guess rather than fix anything with the article alert process, it might be simplest to just include the categorisation through the RMCD bot. Not sure whether anybody has ever brought this up with you (have looked through this page but not the archive). This certainly has the potential to draw a lot more attention to multi move requests as only page watchers get to know about it, but this change would inform Wikiprojects. Schwede6620:35, 27 April 2018 (UTC)
@Schwede66: Transclusion of Template:Requested move/dated is what actually populates the category, and when the closing administrator removes that template the category is automatically de-populated. It would be easy enough for the bot to populate the category when it places the notices on the multi-move pages that point to the page hosting the discussion, but currently the bot is not set up to be able to easily de-populate the category when the discussion closes (and it would be too much to ask the closing admins to do this). On my back burner is a possible enhancement (see WT:Requested moves#Bot-created searchable archives)... that would give the bot the ability to remove these pages from the category after the RM closed. This would be another element of #Followup after moves and/or closes. This isn't a high priority for me right now; there are other ongoing tasks I want to wrap up. But maybe something I will get to later in the year. wbm1058 (talk) 00:36, 28 April 2018 (UTC)
Well, it's been discussed since 2012 as I say, so if you could get to this later in the year, that'll be perfect. There's certainly no urgency to it as far as I am concerned. Thanks for looking into it! Schwede6600:53, 28 April 2018 (UTC)
One process that depends on categorisation of RM-tagged pages is WP:Article alerts. However, since the category is added via the discussion header template, currently only talk pages with active discussions are listed under Category:Requested moves. This is a limitation that affects Article Alerts, as mentioned above under #Add category to talk pages.
I wonder if it wouldn't be a good idea to have another category, which would be populated by {{User:RMCD bot/subject notice}} which the bot places on affected article pages. This wouldn't be redundant to the existing category, since the old cat tags discussions, while the new one would tag all individual articles. --Paul_012 (talk) 05:26, 29 March 2019 (UTC)
Fixed in version 6.93 – problem was with the lowercase "i" at Talk:Bell Media Radio#REDIRECT [[Talk:iHeartRadio Canada]].
Since the software forces all page titles to start with an uppercase character, and that didn't compare equal to #REDIRECT [[Talk:IHeartRadio Canada]], the bot thought they were different pages. It knew it needed to uppercase the first character of the page name, but in this case that meant it stupidly uppercased the "T" in Talk. Now it is smart enough to uppercase the first letter of the BASEPAGENAME. Thanks for reporting this. – wbm1058 (talk) 21:04, 1 September 2019 (UTC)
CPAC (TV channel) requested move
Hi,
I just wanted to make sure there was not a bug in RMCD bot as my requested move for CPAC (TV channel) is still not actioned.
Relisted discussions not being counted/formatted properly
At time of writing, the top of WP:RM#C says "4 discussions have been relisted, indicated by (Discuss)". But in fact there are many more relisted discussions than that, which aren't marked with underlining. e.g.:
There are examples going back over seven days, and several different relisting editors (i.e. it doesn't seem like it's just one user who's not using the relisting template properly). Colin M (talk) 21:32, 10 November 2019 (UTC)
Sorry for the sporadic updates for the last several days. The bot runs on my home PC, which unfortunately was apparently crashed by the Microsoft Windows 7 November monthly updates:
Windows Malicious Software Removal Tool x64 - November 2019 (KB890830)
Installation date: 11/13/2019 1:17 AM
Installation status: Failed
Error details: Code 800B0109
After the download, this tool runs one time to check your computer for infection by specific, prevalent malicious software (including Blaster, Sasser, and Mydoom) and helps remove any infection that is found. If an infection is found, the tool will display a status report the next time that you start your computer. A new version of the tool will be offered every month. If you want to manually run the tool on your computer, you can download a copy from the Microsoft Download Center, or you can run an online version from microsoft.com. This tool is not a replacement for an antivirus product. To help protect your computer, you should use an antivirus product.
So, effectively the "Malicious Software Removal Tool" itself seems to have maliciously shut down my system.
After I became aware that the bot was down, I ran periodic emergency updates from my laptop while attending the annual North American Wiki conference in Boston.
My bots have run for years on Windows 7, which went out-of-support last month, but in moving to my Windows 10 machine, I've had problems as have others:
Hmm, Also check Run with highest privileges. I guess "highest privileges" are now required to wake a computer running Windows 10. wbm1058 (talk) 15:22, 16 February 2020 (UTC)
Move discussion notice on the same Talk page as the discussion itself
Sorry, related to the issue I reported below, when I brought the bot back up, it was running the previous version from before this fix. It's now running the current version again. I didn't notice that this RM that was open on March 2 hadn't been closed yet. wbm1058 (talk) 15:39, 21 March 2020 (UTC)
Bots temporarily offline
Technical issues require my bots to go offline for the next 10+ hours. I'll restart them ASAP. Sorry for the inconvenience. wbm1058 (talk) 16:21, 20 March 2020 (UTC)
The targets need to be changed in two places, both the template parameters, and the list below the template. I realize this redundancy isn't ideal when proposals get changed in midstream, but I haven't yet been able to design a better alternative. I suppose I could enhance the bot to recognize when the template parameters don't match the list below the template, but then it would be guesswork to determine which the user intended, without examining the edit history. wbm1058 (talk) 00:16, 25 February 2017 (UTC)
Wait, you're misunderstanding. The current discussion properly includes |current2=68th Street–Hunter College (IRT Lexington Avenue Line)|new2=68th Street–Hunter College station, yet the bot adds a notice pointing to 68th Street–Hunter College, and didn't update it when I changed the proposed target. Pppery01:19, 25 February 2017 (UTC)
I see, you mean that the notice on the top of the article (in mainspace) isn't updated when you make a midstream change in your proposal. The bot looks for {{User:RMCD bot/subject notice}} on the page, and when it sees that template, it's done. It doesn't overwrite the existing template. You can either manually change it yourself, or remove the {{User:RMCD bot/subject notice}} and the bot will put back the correct one as long as there is not a {{nobots}} tag on the page. I understand that support for midstream changes isn't great, but such changes shouldn't be encouraged too much. If people have already !voted on the original proposal, then it makes it more confusing to understand what people are agreeing to or not agreeing to, sometimes. wbm1058 (talk) 03:03, 25 February 2017 (UTC)
Fixed 22 March 2020 by v 7.12 – Sync tampered subject page notices per #Pandemic (3/21/20). But this introduced a new problem; potential for the bot to edit war with itself as it constantly "fixes" conflicting proposals. – wbm1058 (talk) 16:55, 10 May 2020 (UTC)
Quickly added and removed RM template did not clean up talk pages.
The bot never removes messages from talk pages. It only removes the notices from subject (main) space. This seems a one-off, so I don't think there's anything needed to be done to change the bot's code. – wbm1058 (talk) 11:23, 29 June 2017 (UTC)
Fixed in bot version 7.18 which added an error check for requests not placed on talk pages. Requests will now be reported as malformed when they aren't placed on a talk page. Since the request is malformed, other pages won't be notified, thus there will be no talk pages to clean up. – wbm1058 (talk) 21:16, 10 May 2020 (UTC)
Amakuru: Hi. I just installed version 6.45 of the bot which fixed this issue, so the talk page is created and the cross-post notice is written to the new talk page. Not sure if these notices were posted by any previous versions of the bot; this may have been a side effect of making sure that talk pages of redirects were not created. But, as these pages are content pages where it is proposed to move another page over their content, it makes sense. Ideally, such requests should almost always be submitted as multi-moves specifying where to move the conflicting page in order to clear the way. It's rare that we would do a defacto page deletion via a page move. When these are specified as multi-moves, a complete set of notices is posted. Maybe later I'll enhance it to put User:RMCD bot/subject notice on the target page as well. – wbm1058 (talk) 21:02, 14 July 2017 (UTC)
Ah OK. This target is actually a disambiguation page that will disappear if the move goes ahead, because of WP:TWODABS, so it's not really a proper content page. It didn't occur to me that that scenario might not be covered. Thanks for the response. — Amakuru (talk) 22:00, 14 July 2017 (UTC)
Actually, though I agree with you that this is not the only type of move discussion that can be called malformed, I think it is inaccurate to state that this is not one form of malformed request (according to general understanding). A very brief search showed "Technically this is a malformed request because the target is occupied" (me, 18:13, 6 April 2018 (UTC) at Talk:Dualism), "Oppose as malformed request, since the target is occupied by an article already" (Dicklyon, 03:19, 20 September 2014 (UTC) at Talk:Caregiver), "Also, the nomination is a malformed multimove request, as the target name is already occupied" (BarrelProof, 00:05, 30 January 2018 (UTC) at Talk:Bowser (character)/Archive 2), "this is a malformed move request, because the city currently does not have primary topic for the title proposed--Pilsen is a disambiguation page. You would have to move it to some other title or propose for Pilsen to move to Pilsen (disambiguation)" (Red Slash, 22:24, 26 October 2014 (UTC) at Talk:Plzeň; the target was then edited to not be the occupied title "Pilsen"). It would be easy to find more, but I think these are a good cross-section of RM regulars. Dekimasuよ!05:05, 22 January 2020 (UTC)
This is good. It seems to be mainly picking up unlisted disambiguation pages where the requester may want the dab page to simply be deleted, however. If that's what the requester desires then it is difficult for them to fill out a multimove. Personally I do not understand why disambiguation pages with two entries need to be deleted, though, since they can be shuffled off to "(disambiguation)" and left there to be useful or not. But I'm aware that there is a school of thought that they do not need to be kept in these sorts of cases. Dekimasuよ!14:32, 27 January 2020 (UTC)
@Dekimasu: See {{One other topic}}. Californias, Attar and Sergio Castillo are all currently ambiguous titles with no primary topic. If it is determined that there is indeed a primary topic, then these pages should be moved to Californias (disambiguation), Attar (disambiguation) and Sergio Castillo (disambiguation) in order to clear the title to make way for the move. I believe it's bad practice to delete the disambiguations on the base title, because then you have mixed up the page history, having a deleted history that's not on the same topic as the live history. Once moved to the parenthetical (disambiguation) titles, it may then be appropriate to tag them with {{One other topic}} and/or delete them, as the (disambiguation) would be an orphan when the other topic is linked from a hatnote on the primary topic article. – wbm1058 (talk) 18:06, 28 January 2020 (UTC)
Delay posting notices, to mitigate the impact of vandalism
Deny=RMCD bot
Does the deny=RMCDbot template work on articles i.e. stops the bot on putting page notices on certain articles - for ages, vandal IP addresses has been trying to request moving a few people's names to false names (e.g. Matthew Lowton to Jonathan Field, see page histories). Iggy (Swan) (Contribs) 15:03, 27 February 2020 (UTC)
Yes, {{bots|deny=RMCD bot}} works in mainspace, but of course that prevents notices of legitimate move requests as well, and nothing short of page protection prevents a vandal from removing that template. See also related discussion here. – wbm1058 (talk) 16:50, 27 February 2020 (UTC)
Clutter
When it comes to vandal requests, although users remove them on the talk page of the target, on other pages the text added by this bot still remains (see Talk:Josh Brownhill for example). In theory, the bot should have removed the "clutter" as well as the transcluded notice of move discussion. Yet this remains in place after the bot removed the hidden template. The existing code should be altered a bit to remove the crosspost notice as well in one edit rather than having confused editors seeing there is a move request on the target page when it is not. Iggy (Swan) (Contribs) 15:48, 12 March 2020 (UTC)
Vandalism of this sort is another issue presenting a need for followup after moves and/or closes. In this case the RM was speedy-closed due to vandalism. There are three types of closes: a formal close, a "close" which only removes {{requested move/dated}}, and a reversion of the request. It may be tricky to distinguish vandalism from good-faith requests. I think implementing a minimum 15-minute delay before posting cross-notifications will help mitigate this problem, by giving the recent-changes patrol more time to revert the RM before all the notices are posted. In the case at Talk:Harry Redknapp the RM was reverted after only 9 minutes, but that nine-minute window overlapped with a bot run. The case at Talk:Harry Wilson (footballer, born 1953) was also reverted after 9 minutes while overlapping a bot run. – wbm1058 (talk) 13:24, 13 March 2020 (UTC)
Done – Bot version 7.22 delays at least 20 minutes after the initial move request was made before posting notifications, to mitigate potential damage from vandalism. – wbm1058 (talk) 11:53, 12 May 2020 (UTC)
Continual addition of move discussion notices to a talk page
Bot acting strangely (12/9/18)
Conflicting open RMs, one on a (shared) WikiProject page
This bot keeps adding a "don't reply here regarding the proposed move but on page x" section on the talk page were the proposal is supposed to be discussed per the tags and the text the bot itself posts (see this and this). Why is it doing that?Tvx1 16:46, 9 December 2018 (UTC)
Those are changes I made after the bot started adding the tags and the talk page section. It originally kept adding a section on Talk:Formula One referring to Talk:Formula One, which is clearly a circular and unwanted link. I made my edits exactly to prevent the fork you mention. The discussion originated at WT:F1 and should be continued there. Talk:Formula One is the fork, not WT:F1.Tvx1 20:58, 9 December 2018 (UTC)
So here we have a WikiProject talk page hosting a multiple-move discussion, so I'll get back to work tracking down this somewhat elusive bug. wbm1058 (talk) 15:34, 22 November 2019 (UTC)
No, I said I was still working on it. What I meant to say is that I previously avoided solving the underlying issue by fixing the syntax of the other request, which wasn't hosted on a third-party (WikiProject) page. wbm1058 (talk) 16:06, 22 November 2019 (UTC)
I did limit runs to those needed for debugging and testing. I've cleaned up the ten effected pages by reverting to the bot's initial notice edit. – wbm1058 (talk) 20:46, 22 November 2019 (UTC)
RMCD bot is on the fritz again, so I have blocked it. Please review its contributions. It has been at it for days. ƏXPLICIT10:59, 14 January 2020 (UTC)
First sign of possible trouble I see is a test request at Wikipedia talk:Sandbox; unfortunately this was an ill-timed test because it was saved at 10:44, and the bot runs on the quarter-hour, so it posted this notice at 10:46, one minute before the test was reverted. Cyberbot I cleared the sandbox just before my bot would have got to it. OK, this is interesting but not really the cause of the bot malfunction.
But, then the bot notified all those pages in that multi-move test request, starting with this one! Notifying of move discussion on Wikipedia talk:Sandbox !!
So, OK, since the sandbox request was reverted, the bot just removed those notices on its next run. Again, interesting but not really the cause of the bot malfunction. When the actual move request was entered, the bot re-posted the notice, this time, correctly.
I should add a check for requests made on a sandbox page though, and simply ignore them or report them as malformed.
Looking at Talk:Ahmedabad Vadodara Expressway, I also see expected bot behavior. The first notice about the discussion on the sandbox talk page should be (manually) removed; the solution here is to not allow the bot to post notices about sandbox-hosted discussions in the first place.
I see that a new shortcut WP:MALFORMED has been created, hijacking the meaning of that term from Wikipedia:Requested moves#Malformed requests. WP:MALFORMED requests are not malformed from the bot's perspective, but when editors say they didn't do a mass move because I would have to propose 50 different moves for all of the states. That's a lot of work for me. When I proposed this originally, I wanted to do a mass move on all the 50 states' congressional districts. and are told The easiest way to do it is to copy-paste the list of articles from the category and clean it up in a text editor, then just add the numbered parameter names; then copy the list, change the names in the copy to the intended versions, and change... they end up making bot-like semi-automated requests that have errors in them, like requesting to move the redirect Alaska's congressional districts to Congressional districts of Alaska – does it make sense to move Alaska's at-large congressional district to a title that implies that state has more than one congressional district?
I'm disappointed to see the notice of malformed requests that my bot posted at 10:50, 11 January 2020 has still not yet been tended to three days later. You can't expect me to stay on top of this by myself. Clearing the list of malformed requests will stop the bot from misbehaving.
Nonetheless, I should fix this so that the bot doesn't post notices of malformed requests. It mostly doesn't, but this issue is an oversight of my v 6.80 – enhanced notification of multimoves, to support WP:Article alerts, implemented in April 2019.
Just a couple of quick comments, and I will respond later again if I can. I did some significant edits to the section referred to by WP:MALFORMED, but it had already been established before I made those edits. (If the section as a whole needs to be reverted to a much earlier version then that's all right with me.) As for not fixing the expressway "redirect moves", it appeared that Amakuru had already decided to leave the section open and was monitoring it, so I did the same. Normally I would close those as malformed and/or perform RMUM moves on something like that. In other words, in that case the malformed notifications were being recognized even though they weren't being fixed. Dekimasuよ!08:05, 15 January 2020 (UTC)
@Dekimasu and Red Slash: How about we designate those as "incomplete" rather than "malformed". WP:IRM is an available shortcut for "incomplete requested move". This is simply one specific type of malformed request. One that the bot doesn't flag, but probably could if there is a consensus for that. Was this new section boldly implemented, or was there a discussion? I'd like to have a link to the discussion, if any. wbm1058 (talk) 13:48, 15 January 2020 (UTC)
As far as the shortcut itself is concerned, I don't find one to be necessary. If we need to inform someone that their move request has been closed for procedural reasons like incompleteness, then it is better to explain it directly in simple terms or provide a complete link to Wikipedia:Requested moves or in this case Wikipedia:Requested moves#Requesting multiple page moves, rather than using a shortcut—particularly a shortcut using a word with a negative connotation, which seems bitey. Dekimasuよ!04:56, 17 January 2020 (UTC)
This section covers multiple issues. In addition to the v 7.01 fix:
I have not implemented any specific fixes for sandbox-editing. But, the #Delay posting notices, to mitigate the impact of vandalism fix should address this. Presumably if the sandbox editing is done within 20 minutes, no notices will be posted for it. Effectively sandbox testing can be viewed as a good-faith variant of vandalism.
@Wbm1058: I think it may have something to do with there being a recently opened move discussion of the 1968 article on the 1968 talk page, as well as a combined move discussion of it and other articles on another page. Nil Einne (talk) 15:49, 21 March 2020 (UTC)
Right, it looks like the bot has been attacked by a pandemic of open requested move discussions on different pages. I'll see if I can make it behave in a more defensive manner when such events happen ;) wbm1058 (talk) 15:53, 21 March 2020 (UTC)
Tampering with bot-placed subject-notice templates
I've added a check to the bot which looks for tampering with bot-placed subject-notice templates (changes made after the initial RM request). My test run reports the following:
I was reluctant to make the bot change these, as I don't like to see too many changes made to the parameters of open RM discussions, but these nine active cases show the need to have the bot keep the subject notices in sync with the talk-page requests. – wbm1058 (talk) 16:30, 22 March 2020 (UTC)
Sorry for the extended bot outage while I work through the complexities in coding the workaround for this use case. wbm1058 (talk) 12:46, 23 March 2020 (UTC)
The requests that caused this issue have now been closed, before I was able to implement a solution for the bot's edit-warring with itself. So, if this scenario repeats, please place {{bots|deny=RMCD bot}} on the affected pages and notify me here. Thanks, wbm1058 (talk) 15:50, 29 March 2020 (UTC)
Please could you update the code of your bot so it will add the RM banner just once to each page, for a particular move discussion. Then if it is removed by a human editor, the bot will not edit war. I think this may be the simplest way to avoid many of the problems documented on this page. — Martin (MSGJ · talk) 13:49, 10 May 2020 (UTC)
The continual addition of notices issues reported on 11/21/19, 11/22/19, and 1/14/20 were all fixed the same day they were reported (or the next day).
Sometimes the local discussion is started first; sometimes the remote discussion is started first. – wbm1058 (talk) 12:56, 14 May 2020 (UTC)
The mechanics of the specific offenses also vary:
2/12/20 issue: the offending editor modified a previously open request while it was still under discussion, and changed one of the pages in the request to a different page. They only did this with the parameters the bot uses, while leaving that item unchanged in the list of requested moves shown below the template. This change should have been reverted, but may not have even been noticed. It remained in place up to when the RM was closed.
3/21/20 issue: the offending editor disregarded a notice of the already open move and entered the new, competing request, to move to a different target, immediately below the notice of the other discussion
4/25/20 issue: the same editor started parallel discussions within two minutes of each other – both of these would first be processed on the same bot run
Based on this I think it's almost certainly related to there being two RM discussions affecting the page in two different places at the same time. Since the first was a month old, I have closed it. Kahastoktalk16:19, 23 May 2020 (UTC)
Thanks for the report. I have implemented an incremental fix – this issue is now detected and reported here as a malformed request. Thanks for closing the conflicting discussion.
This problem is that by the time the code detects that problem, the notice-spamming damage has already been done. I'm working on a fix that involves making two passes through all the requested moves – the first pass to compile a list of all pages requested to be moved and detect conflicting requests, and the second pass to actually process the requested moves while skipping the conflicting requests. Since the change to fix this involves significant restructuring of the code, I'm taking it slow and making incremental, transitional changes to try to avoid breaking anything while implementing this fix. It's still a high priority for me. – wbm1058 (talk) 19:57, 23 May 2020 (UTC)
Incident of the Month: June (6/9/20)
After implementing several transitional code restructurings, I have the bot making two passes through the set of requested move discussions. I've spotted the trouble at Talk:Carl XVI Gustaf of Sweden and am making the final push to implement a robust fix. Please leave the conflicting discussion open, to help me with testing. The bot's updates may be delayed a bit while I'm working on this. – wbm1058 (talk) 12:46, 9 June 2020 (UTC)
@Wbm1058: Re your email to me about this issue, it's not likely that [7] affected your bot. That change merely exchanged one failure response for another. More likely is that session loss (likely on Wikimedia's servers, but could be some sort of cookie loss/corruption on your end) caused your bot to wind up logged out and no code was in place to notice that that had happened.The easiest way for a bot to avoid editing while logged out is for it to include assert=user or assert=bot in every API request. That will cause the API requests to return an error (assertuserfailed or assertbotfailed) if the bot becomes logged out.A soft block on the IP in question would also be a way to prevent it from editing while logged out, assuming that the IP address never changes. I note though that the IP in the linked diff seems to be from a residential ISP, which (unless you're paying for a static IP) might change without warning and so cause your bot to accidentally IP-hop around the block. Anomie⚔14:00, 25 June 2020 (UTC)
Hello. I recently made a request for this article to be merged into this article due to the fact that the changes in the former could not be immediately incorporated in the latter. Doing so would violate this policy. I had made a similar request regarding this page being merged into this one for the same reason. For reasons unknown to me, someone using this account removed both requests with no explanation about it. What do I need to do to resolve this issue? Thanks. --Jgstokes (talk) 00:05, 3 August 2020 (UTC)
Fair question. According to my understanding of this policy, if future changes are announced in advance, it would violate that policy to implement the changes to those pages prior to August 1, when they go into effect. Talk page consensus on both articles was to create the subpage to hold the changes until the changes become effective on August 1. As a result, I have established subpages to my user page for each article for the last several years. But the problem is that simply copying and pasting the subpages into the main articles from which they originate would not also transfer the edit history of the subpages, which is necessary information when it comes to page continuity. I have not yet found an acceptable workaround to this issue. Hope the additional context helps. Thanks. --Jgstokes (talk) 03:49, 3 August 2020 (UTC)
You're the only substantial editor of User:Jgstokes/Area (LDS Church)/August 2020, which has edit history dating back to late January. The main article hasn't stood still in the last six months; substantial changes appear to have been made in March and April. When you make your edit to merge in the new changes, you could just state in your edit summary, "merging in content from User:Jgstokes/Area (LDS Church)/August 2020, per WP:CWW" or something similar. As long as your subpages aren't deleted they can remain open for review by anyone interested. – wbm1058 (talk) 15:30, 3 August 2020 (UTC)
Thanks for the suggestion. I think that would work. I may look into finding a better option for making such changes in subsequent years, as I've been in contact with someone else on that subject. In the meantime, thanks again for your help in this matter. I appreciate it. --Jgstokes (talk) 19:49, 3 August 2020 (UTC)
Right, the bot expects that to be in sync with the template parameters. I don't follow the point of the switch; I just reverted it and the bot is happy again. wbm1058 (talk) 19:07, 14 August 2020 (UTC)
For some reason, you keep deleting the proposed name from "Requested moves" and replacing it with a question mark - I understand you're a bot, and therefore, asking whoever is involved with it to look into this problem.
Talk:Kiev#Requested_move_1_July_2020 was started July 1 and closed the next day. That same RM has been reopened now, August 28. It contains a number of comments in a non-standard format (ie the admin comments above), and the nomination is a bit of a mess and was later edited. The bot doesn't seem to be updating the listing, however. I'm not too familiar with how the bot works, but I imagine the formatting there needs to be fixed up in some way so the bot can make sense of it. ProcrastinatingReader (talk) 18:58, 28 August 2020 (UTC)
@Jac16888:This edit should fix it. Basically, the proposed move is to Louane (singer) which already exists as a redirect, so the bot was attempting to notify its talk page, which also being a redirect, sent the bot off somewhere else. Unfortunately, OccultZone (talk·contribs) made a mistake in setting up the redirect - talk pages should never redirect to mainspace. --Redrose64 🌹 (talk) 00:04, 6 January 2018 (UTC)
I noticed your bot posted both the boilerplate and talk page message on the mainspace article. See this diff. I tried to revert, but the message was re-added in the next bot cycle. Could you check what is causing this? Aloneinthewild (talk) 14:51, 14 October 2018 (UTC)
I figured it out, the proposed location talkpage was a redirect to the existing mainspace article (rather than the talk). Quite simple. Aloneinthewild (talk) 14:54, 14 October 2018 (UTC)
Thanks for letting me know. I suppose I should add a check to ensure that these notices are only posted to talk pages, though in theory that shouldn't be necessary. The bigger question is why a talk page is allowed to redirect to main space for over 5 years. There should be some process that ensures that doesn't happen! wbm1058 (talk) 17:53, 14 October 2018 (UTC)
Bot adding message to article, not talkpage
At Bushfires in Australia, RMCD bot keeps adding a notice to the bottom of the article about the move discussion on the talkpage.[11][12] There is already a move template at the top of the page, added by RMCD bot, about the discussion.[13] The edit summary used for the addition to the article is "Notifying talk page of move discussion on Talk:Bushfires in Australia. The notice being added is not necessary on either page. --AussieLegend (✉) 16:16, 15 September 2020 (UTC)
And I addressed the systemic issue of talk-to-mainspace redirects HERE. There were over 1,200 of them before I cleared the list. – wbm1058 (talk) 20:05, 13 January 2021 (UTC)
Don't requested move notices count as "maintenance tags" under MOS:ORDER? If so, the bot should place them beneath hatnotes and protection tags, which it doesn't currently do (see [14] for example). — Goszei (talk) 18:09, 11 December 2020 (UTC)
Goszei, limited MOS:ORDER compliance to place the notices below hatnotes was implemented in November 2017, see the previous discussion about that in the archives. Template:Short description was just created on 1 November 2017 and wasn't on my radar when I implemented my MOS:ORDER fix. The problem here is that the bot wasn't recognizing {{Short description}} as a valid "super-hatnote" that the bot should place its notice below, so this issue was happening on any page with a {{Short description}} which nowadays is quite a lot of articles.
Fixed by bot v. 7.43, at least up to the standard set in 2017. Coding for full compliance with MOS:ORDER, including workarounds for other editors who previously haven't complied, can get pretty complex, as discussed in the 2017 archive. Thanks for bringing this to my attention. – wbm1058 (talk) 21:50, 12 December 2020 (UTC)