Overview (Dictionary) Bot policy Bot Approvals Group Guide Noticeboard Newsletter Bot Requests Requests for Approval Adminbots {{BAG Tools}} Creating a Bot List of bots Bot status report

BAG member instructions

If you want to run a bot on the English Wikipedia, you must first get it approved. To do so, follow the instructions below to add a request. If you are not familiar with programming it may be a good idea to ask someone else to run a bot for you, rather than running your own.

Current requests for approval

DeltaQuadBot 9

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

Time filed: 22:52, Wednesday, February 24, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/dqwiki/scriptpusher

Function overview: Updates js/css based code from github (or whatever site) for user scripts while allowing for maintainers to have a proper code review and issues interface.

Links to relevant discussions (where appropriate):

Edit period(s): As needed when code changes

Estimated number of pages affected: Expect <100, only 3 or so to start

Exclusion compliant (Yes/No): No

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

Function details: The bot takes User:AmandaNP/scriptcopy.js and matches the code with the relevant page listed.

Will be seeking Interface Adminship for this bot task.

Working product at User:DeltaQuadBot/sciptcopytest.js.

Discussion

I've sectioned this to better keep track of the discussion. -- Amanda (aka DQ) 23:30, 25 February 2021 (UTC)

General Approval

• @AmandaNP: per Wikipedia:Interface administrators#Bots Any bot operator requesting access for their bot(s) must permanently possess the user right themselves. - you do not appear to currently possess interface adminship yourself. Are you planning on requesting the rights yourself? --DannyS712 (talk) 23:03, 24 February 2021 (UTC)

Edit conflicted the same time you posted just on another page. I have requested it. -- Amanda (aka DQ) 23:05, 24 February 2021 (UTC)

• Just a heads up I have seen the discussions and intend to give my input, I just need a bit of time to do so. -- Amanda (aka DQ) 19:08, 25 February 2021 (UTC)
• Although I am editing and taking on other duties, I'm not well enough to sit down and reply at the moment. I will aim to start getting the rest of the replies in Friday or Saturday. -- Amanda (aka DQ) 07:52, 2 March 2021 (UTC)

Account Security

• Does this bot use BotPasswords or OAuth? (The latter is recommended due to it being more secure – credentials are not sent over the internet except at time of setup). – SD0001 (talk) 09:58, 25 February 2021 (UTC)

  What's wrong with BotPasswords? I mean, credentials are encrypted in transit anyway so this is not really an issue. Most API requests to any API, from financial services to healthcare to whatever else, contain an API key in each request. BotPasswords are pretty much equivalent to API keys. ProcrastinatingReader (talk) 10:01, 25 February 2021 (UTC)

  Certainly not a dealbreaker. I suppose OAuth is slightly better as secrets keys are only used to sign the requests and not themselves sent. But I guess it's not much of an advantage over HTTPS connections. IIRC Wikimedia documentations have recommended OAuth. I don't have links handy but at least it's mentioned in mw:Manual:Pywikibot/login.py#Login using OAuth. Security aside, OAuth is a bit easier to work with (no login needed, no need to worry about session expiries, no need to cache session cookies, etc). – SD0001 (talk) 13:11, 25 February 2021 (UTC)

  Found it. Wikipedia:Interface_administrators#Bots says All bot operators are required to enable 2FA for their bot accounts and create a strong account password, and are strongly urged to use OAuth for maximum security. – SD0001 (talk) 13:13, 25 February 2021 (UTC)

  It uses BotPasswords where each and every user permission has it's own password to break up the ability to screw anything up if one was to be compromised. I believe this setup is stronger than what OAuth would provide if it were breached (even if unlikely). -- Amanda (aka DQ) 23:33, 25 February 2021 (UTC)

• Have you completed WP:2FA enrollment on your bot account? — xaosflux ^Talk 11:46, 25 February 2021 (UTC)

• Already done Yes, for a long time now. -- Amanda (aka DQ) 23:33, 25 February 2021 (UTC)

• The code suggests that this is going to run on the Toolforge account "deltaquad-bots". But https://toolsadmin.wikimedia.org/tools/id/deltaquad-bots shows that another user (SQL) has access to the account who isn't an intadmin. Unfortunately, I believe the policy is that all maintainers should have the advanced rights that the bot has. – SD0001 (talk) 13:22, 25 February 2021 (UTC)

  @SD0001: I'm a bit out of the loop on intadmin bot policy. Are you able to link me to the policy that says that? Wikipedia:Interface_administrators#Bots only mentions Any bot operator requesting access for their bot(s) must permanently possess the user right themselves.. I'm not the bot operator.

  @AmandaNP: If this is a blocker, please feel free to remove me. SQL^{Query me!} 17:15, 25 February 2021 (UTC)

  I think this is a borderline case, and I'm not sure how to weigh it. In theory, anyone who has access to the Toolforge project is a bot operator/maintainer in some sense, and has access to the bot's password (or OAuth credentials if they were used here, as they should be). This is a bigger concern for an adminbot, where non-admin maintainers could use it to access deleted revisions without being detected, but you are already an admin and obviously a trusted user in general (and a CU). I will leave it to someone else to make the determination here. I will also repeat my earlier suggestion for a separate intadmin-bot account, so you could stay on as a maintainer for everything else DQBot does but leave only Amanda with access to the intadmin flag. — The Earwig (talk) 18:33, 25 February 2021 (UTC)

  I'm not a big believer in being worried over who a botop appoints as a sysadmin or co-dev tbh (the concern is akin to saying only the CTO of the WMF should have root access to the servers), but in this case especially given SQL can just request it at BN anyway I don't really think there's any issues here. ProcrastinatingReader (talk) 18:39, 25 February 2021 (UTC)

  Well for one, IAs are required to have 2FA enabled, sysops and functionaries (atm) are not. It's also not in the purview of BRfA or BAG to make a decision to approve someone to de facto IA permissions. I'm confident in SQL, but I don't think it can be swept away. For this among other reasons, I think Earwig's right about the separate bot account. ~ Amory (u • t • c) 18:47, 25 February 2021 (UTC)

  I don't think we actually have any policy on multiple bot operators (WP:BOTMULTIOP isn't even about bot operators; see Wikipedia talk:Bot policy section #1) which is weird. I have no clue what the precedent is, given we only have one other IA bot and I'm not aware of any Adminbots that ran into the same circumstances. But it does seem like moving this bot to a separate tool is the easiest and least controversial option here. ProcrastinatingReader (talk) 18:55, 25 February 2021 (UTC)

  2FA is not relevant here, since the attack surface isn't SQL's wikimedia account, but their Toolforge private key. – SD0001 (talk) 19:57, 25 February 2021 (UTC)

  SQL was added a short time back because I needed someone to have access to toolforge while I didn't for personal reasons. I will remove them now and we won't have to worry about it. Alternatively, I could request a seperate toolforge project too for that concern. Obviously I would never hand over the keys to someone without the rights. If we want to get technical of course, every WMF staffer who administrates toolforge has access to it to, and I'm not a fan of having to pay to host this bot on my own, because even then those sys admins would have access. -- Amanda (aka DQ) 19:08, 25 February 2021 (UTC)

   Done -- Amanda (aka DQ) 23:24, 25 February 2021 (UTC)

• I'm worried about auditability. If someone's wiki account is compromised, we have plenty of logs (CheckUser and server-level logs) to identify what went wrong, where it was compromised from, and methods to (hopefully) block the malicious actor from doing it again. Even if it was on Gerrit or the hopefully-coming-soon Wikimedia GitLab instance, we have that ability. What does GitHub give us access to? How are you going to make sure that all collaborators to a repository have 2FA, strong passwords, etc.? This is effectively intadmin by proxy and should be held to the same security standards IMO. Legoktm (talk) 07:06, 2 March 2021 (UTC)
  • Not sure I follow/agree. A user doesn’t have to have intadmin to edit their own JS file in their userspace. Accordingly, I don’t really see why they need to have 2FA enabled on GitHub. I don’t see the security concerns in this aspect, personally, aside from general recommendations for GitHub account security (which is likely to be better than WP account security given, for example, GitHub has a properly functioning 2FA system [when I tried WP’s it was filled with bugs]). ProcrastinatingReader (talk) 11:59, 2 March 2021 (UTC)
    • Account compromises on GitHub and Wikipedia have happened in the past and will continue to happen in the future, regardless of how many measures we take, mistakes happen, attackers are clever and motivated. But when we respond to a compromise, we look to audit trails and logs to identify what happened and who the attacker was...which I don't think we can do for GitHub accounts, certainly not at the level we can for things in the Wikimedia infrastructure. Legoktm (talk) 20:08, 2 March 2021 (UTC)

      This kinda seems like saying everything not self-hosted = bad? ProcrastinatingReader (talk) 20:22, 2 March 2021 (UTC)

      And besides, what are you going to do about an attacker on a disposable residential proxy? I mean... I still really don't see the issue myself. ProcrastinatingReader (talk) 20:24, 2 March 2021 (UTC)

      I mean, I use GitHub too. I'm asking if auditability has been considered in the design of this bot, and if there are other features we can integrate (e.g. if users are comfortable with GPG, then verification of GPG-signed commits and tags) to reduce the risk of impact when a compromise happens. I would add that I believe these are real concerns based on past bad/malicious actors and compromises that led to intadmins and other policy adjustments in the first place. Legoktm (talk) 21:08, 2 March 2021 (UTC)

Code/Operational concerns

Initial thoughts: Judging by the format of User:AmandaNP/scriptcopy.js currently (permalink) it seems like you want to update based on the raw file. Wouldn't it be better to setup a webhook or poll the commits, that way you can use the commit message in the edit summary (so the summary will be useful)? ProcrastinatingReader (talk) 23:07, 24 February 2021 (UTC)

Definitely a very good point. I'd be happy to upgrade and include that over time, I just promised to start working on this a few months ago, and just did so today. I can definitely at least work on pulling the latest commit information/reason before it goes completely live. -- Amanda (aka DQ) 23:12, 24 February 2021 (UTC)

• How exactly is this going to run, in terms of edit period? Do you plan to run it on a cron or something? ProcrastinatingReader (talk) 23:10, 24 February 2021 (UTC)

Yes, with a cron job that uses jsub on toolforge. Code would not be updated unless it's changed. -- Amanda (aka DQ) 23:12, 24 February 2021 (UTC)

How would you prevent edit warring? I mean, say an intadmin manually changes code on Wikipedia (because they don't have push rights to the repo), but the GitHub code is different and lacking their change (ie, it's older). Your bot would override the intadmin's edit on the next run, right? ProcrastinatingReader (talk) 23:13, 24 February 2021 (UTC)

It would. Most people fork content already and attribute it as owners have to leave it under CC-BY-SA when they want to change or customize it. I could see stopping the bot from updating if the last revision user is not it's owner or the bot itself. B I'll add that. That said, I would hope people wouldn't use this in an abusive manner to hijack code from the owner when they are still active. -- Amanda (aka DQ) 23:31, 24 February 2021 (UTC)

My concern was more that there may be special cases where an intadmin has to apply a change to someone's JS file for various reasons. Rare I imagine, but could still happen. In those circumstances the change should stick. I guess the IA could also remove the line from User:AmandaNP/scriptcopy.js at the same time as making their update, but I'd probably prefer some kind of handling in the bot to know not to update. Possibly the best way to do this is timestamps. If the timestamp on the Wikipedia revision is newer than the latest commit, then the bot shouldn't push the GitHub changes. Usernames would also work, though.

This does lead me to my second concern, though. On Wikipedia, only intadmins and the script owner can edit a .js script. via GitHub it would be possible to give push access to other users (which I guess is, to some degree, the point of this?). I don't know whether this is sufficiently a concern but I'd like to hear from intadmins about it. Suggest advertising this task to the intadmin noticeboard. ProcrastinatingReader (talk) 23:38, 24 February 2021 (UTC)

This is definitely something to consider. My first initial thought would be that the owner or int admins would already be proxying for others anyway. If the owner gives approval for them to get push access to github, then they are already rubberstamping the code. I'll definitely hit the board though, as I would like this discussed too. -- Amanda (aka DQ) 23:58, 24 February 2021 (UTC)

This is also one of my concerns; there's a difference between an int-admin or the user who controls the JS manually copying whatever's on GitHub and (presumably) checking the diff before saving (gives a chance to detect obvious funny business) and a bot doing it at 3am in response to a malicious commit when no one is watching. I would want to encourage that this only be applied to repos set up such that only users who can edit the corresponding JS page can commit directly to the branch that gets pushed on-wiki, or with a required pull request setup where one of those users needs to sign off on changes. Unfortunately, I can't think of any way to programmatically check this, unless the bot maintains a mapping of enwiki users to GitHub usernames and checks that on push; this may be difficult to maintain. Building on xaos's suggestion below, it could be that the on-wiki JS file lists the GitHub users allowed to make pushes, and the bot checks that before overwriting. Forgive me if this sounds overly cautious, but I think the implications if something goes wrong here are self-evident. — The Earwig (talk) 00:50, 25 February 2021 (UTC)

These were my thoughts too. Personally, I have no concerns with the idea of having multiple maintainers for a script who can edit it. This is normal for software projects, anyway. However, unless the maintainers are all intadmins, this hasn't technically been possible on enwiki until this bot. So I'm not sure where we stand on consensus on the idea of multiple maintainers; xaosflux thoughts? ProcrastinatingReader (talk) 01:20, 25 February 2021 (UTC)

@ProcrastinatingReader: as far as I'm concerned what happens off-wiki isn't an English Wikipedia problem - so if a user wants an intadmin, or that intadmin's bot to update a page for them based on whatever - mostly OK. I'd start to have a different tune if we weren't talking about user scripts. The one thing that may be an issue isn't about script security at all, but about copyright and licensing - and making sure that the work that is being published on-wiki complies with licensing declared off-wiki. I don't go down the details of licensing rules that often though so would leave that to others to expand upon. — xaosflux ^Talk 02:04, 25 February 2021 (UTC)

I understand what you're saying, but the thing about user scripts is other users can import them, and some are so widely used they are effectively gadgets. For GN's script that prompted this BRFA, it doesn't seem to have any other users, so I have no problem with GN deciding who can push to his GitHub repo and run JS on his machine. But then I think we need to make it clear in whatever mechanism that's used to add scripts to this bot that they can't used by other users, or those users have to consent to this risk that they may not know about, perhaps with (again, going back to your suggestion) a clear message at the top of the script. Alternatively, users already consent to this risk when they add anything to their personal JS pages, so it doesn't matter, and I'm just being paranoid. — The Earwig (talk) 02:40, 25 February 2021 (UTC)

Security paranoia isn't a bad thing :) We do specifically warn people (MediaWiki:jswarning) that if you load someone else's script it could change without notice. — xaosflux ^Talk 03:09, 25 February 2021 (UTC)

I'm with Xaosflux on this (an extremely rare thing to happen). If someone trusts others to maintain their script and have DeltaQuadBot auto-update it on-wiki, they (the script owner) are responsible for any and all edits made by the bot, even if those edits were triggered due to github commits pushed by another user. They should take steps to ensure that only users they trust have push access, and add necessary security to their account. The chances of a github account being compromised aren't any more than that of a Wikipedia account being compromised (in fact it's likely lesser because github people have implemented smart security features whereas WMF authentication systems are still stuck in 2015-era). I know this bot is not github-specific, but the principles still apply. Users should anyway not be installing scripts if they don't trust the script owner, which includes trusting them not to give away access to malicious users. – SD0001 (talk) 09:54, 25 February 2021 (UTC)

• If this is going to be a continually running task, I strongly suggest you register a separate bot account for it, to avoid the extra risk of your normal bot being an interface admin. For precedent, see MusikBot II. — The Earwig ⟨talk⟩ 00:06, 25 February 2021 (UTC)

Administrative thinking

• What is the process you are going to use to add new work to this job? Will there be an on-wiki record of users giving you permission to update their personal script pages? — xaosflux ^Talk 00:10, 25 February 2021 (UTC)

  Pending figuring the exact mechanism out - since it's pretty clear I'm a guinea pig here, I give my permission for Amanda/her bot to update User:GeneralNotability/spihelper-dev.js. GeneralNotability (talk) 00:22, 25 February 2021 (UTC)

  @GeneralNotability: thanks for the note, I wasn't too worried about yours - just want to know how this can be reviewed after the fact. While BRFA's are not prescriptive on how an operator wants to do most things, we can have a requirement that something gets done in some manner. One possibility I wouldn't mind seeing would be for the script owners to put a declaration right on the top of their script as a comment for example - and the bot would need to read that and make sure it is there. Something like that could possibly resolve my next question as well. — xaosflux ^Talk 00:35, 25 February 2021 (UTC)

• How can a user decide to have this process stopped if they no longer want you updating their page? — xaosflux ^Talk 00:35, 25 February 2021 (UTC)
• Curious about using User:AmandaNP/scriptcopy.js as the config. I presume using .js (as opposed to json) is to prevent rogue sysops from editing, and it's not like relying on a file on GH or something would be more secure. That being said, would it not make sense to have some additional safeguards in place? Per the code, there's nothing stopping the bot edits from editing any page. Sure, the vector would be limited to intadmins and GIEs, but at the very least I'd expect updatescript.py to do some simple QA like "does this page begin with 'User:'" or "does it end in .js/.css/.json" and so on. ~ Amory (u • t • c) 11:55, 25 February 2021 (UTC)

  Code restrictions are a good idea, if only to prevent this task being used to update scripts in the MediaWiki namespace (ie, gadgets) later down the line. It is possible the updating of gadgets will be a different matter for the purposes of approval. But while we're here we might as well discuss the gadget question: are there issues with using this script to update gadgets, too? I mean, I don't think there's anything inherently special about a gadget, plenty of user scripts (like reply link) which are used more than most gadgets and are in userspace.

  It seems, to me, a good idea to have scripts on Wikipedia synced with the release branch (often master) of GitHub. It's less irritating and more streamlined. I'd, again, probably prefer this bot to be using webhooks here, since with a webhook approach one can push from their text editor / IDE, or merge a PR, and the script will automatically update on Wikipedia (which, in my eyes, is a good thing, incidentally reminding me of Twinkle's script history). ProcrastinatingReader (talk) 12:05, 25 February 2021 (UTC)

YTStatsBot

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

Time filed: 08:37, Friday, February 19, 2021 (UTC)

Function overview: Update the stats (subscriber count, views, last update date) in YouTube Personality infoboxes by data fetched from YouTube API.

Automatic, Supervised, or Manual: Supervised

Programming language(s): Python 3.7

Source code available: https://github.com/petewarrior/pywikibot-youtube-subscribers/

Links to relevant discussions (where appropriate):

Edit period(s): Manually (every few days)

Estimated number of pages affected: 10-20, may accept requests as long as infobox is in the supported format

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details:

This script works in three steps:

1. Parse a YouTube personality infobox on a Wikipedia page to obtain the channel ID (except for infoboxes using channel_direct_url)

2. Query the statistics for the channel ID to the YouTube API

3. Update the stats in the infobox

Requires Pywikibot, Python 3, and a YouTube API key.

Page requirements

• The page must have a Wikipedia YouTube personality infobox, either on its own or as a module in another infobox.
• The script can only parse YouTube channel ID in the channel_url field. If the infobox uses channel_direct_url, both channel_id and channel_direct_url must be hardcoded in the script (example in source code). Only one channel per infobox is supported.
• Last update time is printed in the stats_update field. It must already exist and have a date formatted using the Wikipedia date template with the YYYY-MM-DD format.

Discussion

Initial thoughts:

1. Do you plan to only run this on some specified articles? Wouldn't it be better to have it run on all pages using {{Infobox YouTube personality}}?
2. Suggest advertising this discussion to the template talk page.
3. A similar task was suggested in Wikipedia:Bots/Requests for approval/YoutubeSubscriberBot. Similar questions apply to this task. For example, will it round the stats to 2 or 3 sig figs (so that it's not spamming the article history with daily updates)?

ProcrastinatingReader (talk) 08:52, 19 February 2021 (UTC)

• 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⚡ 09:16, 19 February 2021 (UTC)

  Petewarrior you shouldn't edit using the bot account until the BRFA is approved. Though, since you already have I've looked at some of the edits, e.g. at Rina Ikoma (diff), and concern #3 is even more prominent I think. The figures must be rounded to 2 or 3 significant figures before editing, to ensure it doesn't edit much and not until substantive changes are needed, otherwise it's going to spam the page history. ProcrastinatingReader (talk) 09:25, 19 February 2021 (UTC)

  Alternatively, I would support {{Infobox YouTube personality}} being edited to try to fetch the data from either Wikidata or a userspace/sub-template page, and the bot updating that page continuously. That way, there will be no edits made to the article itself. I think this is probably the best approach to take with data-updating tasks like this. ProcrastinatingReader (talk) 09:27, 19 February 2021 (UTC) Diff added to page link for ease of use later. Primefac (talk) 11:37, 19 February 2021 (UTC)

  Agreed on both counts; not only does it make more sense to pull pages from the template, if we really are going to look into automating this the template should have a subpage with storage for all of the subscriber counts, meaning that only one page needs to be updated. At just under 2k uses we'd need to be a little creative with our switch statements, but really the initial setup will be the main hurdle. Primefac (talk) 11:37, 19 February 2021 (UTC)

  I feel like structured data like this is best suited for Wikidata. However, that would mean this BRFA has to be opened there (as you know, but to be clear for the operator: enwiki BAG has no authority on Wikidata bot operations). A switch should also be okay I'd imagine (not sure tho, never personally tried a 2k entry switch, have you?). Technically however, a for loop in the code can easily produce the output though. I personally think the best option is to send this off to Wikidata, though. ProcrastinatingReader (talk) 11:46, 19 February 2021 (UTC)

  I also agree that Wikidata would be the best place for this sort of thing - it would also make adding new channels easier. With the subpage-and-switch-statement method it would require manually tweaking it every time an additional channel needs to be added (I have no idea whether that's a real concern however, do we foresee the use of this infobox growing significantly over time?). This means the data can be updated as often as we like without spamming pages with "changed 3.44m to 3.43m". ƒirefly ( t · c ) 11:53, 19 February 2021 (UTC)

• Apart from the subpage and Wikidata methods mentioned above, Commons structured data is also useful. See Template:NUMBEROF#How it works. A new template/module in the infobox would retrieve data from a table at Commons (available at all projects). A bot would update the Commons table. Johnuniq (talk) 00:23, 20 February 2021 (UTC)
• Hello, thank you for all your feedback. Following that, I've created a rough script to update the relevant stats in Wikidata, which is in the same Github repo if anybody would like to check it out. I'm still figuring out how to get the WikidataIB module to fetch the data (it seems to dislike string target values). I haven't tried the Commons API.
  As to why it can't update all Youtube infobox in its current iteration, the boxes need to already contain data in a very specific format, which is also why it's proposed to make it a supervised bot to be manually run and verified every week or so. PetéWarrior (talk) 13:16, 20 February 2021 (UTC)

  In regards to WikidataIB, if you need help it could be worth getting in touch with RexxS who maintains the module; he may be able to assist.

  In regards to all YouTube infoboxes, I'm not overly familiar with this template so question: shouldn't all transclusions have some kind of unique identifier (likely the URL/channel ID), and if so can't it automatically update wherever that is present? For the purposes of approval it's fine if you want to manually run and supervise its updates, so that won't affect this approval proceeding, but I do imagine it would be easier if it could safely run as automated. In particular, why is it not possible to parse channel_direct_url? ProcrastinatingReader (talk) 12:30, 25 February 2021 (UTC)

ElliBot

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

Time filed: 14:46, Saturday, January 23, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s):

Source code available:

Function overview: Automatically apply {{redirect category shell}} templates to redirects with Wikidata, and remove redundant {{Wikidata redirect}} templates.

Links to relevant discussions (where appropriate):

Edit period(s): one time run

Estimated number of pages affected: 50,000-100,000

Exclusion compliant (Yes/No): Yes

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

Function details: I recently modified {{Redirect category shell}} to automatically detect Wikidata links and apply the template {{Wikidata redirect}} if they exist. This was previously already done with protection levels, and there is no reason that {{Wikidata redirect}} should not also be applied.

There are currently 100,000 redirects in the category Category:Redirects connected to a Wikidata item, which is applied by the software. There are currently 30,000 redirects in the category Category:Wikidata redirects. Nearly all of these were put into that category by applying {{Wikidata redirect}} manually, meaning they will need the tag removed (as it will be a duplicate).

Many of the remaining 70,000 pages will need the template {{rcat shell}} added. As the change to {{Redirect category shell}} was recent, many redirects connected to Wikidata items, without {{Wikidata redirect}}, but with {{Redirect category shell}}, have not been added to Category:Wikidata redirects. The difference in count between Category:Wikidata redirects and Category:Redirects connected to a Wikidata item is the number of pages that will be modified.

The edits will be carried out with AWB running as an automated bot. There is very low risk of disruption in this task, though the number of edits is significant. Using AWB, this bot can also carry out other generic fixes to redirects, though this is not a significant part of its functions.

A somewhat similar failed request was Wikipedia:Bots/Requests for approval/TomBot, but that that request was for a bot that would edit ~30-60x more pages, with less benefit overall. This is a much more narrow and useful request.

Discussion

1. Any prior discussions on doing this that you're aware of, which establish broader consensus for this task?
2. Will this BRFA cause Template:Wikidata redirect to become redundant? If I understand correctly, this task will orphan all of its transclusions? If so, and especially if there's no prior discussion, I suggest sending that template to TfD (and then this bot task can be technically implementing that TfD). That would be one way to test the wider consensus for this task, too.

ProcrastinatingReader (talk) 16:01, 23 January 2021 (UTC)

There are no discussions I know of establishing consensus around this particular task. {{Wikidata redirect}} will not become redundant for two reasons. {{redirect category shell}} transcludes it. However, this usage could be subst, of course. The other usage is in cross-Wiki (such as to Wiktionary) and category redirects, the "soft" usage. The "hard" usage could be deprecated from the template, however (they are implemented slightly differently, with an automatic switch). Elliot321 (talk | contribs) 16:20, 23 January 2021 (UTC)

To begin with, I'd say stylistically this presentation is inferior. See eg here. The one on the top (caused by the edit) doesn't look as good as the manual one & looks slightly out of place with the plaintext.

If the rcat shell has to be manually added by bot, is there really a point to this? Why not have a bot add {{Wikidata redirect}} to pages in Category:Redirects connected to a Wikidata item? ProcrastinatingReader (talk) 00:39, 24 January 2021 (UTC)

Sorry - that was due to my changes being misunderstood and reverted. If you check now, you can see the way they were intended to look.

The reason for adding {{redirect category shell}} over {{wikidata redirect}} is for automatic detection. If the link on Wikidata is removed, no update on Wikipedia is necessary (likewise, if a link on Wikidata is added to one using the shell, no update is necessary). Elliot321 (talk | contribs) 07:52, 24 January 2021 (UTC)

Okay, makes sense. I'd suggest dropping a link to this BRFA from the template talk pages for the two templates, to allow some time for comments. ProcrastinatingReader (talk) 09:37, 24 January 2021 (UTC)

Done. Elliot321 (talk | contribs) 10:08, 24 January 2021 (UTC)

So the idea is that {{RCAT shell}} should add the Wikidata box by checking for the connected item. Manually adding the template wouldn't be necessary then because the software can already detect if a page is connected to a Wikidata item. Is that correct? --PhiH (talk) 13:20, 24 January 2021 (UTC)

@PhiH: pretty much. The shell will automatically detect a link to Wikidata, and if found, transclude the template. Therefore, this bot will remove the redundant manual transclusions of the template, and add the shell to automatically transclude on any redirect linked to Wikidata. Elliot321 (talk | contribs) 15:36, 24 January 2021 (UTC)

If I understand what changed with {{wikidata redirect}} and {{redirect category shell}} correctly, redirects that only have {{wikidata redirect}} will be changed to an empty {{redirect category shell}}, which then results in an error. This means that manual inspection is needed to determine another redirect category to apply, which obviously this Bot task cannot do. —seav (talk) 01:02, 25 January 2021 (UTC)

FYI, an empty Rcat shell results in sorting the redirect to the Miscellaneous redirects category, which is monitored by editors who will then tag the redirect with appropriate categories. P.I. Ellsworth  ed. ^put'r there 03:41, 25 January 2021 (UTC)

Would that be a problem then, Paine Ellsworth? Filling the cat up with some tens of thousands of pages? ProcrastinatingReader (talk) 08:12, 25 January 2021 (UTC)

An empty RCAT shell with a Wikidata item doesn't need to be categorised in Category:Miscellaneous redirects because it generates the Template:Wikidata redirect. I didn't check if that is implemented yet. A page with that template and no Wikidata item is a problem as well. They just move from one tracking category to another. --PhiH (talk) 08:44, 25 January 2021 (UTC)

Why doesn't it need to be categorised into misc redirects? Having a Wikidata item connected/existing isn't really an explanation of why there's a redirect on enwiki. Surely the redirect still needs to be categorised? ProcrastinatingReader (talk) 09:06, 25 January 2021 (UTC)

@PhiH: @ProcrastinatingReader: the {{redirect category shell}} template should not be applied without any categories by a bot as the Category:Miscellaneous redirects should be filled manually. Consequently, I don't plan to do that with this bot. I can manually categorize the redirects that do not have any categories.

(though, a tracking category for uncategorized redirects that can be applied by a bot would probably be useful. I don't feel like gaining consensus for that, though, as that would likely be much more contentious than this proposal) Elliot321 (talk | contribs) 11:37, 25 January 2021 (UTC)

I think my point is easier to demonstrate with an example, or I’m mistaken about exactly what is proposed here. Can you make 5 edits as a demonstration, either with the bot or by hand if you don’t have the bot coded yet? ProcrastinatingReader (talk) 12:10, 25 January 2021 (UTC)

Maybe a page demonstrating what changes would be made would be more useful, since there are a few differing cases here? Elliot321 (talk | contribs) 03:46, 26 January 2021 (UTC)

An actual edit or two of each case would be preferable, as that's the least confusing way to see what is actually proposed. ProcrastinatingReader (talk) 09:57, 26 January 2021 (UTC)

But you want to add an empty RCAT shell to pages that currently only use {{Wikidata redirect}}, don't you? Should they be added to Category:Miscellaneous redirects if they are connected to a Wikidata item or not? --PhiH (talk) 12:32, 25 January 2021 (UTC)

I can manually categorize the pages currently in that situation. Elliot321 (talk | contribs) 03:46, 26 January 2021 (UTC)

It's not about manual categorisation. We are discussing whether the category should be added by the RCAT shell when the redirect is connected to a Wikidata item. --PhiH (talk) 14:19, 26 January 2021 (UTC)

To ProcrastinatingReader: as long as there is at least one rcat template within the Rcat shell, such as the "Wikidata redirect" template, then the redirect would not be sorted to Category:Miscellaneous redirects. As the proposer suggests, that would not be a problem. The proposer appears to know that a bot should not add an empty Rcat shell to redirects, which would bloat the Misc. redirects category. P.I. Ellsworth  ed. ^put'r there 15:35, 25 January 2021 (UTC)

I think there are multiple cases we have to discuss, feel free to comment below.

1. Redirects that already use the RCAT shell

   This should be uncontroversial: Where {{Wikidata redirect}} is used it gets removed and the template is transcluded by the RCAT shell.

2. Redirects without the RCAT shell…
   1. …that use {{Wikidata redirect}} and are connected to a Wikidata item

      The template gets removed and the RCAT shell is added. Should the RCAT shell be programmed to add these pages to Category:Miscellaneous redirects?

   2. …that don't use {{Wikidata redirect}} and are connected to a Wikidata item

      The RCAT shell is added. Same question as above arises.

   3. …that use {{Wikidata redirect}} and are not connected to a Wikidata item

      The template gets removed. Adding the RCAT shell would cause them to be added to Category:Miscellaneous redirects.
      Currently these pages are tracked in Category:Unlinked Wikidata redirects. Before this bot task begins someone should work through this list and add the pages on Wikidata if necessary.

--PhiH (talk) 14:46, 26 January 2021 (UTC)

If I understand correctly, this bot will add the Rcat shell along with an internal {{Wikidata redirect}} tag when it senses any redirect that is already itemized on Wikidata. If that is what happens, then the redirect will not be sorted to the Misc. redirects category. I also sense a possible challenge where the {{NASTRO comment}} template is applied. One of many examples is at 3866 Langley. Would this bot do anything to those many redirects? I actually like the idea of more Rcat shell transclusions. I wonder if the bot will continue checking for new redirects that become connected to a Wikidata item? P.I. Ellsworth  ed. ^put'r there 21:57, 26 January 2021 (UTC)

The bot won't touch the {{NASTRO comment}} redirects, since it has no need to.

I could run this after the main clean-up job (probably a weekly run would be sufficient). Elliot321 (talk | contribs) 05:25, 27 January 2021 (UTC)

NASTRO comment applies the Rcat shell and so would auto-apply the Wikidata redirect template. There will then be two renditions of Wikidata redirect. Won't one of them have to be removed? P.I. Ellsworth  ed. ^put'r there 18:49, 27 January 2021 (UTC)

I thought the point of this bot is that these edits wouldn't be necessary anymore. Here you said If the link on Wikidata is removed, no update on Wikipedia is necessary (likewise, if a link on Wikidata is added to one using the shell, no update is necessary) --PhiH (talk) 19:00, 27 January 2021 (UTC)

A weekly run would handle any new redirects that have been created. Editors LOVE to create new redirects; however, they generally leave it up to bots and Wikignomes to categorize their new redirects. P.I. Ellsworth  ed. ^put'r there 17:11, 28 January 2021 (UTC)

That sounds reasonable. I hadn't thought about completely new pages. --PhiH (talk) 17:29, 28 January 2021 (UTC)

@PhiH: "Redirects that already use the RCAT shell: This should be uncontroversial": Have you thought about the cases where the rcat shell only contains the Wikidata rcat? 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 21:25, 16 February 2021 (UTC)

Also curious as to why AWB is used? Don't get me wrong; I love AWB. However it's not known for its speed or lack of clunkiness. According to the manual, ...any edit to the bot's talk page will halt the bot. Before restarting the bot, the bot operator must log in to the bot account and visit the bot's talk page, so that the "new messages" notification is cancelled. So why not make a non-AWB bot to do the task? P.I. Ellsworth  ed. ^put'r there 22:14, 26 January 2021 (UTC)

Mainly because I know AWB and regex better than I know any other frameworks to interface with Wikipedia. I could write custom code, if that would be preferred. Elliot321 (talk | contribs) 05:26, 27 January 2021 (UTC)

I was just curious, so it would be up to you, of course. I just know how it drives me crazy sometimes when I have to stop in the middle of something, log out of AWB, log in to Wikipedia just to check notifications, log back out and into AWB to commence. That happens with non-bot-auto work as well. P.I. Ellsworth  ed. ^put'r there 18:53, 27 January 2021 (UTC)

So just to clarify what I'm waiting on: An actual edit or two of each case would be preferable, as that's the least confusing way to see what is actually proposed. After that, it'll be more clear to have the discussion on which edits are good and which need further discussion. ProcrastinatingReader (talk) 15:32, 13 February 2021 (UTC)

SDZeroBot 9

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

Time filed: 12:57, Thursday, November 12, 2020 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): TypeScript

Source code available: GitHub

Function overview: Monitor activity of other bots. Issue alerts to bot operators via talk page or email if they subscribe.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests/Archive_80#A_bot_to_monitor_the_activity_level_of_other_bots

Edit period(s): Continuous

Estimated number of pages affected: -

Exclusion compliant (Yes/No): No

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

Function details: Based on pre-configured information about bot tasks (name of bot account, what edit summaries it uses, what pages/namespaces it edits, how many edits are expected in the last x days, etc), it identifies bots and bot tasks which have stopped working. Stalled bot tasks can be identified even if the bot account is still running other tasks. Bots which perform actions other than editing (deletions/blocks/patrols etc) can also be monitored. A bot status table would be generated and posted to WP:Bot activity monitor.

If configured, this bot can also issue alerts to the operator to let them know that their bot tasks are not running. Alerts can be sent via talk page or email or least intrusively, via a ping from a central page.

I expect anyone should be able to set up a bot for tracking (to be included in status table), but of course only the operator(s) should set up alerts for themselves.

Discussion

Pinging some users from the old BOTREQ discussion: @Sdkb, GreenC, Redrose64, Headbomb, Primefac, Majavah, and Amorymeltzer:. – SD0001 (talk) 15:34, 12 November 2020 (UTC)

• The configuration parameters for describing bot tasks are given at WP:Bot activity monitor. However, I'm a bit confused on how and where should people set up these configurations. My initial thought was to have a central JSON page: Wikipedia:Bot activity monitor/config.json but the problems with JSON are (i) it requires regexes to be weirdly escaped (eg. \d needs to be written as \\d, though it will show up as \d while viewing the page) and (ii) it looks so clumsy, especially when there would be 100s of tasks. It seems using template markup is better to describe the configurations – but should they go on a central page or be decentralized on bot user pages? The drawback of the latter is that it discourages users from setting up tracking for others' bots. – SD0001 (talk) 15:35, 12 November 2020 (UTC)
• I'm super happy to see this; thanks for your work on it, SD0001! I don't have the expertise to comment on the technical questions, but as far as monitoring goes, my sense is that many bots that stop working have retired operators, so it would be good for there to be notifications not just to the talk page of the operator. Looking forward to seeing this in operation! {{u|Sdkb}} ^talk 15:58, 12 November 2020 (UTC)
• Okay, so am I reading it correctly that this is an opt in situation, only "checking up" on whichever specific bots are listed? Also, why do we need a second process when Wikipedia:Bots/Requests for approval/MajavahBot 3 exists? Primefac (talk) 14:12, 13 November 2020 (UTC)

  @Primefac: This is a lot more advanced than MajavahBot 3. See User:SD0001/Bot_activity_monitor/Report for the kind of output it produces – that's based on the data for a cherry-picked set of bots at Wikipedia:Bot activity monitor/config.json. And as mentioned it also supports sending notifications to botops. Because all of this requires data about bot tasks in a machine-readable form, it necessarily has to be "opt-in" (through folks can opt-in others' bots). – SD0001 (talk) 19:07, 13 November 2020 (UTC)

  Fair enough. Per the general precedent, there's no issue with creating a database-style report for these bots (i.e. "only edits one page") but when it starts getting towards notifications there come more questions. Speaking as a bot operator, I don't really care if someone keeps tabs on my bot, but I don't want any sort of automated notice if I happen to decide not to run one of my "active" tasks for some period of time, and I'd rather not find out after receiving a notification that someone's added my name to the "notify" list. Primefac (talk) 20:15, 13 November 2020 (UTC)

  Agreed. I myself wouldn't want these notifications – I've implemented error handling in my own bot tasks so that whenever an error occurs, I get an email with the stack trace of the error – which would be more useful than a generic message from a third-party bot which says the task didn't run. This is why I say above notifications would (should) only be enabled by botops themselves. But I think we can just let this be a convention rather than try to restrict it at the technical level, and hope that people won't be jerks? Remember that it's technically also possible for a random guy to subscribe you to random wikiprojects' newsletters – but this doesn't seem to happen in practise. – SD0001 (talk) 11:33, 14 November 2020 (UTC)

• I'll drop a note at WP:BON about this bot. One point is worth noting, just in case it isn't obvious, is that the "monitoring" is intended for bots that run fully automatically – with zero human intervention. It wouldn't make sense to track bots that are one-time or on-demand, or the even the ones which require any level of operator intervention to run. The intent is to "catch" bot stoppages which the operator may not be aware of, typically occurring due to unforeseen issues such as the ones Anomie mentioned at this discussion, quoting:

• Something changes that causes the bot to fail unless its code or configuration is updated ...
• A software update by the hosting provider breaks the bot's code, again requiring a code update.
• The bot's process stops running or locks up, and the operator isn't paying attention to notice and restart it.
• The hosting provider where it bot is being run closes the account (or closes entirely).

– SD0001 (talk) 12:04, 14 November 2020 (UTC)

• I think this is helpful and not particularly problematic. Of course, operators are not obligated to run tasks, but many times the downtime is accidental not intentional. For example, when my task 3 stops we lose a day of Main Page history. It did lock up once after some maintenance from my host, so Template:2020 Main Page history is missing November 9b and 10. Setting up good app/server monitoring is not what most bots do. Note I haven't looked too closely at the implementation yet to say if I have any concerns with that part. ProcrastinatingReader (talk) 15:21, 14 November 2020 (UTC)
• Sounds like a great idea. I would prefer JSON where each bot monitor is its own object with fields for summary regexes, expected run times, number of runs per day, an array of pages that are expected to have been edited, etc. JSON has the added benefit of being highly extensible since it can contain other objects allowing for more complex configurations. That said it may not be widely accessible to less-technical botops, and the regex escape problem is always a nuisance. Either way, sounds great and I look forward to seeing it in operation! — Wug·a·po·des​ 03:25, 15 November 2020 (UTC)
• BAG question: is the notification system up and running? Primefac (talk) 10:52, 16 November 2020 (UTC)

  Not yet, the notifications code as presently written will keep spamming the botop every half an hour until their bot comes back up again! I'll probably have to further use SQLite to keep track of notifications sent to avoid repetitions. – SD0001 (talk) 15:12, 16 November 2020 (UTC)

  If you can have the dbase/check running without the notifications enabled, feel free to start running that part while the rest gets hammered out. Primefac (talk) 17:40, 16 November 2020 (UTC)

• @SD0001: Happy new year! Gently checking in on the status of this. — The Earwig ^talk 05:10, 12 January 2021 (UTC)
  • {{OperatorAssistanceNeeded}} — The Earwig ^talk 00:44, 25 January 2021 (UTC)

    A bit caught up at the moment with other projects. Will try to take a look at this soon. – SD0001 (talk) 13:58, 26 January 2021 (UTC)

• Apologies to everyone for the long delay. I've changed the config file from JSON to the more tractable wikitext format: it's at Wikipedia:Bot activity monitor/config, powered by Module:Bot task. We've presently got a small cherry-picked set of bots. Requesting folks to add other automatic bots here that you know of. Maybe this can also be mentioned in the next Bots newsletter whenever it goes out. Also in special:diff/1008068560 I've hinted at an automated way of generating a database of active bot tasks, in case anyone wishes to explore that. The work on alerts is not over yet. – SD0001 (talk) 18:22, 22 February 2021 (UTC)

  I can add mine (notifying Draft creators of impending G13 timescale) if you wish? ƒirefly ( t · c ) 18:55, 22 February 2021 (UTC)

  Yep. Feel free to edit that page! – SD0001 (talk) 20:05, 22 February 2021 (UTC)

  Done! ƒirefly ( t · c ) 21:43, 22 February 2021 (UTC)

• Where are you planning to run this bot from? If it's on Toolforge and then Toolforge goes down, it wouldn't be able to alert people. On the other hand, if Toolforge is down, the notifications probably aren't that useful since most bot operators can't do much. In any case, I used to pay for an external monitoring service, so this would be nice. Legoktm (talk) 01:36, 23 February 2021 (UTC)

  Toolforge. I think the platform itself is quite stable – I don't recall it having gone down anytime in the past year. ToolsDB and Redis which I think are less reliable, are not being used. The bot only needs a SQLite db for caching. If it does happen though, as you say, there's little point in notifying people about failures. The status report update task can still run – I suppose I'll take a look at GitHub Actions for that, which is also free. – SD0001 (talk) 11:38, 23 February 2021 (UTC)

  Makes sense to me. Note that using SQLite on Toolforge NFS is really not a great idea, which is why MySQL is provided (see the note at wikitech:Help:Shared_storage#/data/project). Legoktm (talk) 07:50, 2 March 2021 (UTC)

  I wasn't aware of that. Will probably later look into replacing SQLite with redis as it's used for caching. – SD0001 (talk) 21:10, 2 March 2021 (UTC)

• Here is a list of bots that have edited the wiki over the last day or so. It also tries to show what the bot did – the first 3 words of the edit summary after skipping words like "bot" or "task" and any wikilinks, punctuation and numbers. Fun fact: automatic userpage moves by global renamers also get marked as bot edits! – SD0001 (talk) 12:09, 26 February 2021 (UTC)

  This is shaping up very nicely! ProcrastinatingReader (talk) 12:14, 26 February 2021 (UTC)

  small note, might want to trim excess whitespace on the sides on the summaries. ProcrastinatingReader (talk) 12:16, 26 February 2021 (UTC)

Bots in a trial period

MusikBot 16

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

Time filed: 16:04, Wednesday, March 3, 2021 (UTC)

Function overview: Add a new row to Template:Articles lacking sources chart/data every week with the current size of Category:All articles lacking sources. This is used by the chart at {{articles lacking sources chart}}.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Ruby

Source code available: GitHub

Links to relevant discussions (where appropriate): Special:Permalink/1009973605#An automagically updating chart for a given backlog category

Edit period(s): Weekly

Estimated number of pages affected: 1

Namespace(s): Template

Exclusion compliant (Yes/No): No

Function details: Once a week, the bot will query for the size of Category:All articles lacking sources and add a new row to Template:Articles lacking sources chart/data (the data you see there at the time of writing was added manually). This is used to render a chart in {{articles lacking sources chart}}. That template will get transcluded atop Category:All articles lacking sources and possibly elsewhere (maybe somewhere at Wikipedia:WikiProject Reliability, for instance). The idea is to encourage users to help tackle the backlog and reduce the size of Category:All articles lacking sources. We did not seek broader input on this idea but can if anyone feels it is needed.

Discussion

• This is one of the simplest bot tasks I've ever written. It gave the idea of making a general-purpose bot that can create datasets of the size of categories over time so that they can be used in charts. Basically, the idea is if editors working off another category want a chart like this, they'll be able to "sign up" for it without developer intervention, similar to how Community Tech bot 3 works. Let's see how this one-off task goes, and if people like it, I can start a discussion about a general purpose bot that will ultimately replace this one. — MusikAnimal ^talk 16:04, 3 March 2021 (UTC)

Approved for trial (10 edits or 21 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. OK to trial. — xaosflux ^Talk 16:11, 3 March 2021 (UTC)

Bots that have completed the trial period

IznoBot 3

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

Time filed: 01:21, Tuesday, February 23, 2021 (UTC)

Automatic, Supervised, or Manual: supervised

Programming language(s): AutoWikiBrowser

Source code available: AWB

Function overview: Make NavFrame uses accessible in user-space

Links to relevant discussions (where appropriate): Wikipedia:NavFrame, MediaWiki talk:Common.css/to do#NavFrame

Edit period(s): one time run

Estimated number of pages affected: 2400 or less

Exclusion compliant (Yes/No): Yes

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

Function details: Two changes will be made:

• Find NavFrame, replace with NavFrame collapsed
• Find display *: *none *;?, replace with the empty string
• A possible third action: remove empty style attributes. This would probably not occur very often.

Background:

WP:NavFrame has been deprecated for a long time. I've recently taken up the cause (again, I spent some time on templates a year or two ago) of removing its uses, either via replacement with a collapsible template or raw mw-collapsible and friends. Outside the project spaces externally visible (e.g. portal, template, module), a perfect solution probably isn't called for.

What I'd like to do is update user pages particularly to be marginally more accessible by applying the above changes.

At some point, after all article space uses are fixed (I'm not going to fix talk spaces and I've covered the other spaces where necessary pending about 120 individual pages), NavFrame would be removed from Common.css and Common.js. This would cause remaining pages everywhere (user space, article space, talk spaces, etc.) to display uncollapsed and users could elect to update their pages on their own time if they were interested in continuing to have collapsed content, either by using an existing template or migrating to mw-collapsible.

Possible alternatives to this task:

1. Remove the divs entirely. I basically see that change as unnecessarily disruptive to the displayed page in all likelihood, so I'm not interested in implementing this solution.
2. Move users from one system to one of the approved ones with pixel-perfection. This is something beyond my skill to perform near-automatically, though I'm sure a more-skilled bot coder could handle it, so I'm not interested in implementing this solution. (I.e. it's fundamentally a pain in the neck. I'm not looking forward to working on the 4k uses in mainspace with whichever solution I pick for there. Likely total removal given WP:MOSCOLLAPSE.)
3. Simply swap the relevant classes for their mw-collapsible alternatives (and remove the NavHead class). This would change some colors and borders, and the interaction with the toggle element would be slightly "jumpy" for the end user. I have no problem implementing this solution if it is preferable to the later possible disruption when NavFrame is removed entirely.

--Izno (talk) 01:24, 23 February 2021 (UTC)

Discussion

• Forgive my potential ignorance, but could you give us an example edit to show how the change will make user pages more accessible? I'm all for removing deprecated templates and CSS in principle however. ƒirefly ( t · c ) 12:43, 23 February 2021 (UTC)

  Setting CSS to display: none hides it for everyone, even if you mean for the content to be available to some people via JavaScript. That means that people without JavaScript (screen readers, those who turn it off) cannot see the content in the NavFrame divs that have display: none. --Izno (talk) 16:43, 23 February 2021 (UTC)

  Ah yes, my apologies, for some reason known only to past-me I read the task as adding display:none, which is why I got confused. Personally I think it'd be better to do this in one go, just swapping all the old-and-busted CSS for the new-hotness of mw-collapsible. I can have a look at finding a solution for the 'jumpy interaction' problem if you wish? Even without that fix, I would support just swapping out the old for the new in userspace and being done with it. ƒirefly ( t · c ) 17:28, 23 February 2021 (UTC)

  The jumpy interaction is a solved problem give or take (add a div inside the 'title' div with margin-right of 4em if the text of the title div is aligned left or right, margin-left/right of 4 em if centered), it's just a pain to find the content that you might want to do that to because of the conditional on the style of the surrounding element. --Izno (talk) 17:39, 23 February 2021 (UTC)

• About 450 of those search results were .css or .js pages, which should be excluded. So that leaves about 1350 pages. -- WOSlinker (talk) 22:48, 23 February 2021 (UTC)
• Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Seems reasonable to me. At first the #3 alternative sounds better but it could have visual consequences, as you say. Better to leave those design decisions to the user. Overall I think your proposal is the least disruptive, even if it means some end up with uncollapsed content once NavFrame is removed. Do be careful to make sure the display *: *none *;? bit is the same element as the one using NavFrame, though. I also suggest adding a note about the deprecation in the edit summary, that way users who spot your edits can get a head start on fixing their userpage if they so desire. — MusikAnimal ^talk 21:37, 4 March 2021 (UTC)

  Trial complete.. I bumped into some surprises that I'll take care of by mainly-manual fix in AWB (mostly rejecting certain changes or hitting the skip button):

  • 49ersBelongInSanFrancisco does not have display: none in his NavContent. Hit skip on that page, but some users have this elsewhere which had the relevant change rejected (i.e. they have multiple cases of NavFrame and not all are collapsed).
  • User:0fret/sandbox is a sandbox. Skipped the page but there's not much I can do about that.
  • [1] also was manual after the initial AWB suggested change.

  Also left a note at WT:AWB that seems to indicate that subrules don't work right now...

  --Izno (talk) 03:29, 5 March 2021 (UTC)

• Maybe skip those without style immediately after NavContent and then look at those in a little more detail as a second run? There are: with NavContent then style - 2294 and with NavContent but not followed by style - 67. -- WOSlinker (talk) 09:16, 5 March 2021 (UTC)

CommonsCategoryBot

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

Time filed: 21:08, Wednesday, February 3, 2021 (UTC)

Function overview: Adds Template:Commons category to articles that are linked to a Commons category via Wikidata but lack the template.

Automatic, Supervised, or Manual: Automatic

Programming language(s): AWB

Source code available: AWB, orginal configuration at https://pastebin.com/qeqA7MDi, updated/improved confg at https://pastebin.com/ha8uGR4d

Links to relevant discussions (where appropriate):

Edit period(s): When i start it (irregular)

Estimated number of pages affected: At least 220,000.

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: The bot would add template {{Commons category}} to articles that have an associated category on Wikimedia Commons, but lack the mentioned template. In my opinion, the template is much more practical than the link in the sidebar, because it explicitly says "media", which is not the case with the sidebar - so it would certainly be easier for the "normal" reader to find the Commons images. About the way it works: The bot doesn't automatically search for such articles, I feed him with them. I have a list at User:TheImaCow/checkccat with a lot of such articles from a number of topics - how I get to the lists is explained there. Since the bot uses AWB as a base, I will import individual groups, and then let it work through them. The bot is always started manually, I don't want to run it 24/7, or have my PC running non-stop. --TheImaCow (talk) 21:08, 3 February 2021 (UTC)

An updated version, thanks to the suggestions below:

To the actual functionality: As you can see in the the config, the bot replaces

==\s*External links\s*== with

==External links==
{{Commons category}}

.

• If stub tags are found, the inline version will be used.
• If the External link heading does not exist, the "See also"-Section will be used.
• If both sections are not present, but a simple

==\s*References\s*==
{{Reflist}}

is, then this is replaced with

==References==
{{Reflist}}
==External links==
*{{Commons category-inline}}

If none of the mentioned sections or already existing templates like {{Commons category}} and redirects are found, then the page will be skipped. --TheImaCow (talk) 06:17, 23 February 2021 (UTC)

Discussion

What if a given article decides that the template is bloat and shouldn't be added? Will your bot respect the removal, or will it readd it on the next run (ie, edit war with the removal)? ProcrastinatingReader (talk) 14:45, 4 February 2021 (UTC)

ProcrastinatingReader, Good point. I just looked at many of the bridge articles, and in almost all cases they are stubs where that is the case. (like Pol-e Dokhtar, which is actually not a bridge ..but it has a commonscategory, so okay.) Let's see if I can make it so that if stub tags are found on the page, Template:Commons category inline will be used.

Topic Edit-War: It can't actually come to that, because I feed the bot with articles on certain topics, and when he's done with those topics, then he's done with them, and then he doesn't come into contact with those articles at all anymore. So if the template is removed, then that stays removed. --TheImaCow (talk) 15:32, 4 February 2021 (UTC)

So, I've now changed it to use {{Commons category-inline}} if stub tags are present. Was surprisingly easy. Updated configuration file is here. --TheImaCow (talk) 15:59, 4 February 2021 (UTC)

I am mildly concerned about the proposed addition to the References section. To be pedantic, the Commons link is not related to references. More importantly, in my experience, some floating templates, when added to the References section, change the section from three columns to two columns (on my screen), resulting in a bunch of undesirable white space and increased vertical scrolling. I would prefer to see a new External Links section added, perhaps with the inline template used in order to avoid the appearance of an "empty" EL section with just a floating box in it. – Jonesey95 (talk) 16:43, 4 February 2021 (UTC)

Another good point. I've tried that now, but no matter what, the heading is always not placed at all or placed incorrectly - so now the {{Commons category}} template will only be added to "See also" or ""External links" sections. --TheImaCow (talk) 18:22, 4 February 2021 (UTC)

I have now tested around a bit more: If the references consist of a simple {{reflist}}, then I can also add a new section "External links". [2] Will test this more though. --TheImaCow (talk) 20:05, 4 February 2021 (UTC)

• {{Commons category-inline}} should probably be placed in a list item, per the docs. — The Earwig ⟨talk⟩ 20:52, 4 February 2021 (UTC)

  You mean with a "*"? Yes, I already noticed that and built it in. The new config is at https://pastebin.com/W1aUMYs8 But thanks! --TheImaCow (talk) 21:10, 4 February 2021 (UTC)

  The diff linked above did not include the recommended bullet, and it looks like there may be at least one place in the code where the inline template is inserted without a bullet (I can't really read the code, though, so I could definitely be wrong). Thanks for being so reasonable about my trivial concerns. – Jonesey95 (talk) 22:23, 4 February 2021 (UTC)

  So now, however, it should be. About the code: I recommend copying it to an .xml file and then loading it directly into AWB, that's certainly easier than trying to read it. Also, I set it to always use the inline variant for newly created for newly created ==External links== headings. (like here) --TheImaCow (talk) 09:30, 5 February 2021 (UTC)

  An impoved, less confusing configuration file (200 instead of 600 lines) is at https://pastebin.com/ha8uGR4d --TheImaCow (talk) 13:16, 7 February 2021 (UTC)

• Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Please try a variety of pages to test different situations (presence/absence of the various sections) and in a variety of topic areas to increase the number of editors who may notice the changes. Also, please put a link to this BRFA in the edit summary during the trial. — The Earwig ⟨talk⟩ 05:47, 14 February 2021 (UTC)

  The Earwig, The account needs to be added to Wikipedia:AutoWikiBrowser/CheckPage. --TheImaCow (talk) 18:25, 14 February 2021 (UTC)

  @TheImaCow: Done. — The Earwig ⟨talk⟩ 19:37, 14 February 2021 (UTC)

  Trial complete. [3] The only error was this one, but I just fixed the problem (skip if {{sisterlinks}} exists). --TheImaCow (talk) 19:57, 14 February 2021 (UTC)

{{BAG assistance needed}} No BAG attention for 1 week. --TheImaCow (talk) 15:48, 22 February 2021 (UTC)

• I would honestly say increasing the use of this template in today's environment would be a mistake (with Wikidata links to Commons easily available). We also just had an RFC on the matter that has yet to be closed. This task should not run until it is closed in favor of the 'B' option, if that is what it is closed as. See WP:VPPRO#RfC: What to do with category links to Commons?. --Izno (talk) 01:34, 23 February 2021 (UTC)

  Mike Peel may also already have some semi-automated program to perform actions similar to this, and should be informed accordingly. --Izno (talk) 01:35, 23 February 2021 (UTC)

Oh, I didn't know anything about that Rfc. The options A1-3 are only for categories, I don't want to touch them with the bot, and for option B there seems to be light support. But let's wait for the final result, until then I have deactivated the "assistance needed" template. Pinging also User:Mike Peel. --TheImaCow (talk) 06:17, 23 February 2021 (UTC)

@TheImaCow: I'm very happy to see this bot. :-) I was going to propose something similar eventually, but it was a few steps away for me as I was trying to do things via RfCs and after cleaning up Category:Commons category link is locally defined (only another 12k to go!). I'm not 100% sure how the community will react to your bot when it's underway, but I really hope it's positive.

Looking at the config, I think you're using the sitelinks, which is definitely the way to go (I've seen others like Jarbot task 2 using Commons category (P373), which has a lot of bad values, but sitelinks are generally good). You may want to double-check that the sitelink contains 'Category' though, as there are quite a few to galleries (but in most of those cases, if you follow the topic's main category (P910) value you'll find a category item with a commons category sitelink in it - the {{Commons category}} template automatically does this).

Also, please try to avoid adding new 'External links' sections if you can. Personally, I don't think links to Commons are 'external', but I know others disagree. I also generally don't like external links sections as they tend to attract spam. If there is no 'External links' section, but there is a 'See also' section, I suggest adding the template there instead - this is quite common behaviour in articles already. Thanks. Mike Peel (talk) 10:01, 23 February 2021 (UTC)

Yes, sitelinks will be used. Topic "External links": The "See also" section is already preferred over the new section, see this trial diff. And even when a new section is added, it's relatively rare - I've already looked at the possible changes on a few hundred pages to make sure everything works, and there it only happens every fifth or sixth time that a new heading is created. And just for the record: This kind of thing is also being prevented now. --TheImaCow (talk) 14:59, 23 February 2021 (UTC)

BattyBot 53

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

Time filed: 03:33, Monday, December 21, 2020 (UTC)

Function overview:

• Remove maintenance categories Category:Year of birth missing or Category:Year of birth missing (living people) when year of birth exists
• Remove maintenance categories Category:Date of birth missing or Category:Date of birth missing (living people) when full date of birth exists

Automatic, Supervised, or Manual: automatic

Programming language(s): AutoWikiBrowser

Source code available: AWB

Links to relevant discussions (where appropriate): Category documentation

Edit period(s): Monthly

Estimated number of pages affected: Thousands initially, fewer each month

Namespace(s): Articles

Exclusion compliant (Yes/No): Yes

Function details: Use AWB's general fixes to remove the maintenance categories when the year and/or date of birth exists.

• Load all articles from Category:Year of birth missing
• Skip the article if the category is no longer on the article (e.g. someone else removed the category while the bot was running)
• Skip the article if the category is not removed
• Use a default edit summary that states "Removed Category:Year of birth missing and other general fixes"
• Repeat for the other three categories

Discussion

Question: the DOB in BLPs is one of the most inappropriately-added bits of content (from a sourcing perspective) and I don't know if having a bot automatically removing pages from these tracking categories is a good idea; while I don't necessarily know if people are using said cats to find pages where there might not be a sourced DOB, it seems like enough of a possibility that I would be concerned about having this task. What are your thoughts on this? Primefac (talk) 13:56, 21 December 2020 (UTC)

@Primefac: My understanding of these categories is that they should only be used if the YOB/DOB is missing, not if it is unsourced. If the YOB/DOB is unsourced, then it may be appropriate for a human to add {{citation needed}}. GoingBatty (talk) 17:45, 21 December 2020 (UTC)

I guess my point is more that the sequence goes 1) someone adds an unsourced DOB, 2) the bot removes the cat, 3) someone removes the invalid DOB, 4) the cat is re-added, 5) repeat steps 1-4. With no bot edit, only 1 and 3 are enacted (saving two edits to the page).

Don't get me wrong, I understand why the category exists, but if any rando chucking a DOB into an article causes the cat to disappear (assuming that no one notices the cat was removed and thus don't re-add it) it almost makes it seem like a pointless addition. Primefac (talk) 17:54, 21 December 2020 (UTC)

@Primefac: I'm hoping the sequence would go like this:

1. Someone adds a DOB
2. Someone reviews the edit and removes the DOB if it's invalid (and the bot would skip the article)
3. If the DOB is still there, the bot removes the category
4. Reviewers notice the bot's edit summary and have another opportunity to review the DOB
5. If needed, add {{citation needed}} or remove the DOB and readd the category

In case it would be helpful, here is a list of articles for people whose last name starts with "G" where the bot would remove the cat:

GoingBatty (talk) 19:48, 21 December 2020 (UTC)

{{BAG assistance needed}} Happy New Year! GoingBatty (talk) 19:45, 31 December 2020 (UTC)

• Hmm. Personal 2c: I don't think this task is too problematic, and I'm also not sure it's too helpful.
  Not too problematic because: (a) these are no worse than other unsourced info, if the DOB is problematic; (b) if it's a problematic DOB, the person could've just removed the tracking cat in the same edit; (c) Category:Year of birth missing (living people) has 141,310 pages - safe to say nobody is using it; (d) we have Filter 712 for this.
  Not too helpful because: Category:Year of birth missing (living people) has 141,310 pages - safe to say nobody is using it. ProcrastinatingReader (talk) 20:16, 31 December 2020 (UTC)

  PR, would you say then that it might be worth pursuing the removal/deletion of this category? If so, and it fails, where would your thoughts on the appropriateness of this task fall? If not, is it still worth running? I find myself largely in the same camp (i.e. not really useful, not really harmful), be good to think long-term on it. Primefac (talk) 20:27, 31 December 2020 (UTC)

  I think CfD seems to be the way to go. This is kinda like Category:Pages using deprecated image syntax (CfD) -- too large and too minute to be useful. Unlike Category:Living people it has no real technical purpose either afaics. Last batch CfD seems to be 2007 - NC.

  Re bot: On the one hand, a tracking cat which is incorrect is useless. If it were populated by a template updates would be automatic regardless of sourcing, so this should probably be treat the same way. OTOH, I'm not sure removing a few thousand articles changes anything, it's still useless. I guess the task falls closer to useful than useless, but it's indeed very much near the middle. May be useful to get some thoughts from Wikipedia:WikiProject Biography -- if anyone is actually using this, they're probably there. ProcrastinatingReader (talk) 22:28, 31 December 2020 (UTC)

@ProcrastinatingReader: Per your suggestion, I added a note in Wikipedia talk:WikiProject Biography#Notification of bot request. Thanks! GoingBatty (talk) 23:29, 31 December 2020 (UTC)

{{BAG assistance needed}} I appreciate the feedback received so far. What's the appropriate next step to resolve this request? Thanks! GoingBatty (talk) 15:12, 10 January 2021 (UTC)

Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. At some point it sounds like a few of us were going to do this anyway and dropped the ball. Doing so now before I forget again. Primefac (talk) 20:47, 10 January 2021 (UTC)

@Primefac: Trial complete. with link to results. Thanks! GoingBatty (talk) 04:43, 12 January 2021 (UTC)

Six diffs into the review and this is a situation we were worried about: bot adds cat for unsourced year, editor removes the unsourced year but doesn't touch the cat, and we're left with an unsourced cat. Wondering if we need a companion task to remove a DoB cat (or at least flag it somehow) if the corresponding statement in the article is removed? Another thought I had earlier but did not mention: the problematic DoB was added less than a month before the bot came through, so maybe have the bot not do anything until the DoB has been stable in the article for some period of time? OTOH, this adds complexity without really solving the problem. I'm not sure what to do here. — The Earwig ^talk 03:25, 16 January 2021 (UTC)

@The Earwig: As far as I know, AWB doesn't have functionality that allows bots to skip articles if they have been edited in some recent period of time. If that's a requirement, then I will have to withdraw this request. GoingBatty (talk) 03:40, 18 January 2021 (UTC)

Not a requirement per se, just trying to brainstorm. — The Earwig ^talk 05:36, 18 January 2021 (UTC)

{{BAG assistance needed}} Thank you! GoingBatty (talk) 04:01, 30 January 2021 (UTC)

Just as a note, I'm leaning towards declining, since the main issue I found with this task popped up very quickly in the results. I'll give other BAG members an opportunity to weigh in first, though. Primefac (talk) 14:22, 4 February 2021 (UTC)

I started a proposal at VPR for a "companion bot", something of a Hail Mary pass: Wikipedia:Village pump (proposals)#Bot to remove year of birth/death categories when the claim is removed from the article body. If this can be done, I think I would support this task as well. —���The Earwig ⟨talk⟩ 16:32, 4 February 2021 (UTC)

My proposal has not received a ton of interest, but one instance of tentative support so far. Nevertheless, my understanding is that the proposed BattyBot 53 is only running genfixes that plenty of other existing bots are already running, though not as their primary task. For this reason, I have difficulty seeing why we should decline this, unless we want to also push for this task being disabled in genfixes. Would anyone argue for that? — The Earwig ⟨talk⟩ 09:17, 7 February 2021 (UTC)

Throwing my support behind the companion bot idea. And yes, it's true that this bot is basically just running genfixes, but I'll say that this specific genfix is one that I am normally hesitant to apply en masse. This proposal would definitely help alleviate that concern. Ionmars10 (talk) 17:13, 7 February 2021 (UTC)

A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{tl|BAG assistance needed}}. GoingBatty (talk) 00:04, 25 February 2021 (UTC)

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.

• ShortDescBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 2) Approved 05:22, 14 February 2021 (UTC) (bot has flag)
• WikiCleanerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 24) Approved 16:23, 22 January 2021 (UTC) (bot has flag)
• Dreamy Jazz Bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 6) Approved 16:23, 22 January 2021 (UTC) (bot has flag)
• WikiCleanerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 25) Approved 16:16, 22 January 2021 (UTC) (bot has flag)
• BattyBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 54) Approved 00:40, 6 January 2021 (UTC) (bot has flag)
• ShortDescBot (BRFA · contribs · actions log · block log · flag log · user rights) Approved 00:55, 24 December 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 7) Approved 14:51, 30 November 2020 (UTC) (bot has flag)
• PrimeBOT (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 34) Approved 07:01, 26 November 2020 (UTC) (bot has flag)
• Dapperbot (BRFA · contribs · actions log · block log · flag log · user rights) Approved 18:57, 25 November 2020 (UTC) (bot has flag)
• Monkbot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 18) Approved 18:26, 25 November 2020 (UTC) (bot has flag)
• MilHistBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 7) Approved 22:57, 17 November 2020 (UTC) (bot has flag)
• VahurzpuBot (BRFA · contribs · actions log · block log · flag log · user rights) Approved 04:54, 16 November 2020 (UTC) (bot has flag)
• DannyS712 bot III (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 72) Approved 01:29, 16 November 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 6) Approved 01:29, 16 November 2020 (UTC) (bot has flag)
• WikiCleanerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 23) Approved 20:37, 13 November 2020 (UTC) (bot has flag)
• SDZeroBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 8) Approved 20:31, 13 November 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 2.5) Approved 15:45, 10 November 2020 (UTC) (bot has flag)
• MilHistBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 8) Approved 15:40, 10 November 2020 (UTC) (bot has flag)
• MajavahBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 4) Approved 02:48, 9 November 2020 (UTC) (bot has flag)
• Cewbot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 6) Approved 08:38, 7 November 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 3) Approved 14:43, 4 November 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 5) Approved 18:32, 29 October 2020 (UTC) (bot has flag)
• Monkbot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 17) Approved 13:29, 19 October 2020 (UTC) (bot has flag)
• JJMC89 bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 21) Approved 13:24, 19 October 2020 (UTC) (bot has flag)
• SDZeroBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 5) Approved 13:24, 19 October 2020 (UTC) (bot has flag)
• WugBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 5) Approved 17:59, 16 October 2020 (UTC) (bot has flag)
• AntiCompositeBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 3) Approved 17:27, 16 October 2020 (UTC) (bot has flag)
• WikiCleanerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 22) Approved 17:31, 7 October 2020 (UTC) (bot has flag)
• SDZeroBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 6) Approved 16:46, 2 October 2020 (UTC) (bot has flag)
• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 4) Approved 16:08, 30 September 2020 (UTC) (bot has flag)

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.

• Usernamekiran BOT (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 4) Bot denied 14:17, 14 February 2021 (UTC)

• Pi bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 5) Bot denied 03:37, 15 September 2020 (UTC)

• Roccerbot (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 23:15, 28 August 2020 (UTC)

• DaedanBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 2) Bot denied 14:05, 9 August 2020 (UTC)

• Area code bot (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 22:22, 2 August 2020 (UTC)

• NotPlanter (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 22:11, 2 August 2020 (UTC)

• RedWarn (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 23:49, 15 June 2020 (UTC)

• Gedimon (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 14:06, 31 May 2020 (UTC)

• PhuzBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 3) Bot denied 06:51, 28 May 2020 (UTC)

• MDanielsBot (BRFA · contribs · actions log · block log · flag log · user rights) Bot denied 19:54, 1 May 2020 (UTC)

• DaedanBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 1) Bot denied 14:24, 27 April 2020 (UTC)

• PearBOT (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 8) Bot denied 16:10, 2 February 2020 (UTC)

• PkbwcgsBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 25) Bot denied 02:21, 22 January 2020 (UTC)

• PkbwcgsBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 26) Bot denied 02:16, 22 January 2020 (UTC)

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.

• AWMBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 16:16, 22 January 2021 (UTC)

• DeprecatedFixerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 8) Withdrawn by operator 21:01, 28 December 2020 (UTC)

• DomdomeggBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 14:51, 18 November 2020 (UTC)

• YoutubeSubscriberBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 01:29, 16 November 2020 (UTC)

• Yapperbot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 3) Expired 21:06, 14 November 2020 (UTC)

• SDZeroBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 7) Withdrawn by operator 17:51, 18 October 2020 (UTC)

• MDanielsBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 8) Withdrawn by operator 17:46, 11 August 2020 (UTC)

• DismanetBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 22:28, 2 August 2020 (UTC)

• DannyS712 bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 71) Withdrawn by operator 06:37, 29 July 2020 (UTC)

• ProcBot (BRFA · contribs · actions log · block log · flag log · user rights) Withdrawn by operator 16:02, 19 July 2020 (UTC)

• Seppi333Bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 2) Withdrawn by operator 21:57, 10 June 2020 (UTC)

• PearBOT (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 7) Withdrawn by operator 19:02, 11 May 2020 (UTC)

• Creffbot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 21:34, 19 April 2020 (UTC)

• AntiCompositeBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 18:24, 23 March 2020 (UTC)