Cannabis Ruderalis

thcscience_admin
Some sections have been refactored to consolidate multiple reports of the same issues.
Fixed or otherwise resolved issues are archived, so this page serves as a sort of to-do list.

Frequently asked questions

Problems caused by syntax redundancy, when an RM is modified while open[edit]

See also: Template talk:Requested move § Move links

Issue with bot's function?[edit]

I was looking at some RfDs today, and found these two strange diffs on Talk:Cherkasy Raion:

[1]

[2]

I'm not sure what's going on there, but those two diffs are telling the editor/user to go to Talk:Cherkasy Raion from Talk:Cherkasy Raion, the same talk page. Steel1943 (talk) 07:22, 17 February 2013 (UTC)[reply]

  • There's a third diff now, taking the exact same action as the previous two diffs:
[3]
...What's going on with this bot? Steel1943 (talk) 09:52, 17 February 2013 (UTC)[reply]
It looks like the bot was confused after this edit. There is a second, redundant place where corrections of this sort need to be made, and I covered it here. I'm aware of this issue and eventually may simplify the templates to remove this redundancy. Wbm1058 (talk) 23:32, 17 February 2013 (UTC)[reply]

Talk:Line_1,_Beijing_Subway#Requested_move_29_December_2017 malformed?[edit]

Hi wbm1058, I haven't been able to figure out why the move request at Talk:Line_1,_Beijing_Subway#Requested_move_29_December_2017 is listed by the bot as malformed. It seems to have been set up correctly.--Aervanath (talk) 21:15, 30 December 2017 (UTC)[reply]

I fixed it. wbm1058 (talk) 21:36, 30 December 2017 (UTC)[reply]

Anthony Davis pagemove[edit]

I failed to include the secondary page move in the template.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 03:55, 14 September 2018 (UTC)[reply]

Fixed. This is another case of problems with modifying open RMs. — Preceding unsigned comment added by Wbm1058 (talk • contribs) 14:33, 14 September 2018 (UTC)[reply]

Bad edit[edit]

This seems to be a bad edit. Korny O'Near (talk) 00:55, 11 October 2021 (UTC)[reply]

(talk page stalker) @Korny O'Near: Hopefully, this "new1" parameter-fixing edit will fix the problem. GeoffreyT2000 (talk) 01:06, 11 October 2021 (UTC)[reply]
Never mind, I didn't notice that parameter. I guess it wasn't the bot's fault after all. Thanks! Korny O'Near (talk) 01:42, 11 October 2021 (UTC)[reply]
This is another example of #Problems caused by syntax redundancy, when an RM is modified while open, caused by this 22:53, 3 October 2021 edit by Tbhotch. That edit needed to change "Disney" to "American" in two places. Now the "problems" have expanded to include the subject notices (which I added as a later enhancement). – wbm1058 (talk) 14:17, 20 October 2021 (UTC)[reply]

Bot is deleting wikiproject banners[edit]

see [4] where the bot deleted a wikiproject banner with the summary "Notifying of move discussion" -- 65.92.180.137 (talk) 23:09, 18 March 2013 (UTC)[reply]

This is interesting. The bot did just fine when it first posted the notice at 03:00, 6 March 2013.
Seven days later, after leaving the notice undisturbed for a week, at 00:14, 13 March 2013 it removed the project template and updated its timestamp.
That's not the only talk page banner it disturbed with that update. Also:
This seems to be some one-off glitch—I've not seen this bug before. It may be a side-effect of some other issue, and could be hard to track down. Wbm1058 (talk) 13:43, 19 March 2013 (UTC)[reply]
Whatever the bug is, it is causing a wholesale overwrite of the entire talk page, from what I can see, it deletes the entire talk page, and replaces it with the new notice. -- 65.92.180.137 (talk) 06:18, 20 March 2013 (UTC)[reply]
Excellent observation! It could be something more like this type of problem. I'll put it on my list to check the code to see if any edit checks can be made to prevent it. Wbm1058 (talk) 15:14, 20 March 2013 (UTC)[reply]
The Wikipedia:Requested moves/Current discussions update of 00:16, 13 March 2013 doesn't really give any clues, unless it's related to the "Time could not be ascertained" bug. I should fix that one. – Wbm1058 (talk) 14:00, 19 March 2013 (UTC)[reply]
Lightbulb.png I think I finally realize the cause of this (an API function's failure to retrieve the page content when asked), and will get right to implementing the solution, which is to not update the page at all rather than break it. Wbm1058 (talk) 20:15, 13 December 2014 (UTC)[reply]
Fixed, hopefully. Wbm1058 (talk) 20:43, 13 December 2014 (UTC)[reply]
Not fixed yet. The bot needs to be able to tell the difference between a page that has no content because it doesn't exist (normal), and a page which appears to have no content (but probably really does) because the server was down or bits got lost on the Internet. Wbm1058 (talk) 14:44, 15 December 2014 (UTC)[reply]
See how Reflinks deals with this. Wbm1058 (talk) 18:07, 20 December 2014 (UTC)[reply]

Followup after moves and/or closes[edit]

bot on overdrive on a closed RM[edit]

this was just added by RMCD bot re an RM closed weeks ago.....how do you turn the damn thing off?Skookum1 (talk) 18:15, 1 April 2014 (UTC)[reply]

I think the move template – not the discussion, or the decision – should be removed when discussion is closed. The same thing happened with an RM I posted some weeks ago. Remind the closing editor. HandsomeFella (talk) 18:42, 1 April 2014 (UTC)[reply]
See this edit. I then reverted the bot's additions of the discussion on the fresh redirect pages. HandsomeFella (talk) 18:45, 1 April 2014 (UTC)[reply]
OK, the issue at Talk:Alpine skiing at the 2014 Winter Olympics – Men's super-G was that the RM closer neglected to either remove the {{requested move/dated}} template or replace it with {{requested move/old}}, which is intended to be a valid alternative. These are generally caught fairly promptly, as they populate Category:Fulfilled page move requests. Actually, the oversight was fixed within an hour and a half, but the bot runs every 15 mins. Now, the deal with Talk:Mi'kmaq people is that the bot was getting confused between the two requested moves at Talk:Chipewyan people. The first RM was closed with a {{requested move/old}}, but an issue with the bot's coding resulted in this template being used in error for the second, still open RM. I did a {{subst:requested move/old}} which worked around the bot issue, and reverted the bot's bad edits. – Wbm1058 (talk) 01:57, 2 April 2014 (UTC)[reply]

Notifying talk pages that are named in multi-move requests[edit]

It's nice that the bot can be used to notify talk pages that are named in multi-move requests. What is needed is a follow-up notification to those talk pages that reports on the result of the request. 67.100.127.30 (talk) 19:45, 15 November 2014 (UTC)[reply]

See Talk:Zain for an example. I implemented a manual solution, but I agree that an automated solution along these lines would be helpful. – Wbm1058 (talk) 20:55, 12 June 2015 (UTC)[reply]

Removing notice of open discussion[edit]

The bot removed the requested move template on Other (philosophy) and unlisted it from Wikipedia:Requested_moves/Current_discussions despite the fact that the discussion does not appear to have been closed. 93 14:59, 29 August 2017 (UTC)[reply]

An editor, presumably unintentionally, removed the template, effectively "closing" the discussion as far as the bot was concerned. I've reverted that template removal, so the notice should be re-posted in a few minutes. wbm1058 (talk) 17:41, 29 August 2017 (UTC)[reply]

Bot-created searchable archives[edit]

On my back burner is a possible enhancement (see WT:Requested moves#Bot-created searchable archives). – wbm1058 (talk) 16:08, 25 January 2020 (UTC)[reply]

Requests for comment on requested moves[edit]

See Wikipedia talk:Requested moves/Archive 28 § Use requests for comment for supplemental RM notifications? Note to myself to document or develop a workaround. – Wbm1058 (talk) 23:28, 2 November 2015 (UTC)[reply]

  • My edit to add a sub-section header. That doesn't work.
  • Another editor's fix: put the RM template before the RfC template.
  • Bot's edit to fix the RfC subpage.

— Wbm1058 (talk) 23:48, 2 November 2015 (UTC)[reply]

Blast from the past: RM bot's old to-do list[edit]

I suppose when I took over this process, I inherited the to-do items listed at User:RM bot/TODO. A copy of that is below, and I will check on the status of each and respond below. – wbm1058 (talk) 10:56, 21 August 2016 (UTC)[reply]

Pending:

  • Investigate issues with user pages per Vegaswikian
    • We really need to get the bot running every 15 minutes starting at the top of the hour. Going several hours without updates is not acceptable.
      Windows Task Scheduler has my bot running every 15 minutes. Quite reliable, but for the occasional power outage or system hangup requiring a reboot that happens while I'm sleeping or away. wbm1058 (talk) 17:42, 17 March 2022 (UTC)[reply]
    • If a user lists a user page and it winds up at the bottom of the list due to an error, fixing the errors can cause the listing to disappear for a few runs before it reappears. This does not apparently happen with regular namespace pages.
      {{subst:Requested move}} doesn't allow user pages to be listed: Template:Requested move is not for moves from draft or user space.
  • Follow redirects when posting messages on talk pages per Arthur Rubin
    When the target's talk page is a redirect to a different page other than the page which has been requested to be moved, the bot follows that redirect, and if that target's talk page has non-redirecting content, the bot posts a notice there too. (v 5.21)
  • When discussions are archived, may be initially showing up as incorrect syntax; example
    This RM closed at 06:01, 26 October 2011, four minutes before the bot wrote its report at 06:05, 26 October 2011. If the bot began processing at the top of the hour, then the RM closed while the bot was running. The error message This move request does not use the accepted syntax. Please fix. must be something HardBoiledEggs added in a version of the code he never published. It's never been in any of my versions. This seems to have been an "edit conflict"; see § RMCD bot: edit conflict. – wbm1058 (talk) 17:42, 17 March 2022 (UTC)[reply]
  • Find statistics (esp. historical) for mabdul
    Still no formal statistics collection, but maybe someday. – wbm1058 (talk) 17:42, 17 March 2022 (UTC)[reply]
  • Resolve issues in display of unsigned move requests per Station1 and IP
    We avoid issues with unsigned requests by making {{subst:Requested move}} automatically sign. This resulted in occasional doubly-signed requests; the bot now detects and reports these to my console, and occasionally I remove the redundant signatures, e.g. HERE, HERE, and HERE.

About time I got around to reviewing this, five years after I said I would! wbm1058 (talk) 17:42, 17 March 2022 (UTC)[reply]

Broke formatting[edit]

The bot displays broken formatting when you try to include multiple suggested targets in one RM, as I tried to do here. Pppery 20:42, 24 February 2017 (UTC)[reply]

If you are uncertain about what the new page names should be, then you should use the "?" form of request, as demonstrated in the last example in Wikipedia:Template messages/Moving/Requested. The bot reads the template parameters and uses those only to generate the listings at WP:RM. You can do whatever you want with the list of moves which is shown outside the template, as the bot doesn't care about or look at those. wbm1058 (talk) 00:09, 25 February 2017 (UTC)[reply]
No, the {{requested move/dated}} transclusion on that page was properly formatted showing only one target, and the bot failed to properly skip over the list shown outside the request. As you can see here, the bot included by proposed alternate title as if it were part of the reason. Pppery 01:08, 25 February 2017 (UTC)[reply]
OK, the bot was trying to skip over all that and jump to the reason, but a couple of curve-balls tricked it. (1) the bot is looking for an en-dash as the separator indicating where the reason starts. Now, it knows enough to ignore false-positive en-dashes when they are included inside the standard-formatted request. Since your "or this–alternatives" were outside of the expected standard formatting, the first one found was interpreted as the beginning of the reason. Then you get a mangled reason because inside the reason are what appear to be more standard-formatted requests that the bot strips out of the reason. This is all tricky regex to implement and I don't know regex like the back of my hand. I'm not going to attempt to support this, because it is theoretically impossible to create an RM in this format. The idea behind using {{subst:requested move}} is to prevent unsupported syntax in requests, but of course I can't stop editors from hacking up perfectly well-formatted requests after their initial creation. Suggest you use {{subst:requested move}} to create a "name to be determined via discussion" request, and then put your list of alternatives in a separate section below your brief rationale for the move request and your signature. Thus, the discussion of alternatives will only be seen on the talk page hosting the discussion and not get copied to the WP:RM page. wbm1058 (talk) 02:41, 25 February 2017 (UTC)[reply]
Which would take up a lot of unnecessary space, considering the request involves over 100 articles. Would it make sense for the bot to ignore en-dashes in links? Pppery 02:45, 25 February 2017 (UTC)[reply]
I'm not keen on huge proposals like this. Maybe you could start a more general discussion about the naming conventions on the talk page for the relevant naming conventions or WikiProject? If you can get a consensus on naming conventions, then perhaps these become technical requests. wbm1058 (talk) 03:07, 25 February 2017 (UTC)[reply]
Which is what eventually happened at Wikipedia:Naming conventions (US stations)/NYC Subway RfC. These moves eventually happened after that discussion closed. – wbm1058 (talk) 12:23, 5 October 2021 (UTC)[reply]

December 2017–January 2018 changes:

  • On 23 December 2017‎ Nardog changed Module:Requested move to "don't add the dash if multiple", without discussing the matter with me first
  • At 14:20, 25 December 2017, rather than revert Nardog, I made bot version 6.55 accommodate the removal of the dash from multiple move requests in Module:Requested move (thanks for calling me in to work on the holiday!)
  • At 22:08, 19 January 2018 Pppery reverted Nardog's change: "seems to break bot parsing for users who have a dash in their signature"

My "accommodation" code for this change remains in place. – wbm1058 (talk) 14:47, 5 October 2021 (UTC)[reply]

Disambiguation pages[edit]

When a disambiguation page without a talk page is requested to be moved on another talk page, the bot should automatically place {{WikiProject Disambiguation}} on top of the "Move discussion in progress" notice while creating the talk page. I have manually added the template to Talk:United States v. Lee (disambiguation). GeoffreyT2000 (talk) 20:19, 13 June 2017 (UTC)[reply]

 Done in v 6.81 – wbm1058 (talk) 12:26, 7 April 2019 (UTC)[reply]

@Wbm1058: I noticed something is still wrong with the patch. Namely, Talk:CMY (disambiguation) was not actually created with the WikiProject on it. Please try to identify the error with the code that causes this, and fix it. Also, if page A is being requested to be moved to B, page B currently redirects to a disambiguation page C other than page A, and page C does not already have a talk page, then the bot should place {{WikiProject Disambiguation}} as well while creating the talk page for page C. This did not happen with Talk:Tremont Avenue (disambiguation), for example. GeoffreyT2000 (talk) 04:37, 24 August 2019 (UTC)[reply]

 Done in v 6.92 – it's always easier to make a fix while an RM is open, as that provides a use-case for testing. I verified the patch with Talk:Tremont Avenue (disambiguation). However the Talk:CMY (disambiguation) wasn't easy to reproduce. I found that with most move requests of this nature the bot doesn't post a notice (i.e. it doesn't create a new page) as there is no point in creating a notice for a page with no content. So I dug a little deeper to see what was happening here. This request was created by an editor who seemed unware of disambiguation policies and conventions, and who failed to follow the instructions for starting an RM via {{subst:Requested move}}. The bot didn't pick up the request until another editor added a section header for it. At the time the "content" that made the bot decide that a notice was needed was a fork of CMY, which was later changed to the {{r to disambiguation page}} that should have been there all along (and would not have had a talk page notice created for it). So, given the cause of the issue was user error, and the user error didn't break anything significantly, I'm not going to try to accommodate this now; very low-priority issue. If there's anything for the bot to do here, I think it should be able to recognize the existence of a disambiguation fork, and report that as an error, while refraining from creating the Talk:CMY (disambiguation) page that the user error triggered. – wbm1058 (talk) 21:08, 26 August 2019 (UTC)[reply]

Feature request[edit]

Currently at the top of Wikipedia:Requested moves/Current discussions, Wikipedia:Requested moves/Current discussions (alt), and Wikipedia:Requested moves/Current discussions/Table, there is a lead section with an ombox and some text. Could you move this content into templates and have the bot transclude these instead? That way we can edit the text and add special notices if needed. —Guanaco 10:34, 18 June 2017 (UTC)[reply]

Bot wars[edit]

Page set up to archive threads after 5 days (120 hours) with no new comments causes an RM to be archived before it was closed[edit]

Hi wbm1058

I hope I'm in the right place... the headers of this page are confusing to me.

Anyway, as you obviously found this, have a look at https://en.wikipedia.org/w/index.php?title=Talk:Medal_of_Honor_(series)&action=history for an unfortunate interaction between bots which Dekimasu seems to have sorted out.

One result was that for a while, the discuss link at WP:RME pointed to Talk:Medal of Honor (series)/Archives/2018/March rather than to the discussion. Andrewa (talk) 05:13, 13 March 2018 (UTC)[reply]

To be clear, the discussion was there (and open) in the archive, although it was showing up as a malformed request on the RMC page. When I reverted the bot, I also deleted the empty archive as G6, routine cleanup. Dekimasuよ! 05:29, 13 March 2018 (UTC)[reply]
Thanks, I stand corrected. I just followed the link to an archive page, knew it was wrong, and looked for why, but by the time I found out very much more you'd fixed it. Andrewa (talk) 05:51, 13 March 2018 (UTC)[reply]
Now I've seen everything. I suppose my bot should patrol for stupid archiving configurations. This page was set up to archive threads after 5 days (120 hours) with no new comments. Yeah, that's a problem when requested moves are scheduled to run for seven days and nobody comments on the RM after the second day that it was open! wbm1058 (talk) 10:57, 13 March 2018 (UTC)[reply]
Thanks. Nothing is foolproof, because fools are so ingenious! I certainly wouldn't modify the bot on one occurrence. If it became a regular thing, it may be better to modify the archive bot... say, have a template adding a banner and category to the talk page, to indicate that the page is temporarily not to be archived, which might stop some stupid manual archiving too (I said might... hmmm, but that needs a mod to your bot too, to add and remove the template). But even if I'd figured out what the problem was, it was something I think you needed to see. Andrewa (talk) 16:44, 13 March 2018 (UTC)[reply]
Changed it to two weeks, 1 year is overkill for any kind of archiving. --QEDK (後 🌸 桜) 16:45, 13 March 2018 (UTC)[reply]
OK, and if the RM is relisted then the two weeks automatically restarts for that section, because relisting is itself an edit even if there's no other activity... that sounds logical to me, interested in other views. Andrewa (talk) 17:38, 13 March 2018 (UTC)[reply]
There will be no talk page threads most of the time with that setting. Two weeks is an extremely short period for all but the most active articles; I'm not sure why there would be a preference for the talk page to be empty. Actually, given that there is so little action on the page, manual archiving is probably a better option. Also, the RMCD bot isn't updating the moves page now, I think. Is it down or being reworked? Dekimasuよ! 17:41, 13 March 2018 (UTC)[reply]
I have collated the 4 existing archives into one archive that's still only 15K and turned off the auto-archiving. There's no need for archives that look like this, because they don't help us search for relevant previous discussions. On a normal talk page, it would be just fine to have all the talk topics since the creation of the article over ten years ago still on the main talk page, but I haven't taken the step of dearchiving everything. Dekimasuよ! 17:48, 13 March 2018 (UTC)[reply]
Good points all. But this is on archiving rather than on the RM bot. Dekimasu and QEDK, I'd be very interested in continuing this discussion, but I think we should find a better place for it, and leave the bot and its owner in (exonerated) peace. Andrewa (talk) 17:57, 13 March 2018 (UTC)[reply]
I agree. However, the real reason I came by again was to get confirmation that Wbm knows the bot is down, and he does, so I feel reassured as well. Dekimasuよ! 18:07, 13 March 2018 (UTC)[reply]
Or, maybe have a flag on a section that says not to be archived and is respected by archive bots? And add that flag to every properly raised RM (needs a mod to one template)? And remove (or override with another flag, that sounds simpler but is a bit ugly) the no-archive-section flag when the bot sees it as closed (and maybe make it available for immediate archive... that could use the archive-section-anyway override flag and makes it a lot less ugly).
No action on one occurrence, as I said above. Andrewa (talk) 17:53, 13 March 2018 (UTC)[reply]

I agree with Dekimasu re archiving. I'm trying to update to a newer version of PHP, and running into problems. I'm about to give up and revert to the version that works. Then I can futz with trying to upgrade on my other system. I wasn't expecting updating to be so difficult. wbm1058 (talk) 17:54, 13 March 2018 (UTC)[reply]

  • Added a bit of code to the placeholder on the page, not sure if I can do anything else. --QEDK (後 🌸 桜) 18:33, 13 March 2018 (UTC)[reply]
Better option may be a bot to patrol all talk pages transcluding User:ClueBot III/ArchiveThis and check their archiving configurations, and report all pages with overly aggressive archiving setups, including setups changed by _cough_ *vandals*. – wbm1058 (talk) 19:42, 5 July 2018 (UTC)[reply]

RMCD bot: edit conflict[edit]

I'm not sure what this edit is about... did the bot get confused somehow (or am I)? I've already closed the RM as move, I hope that was OK! Andrewa (talk) 19:39, 25 September 2018 (UTC)[reply]

This rhymes with similar "edit-conflict" issues I previously fixed; see User talk:RMCD bot/Archive 1#RMCD bot alert. Unfortunately the bot's console log overwrites itself each time the bot runs, so the internal diagnostic report is lost already. I'll probably need to intentionally reproduce this scenario to follow the processing and confirm a fix, though I may be able to figure it out with a code-walkthrough. Thanks for the report. – wbm1058 (talk) 22:43, 25 September 2018 (UTC)[reply]
All good. It's a brilliant system overall. "Unfortunately, Andy, the closer we get to true artificial intelligence, the closer we also get to artificial stupidity." - My favourite AI expert who may not want to be named. Andrewa (talk) 06:36, 26 September 2018 (UTC)[reply]

An edit conflict that invoked "Error 2"[edit]

See Talk:Darksiders#Move discussion in progress. – wbm1058 (talk) 21:20, 2 September 2019 (UTC)[reply]

Strange placement of notice[edit]

I've just closed a requested move at List of skin conditions, but I noticed that RMCD bot seems to have placed the RM notice in a strange place, it is in ref 43. I was wondering if there is any reason you can see for this bug. Danski454 (talk) 12:03, 17 June 2019 (UTC)[reply]

Danski454, thanks for reporting this. Ideally I would have been notified about this sooner, while the RM was still open. The bot endeavors to comply with MOS:ORDER, so I suspect it got confused by this template:
{{cite journal |author=Ushiki T |title=Collagen fibers, reticular fibers and elastic fibers. A comprehensive understanding from a morphological viewpoint |journal=Arch Histol Cytol |volume=65 |issue=2 |pages=109–26 |year=2002 |pmid=12164335 |doi=10.1679/aohc.65.109 |url=https://www.healthyki.com/2019/01/amazing-facts-about-acne-all-will-shock.html }} |date=December 2017 |bot=InternetArchiveBot |fix-attempted=yes }}
thinking that template belonged with the hatnotes placed "before the lead section" and thus the notice was placed after that template. It's not immediately apparent to me why. This involves regex (regular expressions) which aren't easy to code to perfection at times. As this seems to be a one-off that I've never seen before, I'm giving it a mid-priority, meaning that the next time something like this happens while an RM is open, I expect I would likely bump up the priority then and try to fix it before the RM closed. – wbm1058 (talk) 15:16, 17 June 2019 (UTC)[reply]
On second look at this a drive-by IP partially removed a template, leaving bad syntax that my bot wasn't smart enough to detect – This edit fixed it. wbm1058 (talk) 14:52, 20 June 2019 (UTC)[reply]

Twisted RM[edit]

Please take a look at the RM at Template talk:Infobox medical condition (new)#Requested move 3 July 2019. Is it SOP for this type of malformed RM to not end up in that section at WP:RM? Take a look at that RM's ridiculous entry at Wikipedia:Requested moves#July 3, 2019. "I am so confused!" — Vinnie Barbarino – Paine Ellsworth, ed. put'r there  22:57, 3 July 2019 (UTC)[reply]

Please note at this point that the nom has withdrawn and moved the template back to its previous name. Still doesn't mean I'm not confused, tho. :>) In case you didn't see it, the entry on the WP:RM page was Template:Infobox medical condition (new) → Template:Infobox medical condition (new). Weird. Paine Ellsworth, ed. put'r there  00:06, 4 July 2019 (UTC)[reply]

So you closed the RM as moved page Template:Infobox medical condition (new) to Template:Infobox medical condition. Then the move was boldly reversed, rather than asking you to reopen it. So what we had was {{requested move/dated|Template:Infobox medical condition (new)}} sitting on Template talk:Infobox medical condition (new). The system doesn't assume that this is a malformed request, but rather a fulfilled move request. {{requested move/dated}} displayed The request to rename this article to Template:Infobox medical condition (new) has been carried out. and populated Category:Fulfilled page move requests. So it was in a state that should have been fairly promptly patrolled.
Nonetheless I see that Template:Requested move seems to be missing an edit check to flag requests to move a page to its current location as an {{error}}, and I suppose the bot should also check for edits to previously-submitted RMs to do that. – wbm1058 (talk) 21:46, 9 October 2019 (UTC)[reply]

Use Template:Title notice instead in articles[edit]

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)[reply]

The space between the discussion link and the closing braces isn't there anymore – see editing to remove a space. – wbm1058 (talk) 19:16, 17 March 2022 (UTC)[reply]
But the bot currently still adds {{User:RMCD bot/subject notice|1=New name|2=Discussion link}}. Could you please update the bot to add {{Title notice|1=New name|2=Discussion link}} instead? GeoffreyT2000 (talk) 15:09, 20 March 2022 (UTC)[reply]

Bot not detecting some transclusions of {{Reflist-talk}}[edit]

RMCD bot isn't putting some redirects to {{Reflist-talk}} on a new line, causing rendering issues as seen in two entries of the current backlog. In case it's useful, there is a full list of all redirects to {{Reflist-talk}} below.

Extended content
{{Reflist-talk}}
{{Reflist talk}}
{{Talk-reflist}}
{{Reftalk}}
{{Talk reflist}}
{{Talk ref}}
{{Ref talk}}
{{Reference talk}}
{{Talk reference}}
{{Talkref}}
{{Tref}}
{{TREF}}
{{Talk page reference}}
{{Ref-talk}}
{{Reflisttalk}}
{{Inlineref}}
{{Reflist-quote}}
{{Section references}}
{{Talk page reflist}}
{{REftalk}}
{{Talk page-reflist}}
{{Talk refs}}
{{reflist-talk}}
{{reflist talk}}
{{talk-reflist}}
{{reftalk}}
{{talk reflist}}
{{talk ref}}
{{ref talk}}
{{reference talk}}
{{talk reference}}
{{talkref}}
{{tref}}
{{tREF}}
{{talk page reference}}
{{ref-talk}}
{{reflisttalk}}
{{inlineref}}
{{reflist-quote}}
{{section references}}
{{talk page reflist}}
{{rEftalk}}
{{talk page-reflist}}
{{talk refs}}

Danski454 (talk) 21:35, 9 August 2019 (UTC)[reply]

Fixed in version 6.87 – when I made the formatting fix to support this template in January 2015, there was only one alias for this template, which the bot supported. But then, starting in May 2015, the floodgates started opening. Three different editors added a single new alias in May, June, and July 2015. Then an editor covered most of the bases by adding 8 aliases in September 2015. Two more editors added two new aliases in January and October 2016, bringing the total number of names for the template to 15. The bot is now up to date as-of October 2016 with support for these 15. Right, since then seven different editors have added seven more aliases (total 22), between November 2016–May 2019. These are of dubious value and are thinly used. Maybe I'll update support for these later. Redirects aren't that cheap, when they waste programmer time. – wbm1058 (talk) 18:32, 10 August 2019 (UTC)[reply]

Edit warring[edit]

Suggestion originally posted here

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Misplaced move notification[edit]

For some strange reason, this notofocation has been placed on Talk:North Macedonian passport. I do not know if it can just be removed, or if the bot will renew it. --T*U (talk) 15:20, 25 May 2020 (UTC)[reply]

A notoble notofocation no doubt! EEng 19:58, 13 June 2020 (UTC)[reply]
That notice first went up after MSGJ closed the RM without removing the template. From the bot's perspective, the RM isn't closed until the template is removed. The bot kept posting the misplaced notice until the template was removed. This could be an unintended side effect of my code refactoring in order to solve this issue (or not). In any event, it's now another item on my bug list. – wbm1058 (talk) 17:32, 25 May 2020 (UTC)[reply]
OK, I think this is another instance of the issue reported at #bot on overdrive on a closed RM, a longstanding open issue. I think I can fix this by checking Category:Fulfilled page move requests and upon finding the RM in that category, report it as a malformed request. Probably should have fixed this a lot sooner, but better late than never ;) wbm1058 (talk) 17:58, 25 May 2020 (UTC)[reply]

Modlin[edit]

Problem also recently happened at Talk:Modlin. – wbm1058 (talk) 15:43, 2 June 2020 (UTC)[reply]

  • After the RM was converted to a multi-move request at 04:28, 20 May 2020 the bot posted a redundant notification at 04:31, 20 May 2020 on Talk:Modlin

There are two or three issues here. The first, which happened on 20 May, is the same issue as reported at #John Brown (abolitionist). – wbm1058 (talk) 19:11, 16 June 2020 (UTC)[reply]

New Corella[edit]

This problem has been popping up frequently recently. I'm not sure why but likely a side effect of more recent code refactoring. Adding a second pass to catch redundant requests made on different pages has lengthened the delay from when the transcluded requests are captured to the time they are processed. Also, as I mentioned here, very large multimove requests such as this one can cause significant delays. Longer delays means larger windows for edit conflicts to happen. Edit conflicts have always happened but this previously infrequent problem has now become a common occurrance. I've caught one in action and am posting my findings here for the record as I walk through the processing sequence.

The second-pass console report: 

__________
82 Processing Talk:New Corella, Davao del Norte (:New Corella, Davao del Norte) contents...
Description: No other place, person or event that carry the same name. Refer to [[Talk:Talaingod, Davao del Norte|Talaingod]],  [[Talk:Cagdianao|Cagdianao]] and [[Talk:Capas|Capas]] for similar discussion. --[[User:Exec8|Exec8]] ([[User talk:Exec8|talk]]) 01:17, 6 June 2020 (UTC)
Timestamp: 1591406220 - 01:17, 6 June 2020 (UTC); Original timestamp: 1591406220 - 01:17, 6 June 2020 (UTC) Delay passed?: true
Section> Requested move 6 June 2020 
Current name: 0: :New Corella, Davao del Norte
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=%3ANew+Corella%2C+Davao+del+Norte&rvlimit=1&rvprop=content|timestamp (0.11700701713562 s) (432 b)

*** PAGE :New Corella, Davao del Norte IS A REDIRECT!! ***
#REDIRECT [[New Corella, Davao del Norte]]

Target: New Corella, Davao del Norte
GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=Talk%3ANew+Corella&rvlimit=1&rvprop=content|timestamp (0.091005086898804 s) (2126 b)
New name: 0: New Corella (Talk:New Corella has non-redirecting content) GET: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=revisions&rvslots=main&titles=New+Corella&rvlimit=1&rvprop=content|timestamp (0.092005014419556 s) (11258 b)
Target-page New Corella has non-redirecting content
New Corella is not requested for move
*** Post crosspost notice to Talk:New Corella ***
GET: https://en.wikipedia.org/w/api.php?action=query&meta=tokens&format=json (0.083004951477051 s) (99 b)
POST: https://en.wikipedia.org/w/api.php?action=edit&format=json (1.0500600337982 s) (180 b)
__________

 Working – wbm1058 (talk) 14:39, 13 June 2020 (UTC)[reply]

v 7.36 went live yesterday; that should fix this but I didn't test it. Watch for a live-test which should add a line to Wikipedia:Requested moves/Current discussions for the malformed request: "[pagename] self-redirects. May be in process of moving or closing." While monitoring for a confirming use case, I just found two different scenarios which I added as separate sections below. Oh my. – wbm1058 (talk) 16:40, 14 June 2020 (UTC)[reply]

8′46″[edit]

This represents a different variant of the issue. In this case the talk page was temporarily out of sync with the article. Unfortunately I didn't capture the console report before it was overwritten.

 Working – wbm1058 (talk) 01:58, 14 June 2020 (UTC)[reply]

This is a timing issue that I'm not sure I reproduced in testing, but I think other patches I've put in place including v 7.37 should catch it depending on the timing. So I'm taking this off my to-do list until another instance of the problem is noticed, at least. – wbm1058 (talk) 01:40, 4 July 2020 (UTC)[reply]

John Brown (abolitionist)[edit]

John Brown (abolitionist) was listed as a possibly incomplete request:

After the RM was converted to a multi-move request at 11:53, 14 June 2020, the bot posted a redundant notification at 12:01, 14 June 2020 on Talk:John Brown

The original move notice was lacking the template

{{User:RMCD bot/multimove|1=John Brown (disambiguation)|2=Talk:John Brown (abolitionist)#Requested move 13 June 2020 }}

because originally it wasn't a multi-move. Upon conversion to multi-move the template should just be added to the original notice.  Working – wbm1058 (talk) 15:38, 14 June 2020 (UTC)[reply]

Fixed by bot v 7.40 – wbm1058 (talk) 17:34, 17 June 2020 (UTC)[reply]

Leader of the Opposition in Wales[edit]

This one is similar to #New Corella, but the page was moved conventionally rather than page-mover swapped.

 Working – wbm1058 (talk) 19:31, 14 June 2020 (UTC)[reply]

v 7.38 addresses this... now when this happens notifications are skipped and this won't be reported as a "possibly incomplete" request. Really, notifications should be skipped any time the bot sees what it thinks is a malformed request. "Redirects to requested name" is still reported as a "soft error": "May be in process of closing." This is not a problem needing attention if it's an edit conflict, but if hours pass after the page moved and the RM still hasn't been closed then it is a problem needing attention. – wbm1058 (talk) 15:50, 16 June 2020 (UTC)[reply]

George Papadopoulos[edit]

Hi, wbm1058. A user started an RM at Talk:George Papadopoulos and another that affects the page at Talk:Georgios Papadopoulos. This has led to RMCD bot, well.... see here and here. Is there anything that can be done to stop this, other than closing a discussion? – Muboshgu (talk) 15:58, 23 September 2020 (UTC)[reply]

Belated reply. After becoming aware of this, I cleared out 202 junk bot edits to the George Papadopoulos (junk bot edit dump) and 198 junk bot edits to the Talk:George Papadopoulos (junk bot edit dump). I'm frustrated that after putting a lot of work time into addressing the issues reported previously and making several fixes to address them, my v 7.33 fix of 9 June 2020 didn't address all the remaining scenarios. Also still open is implementing a more robust backup to catch unaddressed issues by making the bot stop #Edit warring. – wbm1058 (talk) 19:45, 13 January 2021 (UTC)[reply]
Fixed by bot version 7.60 – wbm1058 (talk) 18:42, 15 October 2021 (UTC)[reply]

Bot edit warring with itself[edit]

On Ba'ath Party (disambiguation), Talk:Ba'ath Party (disambiguation), and the talk pages affected by my multi-move request at Template talk:G13 soon/styles.css. Not sure what's causing it. * Pppery * it has begun... 20:32, 19 October 2020 (UTC)[reply]

TemplateStyles[edit]

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.
I've made some code changes to accommodate this usage, but still need to make more. Working on it. – wbm1058 (talk) 14:54, 21 October 2020 (UTC)[reply]
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)[reply]
This page history indicates the issue continued after I posted my "working on it" message and the warring didn't stop until 4:39, 22 October 2020 which was 5 minutes after the RM at User talk:SDZeroBot/G13 soon/styles.css closed. – wbm1058 (talk) 15:32, 20 October 2021 (UTC)[reply]

Ba'ath Party[edit]

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 10:26, 15 October 2020 a single-page RM was started to move Ba'ath Party → Baath Party
  • At 22:19, 15 October 2020 the nominator was advised to "withdraw all these separate requests and renominate them in a single multimove."
  • 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.
  • Sahib1609 reverting your own RM is OK if others haven't yet participated in the discussion
    1. History of the Arab Socialist Ba'ath Party – Syria Region at 08:53, 16 October 2020
    2. History of the Ba'ath Party at 08:53, 16 October 2020
    3. Arab Ba'ath Movement at 08:53, 16 October 2020
    4. Arab Ba'ath at 08:52, 16 October 2020
    etc.
  • Sahib1609 reverted the bot on its Wikipedia:Requested moves/Current discussions page (at 08:54, 16 October 2020) which is not necessary, but harmless...
  • ...but you missed a couple, so the bot reverted you at 09:07, 16 October 2020
    1. At 10:48, 16 October 2020 the single-page RM was "Procedurally closed in favor of the multi-move request below."
    2. At 21:00, 19 October 2020 I removed "the RM from this page, since you opened a newer RM at Talk:Ba'ath Party#Requested move 16 October 2020 which supersedes this discussion and nobody else has participated here."

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)[reply]

Dozens of bot edits[edit]

Hey, can you take a look at what the bot's doing at Illegal immigrant population of the United States? Looks like it's stuck in some sort of loop. –dlthewave ☎ 12:09, 29 September 2021 (UTC)[reply]

Update: I added a Bot Deny template to the article and talk page. Feel free to remove it when the issue is resolved. –dlthewave ☎ 12:50, 29 September 2021 (UTC)[reply]

@Dlthewave: This is because Showiecz (talk · contribs) started two parallel discussions about the same proposed move, contrary to WP:MULTI and one or two other guidelines. I've procedurally closed Talk:Illegal immigrant population of the United States#Requested move 28 September 2021 (which was initiated at 03:32, 28 September 2021 (UTC)), and left Talk:Illegal immigration to the United States#Requested move 18 September 2021 (initiated 19:07, 18 September 2021 (UTC)) to run normally. I also reverted your bot deny to allow RMCD bot to tidy up. --Redrose64 🌹 (talk) 21:58, 29 September 2021 (UTC)[reply]
In fairness to Showiecz – they removed it from the multi-move while in-progress but that removal was reverted. Per WP:TALK#REVISE making changes to your RM after others have !voted, without everyone on board with your changes, is asking for trouble. This started out as a single-page move request, so THIS EDIT that converted it to a multi-move after someone had already voted in support of the single-page request is a definite NO-NO!! – wbm1058 (talk) 15:04, 3 October 2021 (UTC)[reply]
Fixed by bot version 7.57 – this should have been caught and flagged as a malformed request and next time this scenario happens it will be. – wbm1058 (talk) 17:42, 3 October 2021 (UTC)[reply]

Bot is still not removing notices from multi-move request after someone removes the mass-move request on the original talk page.[edit]

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)[reply]

@Iggy the Swan: you've linked the wrong Struway there, if it's the football-article editing one I'm thinking of. Seasider53 (talk) 16:48, 13 October 2021 (UTC)[reply]
@Seasider53: - which article are you're thinking of? Iggy (Swan) (Contribs) 16:51, 13 October 2021 (UTC)[reply]
@Iggy the Swan: I now see you filtered the contributions; it is the same user. Seasider53 (talk) 16:54, 13 October 2021 (UTC)[reply]
Seems like that part of the confusion has been solved, I hope. Iggy (Swan) (Contribs) 16:56, 13 October 2021 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]

Why did the bot do this?[edit]

Why did this bot do this?VR talk 19:08, 24 October 2021 (UTC)[reply]

Edit conflict with bot's processing. The bot would have reverted itself on the next run as it automatically removes these templates after an RM is closed. In this case, the RM was still open when the bot passed by the page. This issue should be addressed by my next bot coding task. – wbm1058 (talk) 00:51, 25 October 2021 (UTC)[reply]
Ok thanks. I see that now[5].VR talk 13:28, 28 October 2021 (UTC)[reply]

mw:API:Edit has parameters that are used to detect edit conflicts. My bot framework has a rudimentary option to use these but I think my algorithm is too complicated to use that as designed. Anyhow that may be an option for solving this particular issue, versus trawling through edit histories. Just also noting that I named that template User:RMCD bot/subject notice as an attempt to communicate to editors, "this template is property of the bot, which will take responsibility for its proper usage, including removal when appropriate." The issue is the bot doesn't work in real time, and thus there can be a lag of up to 15–20 minutes or more from when the RM is closed to when the bot removes that template. – wbm1058 (talk) 23:29, 8 November 2021 (UTC)[reply]

OK, so detecting edit conflicts or reversions of bot edits requires still unimplemented changes in my bot's framework. In lieu of that, I have Fixed this specific issue with version 7.67 which won't post notifications more than one week after the RM was listed. That addresses the issues linked above. There is still a chance for this issue to repeat if an RM is speedily closed, but that should happen about as often as it snows in mid-summer. – wbm1058 (talk) 01:09, 16 November 2021 (UTC)[reply]

Correcting a mistaken request is not "tampering"[edit]

The edit comment for this this edit says Sync tampered notice of move discussion on Talk:Horror vacui. "Tamper" is an inappropiate pejorative for a requester fixing their own mistake. Please change this to neutral language, such as "Sync to modified notice of move discussion". Paradoctor (talk) 04:33, 5 December 2021 (UTC)[reply]

 Done Bot version 7.71 changed "tampered" → "modified". – wbm1058 (talk) 17:32, 16 March 2022 (UTC)[reply]

BOt adds underline[edit]

Hello whoever will see this message and respond to it! I've noticed that when a bot adds an entry on the RMCD page, it occasionally adds an underline like this: Discuss. If this is intentional why does the bot underline the whole word and why doesn't the bot do it to all of them? It seems to be random when the bot adds that and I originally thought it was someone's signature forgetting a closing underline tag but no, it's deliberately in those spots. I've checked the history of the page and it's all the bot so that shows that it's not some user adding it as vandalism. ― Blaze The WolfTalkBlaze Wolf#6545 15:45, 9 December 2021 (UTC)[reply]

@Blaze The Wolf: see User talk:RMCD bot/Archive 3#Underlined "scu". I suppose since you're at least the third person to ask me about this, I should just remove this feature – that subtly indicates relisted discussions – on my next bot update. – wbm1058 (talk) 16:30, 9 December 2021 (UTC)[reply]
@Wbm1058: I think an indication of a relisted discussion is good, but I feel it should be a bit more obvious that 1. It's relisted and 2. That that is what it means. Maybe changing the color of the link or something? ― Blaze The WolfTalkBlaze Wolf#6545 17:51, 9 December 2021 (UTC)[reply]
This indicator should be redundant to the — Relisting.  notice posted by the relisting editor (generated by {{subst:RM relist}}), which is included in the subpages. Did you notice the message that the top of the list?
This list is also available in a page-link-first format and in table format. 48 discussions have been relisted, indicated by (Discuss)
I suppose that I could change it to "indicated by (Discuss) but then I think someone would post another question here, "why are some of the links orange?"
The purpose of this is to confirm that the bot recognizes the items as relisted, and I implemented this to support the table, which more clearly distinguishes the discussions that have been relisted. – wbm1058 (talk) 18:24, 9 December 2021 (UTC)[reply]
This feature has been removed, in bot version 7.71 – wbm1058 (talk) 17:34, 16 March 2022 (UTC)[reply]

Indication of move protection settings[edit]

Is it possible to add an indication of page move protection settings of the pages involved in move discussion? Basically, there have been some cases where I go to a RM & realise it's template protected (could even be sysop protected). Maybe, we should add an indication of this in the elapsed/backlog requests list, so that everyone knows what rights are required for closing the move. Sysops would know that this particular RM requires their intervention, etc. An underline on page name, like it is under Discuss seems appropriate. A section noting the significance/meaning of these underlines at WP:RM would help everyone know what they stand for. Thanks! ---CX Zoom(he/him) (let's talk|contribs) 12:50, 2 March 2022 (UTC)[reply]

The technology exists: {{PROTECTIONLEVEL:move|Elton John}} → sysop; {{PROTECTIONLEVEL:move|Template:Pp-template}} → templateeditor. --Redrose64 🌹 (talk) 21:47, 2 March 2022 (UTC)[reply]
Yes, the bot would obtain it via mw:API:Info. But this idea raised another idea in my mind, which is to flag requested move targets that have page histories that prevent page-movers from moving directly over the redirect. I find unnecessary round-robin moves to be annoying as they add confusion to the page-move histories. I envision preemptive deletions of page-move-blocking edits, while the RM is open, to enable RM-closing page movers to move directly over the redirect. – wbm1058 (talk) 17:18, 12 March 2022 (UTC)[reply]
source: https://web.archive.org/web/20220316053726/https://en.wikipedia.org/wiki/User_talk:RMCD_bot

Leave a Reply