Jump to content

Wikipedia:Bots/Requests for approval

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

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
PhuzBot 17 (T|C|B|F) Open 2026-10-25, 13:31:34 Zackmann082026-10-25, 15:00:01 Zackmann082026-10-25, 15:00:01
VulpesBot 6 (T|C|B|F) Open 2026-10-18, 02:34:08 Dr vulpes2026-10-18, 02:36:05 Never edited by BAGn/a
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
POTDBot (T|C|B|F) In trial 2026-09-14, 17:19:53 Avalyn0x452026-10-18, 22:21:43 Primefac2026-10-04, 21:27:57
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
TenshiBot 13 (T|C|B|F) Trial complete 2026-10-17, 18:53:37 Tenshi Hinanawi2026-10-25, 14:28:39 Zackmann082026-10-18, 17:10:12
VWF bot 11 (T|C|B|F) Trial complete 2026-10-10, 11:23:37 Phuzion2026-10-22, 18:34:06 Primefac2026-10-18, 21:09:32

Current requests for approval

PhuzBot 17

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

Time filed: 13:31, Sunday, October 25, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: pywikibot

Function overview: Software rewrite of PhuzBot 15 to use pywikibot, open-ended approval request, no upper limit on batch size.

Links to relevant discussions (where appropriate): PhuzBot 15

Edit period(s): Periodic, when needed

Estimated number of pages affected: Runs will range from a few thousand to 100k+. No upper limit on batch size.

Exclusion compliant (Yes/No): Yes

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

Function details: This is a rewrite of PhuzBot 15 using pywikibot. A few reasons for the rewrite include:

  • AWB performance and memory leaks. While I greatly appreciate the work that the AWB developers are doing, AWB is not particularly performant when working on large lists, especially above 10k items. When running PhuzBot 15, I often have to close and restart AutoWikiBrowser due to memory leaks and performance regressions after handling thousands of pages. The memory usage and CPU time for this script remains effectively flat even on enormous lists. In my dry-run testing, this bot is capable of reading and editing (but not saving) more than 700 pages per minute. Compared to AWB's upper limit of about 120-150 pages per minute in pre-parse mode, this bot is significantly more performant.
  • This bot is much more operator-friendly: My current method for setting up a bot run when we deprecate parameters takes about 15 minutes, going through a checklist, customizing Primefac's infobox code to include the old and new parameters and the redirects that should be resolved, as well as ensuring that genfixes are turned on, and edit summaries are properly configured. The new script fetches the list of redirects to the template, then reads the template’s {{#invoke:Check for unknown parameters}} call for the list of valid parameters (along with the map parameters that |mapframe_args=y and |pushpin_map_args=y add, read from the module itself), its {{#invoke:Check for deprecated parameters}} call for the list of deprecated parameters, and its tracking categories. If the template does not list any deprecated parameters, the script stops. Otherwise, it builds its gameplan, presents it to the operator for approval, and then performs the actions requested.
  • This bot only focuses on the infobox, and does not perform AWB Genfixes (since it's not AutoWikiBrowser).

This bot does abide by the 20 edits per minute rate specified in WP:BOTPERF.

I have about a quarter million edits between my BRFAs 8, 9, 11, 12, 14 and 15. As of the filing of this BRFA, Task 15 has a revert rate of approximately 0.033%, or one revert per every 3,000 edits on more than 167k edits.

My BRFA for Task 15 specified an upper bound of "roughly 100k" pages, with the promise to file a BRFA for tasks significantly above that in scope. With nearly a quarter-million edits in this particular area (including an open-ended task), I think I have demonstrated I have the judgment necessary to run batches larger than 100k pages. When issues have been found and reported to me on my talk page, I generally fix them within hours or even minutes of them being reported.

Given that this is a newly written script on top of pywikibot, I'd like to request that my trial run be set to 250 edits, just so we can have adequate data to review.

As always, happy to answer any questions.

Discussion

VulpesBot 6

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

Time filed: 02:34, Sunday, October 18, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): R rwikibot package https://gitlab.com/vulpes24601/rwikibot

Source code available: https://gitlab.com/vulpes24601/vulpesbot

Function overview: Daily read-only audit of Wikipedia:AI noticeboard case subpages. The bot checks each case page against the new case-page format (case banner, dated filing sections, cleanup tracker, index rows) and writes one report page listing formatting problems.

Links to relevant discussions (where appropriate):

Edit period(s): daily

Estimated number of pages affected: ~250

Exclusion compliant (Yes/No): Yes

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

Function details: # Lists all non-redirect subpages of Wikipedia:AI noticeboard, skipping the numbered archives.

  1. Compares each page's latest revision ID with the one stored from the previous run, and fetches text only for pages that changed. A normal day is a few listing requests plus one batched content request.
  2. Parses each case page and runs these checks:
    • Banner: missing or duplicate banner; case_name not matching the page title; cleanup/llmprod/conduct/case_type values the banner doesn't recognise (status values are read live from Template:AINB case banner/data); malformed or future original_file_date.
    • Structure: missing Discussion or Cleanup section; no {{AIC article list}}; missing {{user-ainb}} on user cases.
    • Filings: a filing heading dated later than its first signature (the move-script bug); unsigned filings; malformed date headings; filings out of order.
    • Cleanup tracker: {{AIC article row}} entries that render as "Unknown status", rows missing an article, duplicate rows, and cleanup marked completed while rows are still open.
    • Subpages: a /2-style subpage carrying a case banner; subpages with no parent case.
    • Index: banner statuses that disagree with the AINB/Cases or AINB/Closed row; cases missing from the index; cases on the wrong table; banner pages missing from Category:All AINB cases.
  3. Rewrites a single report page, User:VulpesBot/AINB format report. Errors and warnings are listed per case with a link; info-level findings are counted. Each entry shows when it was first seen, flags new entries, and lists issues resolved since the previous run. The edit summary gives the totals, e.g. "Bot: AINB format report, 42 open issues (3 new, 5 resolved)".


Discussion

This will be the first time the Rwikibot R package will be used, I've run a few tests on the testwiki under my own account and it has not had any problems pulling pages and data into R. Dr vulpes (Talk) 02:36, 18 October 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
Image 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! Image 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

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
Image Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 21:27, 4 October 2026 (UTC)reply
Any update on the trial? Tenshi! (Talk page) 21:03, 18 October 2026 (UTC)reply
I am currently having trouble developing and testing the bot as I do not currently have access to a machine capable/willing to run a compiler. I am still working on it through Google Colab, however that is a slow process made even slower by my lack of available time. Avalyn (talk) 22:21, 18 October 2026 (UTC)reply

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
Image 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

Bots that have completed the trial period

TenshiBot 13

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

Time filed: 18:53, Saturday, October 17, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available:

Function overview: Regex find and replace based on Wikipedia:Linter/Signature submissions

Links to relevant discussions (where appropriate): Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 31

Edit period(s): As needed

Estimated number of pages affected: No estimate

Exclusion compliant (Yes/No): No

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

Function details: Mostly the same as Qwerfjkl (bot) 31 except with regex. At the moment the code only has 4 different instances to search for, but with time I'll add more when I can.

Discussion

@Jonesey95: I know you are not a BAG, but you are one of the few people I know who actually understands linter errors. Do you have any thoughts on this BRFA? Value your opinion here. --Zackmann (Talk to me/What I been doing) 19:41, 17 October 2026 (UTC)reply

Jonesey95 since the above ping was malformed. Tenshi! (Talk page) 19:48, 17 October 2026 (UTC)reply
Facepalm Facepalm . Thanks Tenshi Hinanawi.... My bad! --Zackmann (Talk to me/What I been doing) 19:50, 17 October 2026 (UTC)reply
This sounds like a great addition to the stable of Linter cleanup bots. I would like to see some test edits. – Jonesey95 (talk) 14:47, 18 October 2026 (UTC)reply
Image Approved for trial (100 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. sounds like this is a useful tool and worthy of giving a trial. @Tenshi Hinanawi: you are go for a trial! Zackmann (Talk to me/What I been doing) 15:04, 18 October 2026 (UTC)reply
Image Trial complete. Edits. A few of the initial edits had a bad replace which included a backslash, which was fixed during trial. Tenshi! (Talk page) 15:42, 18 October 2026 (UTC)reply
The Ichthus newsletter also had an extra div which should have been removed. Tenshi! (Talk page) 16:17, 18 October 2026 (UTC)reply
@Tenshi Hinanawi: it would seem that an extended trial is warranted as there were at least a could of issues. Going to let this sit for a bit and I encourage you to do some more local testing. If there are no objections from other editors in the next day or two I will gladly approve another trial! Zackmann (Talk to me/What I been doing) 17:10, 18 October 2026 (UTC)reply
I don't think it does, since these are minor faults that I would have caught during normal operation. The rest of the regexes were fine, it's just me failing to check the regexes thoroughly. Also, please don't ping, I have this watchlisted. Tenshi! (Talk page) 17:14, 18 October 2026 (UTC)reply
@Jonesey95: Do you mind having a look through the trial edits and giving your opinion? Tenshi! (Talk page) 15:22, 19 October 2026 (UTC)reply
The bot created new Linter errors and failed to fix a font error at User talk:Walkero159, User talk:Kris Skylar Storm Bryden, and similar pages. The bot missed an easy closing /div tag and some easy center tags at User talk:Robynduby; the /div is one of the patterns listed on the signature submissions page. The bot missed some easy Icththus-related errors at User talk:Fulldisclosure07. You can find regexes for many of these fixes at User:Jonesey95/AutoEd/linter.js. (edited to add: This is the entirety of my feedback. I checked the entire edit batch.) – Jonesey95 (talk) 13:50, 25 October 2026 (UTC)reply
  • 1&2: My fault for missing the font tag.
  • 3: The trial ran with only 4 regexes, not everything on signature submissions.
  • 4: It had only the January 2012 issue in mind. Tenshi! (Talk page) 14:04, 25 October 2026 (UTC)reply
    Previous bots have gotten negative feedback for visiting pages repeatedly. Legobot's Linter fixing bot deals with this, and with mistakenly creating new Linter issues with its changes, by checking to ensure that there are no remaining Linter errors on the page before saving. Your bot doesn't necessarily need to do that, but if there is any way to check to see if only font errors are left behind, or only obsolete tag errors, that would be helpful. In my script-assisted edits, I often leave only obsolete tags, hoping that Legobot will be able to clean up behind me in a single edit. – Jonesey95 (talk) 14:12, 25 October 2026 (UTC)reply
    I'm aware, hence I've been trying to add more regexes during this period. Tenshi! (Talk page) 14:28, 25 October 2026 (UTC)reply

VWF bot 11

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

Time filed: 11:23, Saturday, October 10, 2026 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python, using Pywikibot and mwparserfromhell.

Source code available: Custom Pywikibot on my computer.

Function overview: Remove expired "begins" and "resumes" date annotations from airport destination lists.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Bot_to_remove_historical_"begins"_dates_from_airport_destination_lists.

Edit period(s): Daily.

Estimated number of pages affected: Mainspace airport articles using {{Airport destination list}} or {{Airport-dest-list}}. Only articles containing eligible expired annotations will be edited.

Exclusion compliant (Yes/No): Yes

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

Function details: Identifies destination cells in two-, three- and four-column layouts. Removes standalone "begins" or "resumes" annotations containing a valid, complete date on or before the current UTC date, preserving destination links, commas, references. Skips future dates, "ends" annotations, incomplete or ambiguous dates, and unsafe markup. Uses revision checks to prevent conflicting edits, disables cosmetic changes and allows at least ten seconds between edits.

Discussion

Image Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 15:10, 10 October 2026 (UTC)reply

Image Trial complete. See contributions capped at 50. Vanderwaalforces (talk) 18:34, 11 October 2026 (UTC)reply
I’ve just gone through them all as the original requester at BOTR, and can’t see any issues with the edits made - they all cleanly removed the dates as required, and all were dates in the past Danners430 tweaks made 21:53, 11 October 2026 (UTC)reply
I don't have any concerns with the task itself, but the operator has been blocked from article-space indefinitely during the BRFA. I'm not sure how BAG feels about that in regards to how this BRFA should be handled? Tenshi! (Talk page) 21:00, 18 October 2026 (UTC)reply
The bot is not the user, and the edits being made by the bot are specific and (as far as I am aware) not really something where using AI would matter? Primefac (talk) 21:03, 18 October 2026 (UTC)reply
I agree it doesn't matter in this context, I was thinking about reverting potential errant bot edits and how the operator would comply with WP:BOTACC, given they would have to make edit requests, etc. Tenshi! (Talk page) 21:07, 18 October 2026 (UTC)reply
That is indeed what would need to happen, either page-by-page or as a mass rollback request. Primefac (talk) 21:09, 18 October 2026 (UTC)reply
Non-BAG member comment - WP:BOTPOL states, In addition, prospective bot operators should be editors in good standing[...]. I would argue that a user that indefinitely blocked in article space is not a user in good standing. Additionally, if the bot operator is prohibited from editing article space, one could argue that a bot under that operator's control should not be permitted to make article space edits. My reasoning here is that according to WP:BOTACC, Bot accounts are considered alternative accounts of their operator and according to WP:BADSOCK, Sanctions apply to individual editors as people, not to accounts, unless specified otherwise. Whether the account is operating automatically or by hand, the bot operator accepts responsibility for each and every edit that the account produces. Were I a BAG member, I would oppose new article space BRFAs from Vanderwaalforces until they are no longer sanctioned from editing in that namespace.
To be 100% clear, I do not oppose Vanderwaalforces being a bot operator, nor do I think this particular bot has any technical reasons not to be approved. VWF has shown this year that they have the technical aptitude to run bots, and that they are capable of coming up with and coding useful bot tasks that benefit the community. If they are able to resolve their sanctions, I would love to see them continue to develop bots, and would love to see them continue in the bot operator community. phuzion (talk) 18:34, 22 October 2026 (UTC)reply

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=1381893896"