Edge Rewrite
everything Source code View original
// HTMLRewriter · presentation

This page was redesigned at the edge.

Cloudflare fetched the original article and streamed it through HTMLRewriter to apply an entirely new visual system without rebuilding the source page.

// request.cf · coarse context

A page that knows where it met you.

Only coarse request metadata is shown. This demo does not display or persist visitor IP addresses.

Country
US
Cloudflare location
CMH
Connection
HTTP/2
Language
Not provided

Ray ID: a44cfae76f661cc4

Jump to content

Wikipedia:Bots/Requests for approval

Page semi-protected
From Wikipedia, the free encyclopedia
< Wikipedia:Bots
(Redirected from Wikipedia:BFRA)

New to bots on Wikipedia? Read these primers!

To run a bot on the English Wikipedia, you must first get it approved. Follow the instructions below to add a request. If you are not familiar with programming, consider asking someone else to run a bot for you.

 Instructions for bot operators
I Before applying for approval
  • Read the bot policy, and check the list of frequently denied bot requests.
  • If your task could be controversial (e.g. most bots making non-maintenance edits to articles and most bots posting messages on user talk pages), seek consensus for the task. Common places to start include WP:Village pump (proposals) and the talk pages of the relevant policies, guidelines, templates, and/or WikiProjects. Link to this discussion in your request for approval.
  • You will need to create an account for your bot if you haven't already done so. Click here when logged in to create the account, linking it to yours. (If you do not create the bot account while logged in, it is likely to be blocked as a possible sockpuppet or unauthorised bot until you verify ownership)
  • Create a userpage for your bot, linking to your userpage (this is commonly done using the {{bot}} template) and describing its functions. You may also include an 'emergency shutoff button'.
II Filing the application
  • Enter your bot's user name in the box below and click the button. If this is a request for an additional task, put a task number as well (e.g. BotName 2).
  • Complete the questions on the resulting page and save it.

  • Your request must now be added to the correct section of the main approvals page: Click here and add {{BRFA}} to the top of the list, directly below the comment line.
    • For a first request: use {{BRFA|bot name||Open}}
    • For an additional task request: use {{BRFA|bot name|task number|Open}}
III During the approvals process
  • During the process, an approvals group member may approve a trial for your bot (typically after allowing time for community input), and AnomieBOT will move the request to this section.
  • Run the bot for the specified number of edits/time period, then add {{Bot trial complete}} to the request page. It helps if you also link to the bot's contributions, and comment on any errors that may have occurred.
  • AnomieBOT will move the request to the 'trial complete' section by moving the {{BRFA}} template that applies to your bot
  • If you feel that your request is being overlooked (no BAG attention for ~2 weeks) you can add {{BAG assistance needed}} to the page. However, please do not use it after every comment!
  • At any time during the approvals process, you may withdraw your request by adding {{BotWithdrawn}} to your bot's approval page.
IV After the approvals process
  • After the trial edits have been reviewed and enough time has passed for any more discussion, a BAG member will approve or deny the request appropriately.
    • For approved requests: The request will be listed here. If necessary, a bureaucrat will flag the bot within a couple of days and you can then run the task fully (it's best to wait for the flag, to avoid cluttering recent changes). If the bot already has a flag, or is to run without one, you may start the task when ready.
    • For denied/expired/withdrawn requests: The request will be listed at the bottom of the main BRFA page in the relevant section.
Bot NameStatusCreatedLast editorDate/TimeLast BAG editorDate/Time
ParamBot (T|C|B|F) Open 2026-10-01, 03:05:54 Tenshi Hinanawi2026-10-03, 15:16:09 Zackmann082026-10-02, 04:02:08
POTDBot (T|C|B|F) Open 2026-09-14, 17:19:53 Avalyn0x452026-09-28, 12:00:14 Primefac2026-09-27, 18:04:30
AFLTablesBot (T|C|B|F) Open 2026-07-21, 12:46:45 Primefac2026-09-27, 18:12:29 Primefac2026-09-27, 18:12:29
Blippy1998Bot 2 (T|C|B|F) Open 2026-07-14, 05:41:54 Blippy19982026-10-01, 07:23:16 Primefac2026-09-13, 20:55:22
SdkbBot 5 (T|C|B|F) On hold 2026-02-07, 21:26:55 Pppery2026-09-04, 03:13:34 Max2026-09-02, 18:45:41
FengPurgeBot (T|C|B|F) In trial 2026-08-31, 17:07:31 Fengrímur2026-09-30, 18:30:41 Primefac2026-09-27, 18:07:57
Rusabot 2 (T|C|B|F) In trial 2026-09-08, 09:08:39 Voorts2026-09-18, 22:37:08 Max2026-09-15, 14:59:19
Sldst-bot (T|C|B|F) Trial complete 2026-07-24, 08:07:57 Solidest2026-09-28, 09:15:37 Primefac2026-08-30, 16:47:57

Current requests for approval

ParamBot

Operators: Phuzion (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search) & Zackmann08 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 03:05, Thursday, October 1, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python, Pywikibot, mwparserfromhell

Source code available: https://github.com/phuzion/ParamBot

Function overview: Automatically renames deprecated infobox parameters that have come back into articles to their current names, using approved rules

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Bot to regularly check for restored deprecated parameters

Edit period(s): Daily

Estimated number of pages affected: Varies, likely 5-100/day

Exclusion compliant (Yes/No): Yes

Already has a bot flag (Yes/No): No

Function details: This request is for the approval of a new bot, ParamBot, that @Zackmann08 and I have been working on for the past few days.

Before describing what this bot does, allow me to paint a picture of a relatively common issue that we see in the parameter cleanup world.

  1. An infobox template has a parameter deprecated and replaced with a new parameter, e.g. |imagesize= → |image_size=, using a "Deprecated Parameters" category for tracking purposes. The old parameter is still supported, but throws an in-preview warning to editors.
  2. The "Deprecated Parameters" category is cleaned out by bots such as User:PrimeBOT, User:ZackBot and User:PhuzBot, as well as manual work by users with WP:AWB and other tools.
  3. Once the "Deprecated Parameters" category is cleaned up, the deprecated parameters code is removed from the infobox template, and the old parameter no longer works. Uses of the old parameter will result in the article getting placed into an "Unknown Parameters" category (assuming it exists), separate from the "Deprecated Parameters" category.
  4. Well-intentioned editors make changes to the articles with said infobox, not realizing that |imagesize= is now |image_size=. Their edit does not actually do what they expect it to do, and puts the page into an “Unknown Parameters” maintenance category.

Some of the legitimate reasons that an editor might insert a parameter name that is not valid include:

  • Reverting vandalism/LLM/Socks
  • Copying Infoboxes from other Wikipedia languages
  • Old-hat editors that have 20 years of experience writing |imagesize= rather than |image_size=

All of these are useful contributions that shouldn’t just be reverted. This is where ParamBot comes in.

ParamBot is a Pywikibot bot that runs on Toolforge. It is given a curated list of parameter replacements, most frequently pulled from historical uses of {{#invoke:Check for deprecated parameters}} in the infobox template’s edit history. This list tells the bot a list of unknown parameter categories to check, and what changes to make. As it scans through each category, it compares its list of “old parameters” to the list of parameters in the infobox at the time of the run. If it finds any of the “old parameters” that it is supposed to replace, it replaces it with the new parameter. The list of replacements is human-curated. We are not blindly pulling from the history of the template.

Additionally, a rule can be written to completely delete a parameter, for instance removing |nationality= from an infobox where that parameter was entirely deprecated with no replacement.

Once it makes the edits, a report is generated at User:ParamBot/Report that gives a summary of what it did, and any configuration errors it found. Included in this report are a list of articles that need human review, articles it skipped and the reason for the skip, a list of rules pages that have issues, and notes such as rules waiting for a template to drop an old name.

The rules are located at User:ParamBot/Rules. This page is template editor protected, and in order to have a rule take effect, the rule must be listed on the page, as well as its revision ID. While anyone can contribute to the project by creating a rules file (as subpages of the Rules page can be edited and created by anyone), this requirement to list the rule with its revision keeps the bot from being potentially abused by vandals and ne’er do wells. Further edits to the approved rules will not automatically take place, the appropriate revision ID needs to be inserted for the bot to use the updated copy. If the revision on the Rules page is out of date, the bot will continue to use the old revision until the revision ID is updated.

The bot will not edit an article it has edited in the past 30 days; it checks its own recent edits before every run.

Some of the checks that the bot does include:

  • If the "old parameter" is still accepted in the template, that particular parameter of that rule is ignored.
  • If the "new parameter" is not yet accepted in the template, that particular parameter of the rule is ignored.
  • If both the old and new parameter are present in the article's infobox, the bot intelligently handles the scenario according to this table.
  • The bot waits at least 10 seconds between edits, and sends maxlag=5 so it backs off when servers are lagging. We have a --max-edits N argument that we can use to limit the number of edits we will perform in a single run.
  • It never makes an edit that only changes empty parameters.
  • It never edits pages outside of Article namespace (except for its own Report page). It does not touch drafts, sandboxes, user pages, etc.
  • The bot links to its FAQ in every article edit summary, as well as the rule and revision that triggered the edit.
  • It abides by {{nobots}} and {{bots}}, and has an Emergency Stop button that anyone can trigger.
  • Any time the bot edits more than 500 pages in a single run, it leaves a note on the Report page to alert the bot operators.

During development, I have been running the bot locally, and copy-pasting the output of the reports to User:ParamBot/Report, but I have recently turned on "Report Only" mode, which does not edit articles, but does update the Report page. This is permitted under WP:BOTUSERSPACE, as the bot only edits a subpage of its own userpage.

As I mentioned in my original comment announcing this bot over at WP:BOTREQ, this was coded with the assistance of an AI model, particularly Claude Opus 5.5. I have thoroughly reviewed every single hypothetical edit this bot would have made and any mistakes that were found were immediately addressed. As of the filing of this BRFA, I know of no outstanding bugs in the code.

As for edit volume, this is going to vary depending on the number of rules we write. There may be some days where the bot makes zero edits. There may be days where the bot has hundreds or even thousands of edits to perform. Currently, the bot is limited to 1 edit per 10 seconds, and a run will time out after 20 hours. But as of right now, I don't think that we will even come remotely close to that time limit. In testing with 87 pages comprising 1800+ rules, we are seeing 5-10 hypothetical edits per run. For a trial, we would suggest 50 edits, at 5-10 per run. This will take approximately a week at the current pace.

As always, please let us know if there are any questions!

Discussion

Just want to build on what Phuzion has said. This bot has been one I've been kicking around in my head for months. A number of users (some of whom I'll ping below) have expressed interest in this type of bot being created. The need is absolutely there. Phuzion has done a killer job over the last few days building this code base. Together we have been thoroughly testing this with dozens and dozens of data sets. More testing is absolutely needed and will be performed, but I am highly confident that this bot will perform to everyone's expecations! We both stand ready to address any questions or concerns that anyone may have.

Courtesy pings: ChompyTheGogoat, grapesurgeon, Gnomingstuff, Chipmunkdavis, Dionysodorus, DraconicDark, Kowal2701, M kuhner, Knypster, gurkubondinn, Johnuniq, Drmies -Zackmann (Talk to me/What I been doing) 03:13, 1 October 2026 (UTC)reply

So happy. Just had to repair another "alma_mater"; would love to stop doing that. Thank you both. M kuhner (talk) 03:18, 1 October 2026 (UTC)reply
Full disclosure... |alma_mater= will take some time to fully be deprecated, that merge with |education= is a complicated one as the 2 fields often co-exist in a way that makes a bot-run very difficult to achieve. But ultimately that will absolutely be handled here by ParamBot! Zackmann (Talk to me/What I been doing) 03:25, 1 October 2026 (UTC)reply
thank you so much, I look forward to never having to type custom data or whatever it is again Gnomingstuff (talk) 03:56, 1 October 2026 (UTC)reply
Fixing these sorts of things is the type of task a bot would be helpful for. There are other reasons old params might appear, like code being copied from an old revision (or a current revision with old code). I have some caution from past discussions around the accessdate->access-date conversion, so a month between hitting the same article seems sensible. There is the larger question of how outdated code should be before we expect it to break. Viewing very old revisions, you expect to see a bunch of broken templates, but more recent revisions may be more regularly checked for various reasons. The bot report sounds like it can help identify a time when a deprecated parameter stopped being used, and thus inform later removals from code. CMD (talk) 03:57, 1 October 2026 (UTC)reply
actually I do have a question -- when you say It never makes an edit that only changes empty parameters does that mean that if the deprecated parameters were already empty, then those still need to be manually changed? Gnomingstuff (talk) 03:58, 1 October 2026 (UTC)reply
@Gnomingstuff: This is a great question. So the important thing to remember is that the actual deprecation of parameters and what this bot does are 2 separate tasks. During the deprecation (mostly being done these days by ZackBot) I do take on empty parameters. However, there is an ongoing debate about whether this is considered a WP:COSMETICEDIT. So, the way we have setup ParamBot is that it will only change parameters that have a value assigned to them, with one exception! If there are (For example) 2 bad parameters on the page. One with a value and one without, the bot will change both (I.E. fix the blank while it is fixing the other). It will not, however, fix a page that only has a blank bad parameter. What is more, this is unlikely to show up anywhere anyway as Check for unknown parameters almost universally ignores blank params. Zackmann (Talk to me/What I been doing) 04:08, 1 October 2026 (UTC)reply
yeah, and I assume that if someone comes along and populates a previously-empty deprecated parameter, the bot will deal with it in its next run. Are there going to be lots of unknown parameters that aren't currently at /Rules that will get added once they're found in the wild, and will there still be the odd unknown parameter that will need to be done manually (like, how many times does one need to pop up to necessitate adding it to /Rules, or will it be all ones that aren't clearly nonsense)? (also, just making sure, does this basically make WP:RDP defunct and mean editors can ignore the Preview warnings when this goes live? If so, is it worth removing the Preview warnings for old parameters in Rules so people don't spend time manually doing it?) Kowal2701 (talk, contribs) 12:46, 1 October 2026 (UTC)reply
The purpose of this bot is to handle deprecated parameters after the deprecation process is complete. WP:RDP depends on {{#invoke:Check for deprecated parameters}} being present in the template. Eventually, after some time, the support for old parameters is removed, as is the deprecation code. Once this happens, a rule is written, and ParamBot will begin monitoring that template's unknown parameters category.
WP:RDP will remain useful, as there is still plenty of work to be done during the deprecation period. phuzion (talk) 17:01, 1 October 2026 (UTC)reply
This looks like a great solution. I do have a few questions/comments though:
The restriction on the bot re-editing a page within 30 days seems a little long, in my opinion. One of the main purposes listed in the initial proposal was to fix removed parameters that were re-added to a page from reverting a LLM/vandal/sock. Assuming the initial parameter fix and the revert happen within 24 hours, the bot will wait nearly 30 days to fix the broken parameter, if I am understanding this right.
Also, I was just wondering why the bot begins editing after the initial parameter fixes, versus allowing it to first take care of any basic parameter replacements it could before any AWB runs are set up. I’d personally rather see as many of the edits as possible come from a single standardized bot, instead of coming from various AWB runs.
Anyways, I am excited to see this in action! FlammablePizza (talk / contrib) 04:01, 1 October 2026 (UTC)reply
@FlammablePizza: valid points.
  1. The 30 day restriction is something we have gone back and forth on. 30 is where we are at right now, but that is absolutely NOT set in stone and can easily be changed as part of this BRFA. Perhaps 15 days is better? We just want to make sure we avoid a bot editwaring....
  2. As to your second question about why the bot begins editing after the initial parameter fixes. The reason for this is that there are currently 3 approved bots taking on deprecated parameters.... So there is less of an urgent need for that at present. That being said, there is absolutely the possibility of a task 2 for ParamBot down the road! Something Phuzion and I have already discussed. BUT, one thing at a time.... Currently no bots are taking on regressions the way this task for ParamBot would, so that is the primary focus at present!
- Zackmann (Talk to me/What I been doing) 04:12, 1 October 2026 (UTC)reply
Maybe it could keep the 30-day restriction to prevent edit warring while providing an exception (or shorter cooldown) for instances where both:
1. The bot’s previous edit was reverted
2. The edit immediately preceding that one was reverted AND was not created by the bot.
Honestly, I doubt this would be worth the time and technical resources though.
Also, perfectly understandable that this task is the focus for now anyways. As I said earlier, I look forward to seeing it at work! FlammablePizza (talk / contrib) 05:04, 1 October 2026 (UTC)reply
Right now, if the bot were to make an edit, and it were to be reverted, that article would show up on the Report page under the "Not edited" section. The fix could then be handled by a human editor. The idea with the 30-day restriction is to eliminate the possibility that the bot could get into an edit war. I do recognize that this might be a touch overkill, but I wanted to err on the side of caution here.
The cooloff period and a bunch of other decisions are all configurable, as can be seen in the config file. If we decide to make changes to the edit frequency or the cooloff period, that can be done with minimal needed changes. But I think we're talking about a hypothetical that might, maybe, possibly happen a handful of times a month. If it becomes necessary to revisit this, we can. phuzion (talk) 13:27, 1 October 2026 (UTC)reply
Support! My nudge would be to have it run weekly and skip the same page restriction. For CutlassBot (ATODAY removal) there were 100s of redo’s from slop-reverts and only 1 targeted revert (after 89,000 edits). For the edit war case, where the parameter really should be removed from the target list, it’s better to get that sorted early rather than wait 30 days. So if you’ve already built the 30 day feature, I’d recommend changing to 7. You want to get the edit in soon after the slop revert so it’s part of the new baseline. Cheers and thanks for your work on this! Dw31415 (talk) 08:43, 1 October 2026 (UTC)reply
Based on our dry runs, we're seeing about 5-20 hypothetical edits per run, and the number is rising as we add rules. As the list grows, I think we can expect to see dozens to low-hundreds of edits per run, with skips and cooldowns likely being in the single digits for the foreseeable future. If the number of skipped edits or articles in cooldown increases, we can look at lowering the cooldown period. The bot is meant to handle the unambiguous, obvious cases that need to be fixed. Anything that's contentious (aka, it has been reverted) or not obvious should be handled by a human. Zackmann08 and I will be perusing the Report page on a daily basis, and other interested editors are welcome to do so as well. When we spot skips, we will likely handle them manually, rather than waiting for the bot to come back and take care of it in 30 days (or whatever we set the cooldown period to be).
Running weekly would mean that more articles get missed for longer. If anything, I'd like to eventually increase the frequency that the bot runs, not decrease it. phuzion (talk) 00:03, 3 October 2026 (UTC)reply
Note: The work Phuzion has done really is incredible... User:ParamBot/Report even highlights issues with the rules that have been implemented and has already identified a number of things that needed fixing. Mostly typos, but a few were params that were deprecated but then not properly removed from the Infobox in question. Likely never would have been caught without this... Zackmann (Talk to me/What I been doing) 04:02, 2 October 2026 (UTC)reply
According to the linked repo, Claude was involved with writing the repo to some extent. For both operators, have you been checking its output and can properly understand the code is doing, in case there are issues caused by Claude which you yourselves need to fix? Tenshi! (Talk page) 15:16, 3 October 2026 (UTC)reply

POTDBot

Operator: Avalyn0x45 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 17:19, Monday, September 14, 2026 (UTC)

Function overview: Automatically insert and remove {{Picture of the day}} tags on files that appear the the POTD archive.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Zig

Source code available: Will be available on Codeberg as BSD-2.

Links to relevant discussions (where appropriate):

Edit period(s): Daily, potentially more if it makes sense. On edit to any page within Template:POTD (checked at interval TBD).

Estimated number of pages affected: ~1 per day.

Namespace(s): File

Exclusion compliant (Yes/No): Yes

Function details: Iterates through the POTD archive and checks that all images referenced contain the correct {{Picture of the day}} tag, and also iterates through Category:Wikipedia Picture of the day files and ensures that all {{Picture of the day}} tags are valid (correctly formatted and pointing to correct date)

Discussion

Is this not already the case? I see 8284 pages transcluding the template, and 8282 pages in the cat. Why is this bot needed? Primefac (talk) 09:08, 17 September 2026 (UTC)reply

It is the case because I already manually fixed the ~150 that were in some way broken, and more keep needing to be fixed. Avalyn (talk) 11:10, 17 September 2026 (UTC)reply
Apologies, just trying to make sure everything is accurately being described - are you going through the 8k transclusions and fixing what needs fixing in those transclusions? If that's the case, why are you editing 1 page per day? Would not the files going forward ostensibly be tagged with the correct templates/values? Primefac (talk) 18:20, 20 September 2026 (UTC)reply
The once page per day estimate is mostly just from new POTDs being added/modified. Avalyn (talk) 12:36, 24 September 2026 (UTC)reply
Again, forgive me for not understanding as POTD is not anywhere near my wheelhouse or something I even look at occasionally: if I understand the process correctly, when a picture is made POTD it has {{Picture of the day}} added to the file page, yes? This is done by the editor(s) who selected the page? Does it not regularly get added?
To ask for a specific page, File:Pin tumbler no key.svg is today's POTD, and it has {{picture of the day|2013-10-23|2026-09-27}} added to it. Why would that need to be modified? Primefac (talk) 18:04, 27 September 2026 (UTC)reply
The template is often missed/incorrectly added, especially if there is already one present. A lot of times, the author will mistakenly use the date of their time zone instead of UTC, or miss adding a second tag. This bot would also turn the adding of the tag into an automatic process, making the process simpler for those creating POTDs. Avalyn (talk) 11:56, 28 September 2026 (UTC)reply
Also, if you want to see examples of POTDs that were in some way broken, you can go through my edit history, there's a lot there. Avalyn (talk) 12:00, 28 September 2026 (UTC)reply

AFLTablesBot

Operator: Electricmaster (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 12:46, Tuesday, July 21, 2026 (UTC)

Function overview: Synchronizes AFL player statistics (games and goals) from AFL Tables to Wikipedia player infoboxes.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python (using Pywikibot)

Source code available: Custom Python script using Pywikibot and requests.

Links to relevant discussions (where appropriate):

Edit period(s): Daily during the AFL season.

Estimated number of pages affected: ~600 pages checked daily; edits only occur when a player's stats have actively changed.

Namespace(s): Mainspace (Articles)

Exclusion compliant (Yes/No): Yes

Adminbot (Yes/No): No

Function details: The bot scrapes active player statistics (total games and goals) from AFL Tables (e.g., https://afltables.com/afl/stats/2026.html). It then iterates through the corresponding Wikipedia articles for those active players.

The bot targets the {{Infobox AFL biography}} template to update:

  • The `games_goalsX` parameter corresponding to the player's current active club.
  • The `games_goalstotal` parameter if the player has played for multiple clubs.
  • The `statsend` parameter, advancing it to the most recently completed round (e.g., "round 19, 2026").

The script strictly parses the wikitext, updating the stats inline while meticulously preserving existing references, comments, and other infobox data. It runs as a "dry run" first to calculate diffs and will only perform a live edit if the AFL Tables data represents an actual advancement of the player's Wikipedia statistics.

Discussion

  • Information Note: This bot appears to have edited since this BRFA was filed. Bots may not edit outside their own or their operator's userspace unless approved or approved for trial. AnomieBOT⚡ 22:46, 30 July 2026 (UTC)reply
  • Related ANI thread. —ClaudineChionh (she/her · talk · email) 04:22, 15 August 2026 (UTC)reply
  • If having the latest stats is that important, wouldn't a central data page be a better option? The bot could update that one page, and a module could pull the data from there and be invoked in the infobox. We don't usually update stats this way, and I'm not sure having a bot check around 600 pages every day and edit them just to keep the stats up to date is a good approach. I also read the ANI thread, and it gives me the impression that you don't have full control over the scripts you use, so I'd also like to see the source code for this task if you're comfortable sharing it. – DreamRimmer ■ 16:03, 15 August 2026 (UTC)reply
    I would second this. If it were 6 thousand pages it might be different, but having one module (and/or a .json page) storing the data would mean a lot less editing. I would also note that "daily" is excessive for stats when the matches are played what, at most two times a week for any given team? A weekly update is more than sufficient (regardless of if one page or every article is edited). Primefac (talk) 16:16, 15 August 2026 (UTC)reply
    Sorry this is late, but the stats are supposed to be updated once a week, not daily. There is a healer check to avoid vandalism or errors, though this isn't essential for operation. If you like, I can send the source code to you or @DreamRimmer. Electricmaster (talk) 04:34, 20 September 2026 (UTC)reply
    I'm not a BRFA regular so I don't know what's appropriate here, but I've found references to two GitHub repos scattered on different talk pages – is it OK to link them here? —ClaudineChionh (she/her · talk · email) 00:47, 16 August 2026 (UTC)reply
    I'm not sure I understand the relevance; the issue right now is not "does the code work" (which, according to the ANI, seems to be "most of the time") but rather if there is consensus (at all?) for this task, or if there is a better/more efficient way to get the same results. Primefac (talk) 22:52, 16 August 2026 (UTC)reply
    Oh, that was in response to DreamRimmer's question about the source code. —ClaudineChionh (she/her · talk · email) 03:58, 17 August 2026 (UTC)reply
    ClaudineChionh, you are more than welcome to add constructive comments in the BRFA space. Primefac, the reason I asked for the source is, as I said above, they made multiple claims about their code being reliable, but there were still mistakes as mentioned in the ANI thread, so I was curious to see how reliable the code actually was. After checking their GitHub repo, I found the table scraping and template manipulation logic pretty unreliable. There were also quite a few unnecessary functions in the code that I'm not really sure why they were using. That gave me a better idea of what they were actually doing. With our suggested version, though, it won't make any edits outside the single data page, so that shouldn't really be an issue if they're ready to go with this. Max (talk) 18:28, 19 August 2026 (UTC)reply
    I'm not against having a centralized data page, though this may be more trouble than its worth. I can provide the source code tomorrow if you like. Electricmaster (talk) 04:35, 20 September 2026 (UTC)reply
    @DreamRimmer, Primefac, Max, and SuperJew: Cheers for the feedback. I reckon you're absolutely spot on for using a centralised data page makes a lot more sense than having a bot edit ~600 individual articles every week. I'm keen to go down this route; however, I'm also wary about retired players and then having inconsistent references. How do you propose handling older examples. Do they just keep their manual edits? Would we put a plan in to work backwards later?
    The great thing about this approach is that it also addresses Max's concerns regarding the template parsing code. Since the bot will only need to spit out a clean JSON file, I'll be binning all that complex wikitext manipulation logic in favour of a much simpler, robust scraper.
    Just to clarify on the schedule as well, the bot will strictly run once a week after the round finishes, rather than daily, so it won't be clogging up watchlists.
    I've knocked out a sample of what the data page will look like over at User:Electricmaster/AFLTables_data.json. I'm happy to rewrite the bot to just output this JSON payload, but I'm a bit out of my depth when it comes to writing the Lua module needed to get {{Infobox AFL biography}} to actually pull from it. Would one of you guys be able to give me a hand with the template and module side of things once the JSON data page is set up? Electricmaster (talk) 05:44, 23 September 2026 (UTC)reply
    Implementation of the new .json can happen after, the main thing to see is if the bot is editing consistently and accurately (noting that Module:ATP rankings does something similar). As far as retired players go, I would just add a check to only update stats if there are changes to that player's entry; a retired player from 20 years ago can still be "updated 27 September 2026" and have the correct stats (those stats just... haven't changed). Primefac (talk) 18:12, 27 September 2026 (UTC)reply

Blippy1998Bot 2

Operator: Blippy1998 (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 05:41, Tuesday, July 14, 2026 (UTC)

Function overview: updating a draft set of data modules, hopefully with permissions to also edit what would hopefully be a non-draft set of data modules, with new data about legislatures pulled from official/authoritative sources, starting with the United States House of Representatives. btw if i'm allowed to add my own userspace and my own module sandbox to Special:OAuthConsumerRegistration without asking permission, let me know and i'll just do that for now, but it would be nice to get permission to edit Module:Legislature and its subpages in the near future with my bot also. Update (2026/10/01): I added my own module sandbox and pages in my own userspace to the oauth allowlist without asking for permission after a long silence here, but have since again removed the ones in the module sandbox after moving those sandboxed pages to mainspace. I am still requesting approval to edit those pages (Module:Legislature and its subpages) in mainspace.

Automatic, Supervised, or Manual: automatic

Programming language(s): Python, Scribunto

Source code available: it's just on my computer at the moment

Links to relevant discussions (where appropriate):
Wikipedia:Bots/Requests for approval/Blippy1998Bot
User_talk:Morwen#A_barnstar_for_you! - i describe it a bit here, BELOW the discussion about Module:Legislature diagram, which is wholly unrelated (i probably should have started a new section). i have described it elsewhere, too.

Edit period(s): no more than every hour when my laptop is open, but realistically no more than a few times a month to begin with, scaling with how many legislative chambers are covered. it also updates a few timestamp pages every time it runs, which allow the citations to stay updated and so on.

Estimated number of pages affected: for now i think just 3 but probably well under 100 within the next yearthe reasonably intermediate-term future probably less than a dozen

Namespace(s): the Module:Sandbox/Blippy1998 namespace and maybe my userspace for now but in the future hopefully Module:Legislature and all its subpages, plus perhaps some templates. as described above, i'm already having it edit pages in my own userspace without permission.

Exclusion compliant (Yes/No): yes (it would only edit a short whitelist of pages for now)

Function details:

the goal of this bot is to automate updates for data on legislatures - current seats, current members, current committees, and whatever else people see fit to add. there is to be a module with functions that parses that data in useful ways, computing the list of members belonging to a certain party, the balance of power, etc. this is not meant to replace user editing of highly-trafficked pages, but rather to serve as centralized, standardized database-like storage for information that infrequently-edited articles and sections of articles can pull from so that they stay up to date automatically. citations are added also, and those citations stay up to date and mark the information with dates, which otherwise is not done/does not exist. (this can be seen as a major expansion of my previous work, which can be read about at my previous bot request.)

this bot would, initially, edit Module:Sandbox/Blippy1998/Legislature/US/lower/committees, Module:Sandbox/Blippy1998/Legislature/US/lower/members, and Module:Sandbox/Blippy1998/Legislature/US/lower/seatsModule:Legislature/US/lower's subpages only, i think, but i would love to see it grow to cover other legislative chambers, and of course to migrate to Module:Legislature once i think it's ready. i may haveam already having it edit various templates - within my userspace to start - automatically to update citations automatically as it downloads new data, for example.

basically, what it would do is use a number of python scripts to download the xml file, check it against the local copy, and update it if it's new. then, if it did that, it would parse the new one and update the committees, seats, and members jsons i have locally before simply converting those to lua data modules and uploading them to the pages i listed above. in other words, it would effectively just update the data at each of these data module pages in this formatted, quasi-relational way, parsed directly from the official xml file every time it's updated.

Discussion

it just gets this page using a python script every hour while my laptop is connected to the internet. i haven't written code to pull data for every state legislature - that would be incredibly tedious to do alone - but i've designed the structure of the modules to be easily expandable to other legislatures. for example, if someone wrote a script to download data for Texas's Senate, they could put the data into Module:Legislature/US/TX/upper/members, Module:Legislature/US/TX/upper/seats, and Module:Legislature/US/TX/upper/committees, or other subpages as appropriate, and then use the same functions in Module:Legislature (already written in Module:Sandbox/Blippy1998/Legislature) and templates (not yet written) to create views of the data, like a wikitable of all the members of a certain committee, or just the tally of members of a certain party. the point is to set up a framework that is easily extensible so people can write their own scripts and upload a data module to a sensible location with a standardized format (like Legislature/[ISO country code]/[subnational entity code]/[chamber label]/seats) and then not have to rewrite functions that actually parse that data. but all i'm seeking approval for is the bot that pushes the updates to those pages. seeing as all i have is the US House at the moment, updates would realistically not happen more than a few times a month to just a few pages, but, yes, hopefully more legislatures would be added and the number of pages and frequency of edits would scale with that. Blippy1998 (talk) 16:16, 16 July 2026 (UTC)reply

SdkbBot 5

Operator: Sdkb (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 21:26, Saturday, February 7, 2026 (UTC)

Function overview: Removes erroneously italicized commas at the end of italicized terms.

Automatic, Supervised, or Manual: Automatic

Programming language(s): AutoWikiBrowser

Source code available: The bot will be operated by running through lists of pages from the RegEx search query insource:/''[A-Z a-z\[\]\|]+,'' / with a find and replace for ''([A-Z a-z\[\]\|]+),'' →''$1'', . It will use the edit summary Fix erroneously italicized comma and general fixes (task 5).

Links to relevant discussions (where appropriate): None. Although not explicitly specified in the Manual of Style, it is standard English to italicize only the term itself, not punctuation following it.

Edit period(s): Daily

Estimated number of pages affected: 103,000 per this search

Namespace(s): Mainspace (potentially expanding to other namespaces)

Exclusion compliant (Yes/No): Yes

Function details: Because italics markup looks similar to quotation marks and many editors are used to American-style quotation, many editors erroneously put commas following italicized terms within the italicized term, causing the comma to be erroneously italicized. This bot will fix many of these instances, using the AWB settings described above. I did 50 test edits for a version excluding italicized terms with spaces, manually reviewing each one, and the only instances that gave me any pause were ones within quotations, e.g. here (after "for" in the paragraph beginning "King asked a bookmobile driver"). These could be excluded if an issue, but, per the MOS, Insignificant spelling and typographic errors should simply be silently corrected (for example, correct basicly to basically), so I think it's fine to include them. I reviewed another 60 edits (including terms with spaces) via search and found no issues.

Discussion

Should something similar be done with bold? (10,000 per this search) -- WOSlinker (talk) 21:46, 7 February 2026 (UTC)reply

Likely. It might also be worth requesting this be added to the genfixes for AWB so that when this run is over any new instances will be more likely to be picked up. Primefac (talk) 21:50, 7 February 2026 (UTC)reply
Yeah, I think it'd definitely be nice to do the same thing with erroneously bolded commas. I intentionally kept the query constrained to start off (ignoring any italicized terms with unusual characters, for instance), but it could be expanded after the initial run is over.
And yes, I agree it'd be nice to add this to the GENFIX set. Cheers, Sdkb talk 22:54, 7 February 2026 (UTC)reply
Are you not wanting to do bold? Primefac (talk) 17:48, 15 February 2026 (UTC)reply
I looked through the first 100 search results for the bold query. I found one niche edge case: On this page, bolding is used to delineate which parts of two passages match. Because manual line breaks are used, some bolded strings end with a comma. You could argue that this is a downstream effect of the article using poor syntax with manual line breaks, or that a passage like that should have been surrounded with {{as written}}. But because bolding is sometimes used for niche purposes like this, I think it's the slightest bit riskier to try to fix it than italics.
I'll defer to whatever the consensus is here about whether, given this, it's worthwhile to include it or not. Sdkb talk 17:44, 20 February 2026 (UTC)reply

This feels like something so minor that it would be best either ignored or done as part of AWB GENFIXES. I oppose this being done as the sole edit to a page. Thryduulf (talk) 14:28, 20 February 2026 (UTC)reply

It's certainly not the most earth-shattering change to a page, but it is an improvement, and it's clearly in compliance with WP:COSMETICBOT because it changes the output HTML of the page. It is something that I occasionally notice as a reader. Also, because it's an AWB bot, it can be run alongside GENFIXes, so often the comma fix will not be the only change the bot makes. Sdkb talk 17:20, 20 February 2026 (UTC)reply
I think we'll have to agree to disagree on whether the change is an improvement or neutral, and I have no objection to the change being made alongside changes that are unambiguously improvements, but minor changes like this should never be the sole change made by a bot. Thryduulf (talk) 18:40, 20 February 2026 (UTC)reply
On hold. There is opposition to the task, and with only the implication of consensus to run the task based on existing guidelines I would prefer to see a stronger consensus to specifically target this as a bot run. I know AWB releases updates less frequently than most countries change leadership, but that would be another route to go down to start whittling away at the list. Primefac (talk) 20:17, 8 March 2026 (UTC)reply
@Primefac, where would be an appropriate venue to get additional input on whether there is consensus to run this as a bot task? Thryduulf's view seems to be that WP:COSMETICBOT should be made stricter, and while I know that's a view some editors hold, presumably it's a minority given that editors have not found consensus to change the language of the bot policy. Sdkb talk 20:34, 8 March 2026 (UTC)reply
Either at the MOS talk or a Village Pump. I wouldn't necessarily say that it's a more strict ruling on COSMETICBOT given that it already says Minor edits are not usually considered cosmetic but still need consensus to be done by bots. Since this is a "barely visible" type of minor edit, I'd like to get at least some measure of support for making it; it's not like you're going to need an RFC, just enough to indicate that Thryduulf is in the minority when it comes to being concerned. Primefac (talk) 20:48, 8 March 2026 (UTC)reply
@Sdkb: Did you start a discussion to gather consensus at all? Tenshi! (Talk page) 14:59, 10 July 2026 (UTC)reply
@Tenshi Hinanawi, yes, see here. I read it as a weak consensus to proceed, although it didn't gather as much input as I would've liked. Sdkb talk 15:22, 10 July 2026 (UTC)reply
As I said at Wikipedia talk:Manual of Style/Archive 230 § Bot task to remove erroneously italicized commas, I think this would be a useful bot. I always fix those manually as well. However, it should not fix incorrectly "fix" instances of multiple italics separated by a non-italicised space, such as ''The good,'' ''the bad,'' ''and the ugly'', since this is especially common when editing in the VE. Otherwise it might sometimes make the problem worse, not better. FaviFake (talk) 12:54, 10 August 2026 (UTC)reply
How does one person reiterating their comments at a long-archived discussion help anything here? Should every participant just repeated their comments there here? I note that nobody has expressed any opposition to doing this as an AWB-task or alongside some other unambiguously substantive change, and nobody has articulated any reason why that would not be sufficient. Thryduulf (talk) 12:58, 10 August 2026 (UTC)reply
I just wanted to make sure the bot doesn't incorrectly handle this edge case in case it's approved. Do with that what you will. FaviFake (talk) 13:03, 10 August 2026 (UTC)reply
Name-internal commas is an edge case the bot can handle, but name-internal edge cases where also there is a break in italicization is an edge case within an edge case that it cannot. I did not come across any instances of this scenario during the 110 test edits I reviewed, so I believe it is exceptionally rare. Overall, the garbage-in, garbage-out principle applies. Sdkb talk 14:45, 10 August 2026 (UTC)reply
Wikipedia is written for our WP:READERS. As long as the garbage stays in the editor, it's fine. If your bot would cause the garbage to be displayed to our readers, then I oppose the bot. FaviFake (talk) 14:49, 10 August 2026 (UTC)reply
@FaviFake, can you point me to any article where this would happen (or, better, give me a number of articles affected)? I could ensure all of them are resolved before running the bot. Sdkb talk 14:53, 10 August 2026 (UTC)reply
I'm not a technical user, so I can't give you any stats. But I've just tested this on the current version of the VE and I was able to italicise three parts of a sentence with commas in them, and the VE outputted this result in the preview: After ''the withdrawal of U.S. troops from Iraq,'' ''ISI,'' ''then-led by John Doe,'' continued
I suspect this is rare. Someone should figure out a way to find a list of the articles that have this issue. Once they're fixed correctly, I guess your bot could go ahead even if it would still produce incorrect results from new edits. I just don't want to introduce the incorrect formatting into the articles that have been edited since Wikipedia was started. FaviFake (talk) 15:01, 10 August 2026 (UTC)reply
@FaviFake, wait, it's actually pretty easy to find these instances by just adding additional quote marks to the search query. There are 6,600 results. I manually reviewed the first 100 (you're welcome to do the same), and found that nearly all were instances of a list of italicized items or improper italicization in a reference, all of which the bot would handle correctly. There was only one instance, here (a comma being erroneously used to separate a title and subtitle), that was at all questionable.
We could modify the find-and-replace to skip all these instances (where an italicized term ending in a comma is immediately followed by another italicized term after a space) by using a negative lookahead. However, based on the sample, it appears that this isn't an issue, so my weak preference would be to leave them in. Which option do you prefer? Sdkb talk 17:40, 10 August 2026 (UTC)reply
Huh, I didn't think there would be so few false positives. I've reviewed 100 more and they were all incorrect. So now I support the bot based on the data. Even if we assume 1% of 6k articles would cause false positives, that's just 60 articles, which is a great compromise! FaviFake (talk) 17:57, 10 August 2026 (UTC)reply
Doing it as an AWB task would be exponentially slower. Because it is not a cosmetic task as it changes the visible page output, it is eligible to be done by bot. I know you disagree, but if you want to interpret the rules other than as they're written, you need to take that up as a proposed change to WP:COSMETICBOT. Sdkb talk 14:51, 10 August 2026 (UTC)reply
Why does it need to be done more quickly than AWB would do it? What benefit does a change imperceptible to many (maybe most) readers, with no semantic relevance for readers or screen readers, bring that justifies so many edits? It doesn't meet the letter of COSMETICBOT but it certainly matches the spirit. Thryduulf (talk) 15:59, 10 August 2026 (UTC)reply
You had the opportunity to make that argument at the WT:MOS discussion and were not able to get a consensus supporting your view. It's time to drop the stick. Sdkb talk 18:07, 10 August 2026 (UTC)reply
No stick needs to be dropped at this point. The MOS discussion was essentially over by the time I was aware of it and your comment here is the first time anybody has actually acknowledged the substance of my comments and even you've just said "I disagree". You're entitled to disagree but that doesn't equate to a consensus. Thryduulf (talk) 00:39, 11 August 2026 (UTC)reply
  • One small update: I've tweaked the query to include wikilinks. Reviewing the results, I'm not seeing any errors being introduced. Sdkb talk 17:48, 10 August 2026 (UTC)reply
  • @BAG: combining the WT:MOS discussion with FaviFake's additional support above, I'd say this is ready for approval. Are we good to proceed? Sdkb talk 18:10, 10 August 2026 (UTC)reply
    I'm not going to weigh in on this too much just now, but FaviFake also participated in the MOS discussion, so their support here does not do anything to tip the scales in either direction. Primefac (talk) 22:48, 10 August 2026 (UTC)reply
    Yeah, I wasn't suggesting they be allowed to !vote twice, but just that they had concerns at the MOS discussion which are now resolved per above. Sdkb talk 23:00, 10 August 2026 (UTC)reply
    Yeah; to clarify, I commented here because I noticed the MOS discussion had been archived but the issue that another editor and I had hadn't been mentioned here. Now that we discussed it a bit more and discovered it's not really an issue, it just validates the MOS consensus. FaviFake (talk) 23:06, 10 August 2026 (UTC)reply
  • I'm leaning towards declining this in its current form. There seems to be reasonable support for the edit itself, but I don't think there's a clear consensus for making potentially ~100,000 standalone edits for such a minor change, especially with the ongoing concern about cluttering watchlists and page histories. I'd be happy to see this added to GENFIX or run alongside more substantive changes. Max (talk) 02:42, 31 August 2026 (UTC)reply
    There is one editor objecting loudly, but overall it looks to me like there is consensus to proceed. And policy-wise the task abides by WP:COSMETICBOT, so the impetus to show otherwise was on those who object to the plain reading of that guideline. Sdkb talk 18:18, 31 August 2026 (UTC)reply
    And I will continue to object loudly until the substance of my objections are actually engaged with rather than ignored or handwaved away. This does not come remotely close to meeting the spirit of WP:COSMETICBOT, being a tiny change that almost nobody will notice and which has absolutely no semantic or other meaningful impact. Thryduulf (talk) 19:05, 31 August 2026 (UTC)reply
    well i always notice these little things like bolded commas and they often annoy me so much that i fix them on sight, even when I'm on my phone. FaviFake (talk) 19:11, 31 August 2026 (UTC)reply
    Good for you, but that doesn't equate to a consensus to disrupt the encyclopaedia by making only this trivial change, which most people (obviously not everyone) does not notice by bot. Thryduulf (talk) 19:14, 31 August 2026 (UTC)reply
    Making objectively substantial and minor changes to 7k articles does not disrupt the encyclopaedia and there is already consensus for it. Bot edits don't even clutter watchlist-like pages, what exactly would be disrupted in your view? FaviFake (talk) 19:22, 31 August 2026 (UTC)reply
    I don't think watchlist clutter is a valid concern when bots can be hidden in the watchlist, and if they have reason to want to watch problematic bots or something to that effect, the script at WP:HIDEBOT exists to hide specific bots. Tenshi! (Talk page) 19:29, 31 August 2026 (UTC)reply
    Bot edits clogging up watchlists have been a complaint for a long time. Even with the script and CSS rule to hide them, I don't remember the exact discussions, but I've seen people complain about it, so I don't think we can just dismiss it as an invalid concern.
    Sdkb, as I said above, I see consensus to fix the formatting issue, but I don't think everyone is on the same page about doing this as a standalone task, or at least that's how I read the discussion. Maybe the better option would be to unarchive the discussion and leave a notice somewhere more visible to get more people involved. Max (talk) 10:02, 2 September 2026 (UTC)reply
    So you're saying there's consensus to fix those formatting issues but not on whether to do it using a bot. Isn't BRFA the place where new bots are supposed to be discussed? If anything, this request should be made more visible rather than the archived one, imho. FaviFake (talk) 10:09, 2 September 2026 (UTC)reply
    BRFA space isn't really "the place where new bots are discussed" in that broad sense. It's mainly for getting approval for a specific bot task once there's community consensus for the underlying change, rather than being the place to establish that underlying consensus in the first place. That's why the BRFA request is expected to link to the relevant community discussion. Here, the question of whether the incorrectly italicised commas should be fixed at all, and whether a bot is the right way to do it, is something that can be discussed at the relevant venues, or at more visible places like WT:MOS or VPR, and this is where it was discussed. I suggested unarchiving the discussion because I thought it would be better to keep everything in one place and make it easier for people to see the earlier discussion, rather than having the same points repeated across different pages. Max (talk) 11:46, 2 September 2026 (UTC)reply
    Makes sense!  Done, see Wikipedia talk:Manual of Style § Bot task to remove erroneously italicized commas FaviFake (talk) 12:06, 2 September 2026 (UTC)reply
    I'm sure there has been many complaints, but I don't believe they hold any weight when it's 2 clicks and some scrolling for ignoring all bots, and adding a user script for removing specific bots from the watchlist with a bit of configuration. Tenshi! (Talk page) 17:57, 2 September 2026 (UTC)reply
    Firstly you have to know how to do that, and secondly it doesn't address the issue of page histories at all. Thryduulf (talk) 18:21, 2 September 2026 (UTC)reply
    Correct, I haven't said anything about page histories, my contention is with watchlist clutter complaints. It's mentioned at Help:Watchlist#Options, and WP:HIDEBOT is on Wikipedia:Bots, both of these seem pretty easy to understand and on pages which would come to mind when checking how to disable bots in watchlists. Tenshi! (Talk page) 18:38, 2 September 2026 (UTC)reply
    Yeah, I remember disabling bot edits and making other changes even before I read those pages or even understood what exactly bots were. FaviFake (talk) 19:04, 2 September 2026 (UTC)reply
    I mean, sure, the options to hide bot edits are there, and we can definitely suggest them to people who find them useful. But I don't think that means concerns about watchlist clutter don't carry any weight. Just because there's a two-click option to hide bot edits, or a user script to hide a specific bot, doesn't mean everyone affected by the task should have to use them. If we're talking about potentially thousands of standalone edits for a pretty minor change, I think it's fair to consider how that affects people who don't want to change their setup. That's why I'd still prefer to get a bit more input. Of course, I understand you have a different opinion on this. Max (talk) 18:45, 2 September 2026 (UTC)reply
    I agree now that those cases should be considered, as well as the possibility that some people may not be able to (e.g. nojavascript users cannot use the user script), but I still don't think they should be given the same weight. Personally it's not a convincing argument when it's an issue that can be resolved for the majority of people easily. Tenshi! (Talk page) 20:18, 2 September 2026 (UTC)reply
    Let's also keep in mind that "majority of people" here means "majority of editors". The costs of minor edits are borne by editors, whereas the benefits are enjoyed by readers who outnumber editors by an enormous margin and who are the ones we're ultimately creating the encyclopedia for. We should try not to let editor-centric bias influence our calculus. Sdkb talk 20:59, 2 September 2026 (UTC)reply
    We should not lose sight of the fact that hiding bots is an imperfect solution to a problem that we have the option of not creating in the first place. Thryduulf (talk) 21:01, 2 September 2026 (UTC)reply
  • Oppose per Thryduulf. * Pppery * it has begun... 03:13, 4 September 2026 (UTC)reply

Bots in a trial period

FengPurgeBot

Operator: Fengrímur (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 17:07, Monday, August 31, 2026 (UTC)

Function overview: A new implementation of ProcBot 5 and ProcBot 6 for cache purges and link refreshes and category/template fan-outs.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python 3.13, with MariaDB

Source code available: Yes, GitHub.

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Taking over ProcBot 5 and 6

Edit period(s): Queues are checked every five minutes, requests themselves run once or daily at 0:00 UTC.

Estimated number of pages affected: No (0) edits. One per individual request or up to 1.500 per fan-out (purges!).

Namespace(s): Main, Template and Category

Exclusion compliant (Yes/No): No. Because it does not edit pages.

Function details: FengPurgeBot reads two protected queues: individual requests and fan-out requests. An individual request uses purge-page-cache to purge one page, or refresh-page-links to purge it with forcelinkupdate=1. The fan-out actions apply the link refresh to the direct page members of one category or the direct (non redirect) transclusions of one template. Files and subcategories are excluded, and targets are limited to the Main, Template and Category namespaces. I used the purge API instead of null edits so that the task does not need to save wikitext.

Each nonblank line must contain one request template. Requests run once or daily at 00:00 UTC. Fan-outs also need an English Wikipedia permanent link to the discussion behind them. The bot records the link for logging purposes. I split the queues so individual requests can remain semi-protected while the higher-impact fan-out queue is extended-confirmed protected. A malformed line pauses that queue.

Before a fan-out starts, the bot reads the complete category or transclusion result twice. Both sets must match, and a set over 1,500 pages is rejected in full. The accepted targets are fixed by page ID. Before every effect POST, the bot resolves those IDs again and rereads the queue to confirm its protection and that the request is still present. Removing an entry cancels anything not yet sent.

A MariaDB ledger records dispatches before HTTP and prevents the same one time request or daily slot from running twice, including after a restart. Missed daily slots are coalesced. Ordinary purges use batches of up to 50 and link refreshes use up to 25. POSTs are serial, at least 30 seconds apart, and use maxlag=5. In any rolling 24 hours, the limits are 180 effect POSTs, 3,000 target attempts and 1,500 forced link-update attempts.

A target is accepted only if MediaWiki returns purged, plus linkupdate for a link refresh, and its identity is unchanged after the request. The bot retries temporary errors later using increasing delays. If a POST may have succeeded but cannot be verified, that target gets at most one later retry by itself. A second ambiguous result suspends the request for my review.

Discussion

Apologies if I'm asking a dumb question (I really need to start checking these earlier in the day), but if I wanted to do a fan-out request on all pages calling {{infobox cricketer}} (which has 32k transclusions) it would reject the request? Primefac (talk) 21:50, 7 September 2026 (UTC)reply

+. Each transclusion means a forced link update, and since maxlag alone does not stop one huge request from putting too much load on the servers or tying up the bot, it needs a per-job cap. I chose 1,500 because the discussion mentioned just under 1,200 redlinked categories, giving about 25% headroom, and because 1,500 had already been used for a similar task by Joe's Null Bot. If a higher limit works and is needed, I could raise it. A lower one is probably better for a trial, anyway... Fengrímur (talk) 08:12, 8 September 2026 (UTC)reply
I think I'm good for a trial, but I'd like a second opinion. Would be good to also make sure we have requested purges ready to go (i.e. is the BOTREQ request still ongoing?). Primefac (talk) 20:44, 13 September 2026 (UTC)reply
Not really ongoing. Depending on how much time people are willing to give this, I could continue working on my next planned bot — an updated version of this one — which would shove the problem off Wikipedia entirely. Basically, that means eliminating the human-in-the-loop that FengPurgeBot currently needs and just autonomously purging whenever it's needed and never when it's not supposed to (It's possible, I can confirm!). Naturally, I could also find pages for us that need requests specifically for this trial... Orrr we pause this for a bit until I publish the update for iFengPurgeBotPro. If it's up to me to decide, that's what I'd recommend, unless there’s a specific need for the bot in the next 1–2 weeks. Fengrímur (talk) 12:48, 14 September 2026 (UTC)reply
Does that mean you are withdrawing this for now? Primefac (talk) 18:22, 20 September 2026 (UTC)reply
No, I changed my mind. I’m way too busy right now to continue working on this bot’s replacement. I think it’s best if we move forward with this bot and its trial, and once I’ve finished my work on the other, previously mentioned bot (the updated version of this — more primitive — one) I shall file a separate BRFA. Let me know when a trial is ready or if you want me to look for much-needed purges myself. Fengrímur (talk) 12:33, 21 September 2026 (UTC)reply
Approved for trial (3 individual requests and 3 fan-outs, or 30 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. I do recognise there won't necessarily be a contribution log, but if there are any logs please link to them as well as the request diffs. Primefac (talk) 18:07, 27 September 2026 (UTC)reply
I will get to this soon. Fengrímur (talk) 18:30, 30 September 2026 (UTC)reply

Rusabot 2

Operator: Rusalkii (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 09:08, Tuesday, September 8, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/rusamoss/rfd_watch

Function overview: Maintain a manual RfD pseudo-watchlist for users that have opted in, to work around the fact that there's no way to watchlist individual RfD discussions.

Links to relevant discussions (where appropriate): N/A

Edit period(s): Continuous (every 15 minutes)

Estimated number of pages affected: Single userspace page for each user who opts in

Exclusion compliant (Yes/No): No

Already has a bot flag (Yes/No): Yes

Function details: For every user that opts in at User:Rusabot/RfD subscribers, maintain a list at User:Username/RfD subscriptions, which is updated whenever that nomination has any changes. Any RfD nominations from your Twinkle log is added automatically, and you can manually add entries as well.

It's been running at User:Rusalkii/RfD subscriptions without any issues. Not entirely sure I need a BRFA for an opt-in userspace-only bot, but filing just in case; I'll unprotect the subscribers page once the bot is approved for other users. Possibly the subscribers page should be permanently ECPed since it controls a bot and non-EC users are pretty unlikely to need it.

Accompanying userscript User:Rusalkii/subscribeToRfDs.js adds some convenience buttons.

Discussion

  • Not entirely sure I need a BRFA for an opt-in userspace-only bot To write anyone else's userspace besides your own and the bot's, you do. WP:BOTUSERSPACE doesn't cover userspace in general, even with opt-in. BTW, I note that an unprotected subscription page may not be completely opt-in, if there's no guard against someone adding other names to the list. Anomie⚔ 11:31, 8 September 2026 (UTC)reply
    I'd ECP it, but if that's not sufficient I suppose I could full protect it and add people on request from the talk page. Since the scope of potential damage is pretty low (adding a single page to each editor's user space that they wouldn't notice unless they went looking for it) I think that's excessive, though. Theoretically I could add a check for someone adding more than one username at a time or adding usernames other than their own, but that's a lot of extra code for pretty marginal benefit. Rusalkii (talk) 17:56, 8 September 2026 (UTC)reply
    Mostly I mention it so it can be taken into account when making the decision. You're right the impact is pretty small, so not worrying about it could be a valid choice. If you decide to worry about it anyway, one strategy might be to have people create a particular .js or .css subpage in their userspace to confirm. Anomie⚔ 23:43, 8 September 2026 (UTC)reply
    I generally don't see any issue with bots editing user space for the purposes of making life easier when the backend software isn't doing the most ideal job, especially if it's opt-in, but there also needs to be a demonstrated need. I'd be fine with a trial (maybe 30 days?) to gauge interest and get feedback from the community. Primefac (talk) 20:40, 13 September 2026 (UTC)reply
    There's been some complaints about the lack of this feature over the years - the latest I've seen is at Wikipedia talk:Redirects for discussion#Watching RfD discussions. Rusalkii (talk) 20:43, 13 September 2026 (UTC)reply
  • Approved for trial (30 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. I'm fine with a speedy approval, but Primefac's idea of a trial makes sense to see if people actually find it useful. Even after that, if there isn't much interest, I personally don't see any harm in approving it. It'll be your call how much effort you want to put into running it. Max (talk) 14:59, 15 September 2026 (UTC)reply
    I find this extremely useful and I'm sure other RFD regulars will as well. voorts (talk/contributions) 22:37, 18 September 2026 (UTC)reply

Bots that have completed the trial period

Sldst-bot

Operator: Solidest (talk · contribs · SUL · edit count · logs · page moves · block log · rights log · ANI search)

Time filed: 08:07, Friday, July 24, 2026 (UTC)

Function overview: One-off runs to correct music charts or infoboxes.

Automatic, Supervised, or Manual: Starting with supervised, then automatic

Programming language(s): Python/Pywikibot

Source code available: -

Links to relevant discussions (where appropriate): Template talk:Single chart#Canadian RPM templates need updated

Edit period(s): Series of one time runs

Estimated number of pages affected: around 8300 articles

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: The Canadian music charts website was recently updated, and all the IDs have changed. I’ve created a mapping table which I’m going to use to transfer the old entries to the new chart with the new IDs. Moreover, these kinds of charts edit runs happen from time to time; I used to carry them out from my main account, but it would be more convenient for me to do so from the bot's account. To comply with the policy on bulk edits and avoid flooding.

Discussion

Approved requests

Bots that have been approved for operations after a successful BRFA will be listed here for informational purposes. No other approval action is required for these bots. Recently approved requests can be found here (edit), while old requests can be found in the archives.

Denied requests

Bots that have been denied for operations will be listed here for informational purposes for at least 7 days before being archived. No other action is required for these bots. Older requests can be found in the Archive.

Expired/withdrawn requests

These requests have either expired, as information required by the operator was not provided, or been withdrawn. These tasks are not authorized to run, but such lack of authorization does not necessarily follow from a finding as to merit. A bot that, having been approved for testing, was not tested by an editor, or one for which the results of testing were not posted, for example, would appear here. Bot requests should not be placed here if there is an active discussion ongoing above. Operators whose requests have expired may reactivate their requests at any time. The following list shows recent requests (if any) that have expired, listed here for informational purposes for at least 7 days before being archived. Older requests can be found in the respective archives: Expired, Withdrawn.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bots/Requests_for_approval&oldid=1378025052"