Wikipedia:Bots/Requests for approval

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 Bot activity monitor

BAG member instructions

Please remember that all editors are encouraged to participate in the requests listed below. Just chip in – your comments are appreciated more than you may think!

Shortcuts WP:BRFA WP:RFBOT

Если вы хотите запустить бота в английской Википедии, вы должны сначала получить его одобрение . Для этого следуйте инструкциям ниже, чтобы добавить запрос. Если вы не знакомы с программированием, может быть хорошей идеей попросить кого-нибудь запустить для вас бота , а не запускать собственный.

Cewbot 8

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

Time filed: 23:43, Saturday, May 8, 2021 (UTC)

Function overview: Maintain challenge templates at corresponding page.

Automatic, Supervised, or Manual: Automatic

Programming language(s): wikiapi on GitHub

Source code available: [1] on GitHub

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Bot for Challenges projects

Edit period(s): daily

Estimated number of pages affected: 2K+

Namespace(s): talk pages

Exclusion compliant (Yes/No): Yes

Function details: This task will take over work of Wikipedia:Bots/Requests for approval/HasteurBot 15.

Discussion

In this TfD the community overwhelmingly decided to merge the banners into the WikiProject banner stuff. Although that was only to apply to the {{WPUS50}} template, I think the sentiment in that discussion was against having it in a separate banner. Example new usage. In line with that, I'm wondering how your task would add these templates? ProcrastinatingReader (talk) 00:19, 9 May 2021 (UTC)

Thank you for the comment. I think we may insert the templates into {{WikiProject banner shell}}. Maybe BabbaQ have good idea? By the way, I think using the expression |WPUS50= will cause difficulties of related templates if we want to add/remove them later. The same problem appears when I run the task Normalize Multiple issues in zhwiki or jawiki, they allow both {{Multiple issues|BLP sources=true}} and {{Multiple issues|{{BLP sources}}}}. Kanashimi (talk) 00:57, 9 May 2021 (UTC)

TolBot 3

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

Time filed: 19:04, Monday, May 3, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available:

Function overview: Add NOINDEX to old WikiProject Spam reports

Links to relevant discussions (where appropriate): Bot request

Edit period(s): Continuous (one time)

Estimated number of pages affected: ~6809:

• ~6799 subpages of Wikipedia:WikiProject_Spam/LinkReports;
• ~10 subpages of Wikipedia:WikiProject_Spam/Local.

Exclusion compliant (Yes/No): No

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

Function details: The bot:

1. Logs in;
2. Gets the list of pages with a certain prefix;
3. Checks each page if it is in a category (Category:Noindexed pages)
4. If it is not, it adds a newline and {{NOINDEX}} to the page.

Discussion

A quick note: The estimated number of pages is an absolute maximum; the number will be far smaller than that. However, each of those pages must be checked to see how many still have to be NOINDEX-ed (which is taking a very long time). A better estimate will probably come sometime within the next day. Tol | Talk | Contribs 19:10, 3 May 2021 (UTC)

I had meant to ask this at BOTREQ, but I suppose now it’s here I might as well ask here! What problem exactly is this solving? I don’t see a massive issue with it, but I’m not sure exactly why it needs to be done... ƒirefly ( t · c ) 19:41, 3 May 2021 (UTC)

Some older spam reports are not properly NOINDEX-ed, so they may show up in search engines. This can cause issues when people on those search engines find these spam reports and may misinterpret them. Tol | Talk | Contribs 23:32, 3 May 2021 (UTC)

All the pages seem to contain User:COIBot/Summary/LinkReports (embedded as a template). Can't we just add {{NOINDEX}} into that? ProcrastinatingReader (talk) 20:00, 3 May 2021 (UTC)

That sounds like a good idea — however, this template transclusion count says there are only 185724 transclusions. Unless this counter is wildly inaccurate, it would seem that some pages lack this template. Tol | Talk | Contribs 23:32, 3 May 2021 (UTC)

Could be some other template on the other pages. Best to get the number affected as low as possible by adding the template to any already-transcluded templates, then redoing the numbers for pages affected to proceed here. ProcrastinatingReader (talk) 07:37, 4 May 2021 (UTC)

However, each of those pages must be checked to see how many still have to be NOINDEX-ed (which is taking a very long time). A better estimate will probably come sometime within the next day Are you trying to do that with a bot? A search immediately shows there are 21,574 pages. Many of these transclude User:COIBot/Summary/LinkReports as PR says above. I edited that template to add NOINDEX. Let's wait for some time for the job queue to settle, and we should hopefully have a lower figure. – SD0001 (talk) 11:17, 4 May 2021 (UTC)

Adding: this search shows that 14,775 of those pages transclude that template, so should get noindexed soon. – SD0001 (talk) 11:19, 4 May 2021 (UTC)

 Self-trout Yes, for some reason I was. The same search now shows 15,206 pages left (which is probably still too high); I looked at a few and most (on the first few pages) have an ambox header. Thanks for editing the template. Tol | Talk | Contribs 19:29, 4 May 2021 (UTC)

I think part of the problem is that many of these pages are old and are not re-parsed unless read. As the person who is complaining about one of the pages appearing in a Google result is not disclosing which page it is, I cannot check. I presume this is a very old report and hence it is (was) not noindexed and hence in Google's search results. This exercise would be to ensure that every single COIBot report is actually actively no-indexed, so that removing it from the Google search results will actually stick (this is not the first time that I get a 'complaint' that a report is showing up in Google, whereas they are, for years, noindexed by default).

Probably most of them could be blanket deleted, but some of them are representations of evidence that has been used in admin actions, which I think should be visible to everyone (but not to google). --Dirk Beetstra ^{T C} 12:18, 5 May 2021 (UTC)

A mass null edit run on those pages would probably get them no-indexed if the issue is caching. Headbomb {t · c · p · b} 13:29, 7 May 2021 (UTC)

ProcBot 8

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

Time filed: 21:18, Sunday, May 2, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Ruby

Source code available:

Function overview: Update an edit filter automatically.

Links to relevant discussions (where appropriate): Edit filter mailing list

Edit period(s): Continuous

Estimated number of pages affected: 1

Exclusion compliant (Yes/No): No

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

Function details: The bot will periodically update data of a specific edit filter. There's discussion on the edit filter mailing list if any BAG members have access, also happy to discuss on IRC.

The bot account will need to be flagged with EFM. I've done a test without submitting on my own account. Worth noting that since there are no API endpoints to update edit filters programmatically, the bot makes normal web requests for this purpose. It has checks for roughly expected data and saves a record of the request for safekeeping.

Discussion

• In principle, I think this is fine. I would prefer if it runs under an isolated account due to the inherit risk of the EFM role and to make auditing easier. I wish there was more we could say to explain to users about what it's trying to do, but I understand the BEANS risks. Suffusion of Yellow, I checked recent hits of the filter and while I see plenty of unconstructive edits being stopped (and some constructive ones as well), I don't see much of the actual thing it's trying to target. How often do you expect it to hit? Also, would it be at least OK to give the filter number, so users with EFH/EFM/sysop permissions can understand what's going on, without needing to dig through the mailing list? — The Earwig (talk) 22:38, 2 May 2021 (UTC)

  Well, once the bot's running, it will have to be public at Special:Log/abusefilter that it's editing 1122 (hist · log). And we can say that this is what the bot will be doing.

  Yes, the LTA(s) have "gone dark" right now. I was tempted to disable the filter, before I saw this request. But then we'd be back here in a few months when one of the LTAs returns. So, ProcrastinatingReader, will the bot leave the filter's actions unchanged? What I'd like to do is switch it to log-only (probably a good idea while bot's in testing anyway), but be able to switch it back to disallow again as soon the problem returns. Suffusion of Yellow (talk) 23:09, 2 May 2021 (UTC)

  Yeah, it won't try to overwrite any of the other filter properties, or the rest of the filter (outside the relevant portions). ProcrastinatingReader (talk) 23:13, 2 May 2021 (UTC)

  FWIW (not much!), I also feel that bot tasks with 'advanced' rights should run under an isolated account. ƒirefly ( t · c ) 11:03, 3 May 2021 (UTC)

  I'm not particularly convinced it improves security, especially in the case of this task, but I also don't mind maintaining a second account. I created User:ProcBot II but it'll need to be temp flagged with bot as well if this goes to trial (due to same issue as ProcBot I; captchas and IP blocks). ProcrastinatingReader (talk) 11:25, 3 May 2021 (UTC)

  This is on my watchlist now, so if it goes to trial I'll give all of the appropriate permissions. Primefac (talk) 12:12, 4 May 2021 (UTC)

  FWIW agree that a second account doesn't really improve security as long as your other bot tasks are running out of a BotPassword configuration that doesn't have access to EFM rights. But since it's an advanced right, it might help to enable 2FA for its web-login. – SD0001 (talk) 05:17, 5 May 2021 (UTC)

  Personally, I don't view it as a security issue, I view it as more of a transparency/clarity issue. If MyBot1 is a "normal" bot and MyBot2 has TPE and MyBot3 is an adminbot, if I see them in the contribs I immediately (assuming I know the bot functions) have a better idea of what "type" of edits the bot is making (in other words, it's easier to quickly check if it is functioning properly). Primefac (talk) 11:58, 5 May 2021 (UTC)

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)

  Just checking in, AmandaNP, since it's been a few weeks. I hope you're feeling better. — The Earwig (talk) 05:24, 29 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. SQLQuery 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)

      GPG is a fair point. However, from personal experience, I've found this to be a pain when I used to use Windows. Maybe we can just set a requirement that all people with commit access to the repo enable 2FA? I mean, the bureaucrats (when they ask potential IAs to enable 2FA) can't actually check if 2FA was actually enabled, right? They just go on their word. So I don't see why we can't just go on people's word. ProcrastinatingReader (talk) 13:50, 8 March 2021 (UTC)

      GPG is a nightmare, I wouldn't suggest anyone actually use it. Stewards can see if you have 2FA enabled or not, presumably a crat would check with a steward.

      Anyways, all of this is not really related to my main point, which is about auditability. Legoktm (talk) 18:33, 8 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)

  I second this - if a bot only needs advanced perms for a subset of tasks, it should probably be a separate account. This will also remove the SQL-has-access issue. Primefac (talk) 13:46, 8 March 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)

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)

Um... you don't have to log out of AWB to reset the counter. Also, technically you don't have to log out of Wikipedia either if you log in to the bot account in private mode. Primefac (talk) 13:44, 8 March 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)

Re: the message above. Primefac (talk) 13:44, 8 March 2021 (UTC)

@Primefac and ProcrastinatingReader: thanks for the ping. I've actually expanded the scope of what I'm intending to do here a bit (see User:Elli/rcat standardization) - and planning on getting consensus for the changes elsewhere first, before going through with this, so if I could put this request on hold or something that would be ideal (sorry, I'm not sure exactly how this type of situation works, but getting approval for the narrow task of shelling and removing one rcat doesn't really make sense given my goal to deal with ~20 of them). Elli (talk | contribs) 18:38, 8 March 2021 (UTC)

 On hold. Just comment out the template when you're ready to go (no harm in having it sit here for a while). Primefac (talk) 19:29, 8 March 2021 (UTC)

AnomieBOT III 7

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

Time filed: 13:35, Thursday, April 29, 2021 (UTC)

Function overview: Apply pending changes protection to TFAs while they are on the Main Page.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Perl

Source code available: User:AnomieBOT/source/tasks/TFAProtector.pm

Links to relevant discussions (where appropriate): Wikipedia talk:Today's featured article#Pending changes TFA trial, Special:PermanentLink/1017460384#Pending-changes protection of Today's featured article

Edit period(s): Hourly, but typically will only apply protection once per day.

Estimated number of pages affected: 1 per day

Namespace(s): Article

Exclusion compliant (Yes/No): N/A, does not edit

Adminbot (Yes/No): Yes

Function details: The bot will apply pending changes protection to a TFA about an hour before it begins to be featured on the main page, set to expire an hour after the featuring ends. The day's TFA is identified using the date's subtemplate of Template:TFA title.

It will also re-check each hour to ensure that someone has not removed the protection. If an existing PC protection would end before the bot's protection would, the bot will extend it. It will not shorten any existing PC protection that lasts longer than the protection it would apply.

Discussion

Note this task is itself a trial, per the RFC. The code at present will refuse to run beyond May 31, 2021 at 22:00 UTC (i.e. it will protect TFAs through the end of May, but will stop before it would protect June 1's TFA). After that it will be up to interested people to hold another RFC to determine whether consensus exists to continue the task. If that consensus exists, I'll remove the relevant code to allow the bot to continue running (without a subsequent BRFA).

I ran the task once already with a hack to point it at Wikipedia:Pending changes/Testing/9 instead of the actual TFA (and with the reason hacked too), to validate that the stabilize API call worked as expected. I'd have used a userspace page, but PC protection can't be used in userspace. Anomie⚔ 13:35, 29 April 2021 (UTC)

Approved for trial (32 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. This allows you to start immediately but end on 31 May as described above. Primefac (talk) 13:53, 29 April 2021 (UTC)

First two protections: [2][3] Anomie⚔ 23:23, 29 April 2021 (UTC)

Today's protection: [4] Anomie⚔ 00:51, 1 May 2021 (UTC)

Today's protection: [5] Anomie⚔ 01:57, 2 May 2021 (UTC)

Today's protection: [6] Anomie⚔ 00:11, 3 May 2021 (UTC)

Two more: [7][8] Anomie⚔ 12:06, 5 May 2021 (UTC)

Today's protection: [9] Anomie⚔ 10:45, 6 May 2021 (UTC)

Today's protection: [10] Anomie⚔ 11:28, 7 May 2021 (UTC)

K.Kapil77 Bot

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

Time filed: 08:54, Wednesday, April 28, 2021 (UTC)

Function overview: This Manually-assisted Bot rectifies minor spelling mistakes on less to mid popular pages based on high confidence heuristics.

Automatic, Supervised, or Manual: Manual

Programming language(s): Python

Source code available: Will be made available after approval and testing

Links to relevant discussions (where appropriate):

Edit period(s): daily

Estimated number of pages affected: 10-15 per day

Namespace(s): Articles

Exclusion compliant (Yes/No): Yes

Function details: We have generated a dataset containing minor to larger spelling mistakes using Wikipedia dump based on heuristics like edit distance, popularity, frequency of use. We manually verify about 10-15 such changes everyday on our own designed portal at https://www.iitg.ac.in/cseweb/WikiFeedback. This bot will reflect those changes from our SQL server to Wikipedia bot.

Discussion

Hi there. Interesting project. For the purposes of approval, I'm afraid it would not be responsible for us to approve a closed-source bot, that also requires registration to use, and could violate WP:CONTEXTBOT unless all the edits are supervised. But it appears you might be affiliated with an Indian Institutes of Technology (judging by the domain of your site) so I'm not going to decline this BRFA yet, as your project may be promising, but the function will need tweaking to meet our standards for bots. If we did approve a bot like this we need to have a high level of confidence that it isn't going to make problematic changes (see WP:CONTEXTBOT). You do mention that you'll manually verify 10-15 a day. The bot could be coded as a tool using OAuth to make the edits on a user account directly (see WP:BOTMULTIOP). A bot account isn't usually needed to make a tool like this. All the edits would have to be manually verified by a human before going live on an article to make sure that they're okay. ProcrastinatingReader (talk) 14:05, 28 April 2021 (UTC)

Hello ProcrastinatingReader, Yes I am a research student at an Indian Institutes of Technology. Sorry, I guess it wasn't clear from my previous writing that we have a high confidence dataset which will also be voted upon by many users from our research group on the Portal I mentioned above. Based on User voting (expected 10-15 votes per day per user), our heuristics and recent revisions on similar pages on Wikipedia we would want our bot to make changes, keep tracking if some human user reverts back the changes made and notify us as well as our voters about revisions. I couldn't mention complete heuristics of generating the dataset since it is a live project. Also since all changes are being verified manually, I believe chances of problematic changes is quite low. I can make source code available only after permissions from our group, if its non-availability is a deal-breaker. Please do let me what can be done to get this bot live. K.Kapil77 (talk) 18:29, 28 April 2021 (UTC)

Source code is not required by default to be published, but it's encouraged, and for some tasks it can be preferable to have others look over it.

You can code your algorithm to generate diffs for a change however you like of course (eg using user voting or analysis of revisions). The key for the purposes of this bot is that you need a human to look over the change and make sure it's okay before it actually goes live on an article. If you're looking to move into unsupervised territory, this could maybe be re-evaluated if there's a track record of generated changes being accurate, but in the first instance I don't think a bot could be approved for unsupervised editing in this manner.

As for the 'checking over' part, this is referred to as semi-automated editing. You can use OAuth (see mw:OAuth/For Developers) to directly make the edits on the human editor's Wikipedia account, so it wouldn't necessarily need to go via a bot account and this method wouldn't really require any sort of approval. ProcrastinatingReader (talk) 18:45, 28 April 2021 (UTC)

​ They have already said all edits are manually vetted, so I don't think CONTEXTBOT is applicable. There exist a lot of bots whose edits are manually supervised. Making it an OAuth tool is added complication which is useful only when the creators want to crowdsource vetting of the edits (here they indicate they'll do the vetting themselves). So all in all I don't see any issues here. Having a quick trial will likely help further review. – SD0001 (talk) 12:42, 29 April 2021 (UTC)

Hmm. I guess if these conditions (all edits manually verified by the same editor) will not change in the future it won't actively be a problem. @SD0001: do you want to take it through trial? ProcrastinatingReader (talk) 12:52, 29 April 2021 (UTC)

Approved for trial (25 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Please don't mark edits as minor for the trial (so that they show up in watchlists and RecentChanges). Let us know if you run into any issues. – SD0001 (talk) 13:07, 29 April 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)

  Hmm, I wonder why EarwigBot only has " " as a task. — The Earwig (talk) 05:21, 29 March 2021 (UTC)

Approved for trial (30 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. as this bot has limited pages to edit / actions to perform - no big deal letting it officially be in a trial. — xaosflux ^Talk 10:13, 28 April 2021 (UTC)

AWMBot 2

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

Time filed: 15:32, Thursday, April 22, 2021 (UTC)

Automatic, Supervised, or Manual: supervised

Programming language(s): Node

Source code available: https://github.com/Oppurtun/AWMBot/blob/main/task1.js

Function overview: The bot scans broken review templates then scans previous names and places it under the peer review template.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Bot_to_repair_broken_peer_review_links

Edit period(s): one time run

Estimated number of pages affected: Around 1000

Exclusion compliant (Yes/No): No

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

Function details: The bot scans pages under the category. It then scans previous names and places it under the peer review template.

Discussion

Have any changes been made to address the feedback/issues discussed in Wikipedia:Bots/Requests for approval/AWMBot? ProcrastinatingReader (talk) 11:02, 23 April 2021 (UTC)

Yes, there has been a change that involves the replacement of the entire tag with a near 0 margin of error with editing. BJackJS talk

I think part of the issue there was that it was adding page titles which just didn't exist. For example Special:Diff/989309968, even though Wikipedia:Peer review/Becky (model)/archive1 is a redlink. Is that resolved? If so, what's the behaviour of this bot if it runs on a page like that? Will it skip, remove the entire peer review tag, or is there a different parameter name/value it will add? ProcrastinatingReader (talk) 16:31, 24 April 2021 (UTC)

I'm working on a function that verifies if a tag replacement is a redlink and it will then skip over that so it can be done manually by people who may have a better idea of what to do than an automated system. BJackJS talk

Okay. Send me a ping once that's done and I'll be happy to send this for trial :). I don't think it's worth cycling through trials without that function, like in the previous BRFA, as in this edge case making those edits doesn't really solve the problem. ProcrastinatingReader (talk) 15:38, 25 April 2021 (UTC)

User:ProcrastinatingReader The function has been added along with a major bugfix. BJackJS talk 17:18, 27 April 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⚡ 16:57, 27 April 2021 (UTC)
• Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. ProcrastinatingReader (talk) 02:09, 28 April 2021 (UTC)

PearBOT II 11

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

Time filed: 21:34, Monday, April 19, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): AWB (or possibly JWB)

Source code available:

Function overview: General TfD implementation through removal or simple replacements

Links to relevant discussions (where appropriate):

Edit period(s): As needed

Estimated number of pages affected: Dozens to thousands depending on template

Exclusion compliant (Yes/No): Yes

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

Function details: It is often enough that I want to perform TfD implementation using a bot that I think this is warranted. There is no acute need for another bot of this nature with PrimeBOT 24 SporkBot and BsherrAWBBOT 2, but it would reduce the wait time for these projects at times. The template that prompted this request was {{R from historic name}} where {{R printworthy}} has to be added to the 5000ish uses which doesn't have it separately, but if I had the bot last month I would probably have done {{Friendly search suggestions}} as well and {{WPUS50}} looks like a likely future candidate for the task.

Discussion

So I think Wikipedia:Bots/Requests for approval/PearBOT was a TfD-related task, have you done any others? If this goes to trial, do you have any templates in holding in mind you'd like to work on? ProcrastinatingReader (talk) 22:14, 19 April 2021 (UTC)

ProcrastinatingReader I have one other TfD task now, PearBOT 4. If I ever want to do something even as close to the technical or implementation complexity of PearBOT 1 that will go through another BRFA since a lot of testing and a second pair of eyes will be needed. As I said in the function details, the first usage would be {{R from historic name}} with {{WPUS50}} likely to follow. I've implemented tons of TfDs, often using AWB, over the past few years. --Trialpears (talk) 22:31, 19 April 2021 (UTC)

I think for the Rcat template it can just be replaced with a template call of the target template name, and use AnomieBot to subst it all. But the same can be said for many TfD merges. I suppose they're different tools, and depending on the case one approach can be slightly (or substantially) easier than the other.

Approved for trial. Please provide a link to the relevant contributions and/or diffs when the trial is complete. Approved for 3 templates, 25 diffs each. ProcrastinatingReader (talk) 22:40, 19 April 2021 (UTC)

The problem with using AnomieBOT for {{R from historic name}} is that there is a significant number where {{R printworthy}} already is present which would result in duplicate templates. Anyway, I've done 25 edits with {{R from historic name}} (1, 2, 3-25). Everything went as expected, except me forgetting to turn of the other currently running task at first which would have made the edits interspersed with each other and put the bot over the recommended max edit rate. Would it be possibly to go ahead with the specific templates I've already had a trial for or do I have to complete all 3 templates first? I don't think there's a third appropriate template for a bot in the holding cell right now and it would be a shame to artificially delay the others. --Trialpears (talk) 23:09, 19 April 2021 (UTC)

Why is {{R printworthy}} being added? ProcrastinatingReader (talk) 11:28, 20 April 2021 (UTC)

As noted in the relevant discussions the main difference between them is that historic name tags redirects as printworthy while former name does not. As stated in the latest TfD "It's best to just tag relevant "historic" names as printworthy". --Trialpears (talk) 12:41, 20 April 2021 (UTC)

Gotcha. Presumably it would omit adding printworthy if it's already added? If so, and given diffs look fine, you can complete the run for that template. ProcrastinatingReader (talk) 14:15, 20 April 2021 (UTC)

Yes the list excludes all pages with either {{R printworthy}} or {{R unprintworthy}}. I've started the run and expect it to finish for tomorrow and I plan on doing {{WPUS50}} then. --Trialpears (talk) 14:40, 20 April 2021 (UTC)

Another template trial done for {{WPUS50}}: Contribs. First edit got the wrong edit summary because AWB was being weird and unselecting my custom summary. Other than that this was a very uneventful trial. --Trialpears (talk) 23:14, 27 April 2021 (UTC)

Those mostly seem fine but it might be a good idea to respect the spacing preferences that exist in the template. For example in Special:Diff/1020227303 or Special:Diff/1020227281. Don't AWB's AddParameter functions automatically account for this? ProcrastinatingReader (talk) 14:19, 28 April 2021 (UTC)

I implemented a version to deal with block formatted templates (none of the ones that appeared in the trial were block formatted though), but didn't deal with the spacing. I could make a specific regex for it. I don't know about the AddParameter functions but if such things exist that would be awesome. I know there is the template parameter renamer and I suppose the template dater module has to have some sort of parameter adder. Could you give me a pointer to this thing? --Trialpears (talk) 12:59, 29 April 2021 (UTC)

I think it's [11] ProcrastinatingReader (talk) 15:18, 29 April 2021 (UTC)

Thanks! I've implemented a module using this. It appears that it only deals with spacing around the equals sign though so I've added some regex to deal with whitespace around the pipe as well. I've done about 25 preview tests with this and it works well. Do you want another 25 edits or can I start the run? --Trialpears (talk) 10:04, 6 May 2021 (UTC)

Though I have no reason to think there will be any issues, another 25 seems preferable for trial. ProcrastinatingReader (talk) 12:07, 6 May 2021 (UTC)

Here you go! It makes the parameter spacing consistent with the first parameter. Some of the templates in the trial already had inconsistent spacing which it of course doesn't fix. --Trialpears (talk) 12:15, 6 May 2021 (UTC)

LGTM. Feel free to complete the run. ProcrastinatingReader (talk) 12:39, 6 May 2021 (UTC)

GreenC bot 20

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

Time filed: 03:12, Thursday, April 15, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): GNU Awk and BotWikiAwk

Source code available: User:GreenC_bot/Job_20

Function overview: peerr removes the template {{Peer review}} from talk pages where no longer needed. ie. the template was added more than 7 days ago indicating the peer review processes has stalled or was not properly initiated.

Links to relevant discussions (where appropriate): User_talk:GreenC#Bot_functionality_request & Template_talk:Peer_review#Bot_task

Edit period(s): Daily

Estimated number of pages affected: 0-5 per day

Exclusion compliant (Yes/No): Yes

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

Function details: Long description: As part of the peer review process, {{Peer review}} are added to article talk pages, but sometimes the process is not done correctly or stalls. A tracking cat was created to catch these (Category:Peer review requests not opened), but still requires manual removal of the template after waiting some time. It is safe to say if the template has been in place for more than 7 days without indication the rest of the processes has been done, the template can be removed. To automate: once a day, the bot retrieves the list of page names in the tracking category, along with today's date ("added date"), and adds it to a text file. If the page name is already in the text file don't add it again, rather check if it has been more than 7 days since the added date. If so, verify there is a corresponding peer review page called Wikipedia:Peer review/PAGENAME/archiveX and if not then remove the Peer review template, and remove the text file entry. Likewise if the page name is in the text file but not in the tracking category then remove the page name from the file.

Discussion

• Suggest dropping a link at Wikipedia talk:Peer review, as it has more talk page watchers than the template talk. ProcrastinatingReader (talk) 05:10, 15 April 2021 (UTC)
• Thank you for helping us out at WP:PR with this bot. There are a few tasks at peer review that could be automated and this is one of them that I am thankful for.Tom (LT) (talk) 08:11, 15 April 2021 (UTC)
• Approved for trial (25 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. To make the edits more obvious please do not mark the edits as minor so that the change ends up on all watchlists. Primefac (talk) 13:03, 15 April 2021 (UTC)
• The bot is running. Nothing will happen for at least 7 days. The 25 edits might take weeks or months. Feel free to ping me anytime for a list of existing edits. -- GreenC 21:38, 17 April 2021 (UTC)
• I'm a little confused as to why the bot op is edit warring with the bot at Talk:Nightingale College. Beeblebrox (talk) 00:21, 18 April 2021 (UTC)

• These were test edits to ensure that when I am not looking (such as sleeping or working) when it begins editing automatically 7+ days from now it doesn't destroy a page. And Nightengale College the template qualifies to be removed, if you want to revert the page to this edit as the first trial edit, though it is kind of cheating; better to wait 7 days when it will do it again automatically which is what the trial is testing. -- GreenC 03:40, 18 April 2021 (UTC)

• I think I'd just prefer that you not make six edits on a live talk page of an article for testing purposes, or at least that you make it clear that you are running a test on that talk page. I very nearly just shut off the bot because you were just repeatedly reverting it without explaining why, even by edit summary. So, consider this a gentle reminder that bots are here to help the rest of us, and mucking around article talk pages without explaining yourself isn't helpful. Beeblebrox (talk) 17:51, 18 April 2021 (UTC)

PearBOT II 10

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

Time filed: 19:48, Sunday, April 11, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): AWB

Source code available:

Function overview: Replaces the short descriptions "Wikimedia list article" and "Wikipedia list article" with none

Links to relevant discussions (where appropriate): Wikipedia talk:Short description#"Wikimedia list article"

Edit period(s): One time run

Estimated number of pages affected: Around 75,000

Exclusion compliant (Yes/No): Yes

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

Function details: It's all discussed at Wikipedia talk:Short description#"Wikimedia list article". TLDR: There's a consensus that "Wikimedia list article" and "Wikipedia list article" are undesirable short descriptions and that no short description is necessary for most lists and a bot is the way to implement it. This bot is about as simple as they get and a trial would be a bit silly, but I can do it if so desired.

Discussion

• @Trialpears: You are a trusted bot op, but let's have a brief trial to sanity check ourselves. Could you please confirm whether this bot has any impact on Wikidata entities relating to these articles? Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. --TheSandDoctor ^Talk 01:03, 15 April 2021 (UTC)
• A list article affected by the trial is on my watchlist: I wouldn't mind this bot getting the prize of this year's most useless bot operation. For clarity oppose this bot. What would it do other than creating watchlist clutter? What would its actual benefit be? Edit-warring with bots or editors importing short descriptions from Wikidata? Really, this is the kind of bot operations we can miss big time. --Francis Schonken (talk) 07:20, 15 April 2021 (UTC)

  Francis Schonken I'm trying my best to get the underlying concern of removing tens of thousands of useless descriptions. I brought up the watchlist spam concern at Wikipedia talk:Short description#"Wikimedia list article". It won't edit war with people since there will only be one run and it will use {{short description|none}} which prevents shortdesc helper from importing the description and hopefully it won't suggest it at all even when it isn't present soon. Could you go to the above discussion and express your opinion there? I will put the bot on hold for a bit. --Trialpears (talk) 07:44, 15 April 2021 (UTC)

  Expressed my opinion there. This bot should not, as in not ever be allowed, imho. Please think this through instead. --Francis Schonken (talk) 08:05, 15 April 2021 (UTC)

  Example diff. How is "none" more useful than "Wikimedia list article"? You are replacing a relatively useless description by something that's absolutely useless. I oppose this task to make bad descriptions even worse. --mfb (talk) 08:14, 15 April 2021 (UTC)

  Mfb "none" won't actually be displayed as the description but is rather a special word that makes the article have no description at all. For instance if you search for "list of a" on the mobile site (image included) you will see basically all entries having either of the descriptions under the article name contributing nothing and being useless clutter. This bot task or the template solution I proposed at Wikipedia talk:Short description#"Wikimedia list article" would both remove this and make it look like the entry for List of Arrow characters. If you want it would be appreciated if you share your opinion at Wikipedia talk:Short description#"Wikimedia list article". Also, mostly due to curiosity, what would be the optimal short description for COVID-19 pandemic by country and territory in your opinion? --Trialpears (talk) 09:19, 15 April 2021 (UTC)

  If it's so critical to suppress two specific short descriptions then the template could do that, as proposed. The title of that article is a good description on its own I think, but not all list titles are that verbose. --mfb (talk) 09:37, 15 April 2021 (UTC)

  I can see a benefit if we can make sure no future import will give these two or similar general short descriptions, but that would need to be done first. --mfb (talk) 09:42, 15 April 2021 (UTC)

  @Mfb and Trialpears: how about this more meaningful short description? --Francis Schonken (talk) 10:39, 15 April 2021 (UTC)

  • For clarity: the discussion at Wikipedia talk:Short description#"Wikimedia list article" shows no consensus whatsoever for the proposed bot operation (that is even before I added my opinion there). Can't you people read a discussion and see that it goes in all sorts of directions without the least bit of consensus? That is not a basis for a bot task as if there was some sort of approval for the idea behind the task; there is no such approval. The task should never have been proposed. Tx. --Francis Schonken (talk) 08:23, 15 April 2021 (UTC)

    My read on that discussion is that is that first there's broad agreement that Wikimedia/Wikipedia list article doesn't contribute anything as a short description. I propose that we edit {{Short description}} to ignore the descriptions and threat them like none. When I implement this after waiting a reasonable time for objections or counter proposals to be raised some editors say that they would rather see a bot replace the descriptions. MichaelMaggs starts a subsection about how the description should be removed whether by bot or template edits is preferred. A few people, me included are neutral on how it's implemented since there are pros and cons with both and the rest prefer a bot. A week after the discussion started I decide to file this BRFA to move the project forward and since noone actually objected to a bot that was the favored outcome by the participants. Given that the talk page is quite highly trafficked for an implementation discussion (many template edits get no input at all) I considered that suitable and since the trial was approved the bot approval group agreed. It is however great to hear your opinions at this stage and not when we've had a bot doing thousands of edits, but rather just 10. We will just have to wait and see where the consensus takes us. Could also put an RfC tag on the WT:SHORTDESC discussion if you want to get a 30 day discussion and a proper close at the end. --Trialpears (talk) 09:03, 15 April 2021 (UTC)

    Yeah... messy discussion... no consensus... anyone can read in it what they want... no actual conclusion. As a minimum (even if no formal RfC had been initiated) it should have been listed at WP:ANRFC, so that someone uninvolved could have assessed the discussion for what, if anything, could be concluded from it. Note also the new subsection which I initiated in that discussion: I think you all started more or less from the deluded assumption that meaningful short descriptions for list articles are out of reach. --Francis Schonken (talk) 09:34, 15 April 2021 (UTC)

•  On hold. Until Wikipedia talk:Short description#"Wikimedia list article" is closed. --Trialpears (talk) 21:40, 19 April 2021 (UTC)

TolBot

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

Time filed: 21:48, Friday, April 16, 2021 (UTC)

Automatic, Supervised, or Manual: supervised

Programming language(s): Python

Source code available: User:TolBot/Task 1#Source

Function overview: The bot would automatically update Template:COVID-19 vaccination data from the [CSV data file] from Our World in Data (the source already used for this template).

Links to relevant discussions (where appropriate): None yet

Edit period(s): Daily

Estimated number of pages affected: 1

Exclusion compliant (Yes/No): No

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

Function details: The bot:

1. Downloads the CSV file.
2. Processes it in accordance with the instructions at the template documentation.
3. Generates wikitext in a similar fashion to the spreadsheet formula in the documentation.
4. Logs in to its account.
5. Downloads the page's wikitext.
6. Uses a regular expression to replace the data in between the comments with the updated data.
7. Makes an edit with the new wikitext.

Discussion

Very cool! The table layout has been pretty stable for a while. Only recent changes involved excluding specific regions. If we need to make minor adjustments in the future, is the Python code fairly easy to update? Bom4446 has been handling the daily updates so I'm sure they would welcome the break. - Wikmoz (talk) 07:07, 17 April 2021 (UTC)

Approved for trial (14 days). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 10:25, 17 April 2021 (UTC)

@Primefac: Should I do this on the bot account or on my main account? If it's on the bot account, I'll need a confirmed flag. (Sorry, this is my first time doing this!) It seems that I'll also need a bot flag or IP-block exemption flag, as the IP from Google Cloud that I'm using is blocked. Tol | Talk | Contribs (formerly Twassman) 15:16, 17 April 2021 (UTC)

@Primefac: I'm currently running the script to do everything but actually edit the article as the cloud IP is blocked, then editing manually (copy/paste) on my main account. Please advise — should I continue this or is there some way I can get either an IP-block exemption (on my main account) or confirmed and bot groups (on my bot account)? Tol | Talk | Contribs 15:37, 19 April 2021 (UTC)

Trial complete. Diffs are here. No problems other than the sorting issue, which is fixed. Tol | Talk | Contribs 17:12, 3 May 2021 (UTC)

Update: I have added some extra code and cleaned up generate() so that it handles cases with only people fully vaccinated and neither people vaccinated (at least once) nor total vaccinations; this is because Oman currently only has data on people fully vaccinated. Tol | Talk | Contribs 01:27, 9 May 2021 (UTC)

I can update the code as needed; all foreseeable updates will be to only one function (generating the wikitext from the processed table). I'll follow the talk page, but if you'd like me to change anything, please send me a ping/mesage! Tol | Talk | Contribs 15:27, 17 April 2021 (UTC)

Sounds good. It looks like there's one minor issue in the current build. Several (non-COFA) countries with high vaccine counts are appearing at the bottom of the list, including Egypt, Belarus, and Pakistan. - Wikmoz (talk) 05:16, 18 April 2021 (UTC)

@Wikmoz: Thanks for catching this! The issue seems to be that it sorts by total_vaccinations, but El Salvador, Belarus, Pakistan, and Egypt do not have total_vaccinations, only people_vaccinated. I'll set it up so that it checks for blank total_vaccinations and substitutes people_vaccinated instead. Tol | Talk | Contribs 18:13, 18 April 2021 (UTC)

@Tol This is indeed very cool! Thank you very much! Although I will continue updating the daily updates whenever possible. OWID usually updates their data around noon daily (CEST). The time is very convenient for me and also I can update the table as soon as new data becomes available. Bom4446 (talk) 14:11, 19 April 2021 (UTC)

@Bom4446: Thank you, and you are welcome! I'll see if I can run it at around 16:00 UTC (18:00 CEST) during the trial period. Tol | Talk | Contribs 23:26, 19 April 2021 (UTC)

Hi @Bom4446, could you please refrain from updating the table so that the bot can do it? Thanks, Tol | Talk | Contribs 15:34, 20 April 2021 (UTC)

I think the bot has done good work during the trail. Will it run again?Nico (talk) 05:44, 7 May 2021 (UTC)

@Nicob1984: The bot is currently awaiting approval. If it is approved (and it probably will be), it will run indefinitely. Tol | Talk | Contribs 16:36, 7 May 2021 (UTC)

FireflyBot 12

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

Time filed: 08:35, Thursday, April 15, 2021 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/rwjuk/drn_clerk_bot

Function overview: Clone of MDanielsBot 6, updating Template:DRN_case_status with current status information.

Links to relevant discussions (where appropriate): Wikipedia:Village_pump_(technical)#Bot_Partially_Non-functioning

Edit period(s): Every 30 minutes

Estimated number of pages affected: 1

Exclusion compliant (Yes/No): No

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

Function details: Clone of MDanielsBot 6, updating Template:DRN_case_status with current status information. I used Hasteur's code but adapted it to use mwparserfromhell for the heavy lifting of parsing the DRN page rather than regex.

Currently updating this test page in the bot's userspace for evaluation.

Courtesy ping to Robert McClenon who asked this to be picked up.

Discussion

Approved for trial (25 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. Primefac (talk) 13:01, 15 April 2021 (UTC)

Trial now running, thanks! ƒirefly ( t · c ) 21:13, 17 April 2021 (UTC)

Trial complete. Edits can be seen here. ƒirefly ( t · c ) 06:39, 27 April 2021 (UTC)

Thanks. I understand that the bot has been paused for evaluation of trial results before going into permanent operation. My opinion is that the bot is working, and does what two previous bots did. Robert McClenon (talk) 21:03, 2 May 2021 (UTC)

Cewbot 7

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

Time filed: 10:03, Wednesday, April 14, 2021 (UTC)

Function overview: Sorting category of Thai names

Automatic, Supervised, or Manual: Automatic

Programming language(s): wikiapi on GitHub

Source code available: 20210416.Sorting category and sort key of Thai names.js on GitHub, 20210422.Sorting category and sort key of Thai names.js on GitHub

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Category sorting for Thai names

Edit period(s): weekly

Estimated number of pages affected: hundreds up to 5,500

Namespace(s): Articles

Exclusion compliant (Yes/No): Yes

Function details: Please refer to Wikipedia:Bot_requests#Category sorting for Thai names. --Kanashimi (talk) 10:03, 14 April 2021 (UTC)

Discussion

• @Kanashimi: I am glad that this task is being filed. Approved for trial (50 edits). Please provide a link to the relevant contributions and/or diffs when the trial is complete. --TheSandDoctor ^Talk 01:01, 15 April 2021 (UTC)

Operations till now...

1.  Done Insert {{Thai people category}} to list in Wikipedia:WikiProject Thailand/Thai name categories
2. Doing... Fix Wikipedia:WikiProject Thailand/Thai name sort keys... @Paul 012: It seems there are some bugs(?) in the list, I fix them just now. Are the modification I made right? By the way, is "Same" means "Article title is the same with default sort"? And how should we do if there are redirects? (e.g., Namkabuan Nongkee Pahuyuth → Namkabuan Nongkeepahuyuth, Samuenthep Por Petchsiri → Parnthep V.K.Khaoyai and other 8 pages now) --Kanashimi (talk) 03:14, 17 April 2021 (UTC)

   Kanashimi, the intention was for the Same column to indicate pages which should be tagged with {{Thai sort same as defaultsort}}. They are the rows with empty Thai sort values. (I don't think we need to consider whether the article title is the same as the Defaultsort; even if they are, I think a manual Defaultsort value should still be given, to prevent later mistaken automatic additions.) As for the redirects, which are the result of recent page moves, I've now updated the corresponding entries in the table. --Paul_012 (talk) 05:21, 17 April 2021 (UTC)

Looks like I got the meaning of the word "Same" wrong. I have changed the title. --Kanashimi (talk) 06:19, 17 April 2021 (UTC)

@Paul 012: I find there are already some sort keys in the page. Do we need to overwrite them? e.g.,

1. Krissada Sukosol Clapp: The default sort key of {{DEFAULTSORT:Clapp, Krissada Sukosol}} will set to "Sukosol Clapp, Krissada"!
2. Krissada Sukosol Clapp: The sort key of Krissada Terrence will set to "Krissada Sukosol Clapp"!
3. Krissada Sukosol Clapp: The sort key of Krissada Terrence will set to "Krissada Sukosol Clapp"!
4. Nicolene Pichapa Limsnukan: The default sort key of {{DEFAULTSORT:Limsnukan, Pichapa}} will set to "Limsnukan, Nicolene Pichapa"!
5. Vachirawit Chivaaree: The default sort key of {{DEFAULTSORT:Chiva-aree, Vachirawit}} will set to "Chivaaree, Vachirawit"!

And I find many pages not listed in Wikipedia:WikiProject Thailand/Thai name sort keys. Do I need to list up them in a page? Is there a good page name for this? For these pages, do we just need to Modify sort key of categories in Thai_CATEGORY_LIST, as [[Category:Category name|PAGENAME]]? --Kanashimi (talk) 04:40, 18 April 2021 (UTC)

@Kanashimi: Yes, the five examples above are all cases where the existing sort keys/defaultsort should be overwritten. As for pages that are not listed, I identified 1,227 non-redirect items via this Petscan query; do they match your list? Most of them should be either non-Thai names, single-word names, or non-biographies, so yes, only PAGENAME sort keys should be added to the Thai categories, without touching the defaultsort values. (There are a few recently created articles, which I think will be easier to manually deal with.) I'll go through some examples to make sure we're on the same page.

• 2007 Thai House of Representatives is a non-biography page, so it should be ignored (though Category:House of Representatives of Thailand shouldn't have been on the list; I've removed the Thai name category template now). So is Abhisit cabinet, Australians in Thailand, etc., and all the List of... articles. Armchair (band) is about a band, not a person, so articles like these should also be regarded as a non-biographies. (There were a few biographical articles that were missing birth/death year categories; I've gone through and added them, so all articles without such categories are now non-biographical.)
• Abbas Sarkhab is a non-Thai name, so the only change should be to add the sort key [[Category:Police Tero F.C. players|Abbas Sarkhab]]. Similarly, Abdoul Karim Sylla (footballer, born 1981) should have [[Category:Uttaradit F.C. players|Abdoul Karim Sylla]] (without the parenthetical disambiguator).
• Abbhantripaja is a single word, so no sort key is necessary, and it should be skipped. I forgot to account for cases like this in the original discussion; can this be added to the logic?
• Similarly, Aguinaldo (footballer) is one word (excluding the disambiguator) and should be likewise skipped.
• Abu Samah Mohd Kassim currently has no defaultsort value. Alef Vieira Santos currently has {{DEFAULTSORT:Alef Vieira Santos}}, which is identical to the page name. Abbas II of Egypt has {{DEFAULTSORT:Abbas II Of Egypt}}, which differs only in capitalisation. Adding PAGENAME as sort keys will result in no change, so all of these cases should also be skipped.

There are a few complicated cases, mostly involving foreign royalty. Examples include Frederick IX of Denmark ({{DEFAULTSORT:Frederick 09 Of Denmark}}), Prince Gustav of Denmark ({{DEFAULTSORT:Gustav Of Denmark, Prince}}) These should all be skipped, though I'm not sure if there's a common pattern that could identify them. Maybe they'll have to be manually listed?

Also, I'm thinking maybe {{Thai sort key not needed}} might be a better, more self-explanatory name for the {{Thai sort same as defaultsort}} template. --Paul_012 (talk) 14:28, 18 April 2021 (UTC)

•  Done Skip single-word-pages.
•  Investigating... I find it is hard to judgment if a page is biography only with {{bd}}. For example, there is no {{bd}} in Aguinaldo (footballer). Although it has {{birth date and age}} in it, but there are many unexpected exceptions, I think. @TheSandDoctor: Do you have good ideas to judgment whether a page is biography or not?
•  Investigating... For the special cases, yes, please list up them in Wikipedia:WikiProject Thailand/Thai name sort keys.
•  Investigating... May you do a sample edit for {{Thai sort key not needed}} or {{Thai sort same as defaultsort}}? --Kanashimi (talk) 22:59, 18 April 2021 (UTC)

• Biographical articles should all contain Category:Living people and/or a one-level subcategory of Category:Births by year and/or Category:Deaths by year, which non-biographies should not have. I think checking for the categories Living people, #### births, #### deaths, Year of birth missing‎, Year of birth uncertain, Year of birth unknown‎, Date of birth missing‎, Date of birth unknown, Year of death missing, Year of death uncertain‎, or Year of death unknown‎, should work.
• I'm now working on the remaining special cases. --Paul_012 (talk) 03:51, 19 April 2021 (UTC)
• I've placed {{Thai sort key not needed}} on Chaophraya Phra Khlang (Hon). Is this example adequate? --Paul_012 (talk) 03:51, 19 April 2021 (UTC)

@Paul 012: Well, I start to do some test edits (please search "Maintain sort key of Thai peoples"). Please tell me how about the results. --Kanashimi (talk) 06:16, 19 April 2021 (UTC)

The bot worked as expected in almost all cases, but it seems to still have problems with cases where the value in the Thai sort = Default sort column is yes. For Phra Chenduriyang (diff), the desired result would have been to:

1. Update the defaultsort value to {{DEFAULTSORT:Chenduriyang, Phra}} (no change since this matches the value already in the article)
2. Add {{Thai sort key not needed}} above the defaultsort line
3. Skip to the next article without adding sort keys to individual categories.

I noticed a few cases where categories that should have had {{Thai people category}} added were missed; that was an oversight on my part, and I've manually added the template. I've also added foreign royals to the top of Wikipedia:WikiProject Thailand/Thai name sort keys. Please note that they will need to be treated differently from other items, as no change should be made to their defaultsort values. --Paul_012 (talk) 09:47, 19 April 2021 (UTC)

@Paul 012: I fixed the mistake of {{Thai sort key not needed}} and do some more test edits (please search "Maintain sort key of Thai peoples", after 10:15, 19 April 2021 diff hist +60‎ m Tamarine Tanasugarn ‎ Maintain sort key of Thai peoples:). May you take a look at them? Thank you. --Kanashimi (talk) 10:29, 19 April 2021 (UTC)

Thanks. The addition of {{Thai sort key not needed}} works properly now. The only errors here are non-biographical pages getting included in the edits: Royal Standard of Thailand (diff), Supreme Council of State of Siam (diff), Royal flags of Thailand (diff), The King Never Smiles (diff), Chakri dynasty (diff), and Australians in Thailand (diff). Have you implemented the check yet? --Paul_012 (talk) 10:52, 19 April 2021 (UTC)

@Paul 012: Sorry. I implement the function just now. I have do some more edits (from "13:45, 19 April 2021 diff hist +29‎ m Vapi Busbakara"). Are they seems OK? By the way, do I need to create a page to log all the pages I detect as non-biography, to prevent something missed? --Kanashimi (talk) 13:59, 19 April 2021 (UTC)

The new results are all good. Having a log would be useful, though would probably only be needed for the initial run (and not the subsequent weekly(?) updates). I would like to see some edits confirming that the bot respects the "don't change" values in the table; could you have it run through Category:Knights Grand Cordon of the Order of Chula Chom Klao? Also, could you demonstrate the behaviour for the subsequent weekly(?) runs, where it does not refer to the table and does not change defaultsort values? (Category:Thai people of American descent could be used for this, since the bot has already gone through its contents once, and there are some changes that should be made since I just tagged a few missing categories.) --Paul_012 (talk) 18:08, 19 April 2021 (UTC)

@Paul 012: I run through Category:Knights Grand Cordon of the Order of Chula Chom Klao, Category:Thai people of American descent and Category:Thai female Phra Ong Chao just now. Please take a view. According to the implement now, the bot always refer to Wikipedia:WikiProject Thailand/Thai name sort keys every time, so the table MUST keep updated. --Kanashimi (talk) 21:44, 19 April 2021 (UTC)

The don't change instructions aren't generating the desired behaviour. See Frederick IX of Denmark (diff), Princess Irene of the Netherlands (diff), etc. Since the entries have Thai sort = Default sort set to yes, {{Thai sort key not needed}} should have been placed and no category sort keys added. (Alternatively, it'd be okay to skip these pages altogether; I can manually add the template later.)

As for the current implementation depending on the table, that's fine for the initial run, but it would be impractical to keep the table updated into the future. If it can't be tested now, I'm not sure if a second BRFA would be needed for the updated future task. (The major functional differences would be skipping the defaultsort change and finding {{Thai sort key not needed}} on a page instead of looking up the Thai sort = Default sort column in the table.) --Paul_012 (talk) 03:57, 20 April 2021 (UTC)

I fix the code and it seems works now. --Kanashimi (talk) 06:00, 20 April 2021 (UTC)

the long term task

@Paul 012: It seems that this is what we want to do in the future:

1.  Done Get all pages of Thai_name_categories (categories transcluding {{Thai people category}}).
2. If the page transcluding {{Thai sort key not needed}}:
   1. Remove all sort key of Thai_name_categories -- It is possible for the bot.
3. else (page does not transcluding {{Thai sort key not needed}}):
   1. Here comes the problem: How do the bot determine the DEFAULTSORT and the sort key of Thai_name_categories without Wikipedia:WikiProject Thailand/Thai name sort keys for a new created page? --Kanashimi (talk) 06:01, 20 April 2021 (UTC)

In the future, I expect that the bot should always leave DEFAULTSORT values unchanged. (For new articles, the correct values should be added manually when creating the page.) For 3.1, pages which do not transclude {{Thai sort key not needed}}, the bot should follow the same behaviour as currently done for pages not in the table, e.g. Amanda Mildred Carr (diff). I.e., the sort key for Thai_name_categories should be the PAGENAME, excluding (parenthetical disambiguators). For 2.1, I don't think we want the bot to remove sort keys; there may be cases where manually added keys are still needed in some categories. As with the current set-up, pages with single-word titles should also be skipped, as well as pages with empty DEFAULTSORTs or DEFAULTSORTs that are identical to the PAGENAME or differ only in capitalisation (e.g. Abu Samah Mohd Kassim and Alef Vieira Santos above). I'm not sure if this last check has already been implemented? (There are very few pages that will be affected, so it's hard to tell from the trial so far.) --Paul_012 (talk) 18:05, 20 April 2021 (UTC)

Since the operating mechanism changed, this part should implement after the initial run. @TheSandDoctor: May I start the initial run? It seems no problem now. So we can go further. Kanashimi (talk) 21:47, 20 April 2021 (UTC)

@Kanashimi: Were any edits made? --TheSandDoctor ^Talk 22:21, 20 April 2021 (UTC)

The initial run will works on most pages of categories transcluding {{Thai people category}}. --Kanashimi (talk) 23:19, 20 April 2021 (UTC)

I think TheSandDoctor was asking about the trial run. Here are the filtered contributions: 1, 2, 3, 4, 5 --Paul_012 (talk) 03:18, 21 April 2021 (UTC)

@Kanashimi: Paul_012 was correct. I just wanted to confirm whether it was an extended trial being asked for or if you could just continue the one you are on. How many edits would you like to see for the extended? I can set it to whatever works best for you. --TheSandDoctor ^Talk 04:09, 21 April 2021 (UTC)

I want to continue the task I am doing now. The code is listed here: 20210416.Sorting category and sort key of Thai names.js on GitHub. The code is, as you see above, tested. It will about thousands of pages. After the initial run, I will try the long term task mentioned above. Kanashimi (talk) 04:47, 21 April 2021 (UTC)

To clarify, the task is composed of two parts: (1) a one-time initial run (affecting up to some 5,000+ articles by my count (I've modified the request figure above), though likely less since pages which are already correctly formatted should be unaffected), and (2) a repeating long-term task (covering the same articles, but only as updates are needed following page category changes). From the trials thus far, the bot seems to be almost ready for the initial run, but a further trial period may still be needed after that to adjust the bot for the long-term task.

Before that is considered, I would still like to see another test, though. Kanashimi, could you perform another test to confirm that the following articles are skipped by the bot?

• Adenilson Martins do Carmo
• Alex Henrique José
• Brinner Henrique Santos Souza
• Cristiano da Silva Santos
• Danilo Cirino de Oliveira
• Jerri Ariel Farias Hahn

These are all members of Category:Chiangrai United F.C. players. --Paul_012 (talk) 08:38, 21 April 2021 (UTC)

 Done Well, maybe we can remove the DEFAULTSORT of these articles and insert {{Thai sort key not needed}}? Kanashimi (talk) 09:49, 21 April 2021 (UTC)

Hmm. So the check isn't currently implemented? Would it be complicated to do so? In any case, the DEFAULTSORTs should not be removed (Brazilian names seem to have a separate set of rules which I'm not quite familiar with). Using {{Thai sort key not needed}} (and marking the DEFAULTSORT as don't change, similarly to the foreign royals) could technically work, but the problem is that I have no idea which articles would need to be marked as such, and can't list them without manually checking the DEFAULTSORT for each and every one of them. It would be much simpler if the bot could automatically do the check and skip them altogether. On the other hand, if it's technically costly, I guess these edits and the need to skip them could be ignored, as they aren't causing any harm (apart from being unnecessary edits, but I don't expect that there are more than a few dozen cases.) --Paul_012 (talk) 11:32, 21 April 2021 (UTC)

I need a clear rule for this kind of articles. Is this right? For all Thai people pages not listed in Wikipedia:WikiProject Thailand/Thai name sort keys,

1. If the DEFAULTSORT is the same as the page article (excluding the disambiguator)
   1. then do the same thing as don't change
2. else (the DEFAULTSORT is NOT the same as the page article excluding the disambiguator)
   1. Modify sort key of Thai categories, as page name. Kanashimi (talk) 11:37, 21 April 2021 (UTC)

If the is rule is already being checked, it shouldn't be necessary to add {{Thai sort key not needed}}. I think it'd be better to skip the article entirely (the same treatment as articles with single-word titles). Also, I forgot about diacritics, which should be removed for comparison (and for the sort keys). So the rule would be: For all Thai people pages not listed in Wikipedia:WikiProject Thailand/Thai name sort keys,

1. If (the page title is a single word OR a single word plus a disambiguator) OR (the page has no DEFAULTSORT) OR (the DEFAULTSORT, with diacritics removed, is the same (case-insensitive) as the page title (excluding the disambiguator), with diacritics removed)
   1. then skip the page
2. else (the DEFAULTSORT is NOT the same as the page article excluding the disambiguator)
   1. Modify sort key of Thai categories, as page name (excluding the disambiguator), with diacritics removed.

--Paul_012 (talk) 12:08, 21 April 2021 (UTC)

Fixed Are there other concerns or pages to test? Kanashimi (talk) 12:45, 21 April 2021 (UTC)

Thanks. Could you test the above pages again, to confirm that the fix works as intended? And also, as a final matter, a test-run that covers some of the following pages (all in Category:Thai male boxers) would be a good idea, since so far no multi-word surnames seem to have been included in the trial run yet.

• Eaktwan BTU Ruaviking
• Pajonsuk SuperPro Samui
• Samson Dutch Boy Gym
• Yodsanan Sor Nanthachai

--Paul_012 (talk) 13:23, 21 April 2021 (UTC)

 Done 6 pages skipped. Kanashimi (talk) 13:33, 21 April 2021 (UTC)

Seems good now; thanks a lot. TheSandDoctor, I believe the identified bugs have been addressed and don't expect problems going through with the entire initial run (phase 1). If approved, maybe the BRFA could be kept open so that discussion of phase 2 can continue later? --Paul_012 (talk) 13:47, 21 April 2021 (UTC)

I set the summary to "Maintain sort key of Thai peoples: Modify sort key of Thai categories, as page name." Please help me to change to a better summary, thank you. Kanashimi (talk) 01:15, 22 April 2021 (UTC)

I think, after the initial run, there will be few pages left. Maybe I can do some test edits for phase 2? I have do one test edit at Kiatprawut Saiwaeo. Kanashimi (talk) 02:22, 22 April 2021 (UTC)

I don't have a problem with the current edit summary, but to be a bit more precise I guess it could say "Maintaining sort keys in Thai-people categories: Per values in Wikipedia:WikiProject Thailand/Thai name sort keys" and "Maintaining sort keys in Thai-people categories: Adding page title as sort keys". --Paul_012 (talk) 18:46, 22 April 2021 (UTC)

To reiterate, I think the workflow for phase 2 should be something like this:

1. Get all pages of Thai_name_categories (categories transcluding {{Thai people category}}).
2. If (the page is not a biography) OR (the page transcludes {{Thai sort key not needed}}) OR (the page title is a single word OR a single word plus a disambiguator) OR (the page has no DEFAULTSORT) OR (the DEFAULTSORT, with diacritics removed, is the same (case-insensitive) as the page title (excluding the disambiguator), with diacritics removed)
   1. then skip the page
3. else
   1. Modify sort key of Thai categories, as page name (excluding the disambiguator), with diacritics removed.

I realise this makes {{Thai sort key not needed}} kind of redundant for articles like Headache Stencil, Abha Barni Aed Carabao, where the DEFAULTSORT should match the title, but I don't think that should be a problem. --Paul_012 (talk) 18:46, 22 April 2021 (UTC)

Yes, I am now do the same thing as as stated above. The code is 20210422.Sorting category and sort key of Thai names.js on GitHub. It is ready to test now. Kanashimi (talk) 22:28, 22 April 2021 (UTC)

@Paul 012: Maybe we can run full task after be sure the phase 2 code is OK? Kanashimi (talk) 05:36, 23 April 2021 (UTC)

Here are a few articles that could be used to test phase 2.

• Rama II
• Asdang Dejavudh
• Therdsak Chaiman
• Adenilson Martins do Carmo
• Ong-ard Satrabhandhu
• Abbas Sarkhab
• Aed Carabao
• Bernard Trink
• Ajaan Suwat Suvaco

By the way, I just noticed that Thai expatriate sportspeople in Foo categories have not been tagged with {{Thai people category}}, though Thai expatriates in Foo have. Looking at this again, and considering the original wording of that template's documentation ("the category contains nearly exclusively people with a Thai name living in Thailand"), I'm thinking maybe Thai expatriates in Foo shouldn't have been tagged. I'll revert those edits. --Paul_012 (talk) 22:29, 23 April 2021 (UTC)

@Paul 012:  Done Pages that are not edited are skipped. Kanashimi (talk) 23:30, 23 April 2021 (UTC)

Seems to be working as expected. TheSandDoctor, I think both functions are ready pending approval: phase 1 (a one-time task) and phase 2 (on a continued weekly basis). --Paul_012 (talk) 06:34, 24 April 2021 (UTC)

Trial complete. --Kanashimi (talk) 21:22, 26 April 2021 (UTC)

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.

• WikiCleanerBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 26) Approved 12:59, 22 April 2021 (UTC) (bot has flag)
• Dreamy Jazz Bot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 7) Approved 14:32, 15 April 2021 (UTC) (bot has flag)
• FireflyBot II (BRFA · contribs · actions log · block log · flag log · user rights) Approved 00:11, 15 April 2021 (UTC) (bot has flag)
• MusikBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 17) Approved 19:16, 10 April 2021 (UTC) (bot has flag)
• BattyBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 53) Approved 17:14, 30 March 2021 (UTC) (bot has flag)
• IznoBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 3) Approved 16:39, 5 March 2021 (UTC) (bot has flag)
• 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)

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.

• DannyS712 bot IV (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 73) Bot denied 09:51, 21 April 2021 (UTC)

• 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)

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.

• TolBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 2) Withdrawn by operator 20:12, 3 May 2021 (UTC)

• DaxServerBot I (BRFA · contribs · actions log · block log · flag log · user rights) Withdrawn by operator 19:19, 17 April 2021 (UTC)

• YTStatsBot (BRFA · contribs · actions log · block log · flag log · user rights) Expired 13:16, 9 April 2021 (UTC)

• MusikBot (BRFA · contribs · actions log · block log · flag log · user rights) (Task: 16) Withdrawn by operator 17:32, 23 March 2021 (UTC)

• CommonsCategoryBot (BRFA · contribs · actions log · block log · flag log · user rights) Withdrawn by operator 20:03, 7 March 2021 (UTC)

• 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)