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.
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)
Checking the edit history of pages to see if the bot has previously been reverted is something that could be done, though coding for that isn't a quick 'n easy task. I view this as checking for symptoms. For example you could watch for fuel leaks on the launchpad (symptom) and abort the launch upon detection, but you'll still want to find and fix the source of the leak before restarting the countdown. If this was life and death task I would surely do that, but resources are stretched thin around here, so just keeping this on the back burner for now. – wbm1058 (talk) 21:31, 12 June 2020 (UTC)
This incident has convinced me that I need to bump up the priority of this task; seems I'll never plug all the holes enabling the bot to edit-war as users will always find another way. This is my next significant task, as soon as I make time for it. – wbm1058 (talk) 19:11, 21 October 2021 (UTC)
mw:API:Revisions documents the API for getting the content of pages, including the page history (all revisions). The framework's getpage function sets rvlimit=1 which limits the server to providing only the latest revision. Replacing this with rvend= specifying a timestamp with a sufficient window to detect the same previous edit that was subsequently reverted will enable the framework to stop apps from edit warring. Not sure what the default timestamp should be (1 day, 1 week?) but the RM app could specify the timestamp of the edit that started the RM. – wbm1058 (talk) 15:45, 16 November 2021 (UTC)
I spent some more time thinking about how to do this. Most of the time after the bot gets (getpage) a page it decides that it does not need to POST an update. So getpage just the latest revision is fine.
There's only a need to check for previous bot edits to a page AFTER it has decided it should POST, i.e. edit a page.
Only then call a new function to get an array of previous editors and edit times (no need to get previous content, I don't think) and check whether the bot was a recent editor, especially with multiple recent edits.
This new function will often be called just after nobots has made sure the bot is allowed to edit the page.
Facepalm – I started working on adding a new function to the bot's framework yesterday, and that function had a syntax error (a missing ".") and then I wasn't paying attention because I hadn't yet coded anything to actually call the function. Sorry about that, and thanks for the heads-up. I've been multi-tasking and working reducing on another backlog so far this morning. Need my coffee to kick in before I get back to coding. – wbm1058 (talk) 14:20, 14 December 2023 (UTC)
The bot cannot place notices on CSS pages; I see this error message:
Invalid selector list at line 1 character 1. Invalid selector list at line 2 character 1.
Then since there's no notice on the pages; the bot assumes that the discussions have closed and thus removes the templates from the talk pages of the others in this multi-move request.
So, as with Lua modules, CSS pages are special cases that need special handling. Hmm, I see Wikipedia:TemplateStyles – I need to familiarize myself with that.
Bot version 7.41 added a check to catch requests to move CSS pages, and handle them in a similar way as requests to move Lua modules. I'm not sure whether there's anything more I need to do here. – wbm1058 (talk) 15:01, 20 October 2021 (UTC)
OK, the v 8.41 fix would have stopped the bot's edit-warring here. Not sure about how well the bot may handle future requests to move CSS pages, but I'm dropping this from my to-do list and will deal with any new CSS page-move issues as they may happen in the future. Really, these moves are borderline out-of-scope for RM. – wbm1058 (talk) 23:43, 19 February 2024 (UTC)
Ba'ath Party
Ba'ath Party (disambiguation) and Talk:Ba'ath Party (disambiguation) each have hundreds of deleted edits (I buried them to remove the clutter in the page histories) dating from 11:06, 16-Oct-2020. This problem persisted for over three days before I was notified here.
At 08:38, 16 October 2020 a multi-move RM was started without closing the above single-page RM. It would be nice if I could "blacklist" this edit from being allowed to be saved.
The bot's edit warring started after the 10:48, 16 October 2020 procedural close and persisted until my 21:00, 19 October 2020 edit, which was the second procedural close. – wbm1058 (talk) 17:57, 21 October 2021 (UTC)
Bot is still not removing notices from multi-move request after someone removes the mass-move request on the original talk page.
Hi, a vandal has returned to make a vandal mass-move request earlier today on a random talk page. The bot posts on every talk page alerting watchers that they should participate in the original talk page of where the mass move request takes place. After someone removed the mass move request for vandalism, the bot removes the transcluded notice off the talk pages from the same group of pages but the text stays put. (Example: as seen on the bottom of this talk page at 10:38 today (UTC). I know this sort of thing does not happen very often but I think that issue should be fixed so that users like me and Struway2 for example does not have to manually remove nonsense posted by a good bot themselves which, of course, only edits by it's programming. Thanks, Iggy (Swan) (Contribs) 16:40, 13 October 2021 (UTC)
I implemented a 20-minute delay before posting notices on other pages in May 2020. A couple of previous vandalism posts of this sort were each reverted after nine minutes. In this case, 52 minutes passed before the revert. I could make the bot wait a full hour before posting these notices, but then I might see people asking me here why the bot is so slow in posting notices. I suppose it's a trade-off. Or maybe increase the delay time for multi-moves with more than a small number of pages involved. If Seasider53 had reverted rather than shrug, then time to revert would have been 35 minutes. – wbm1058 (talk) 23:41, 13 October 2021 (UTC)
@Wbm1058: I spent thirty minutes reverting them before realising how futile it was, since it will likely happen again. I think we need competent bot owners. Seasider53 (talk) 23:45, 13 October 2021 (UTC)
Oh. So sorry to see you wasted so much time doing that. Why didn't you make THIS your first edit? The bot would not have edit-warred with you if you had. I guess I need to either bite the bullet and implement code to detect reverts of bot edits, or just pull the plug on notices and just stop posting them altogether. I'm guessing it could take me a couple days or more to implement edit-reversion detection handling. The lack of experienced editor/administrator oversight of the RM process at times is frustrating. – wbm1058 (talk) 00:44, 14 October 2021 (UTC)
My guess would have been that Seasider53 is not familiar with the usual behaviour the vandal has been doing this and last year. I actually missed those replies linked from the discussions I started back in 2020, and there are good points explained there. Additionally @Gricehead: suggested an edit filter to disallow certain strings commonly used in those mass move vandal requests & regularly affected articles, since that filter was active the vandal appeared to stop doing that until yesterday. If that filter can be modified, that would help stop the bot making loads of invalid edits over a small period of time as well. See the relevant edit filter request discussion. Thanks, Iggy (Swan) (Contribs) 06:13, 14 October 2021 (UTC)
@Wbm1058: I think the issue is that on the article page, e.g. here, the bot does remove the whole of its addition, but on the associated talk page, e.g. here, it leaves some behind. If it reverted the whole of its addition, there wouldn't be a problem. cheers, Struway2 (talk) 12:02, 20 October 2021 (UTC)
Struway2, notices on article pages are intended to be temporary, only posted while the RM is still open. In contrast, the talk page notices are intended to last forever, or until archived, as a permanent record of historical move requests. Yes, ideally the bot would be smart enough to distinguish between legitimate requests and vandalism, and would revert only the vandalism, but... Your struggle with my bot to revert the vandalism has convinced me to make this task a high priority, and I intend to implement that fix before I address the specific issue here any further than I already have by implementing the 20-minute delay. – wbm1058 (talk) 19:27, 21 October 2021 (UTC)
Thanks for the explanation. I did realise (after posting, obviously: sorry I'm a bit slow) that was probably the reason the bot left the notice in place. cheers, Struway2 (talk) 20:06, 21 October 2021 (UTC)
I might could write a bot that patrolled for these by monitoring recent changes in talk namespaces, and parsing out edits ending with standard-format signatures. Would be an interesting project. – wbm1058 (talk) 23:11, 18 February 2024 (UTC)
Currently, the bot puts {{User:RMCD bot/subject notice|1=New name|2=Discussion link }} at the top of articles requested to be moved. With the recent move to Template:Title notice, the bot should be updated to instead put {{Title notice|1=New name|2=Discussion link}} with no space between the discussion link (usually ending with the year, currently 2019) and the closing braces, and remove transclusions of both the template and the userspace redirect after move discussions are closed. GeoffreyT2000 (talk) 23:21, 7 August 2019 (UTC)
Coding to support a transition to a new template name isn't as easy as you might think. I have recently made a series of updates to support the new name, and only after I did that, did the bot find and remove these (one), (two), (three) "off-label" uses of the template (where no formal discussion was ever opened). I anticipated that this off-label usage would happen, so I coded the bot to patrol for and remove notices placed on articles without any discussion started on their talk. My thought was that giving the template the bot's name would discourage such off-label usage, which is why I'm hesitating to complete the changeover. I have noticed though, that putting the bot's name on the template hasn't fully discouraged editors from manually placing or editing the template as I'd hoped. I guess I kind of have the same question others are asking you at Wikipedia:Deletion review#Template:Movenotice – what problem is the rename solving?
Moved from User talk:wbm1058
