Wikipedia:Bots/Requests for approval

BAG member instructions

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

New to BRFA? Read these primers!
 Instructions for bot operators

Current requests for approval

PkbwcgsBot 25

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

Time filed: 21:45, Friday, January 10, 2020 (UTC)

Function overview: The bot is going to substitute the templates listed at Wikipedia:Templates_for_discussion/Log/2019_December_20#Template:WikiProject_24 into Template:WikiProject Television and remove any duplicates.

Automatic, Supervised, or Manual: Supervised

Programming language(s): AWB

Source code available: AWB

Links to relevant discussions (where appropriate): Wikipedia:Templates_for_discussion/Log/2019_December_20#Template:WikiProject_24

Edit period(s): One-time run

Estimated number of pages affected: 5000-15,000

Namespace(s): All namespaces

Exclusion compliant (Yes/No): For this specific task, no

Function details: The bot is going to convert the use of the templates at Wikipedia:Templates_for_discussion/Log/2019_December_20#Template:WikiProject_24 before deletion. An example of conversion is shown here. The bot is going to remove the transclusions of the WikiProject templates that were listed at Wikipedia:Templates_for_discussion/Log/2019_December_20#Template:WikiProject_24 and convert them to be used as wrappers. This is a bit of a complex task so I may need a bit of assistance but I am willing to take on this task as it needs to be done. The templates have been merged by User:Gonnym at this edit. For this task specifically, the bot will not be exclusion compliant.

Discussion

I have PearBOT 4 with approval for this type of task and could do it if you want. I'm quite busy currently, but should hopefully be able to get it done next week if you want me to. ‑‑Trialpears (talk) 23:28, 10 January 2020 (UTC)
@Trialpears: I may need some help on working out what regular expressions are the best to use. Pkbwcgs (talk) 10:29, 11 January 2020 (UTC)
The regex for Template:WikiProject 24 is as follows:

Find: ({]*)((a|[^a])*)({]*\|class=|importance=)([^}|=]*)([^}]*}})

Replace: $1|24-task=yes|24-importance=$5$2

Find: ({]*)((a|[^a])*)({]*\|class=|importance=)([^}|=]*)([^}]*}}

Replace: $3$5|24-task=yes|24-importance=$2

It works but it does the wrong thing because it removes parameters from Template:WikiProject United States rather than Template:WikiProject 24. Pkbwcgs (talk) 10:44, 11 January 2020 (UTC)

It looks like PearBOT II from User:Trialpears has converted the templates to wrappers already. However, I will keep this BRFA open so that I can get approval to convert more templates to wrappers in talk pages in the future. Pkbwcgs (talk) 11:24, 12 January 2020 (UTC)
I only took care of the wire and started x-files. The rest was PrimeBOT. ‑‑Trialpears (talk) 14:05, 12 January 2020 (UTC)

PearBOT 7

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

Time filed: 00:22, Tuesday, January 7, 2020 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: Will add tomorrow

Function overview: Remove red links to sister projects using {{Sister project}}.

Links to relevant discussions (where appropriate): Wikipedia:Bot requests#Remove sister project templates with no target

Edit period(s): One time run

Estimated number of pages affected: I really don't know. Somewhere between 500 and 10000 maybe?

Exclusion compliant (Yes/No): Yes

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

Function details: Since many of these templates link to a search using the articles page name as the query only links where there are zero search results.

Discussion

Hmm. Sometimes the lack of a namespace prefix can be the actual problem; we often link from Wikipedia articles to the corresponding Commons category. Jo-Jo Eumerus (talk) 09:19, 7 January 2020 (UTC)
Jo-Jo Eumerus, commons search results display results from several namespaces (gallery, file, category, creator, institution, help) by default. I will do the search in all of them just as a user following the link would. ‑‑Trialpears (talk) 07:16, 10 January 2020 (UTC)
Thanks for taking this on. My gut guess as the requester is that the "Estimated number of pages affected" would be much higher. I run into the problem on species articles, but I suspect the problem is Wikipedia wide, and that every article with a sister project template should be checked. I'd guess that's into the millions. SchreiberBike | ⌨  04:01, 10 January 2020 (UTC)
SchreiberBike, I think this issue would affect animal/plant species disproportionately since the articles often contain a commons/wikispecies link that is copied by other editors even when it's not applicable. It would also be more common that it's automatically removable for species since the title can't show up on any user facing page on all of commons (or other project) to have zero search results which should be more common for species with their latin names. I may very well be wrong though. I'll run it without saving on a few pages to get an actual estimate this weekend. ‑‑Trialpears (talk) 07:29, 10 January 2020 (UTC)
  • @Trialpears: Pi bot does similar things with commons categories, and is also written in Python, so there may be code that you can adapt from that to handle these cases. In particular, I would recommend using Wikidata interwiki links to replace bad links with good ones where possible. There's also a discussion with @Hike395: on my talk page which might be relevant - having some code in the templates along the lines of that used in {{Commons category}}, plus similar tracking categories to those at Category:Commons category Wikidata tracking categories, would help with manually checking cases that the bot can't handle. Thanks. Mike Peel (talk) 09:25, 18 January 2020 (UTC)
@Trialpears and SchreiberBike: Hi, Trial. How were you planning on defining "red links"? I've been gathering data about commons links, and the concept is rather complex. You can see the wikidata dump of commons links for en articles that contain {{commons and category}} or {{commons and category-inline}} with missing arguments, here and here. Out of 924 such articles, 51 (5.5%) do not have any commons links recorded in wikidata. The Commons search quality is variable:
Were you planning on testing for an empty search result? Otherwise, I'm not sure how a bot can tell the difference between a useful search result and junk. There's also the question of timing --- it could be that a search result is empty or junk now, but will return a good result in the future. — hike395 (talk) 00:33, 19 January 2020 (UTC)
Hike395, my plan was defining it very strictly only removing if there are no hits in any user facing namespaces which means only Anjum Shahzad would be removed of the ones above. While it is possible there will be a good result in the future there has repeatedly been a consensus that redlinks in navigational templates such as this one should be removed if they are not very likely to be created shortly as documented at WP:EXISTING. It will take some time for me to look into Mike Peel's code but it looks very promising and seems to be more efficient then my current implementation. ‑‑Trialpears (talk) 17:36, 19 January 2020 (UTC)
IIUC, you are planning on running Commons searches like Commons:Special:Search/Anjum Shahzad in your bot, and then remove en template if the search results contain no Files, galleries, or Categories. That seems good. Mike Peel's bot code could be helpful --- it could be faster to look up entities in wikidata, filtering out the 95% that have entries in P373, P935, sitelinks, or P910 sitelinks. Then you would only run the search on ~5% of the boxes. — hike395 (talk) 18:58, 19 January 2020 (UTC)

DemonDays64 Bot 2

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

Time filed: 04:51, Monday, December 30, 2019 (UTC)

Function overview: To edit in HTTPS to applicable links. Everything is the same as at Wikipedia:Bots/Requests for approval/DemonDays64 Bot, but the RegEx is modified in a significant way and the www. should not be removed.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Javascript Wiki Browser

Source code available: In the bot's JWB settings

Links to relevant discussions (where appropriate): Wikipedia:Bots/Requests for approval/DemonDays64 Bot

Edit period(s): When computer is on.

Estimated number of pages affected: Every page with a link on it could be edited eventually. See Wikipedia:Bots/Requests for approval/DemonDays64 Bot for more info.

Namespace(s): Mainspace

Exclusion compliant Yes

Function details:

Hello again! See Wikipedia:Bots/Requests for approval/DemonDays64 Bot; everything is the same except for the RegEx it uses.

This bot was previously approved, but concerns about it removing the www. from URLs led to me voluntarily suspending running it. I have returned to update it, but, as the RegEx, the most important part of the bot, is different, I feel that it would be inappropriate to continue with just the approval of the original version (and I would like feedback if I can do this better).

Here is the RegEx that I will use: the selection is with ((?<=(?<!\?)url ?= ?)|(?<=\[)|(?<=<ref>))(http:\/\/)?(www\.)?example\.com(?!\.) and the replacement is with https://$3example.com. The code for finding is identical to the original, but the replacement uses capture group #3, which is either www. or nothing, so that the www. is retained.

Credit to User:Lordtobi for saying how they would do it at User talk:DemonDays64#Removing www; this is very slightly modified from what they said to do.

Discussion

  • A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{tl|BAG assistance needed}}. — it's been almost 7 days, with no replies. I am not sure I'm doing this correctly and if I should have made/had to make this request in the first place, as this is just a request to be allowed to change the RegEx and get some other people to make sure it's good. Can someone please help? Thanks! DemonDays64 (talk) 23:26, 4 January 2020 (UTC) (please ping on reply)

Seppi333Bot 2

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

Time filed: 22:49, Thursday, December 19, 2019 (UTC)

Function overview: Create missing redirects from gene symbols to articles about the corresponding gene/protein and categorize them using {{R from gene symbol}}.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Python

Source code available: No. Not going to write it unless approved for trial.

Links to relevant discussions (where appropriate):

Edit period(s): One time run

Estimated number of pages affected: 2000 or 4000, give or take a few hundred (2000 if just the gene symbol redirects; 4000 if the parenthetically disambiguated redirects as well - see discussion below)

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: Create missing redirects from gene symbols to articles about the corresponding gene/protein and categorize them using {{R from gene symbol}}.

Discussion

{{BAGAssistanceNeeded}} Seppi333 (Insert ) 23:17, 19 December 2019 (UTC)

Give us a little bit to review before BAGAN tagging please. — xaosflux Talk 00:38, 20 December 2019 (UTC)
My bad; will wait next time. Seppi333 (Insert ) 01:13, 20 December 2019 (UTC)

It might be worth creating the corresponding set of parenthetically disambiguated " (gene)"-suffixed redirects (a la Wikipedia:Bots/Requests for approval/BogBot 3) along with the proposed set, though it's not quite as necessary. Doing so would double the number of redirects I'd need to create.
Wondering what others think; @Boghog: you in particular. Seppi333 (Insert ) 03:30, 24 December 2019 (UTC)

The justification for the parenthetical redirects was very clear: provide an unambiguous mechanism for locating Gene Wiki articles. Most of these redirects have already been created. Hence it would very useful to provide redirects for the newly created articles and update redirects for the rare cases where the official gene has changed. The redirects provide an efficient mechanism to find Gene Wiki articles. Why is necessary to create and maintain lists of tens of thousands of genes? Who is going to use these lists and for what purpose? Boghog (talk) 15:08, 24 December 2019 (UTC)
Hmm; I don't think it's that rare TBH; I saw around half a dozen gene symbols change when I updated those gene lists today. That said, the gene lists aren't relevant to this task in any way; I'm just proposing the creation of redirects. But, to answer your questions, it's not any more or less necessary than creating and maintaining any other article on Wikipedia. I do it voluntarily because I know there are some who would find it useful/interesting for the same reason I do. I suspect that people who would "use" these lists are readers who are interested in human genes. The alternative is HGNC's gene browser which cuts off the list at 1000 entries and utilizes such an excessive amount of pagination so as to render the viewer relatively useless. As for the purpose, I can't say; I only know what I used it for. But, for what purpose would any of the other lists in lists of human genes be used for that matter? Seppi333 (Insert ) 18:44, 24 December 2019 (UTC)

Been about a month, so... A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{tl|BAG assistance needed}}.. Seppi333 (Insert ) 05:26, 18 January 2020 (UTC)

ST47ProxyBot

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

Time filed: 07:33, Sunday, December 1, 2019 (UTC)

Function overview: Block IP addresses belonging to open proxies, public VPN services, and web hosts.

Automatic, Supervised, or Manual: Automatic

Programming language(s): Combination of Python and Perl

Source code available: No, to protect sources and testing methods. Mostly uses pywikibot to interact with the wiki.

Links to relevant discussions (where appropriate): WP:NOP authorizes open proxies to be blocked, Wikipedia:Bots/Requests for approval/ProcseeBot demonstrates that a bot may be used for this task.

Edit period(s): Continuously

Estimated number of pages affected: Initially a higher rate due to a large number of not-currently-blocked proxies, once it reaches steady state, probably about 100 logged actions per day.

Namespace(s): None

Exclusion compliant (Yes/No): No, not applicable

Adminbot (Yes/No): Yes

Function details: WP:NOP states that open proxies may be blocked at any time. Open proxies allow editors to evade blocks, avoid detection, or appear to be multiple users when they were actually only one person. Waiting until these proxies are abused is not practical, as multiple easily-searchable websites advertise thousands of such proxies. The number of blocks to be made is high enough that automation is required.

There is already a bot approved for this task. However, it is beneficial to have multiple independent tools. There are a large number of data sources out there, and I've already been able to find a number of proxies that I can access, but which haven't been blocked. I'm sure others can find things that I can't. Since this involves trying to test the proxies, operators in different geographical areas or homed to different ISPs may have different views on the internet, one ISP may "blackhole" a network that hosts a lot of malicious proxies while another ISP may not, or one bot might have an outage of some sort while another is still running normally.

This bot makes three types of blocks:

  1. Open (HTTP/HTTPS/SOCKS) proxies, tested by accessing Wikipedia through the proxy
  2. Open VPN servers, verified by at least two data sources
  3. IP ranges used for web hosting, cloud services, etc, manually reviewed and curated

In the first two cases, it uses open sources to build a list of IP addresses, which it scans through. For proxy types that can be automatically tested, the bot attempts to access the Userinfo API. VPN testing cannot easily be automated, so instead the bot performs checks against several independent sources to determine if the IP address is a VPN node or not. The original proxy list is the first source, and the bot requires positive responses from at least two more sources before blocking. Once the bot has either successfully accessed API:Userinfo through the proxy or verified the proxy against enough independent data sources, it adds the IP to a list to be blocked.

The block duration varies based on the number of previous proxy blocks of that IP address. Currently, the first block is set for 14 days, ramping up to 2 years after enough blocks. The block is set to account-creation-blocked with anon-only unselected. I.e., this is a hardblock. The block message uses {{blocked proxy}} with a comment providing enough information for me to investigate why the IP was blocked in case there is any question. If the IP is already blocked, the bot skips it. This includes if it is already subject to a local rangeblock. The bot does not check global blocks. If the proxy is an IPv6 IP, the bot blocks the /64 range.

In the case of web hosting IP ranges, these are ranges that I identify through whois data and other sources as belonging to web hosting or other similar types of companies. I generally find an address that is being abused, usually by a spambot, and then investigate and block the entire address space assigned to web hosting at that company. In this case, I manually review the list of ranges to be blocked, and the bot blocks them for a fixed time period, generally using the {{colocationwebhost}} template, and a description of the IP ownership in the block comment. This task will never be fully automated, as it is based on me finding and deciding to block a given set of IP ranges. However, I'm bundling it with this bot request because it also entails making a large number of blocks at once.

Further, this bot may modify blocks that it initially issued, either extending them if they are near expiration and the proxy is still active, or removing them if the proxy is confirmed to be inactive. (The removal would only be after several checks in a row, over a period of time, confirm that the proxy isn't active, and this isn't currently implemented.) ST47 (talk) 07:33, 1 December 2019 (UTC)


Discussion

To which degree does this task overlap with that of User:ProcseeBot? Also, summoning their botop slakr here. Jo-Jo Eumerus (talk) 11:35, 1 December 2019 (UTC)
  • @Jo-Jo Eumerus: Same objective, but I am finding a large number of proxies that are not currently blocked, and that need to be. Possibly because I'm using different data sources or different testing methods. ST47 (talk) 18:32, 1 December 2019 (UTC)
What mechanism do you have in place to prevent wheel warring, especially with human admins? — xaosflux Talk 14:17, 1 December 2019 (UTC)
  • @Xaosflux: I will add a check that it will not block any IP address that has ever been unblocked by a human admin. Instead it will log those to a file or to userspace. ST47 (talk) 18:32, 1 December 2019 (UTC)
Does this bot support IPv6? SQLQuery me! 16:12, 1 December 2019 (UTC)
Also, as far as the major compute services (amazon, azure, google) - how are you identifying these? SQLQuery me! 16:14, 1 December 2019 (UTC)
  • @SQL: It does support IPv6, and blocks the /64 of detected IPv6 proxies. There is no special handling for the major compute services. Most of them are already blocked, if a blocked IP (including via a range block) shows up on one of the proxy lists, I currently don't even bother testing it, no point since it's already blocked. (For the ancillary task of blocking web hosting types of IP ranges, that would be through manual review of the whois information. Basically, if I CU a spambot and find that it's on some minor cloud services company's IP range, I run it through ISP rangefinder, review the netblock names, and block everything that looks webhost-y. The only automation for those is to save me from clicking the block button 100 times.) ST47 (talk) 18:32, 1 December 2019 (UTC)
    ST47, It is often not the case that the major providers are already blocked. Amazon, and azure get new ranges all the time, see: User:SQL/Non-blocked compute hosts. I've always used [1] to detect azure, and [2] to detect amazon. Google is a bit more complicated. SQLQuery me! 18:39, 1 December 2019 (UTC)
@SQL: What would you suggest doing with this information? Refrain from blocking proxy IPs within that range, or block the entire range? ST47 (talk) 19:14, 1 December 2019 (UTC)
ST47, I normally completely block those ranges by hand, It can be a bit tedious / tiresome. They're webhosts, and very commonly used by spammers / UPE. SQLQuery me! 21:02, 1 December 2019 (UTC)
@SQL: Right, I guess my point is that if that range isn't blocked yet, it's still good to directly block any proxies within that range. (Hopefully, that range won't be unblocked for more than a couple of days, and once the range does get blocked, the bots will stop scanning it for proxies, and the short initial block will eventually expire, leaving the long-term rangeblock.) Improving the automation around detecting (and hopefully eventually blocking and unblocking) hosting ranges is important, but isn't this bot request's objective. ST47 (talk) 21:26, 1 December 2019 (UTC)
Fair enough, I thought that this would fall under point 3, IP ranges used for web hosting, cloud services, etc, manually reviewed and curated. SQLQuery me! 22:10, 1 December 2019 (UTC)
That's intended to cover cases when I checkuser a spambot, find some huge webhosting range, run it through ISP rangefinder and decide to block the whole darn thing. Or for another example, based on this experimental product, I found these guys. There are over 1,000 individually blocked proxy IPs in that AS. Some of the ranges in ISP Rangefinder I wasn't sure about, and left unblocked. But still, the 81 ranges that I did block, I think should be done with a bot account - it's assisted rather than automatic, but doing it with my normal account just floods my block log. ST47 (talk) 22:35, 1 December 2019 (UTC)
  • What authentication mechanism do you plan to use for this bot? Do you plan to secure the account with 2FA? — xaosflux Talk 18:19, 1 December 2019 (UTC)
    • @Xaosflux: BotPasswords with only the necessary permissions granted, and obviously a strong unique password on the main account. I don't currently use the beta 2FA extension, preferring instead to use strong random passwords which are only used for a single account on a single website. ST47 (talk) 18:32, 1 December 2019 (UTC)
  • How are you going to avoid wheeling with User:ProcseeBot which it appears uses different block lengths than your proposal. We really don't need that bot coming around and blocking for one period, then you coming around and blocking for a different period. — xaosflux Talk 18:41, 1 December 2019 (UTC)
    • @Xaosflux: I don't really see what would be wheeling about that. If an IP is already blocked, neither this bot not ProcseeBot would change the block duration. If an IP isn't currently blocked, then whichever bot or human admin gets around to it first would choose a block duration. ST47 (talk) 19:05, 1 December 2019 (UTC)
      • @ST47: ok so if the other bot thinks a one year block is fine, your bot isn't going to go and change it to a 2 year? — xaosflux Talk 20:08, 1 December 2019 (UTC)
        • @Xaosflux: That is absolutely correct. If an IP is blocked, either directly or via a range block, this bot does not modify the block settings at all. ST47 (talk) 20:14, 1 December 2019 (UTC)
  • {{BAGAssistanceNeeded}} I know we like to leave these open for a while for comment, but there hasn't been any action in a while. It has already been advertised in several places including AN. Is a trial possible? ST47 (talk) 05:28, 3 January 2020 (UTC)
    @ST47: please build out a userpage at User:ST47ProxyBot that clearly explains what this bot will do, and what anyone who is blocked by it should do if they have issues with their block. — xaosflux Talk 15:15, 3 January 2020 (UTC)
    @Xaosflux: done. ST47 (talk) 20:22, 4 January 2020 (UTC)

Bots in a trial period

DannyS712 bot III 63

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

Time filed: 05:25, Wednesday, November 20, 2019 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Javascript

Source code available: https://github.com/DannyS712/bot/blob/master/redirect-patroller.js

Function overview: Automatically patrol redirects with the difference between the title and the target is using:

  • US vs U.S.
  • USA vs U.S.A.
  • & vs and
  • UK vs U.K.
  • FC vs F.C.
  • SC vs S.C.

Links to relevant discussions (where appropriate): Wikipedia talk:New pages patrol/Reviewers/Archive 34#Bot patrolled redirects

Edit period(s): Continuous

Estimated number of pages affected: Lots of pages patrolled

Exclusion compliant (Yes/No): No

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

Function details: Follow up on other tasks (see 1, 2, 3, and 4) to patrol more redirects uncontroversially.

Discussion

  • If possible, I'd like to request speedy approval, so I don't need to add separate logic for handling the trial, now that the bot task in run via cron. I believe that this task falls with Wikipedia:Bot Approvals Group/Guide#Trials's suggestion of If the task is completely non-controversial, such as extensions to tasks that have already been approved in the past, by an experienced coder in good standing, then the task can be speedily approved without a trial. and Wikipedia:Bot policy#Requests for approval's explanation of Non-controversial, technically-simple tasks or duplicates of existing tasks, especially if performed by trusted bot operators, can be speedily approved. Thanks, --DannyS712 (talk) 05:29, 20 November 2019 (UTC)
    Not a BAG member but that sounds like a reasonable request. Jo-Jo Eumerus (talk) 09:57, 20 November 2019 (UTC)
  • The abbreviation without dots being autopatrolled is a great idea! Maybe this could auto patrol United States -> U.S., United Kingdom -> U.K., etc., too? Keep up the good work! DemonDays64 | Tell me if I'm doing something wrong :P 02:24, 25 November 2019 (UTC)
    @DemonDays64: maybe, but that would be a future task DannyS712 (talk) 03:03, 25 November 2019 (UTC)
  • {{BAGAssistanceNeeded}} Thanks, --DannyS712 (talk) 05:37, 30 November 2019 (UTC)
  • Just to double-check, this task is for patrolling redirects where the only difference is punctuation? Primefac (talk) 15:13, 8 December 2019 (UTC)
    @Primefac: yes DannyS712 (talk) 20:27, 8 December 2019 (UTC)
  • {{BAGAssistanceNeeded}} cc @Primefac any updates? --DannyS712 (talk) 05:18, 19 December 2019 (UTC)
  • Approved for trial (5 days).. How does that sound, DannyS712? --TheSandDoctor Talk 10:21, 27 December 2019 (UTC)
    @TheSandDoctor: well, now that the task runs more frequently for the redirect whitelist, I'm not sure how to add the trial limit. Could the trial be for a specific number of days instead? DannyS712 (talk) 10:35, 27 December 2019 (UTC)
    @DannyS712: 5 days sound good? --TheSandDoctor Talk 20:43, 27 December 2019 (UTC)
    @TheSandDoctor: Sure. Completely forgot about this, coding now... DannyS712 (talk) 04:33, 18 January 2020 (UTC)
    Deployed DannyS712 (talk) 04:38, 18 January 2020 (UTC)
    First round: Special:Permalink/936337128 DannyS712 (talk) 05:15, 18 January 2020 (UTC)

Bots that have completed the trial period

MajavahBot

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

Time filed: 09:02, Saturday, November 23, 2019 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/supertassu/majavahbot

Function overview: This bot will patrol WP:EFFPR and automatically 1) add messages such as "User blocked" and "Private filter" from {{effp}}, 2) add or fix typos or formatting in filter title in reports and 3) archive old reports.

Links to relevant discussions (where appropriate): Wikipedia:Edit filter/Noticeboard#Bot idea for EFFP

Edit period(s): Continuous

Estimated number of pages affected: WP:EFFPR + archive page

Exclusion compliant (Yes/No): Yes

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

Function details: Using wikitech:EventStreams, the bot will listen to changes on the false positive page, and automatically clerks the reports. Some checks (filter private, task name) are only ran when a new report is added and some (archive, user blocked) are ran after every edit to the page.

About the archiving function: Similar to RFPP, the bot will maintain a rolling archive of 25 (configurable) last reports on a separate page. All reports older will be hidden in page histories. Reports will be archived based on when the last comment was posted, and comments posted on the report can be used to change the delay (for example, if {{effp|denied}} template is used, the report will be archived in 1h after the reply instead of 48h which is used as a default).

Discussion

I see that that noticeboard is currently archived by Lowercase sigmabot III. I am a little unsure what add or fix typos or formatting in filter title in reports means; can you clarify? Jo-Jo Eumerus (talk) 13:25, 23 November 2019 (UTC)
@Jo-Jo Eumerus: The noticeboard is currently archived by Sigmabot, however it isn't very great at the reports page (more reasoning in discussion linked above). The fixing filter title in reports means that if the user creating a report there either does not fill in title of the affected page at all or if there's an obvious mistake (capitalization in later chars or directly pasting in page URL instead of name) in the report, the bot will correct that. Regards, Majavah (t/c) 14:03, 23 November 2019 (UTC) (typo fixed at 21:09, 23 November 2019 (UTC))
{{BAG assistance needed}} I'm requesting BAG assistance as it's been over a week since the last reply. Majavah (t/c) 08:06, 3 December 2019 (UTC)
Approved for trial (7 days). For this trial, have the bot make edits to a subpage in its user space; archives should go to another subpage. This way we can tell if the bot works without potentially messing with the main EFFPR page. Code looks good to me; interesting strategy to make a Pywikibot wrapper. The field self.open in database.py looks a bit suspicious to me, but it'll probably be fine. Thank you for writing this bot! Enterprisey (talk!) 18:17, 3 December 2019 (UTC)
Great, I'll start the trial at tomorrow as I'm having some issues with Toolforge's job engine (most likely user error). And yes, self.open in database.py is really hacky, however it works(TM) and it does not keep a database connection open when not necessary to comply with replica database guidelines on wikitech. --Majavah (t/c) 19:12, 3 December 2019 (UTC)
Majavah, good to hear. And one more thing: the bot's configuration page, being currently semi-protected, is of course editable by any autoconfirmed user. That's not ideal, so it should be moved to a JSON contentmodel (ie the page title should end in .json) so that only the bot account (and interface admins) can edit it. Enterprisey (talk!) 00:32, 4 December 2019 (UTC)
@Enterprisey: Note: any admin can edit user json pages. Also, moving it to a .json page wouldn't change the content model; it would need to be recreated DannyS712 (talk) 01:45, 4 December 2019 (UTC)
I've corrected my comment (thanks for pointing that out), and yeah, I'll change the content model when it gets moved. Enterprisey (talk!) 02:14, 4 December 2019 (UTC)
@Enterprisey: which would mean that the bot op cannot edit the config - maybe ecp protection? DannyS712 (talk) 02:23, 4 December 2019 (UTC)
The bot op could still log in using the bot account. Alternatively, and this is probably a better idea, the bot op could put it in their own userspace. Enterprisey (talk!) 02:27, 4 December 2019 (UTC)
@Enterprisey and DannyS712: This was discussed on the edit filter noticeboard (Wikipedia:Edit_filter_noticeboard#Bot_idea_for_EFFP), and it was agreed that it should be possible for at least edit filter managers to adjust the config without bugging me. Majavah (t/c) 07:07, 4 December 2019 (UTC)
Also, I've started the trial, and on the database it's marked to end at 2019-12-11 07:27:28 UTC. Majavah (t/c) 07:53, 4 December 2019 (UTC)
Trial complete. I fixed a few edge cases in the beginning. Majavah (t/c) 17:59, 11 December 2019 (UTC)
Will get to reading through the contribs in the next few days; sorry for the delay. Enterprisey (talk!) 06:47, 19 December 2019 (UTC)
Symbol tick plus blue.svg Approved for extended trial (50 edits or 30 days). I see the bot's made five edits to the report page (and two to the archive) all of which look good. Bugs - if any - are more likely to show up with a slightly longer run that includes more edits, so approved for a trial of 50 edits or 30 days, whichever comes first. This is just me being a little cautious because the bot will be editing alongside humans (especially new users & IPs). Very sorry for the extended delay; my schedule has taken a turn for the better, so I expect to be much more responsive this year. Enterprisey (talk!) 07:00, 2 January 2020 (UTC)
Also, for the trial, it would be nice if you would run the bot on the live EFFPR content (so it would get the actual reports), but instead of saving the page to EFFPR it would save to the trial page you've created. Enterprisey (talk!) 07:03, 2 January 2020 (UTC)
@Enterprisey: By "run the bot on the live EFFPR content (so it would get the actual reports), but instead of saving the page to EFFPR it would save to the trial page you've created", do you mean that the bot will listen on changes on the actual page but save (not read) to the test page? Majavah (t/c) 09:41, 2 January 2020 (UTC)
Majavah, yes, precisely. Enterprisey (talk!) 06:48, 5 January 2020 (UTC)
Great, thanks. I've started the trial, it will write to User:MajavahBot/EFFP Helper Test/Report page and archive to User:MajavahBot/EFFP Helper Test/Rolling archive page. Majavah (t/c) 10:14, 5 January 2020 (UTC)
Trial complete.. The bot got confused a couple of times because some threads were present both in the archive and on EFFPR. Majavah (t/c) 14:53, 7 January 2020 (UTC)
Ok, I've been reading through the bot's edits. Some notes:
  • Just looking at the very final edit made by the bot, it looks like the "pagenameadded" message was inserted even though the page title in the original seemed to be there. I don't immediately see anything wrong with the code (i.e. the specified config's regex seems to have a match in the original report). Feel free to keep testing in the bot's userspace as much as you want, since BOTPOL says nothing about that.
  • Actually, the "add missing page" seemed to work pretty well here (compare original), so great job with that.
  • The code seems to assume that reports were always made on the reporter's most recent flagged edit. Probably a reasonable assumption.
  • 1 hour for archives seems pretty short. The test report page was much shorter than EFFPR - in fact, the test report page seemed to contain at most one report most of the time. Might be a bug. I feel like the humans working on EFFPR will be a bit surprised at first that the page got so much shorter; perhaps try to keep the length of the test report page about the same length as EFFPR? (this may require a really long archive length, I don't know)
  • The edit summaries are very long, and should be much shorter. I would suggest something like "archived X sections and modified Y sections", and/or the current status of the page (much like the summaries used by the AIV clerk bot).
I found the "add missing page" edit by searching the summaries for the string "task 1a". I haven't yet found an example of the other parts (detection of blocks or private filters) working. If you know for certain that they worked in a certain edit feel free to link them here.
Generally, great stuff so far, and please run the bot again for about 3-4 days or so (or 50 edits) once these issues are resolved one way or another. Enterprisey (talk!) 05:10, 10 January 2020 (UTC)
(and a ping: Majavah) Enterprisey (talk!) 05:11, 10 January 2020 (UTC)
I would support having easily configurable archiving times at Wikipedia:Edit_filter/False_positives/Reports/Archive_config or something. It will likely take some tweaking to find what is appropriate for each type of result which would be faster if anyone can modify it. ‑‑Trialpears (talk) 08:14, 10 January 2020 (UTC)
Hi folks, I'll be really busy the following weekend, but anyways I wanted to comment on your points:
  • I have no idea about that one edit adding page name when it's already there, so I'll do some investigative work.
  • The edit summaries are very long as it's "archiving" most reports on every edit. I'll condense them, even thru that will most likely not be a problem when it's reading and writing to same page.
  • Yes, the page is short, it's not a bug. EFFPR is not a busy noticeboard. Most reports are (with current config) kept for an hour or two after being handled, and personally I think old handled reports should not be kept there extended times.
  • Special:Diff/934238209 seems to be a case where a filter was private but it wasn't notified. Will investigate.
  • For blocked notices, there's a design issue: as the bot only edits after the page was edited by someone else, the user needs to be blocked before someone adds new report without a human adding blocked notice, I don't think that happened in this trial (I don't think there even was a blocked notice at all during that time)
  • For @Trialpears: there already is: User:MajavahBot/EFFP Helper Configuration
(also ping Enterprisey) Majavah (t/c) 14:54, 10 January 2020 (UTC)

PearBOT 6

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

Time filed: 02:03, Friday, December 20, 2019 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): AWB

Source code available:

Function overview: Remove confusing date parameter from taxapad citations.

Links to relevant discussions (where appropriate): Wikipedia:AutoWikiBrowser/Tasks#Taxapad

Edit period(s): One time run

Estimated number of pages affected: 3833

Exclusion compliant (Yes/No): Yes

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

Function details: The bot will look for a very specific string ("|date=1997–2012 |url=http://www.taxapad.com") and remove the date parameter. This should avoid any false positives. For the why see Wikipedia:AutoWikiBrowser/Tasks#Taxapad where Soap explains it better than I could.

Discussion

So is it a complete removal of the date or a replacement with "2012"? Primefac (talk) 17:55, 30 December 2019 (UTC)

Primefac, complete removal. Most items weren't added in 2012 making the date meaningless for most items, just the date when the website stopped updating. Also worth noting that the purpose of the date parameter is to disambiguate short form notations which isn't necessary since none of the affected pages use short form citations. ‑‑Trialpears (talk) 19:12, 30 December 2019 (UTC)
Approved for trial (33 edits). Primefac (talk) 02:04, 31 December 2019 (UTC)
Trial complete. 33 edits no issues. ‑‑Trialpears (talk) 16:31, 31 December 2019 (UTC)

I created most of those references when the Taxapad website went down and I used AWB to set up the archive links. Since each database entry has no date, I used the copyright date range in the pages' footer in the |date=. That's not a good date, but I figured it was better than none. I've no objection to the removal of the range. SchreiberBike | ⌨  04:09, 10 January 2020 (UTC)

Creffbot

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

Time filed: 01:45, Thursday, November 14, 2019 (UTC)

Automatic, Supervised, or Manual: automatic

Programming language(s): Python

Source code available: https://github.com/creffett/creffbot_wikipedia

Function overview: Maintain CAT:UAA by removing the template from users who have had the template applied for a long time and users who are blocked.

Links to relevant discussions (where appropriate): Wikipedia:Bot_requests#Feedback_request_-_bot_to_maintain_CAT:UAA_and_similar_categories

Edit period(s): daily

Estimated number of pages affected: currently 4,000 in the category

Exclusion compliant (Yes/No): Yes

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

Function details: creffbot will remove the category tag for users who have been tagged as having possible username issues and are either stale or blocked. Per the category's description, Accounts should be removed from this category when they have been indefinitely blocked, inactive for more than one week, or are clearly not violations of the username policy. My plan is to initially have the bot only run on users who have been inactive for more than one year during initial testing, and then move it up to one month during operations. The bot would run once daily. Note that User:AvicBot was approved for a similar task, but that was AWB rather than fully automated and AvicBot's human has been inactive for a while.

Rationale: currently, CAT:UAA isn't very useful to patrollers since it is clogged with very stale users. By pruning the category, it would be practical for patrollers to monitor the category.

Discussion

Two further notes:
  • I have tested the user-identifying capability successfully, but haven't tested the template-removal. I will test that in the bot's sandbox in the immediate future. I hope to have the bot ready for operational testing within the next day or two.
  • I will have the bot log its operations to a subpage of its userpage.
creffett (talk) 01:50, 14 November 2019 (UTC)
  • Useful task. Would make that category usable again. –xenotalk 14:17, 16 November 2019 (UTC)
  • Editing features tested, ready for limited operational testing. creffett (talk) 14:28, 16 November 2019 (UTC)
Approved for trial (10 edits). ns:23 only. — xaosflux Talk 15:21, 25 November 2019 (UTC)
Please include a link to your task (either a description on your bot userpage, or this BRFA) in your edit summaries. Mark edits as "minor". — xaosflux Talk 15:24, 25 November 2019 (UTC)
Xaosflux, isn't it ns:3 (User talk:)? ‑‑Trialpears (talk) 15:30, 25 November 2019 (UTC)
@Trialpears: ah ok, in that case reducing that trial to 10, since every case of this is going to trigger the "new messages" flag for these accounts while running without a bot flag. — xaosflux Talk 15:33, 25 November 2019 (UTC)
Y'all might consider adding this bot to MediaWiki:Echo-blacklist - if my understanding of the scope of that page is correct, listing the bot there will prevent it from generating messages. Jo-Jo Eumerus (talk) 22:06, 25 November 2019 (UTC)
@Jo-Jo Eumerus: that page only works for things like inline/summary notifications, not for directly editing a usertalk page. Once flagged as a bot, the account will gain access to 'nominornewtalk' permission that will suppress these. — xaosflux Talk 23:43, 25 November 2019 (UTC)
@Xaosflux: Test complete, no significant issues (it didn't log the first removal due to a syntax error in the logging function, the rest of the issues were just me realizing that a few log messages and edit summaries needed to have links added). Please have a look at the bot's actions at Special:Contributions/Creffbot at your convenience. For reference, I set the inactivity threshold to 1 year for testing, per my BRFA above I plan to move that down to one month after approval unless someone would prefer it be a different value. creffett (talk) 23:40, 25 November 2019 (UTC)
@Creffett: I'm not sure if a per-edit log-edit is needed for this task, will you need that to go live? — xaosflux Talk 23:46, 25 November 2019 (UTC)
Xaosflux, that's easy to remove. Will take care of that. creffett (talk) 23:47, 25 November 2019 (UTC)
All set, but I'll be traveling for the rest of the week so no test runs for a while. creffett (talk) 03:19, 27 November 2019 (UTC)
  • @Xeno: regarding the usefulness of the category, do you find that the task threshold above is appropriate for removals (~1 month)? — xaosflux Talk 23:46, 25 November 2019 (UTC)
    A month seems fine. I wonder if the removed names should be tracked for resumption of editing? –xenotalk 15:36, 27 November 2019 (UTC)
    Xeno, are you suggesting that editors who were removed would be re-added if they become active? I could do that, though I'd rather that be a separate BRFA so I can get this signed off. In the interim, I can compromise on logging (re xaosflux's comment above) - I'll batch the logging so that it only logs at the end of a run instead of logging after every removal. creffett (talk) 17:00, 27 November 2019 (UTC)
  • Creffett, looks like there are still 5 edits to go in the trial. Do you still want to proceed? Primefac (talk) 16:24, 8 December 2019 (UTC)
    Primefac, yeah, I would like to proceed with approval - I thought that that 10 was a max rather than expected number of edits, and I was satisfied with the bot's operation after those first five edits so I stopped early. creffett (talk) 17:12, 8 December 2019 (UTC)
    That's the expected number, so that any issues or bugs can potentially be worked out. Primefac (talk) 17:39, 8 December 2019 (UTC)
    Primefac, understood. I do have a couple tweaks that I'd like to make, so I'll go finish that off now. creffett (talk) 17:43, 8 December 2019 (UTC)
    Trial complete. Primefac okay, ran the other five edits in order to test out batched logging (and yes, I did run find a couple of bugs in the process...). Ready for review at your convenience. creffett (talk) 18:09, 8 December 2019 (UTC)

Qbugbot 4

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

Time filed: 21:25, Tuesday, September 24, 2019 (UTC)

Function overview: This will resolve self-redirect links in arthropod articles by replacing the redirect page with a new article when possible (around 76% of the time) or by de-linking the self-redirect link.

Automatic, Supervised, or Manual: Automatic

Programming language(s): vb.net

Source code available: Yes. I will update User:Qbugbot/source before the first test.

Links to relevant discussions (where appropriate): https://en.wikipedia.org/en/Wikipedia_talk:WikiProject_Tree_of_Life/Archive_44#Request_for_comment%2C_qBugbot_and_self-redirects

Edit period(s): 8-24 hours per day

Estimated number of pages affected: 5,500 max

Namespace(s): Mainspace

Exclusion compliant (Yes/No): Yes

Function details: I would like to use qBugbot to resolve some self-redirects in arthropod articles. For clarity, and because it confuses me, when page A links to page B, and page B is a redirect page pointing back to page A, I am saying that page A contains a self-redirect link to page B.

About 585 arthropod articles contain self-redirect links pointing to 5428 redirect pages, excluding links to article subsections.

Here is what I am proposing:

  • A self redirect link in a monotypic genus to its sole species will be de-linked in the genus page.
  • Other self-redirects to species will have the species articles created to replace the redirect.
  • Self-redirect links to genus pages will have an article created to replace the redirect page.
  • Self-redirects to tribes, subfamilies, superfamilies, and higher ranks will be de-linked in general, but some of these articles may be created by the bot after manual review.
  • Self-redirects to families will generally have the article created to replace the redirect, but these pages will be manually reviewed (113 cases).
  • Self-redirect links in Automatic Taxaboxes and Speciesboxes will not be handled by the bot.

New articles can be created for about 4147 of 5428 redirect pages. The other 1253 or so are questionable for one reason or another. For them, the self redirect links will be de-linked and the redirect pages left unchanged.

A list of articles with self-redirect links is on the Qbugbot talk page.

Discussion

{{BAG assistance needed}}

  • Approved for trial (50 edits). Seem to recall that this is a trusted op with a good handle on edits, but let's make sure there are no bugs (pun intended). Primefac (talk) 12:51, 12 October 2019 (UTC)
    Trial complete. No major problems were encountered. Most edits replaced redirect pages with new articles. One edit removed some links from an existing article, Acerella. I inadvertently did 51 edits instead of 50 due to a mental malfunction.
    In future runs, the bot will add WikiProject templates to talk pages of articles that replace redirect pages and do not already have the templates. (I forgot about that.) I'll add WikiProject templates to those pages in this trial run when the bot gets authorization. I didn't do it now because I'm not sure whether it would be considered additional edits.
    Bob Webster (talk) 16:25, 14 October 2019 (UTC)

{{BAG assistance needed}}

  • Hi Edibobb, could you quickly clarify this for me? "the bot will add WikiProject templates to talk pages of articles" is not mentioned anywhere else in this BRFA. Are you requesting to modify this BRFA or are you going to file another one or? --TheSandDoctor Talk 18:38, 26 October 2019 (UTC)
    When the bot creates an article, it also creates a talk page with something like in it. It occurred to me that this should also be done when an article replaces a redirect page. I had intended to do it now, as a slight modification (or clarification) to the BRFA, but if you think it would be better it's no problem to do this as a separate bot run. --Bob Webster (talk) 22:48, 26 October 2019 (UTC)

{{BAG assistance needed}}

@Edibobb: Do you have a list of diffs for review? Headbomb {t · c · p · b} 23:48, 1 November 2019 (UTC)
I just added one to the Qbugbot talk page. Bob Webster (talk) 06:36, 2 November 2019 (UTC)

Are we sure this is a good idea? I mean, this [3] doesn't contain any information beyond what the genus level Acerentomon article had. Headbomb {t · c · p · b} 17:30, 2 November 2019 (UTC)

It seems to me like the self-redirects should be eliminated either by un-linking the links to self-redirects or by replacing the redirect pages with stubs. Using the stubs does duplicate some information, but it also has some advantages:
  • In some cases some additional information is provided in the new stub, such as the distribution range in Acerentomon noseki, occasional photos, IUCN status, etc.
  • Replacing the self-redirects with stubs makes it easier for other editors to make more complete species pages.
  • It many cases, such as this one, the new articles have better references.
Bob Webster (talk) 18:28, 2 November 2019 (UTC)
A couple of other thoughts: the TOL discussion seemed in favor of this project, and about 1000 of the redirect pages are for Genus rank instead of Species.
Bob Webster (talk) 05:54, 3 November 2019 (UTC)

{{BAG assistance needed}}

I've been traveling a bit in the past week, any BAG member can feel free to pick up this, otherwise I'll look at it once I'm back home next week. Headbomb {t · c · p · b} 18:10, 9 November 2019 (UTC)
Headbomb Is there anything I can do to speed the approval process? Bob Webster (talk) 20:30, 22 November 2019 (UTC)
@Edibobb: Can you provide a bit more information about what sources will be used for the created stubs? During previous runs of Qbugbot, there was some dissatisfaction with the references and further reading entries. Take [4] for example. It references Catalog of Life, ITIS, and World Spider Catalog, although Catalog of Life and ITIS get all of their spider data from World Spider Catalog, and are thus completely redundant. Also, BugGuide is a self-published (or community-published source), similar to Wikipedia, and probably doesn't qualify as a reliable source. Finally, only 1 of the 8 sources listed in the Further reading section have any mention of the topic species whatsoever. They seem to be related to the genus and family, not the species. I'm hoping that some of these issues can be fixed before we do the full run (if they haven't already been fixed). Kaldari (talk) 05:59, 4 December 2019 (UTC)
The references in Qbugbot were overhauled before the previous run (Qbugbut3), both in format and inclusion criteria. The result is far fewer references in "Further reading" and somewhat fewer references in "References", as well as more accurate and consistent references.
One of the main reasons for Qbugbot3 was to update the references from the previous run. In fact, the page you referred to is a good example. Your link goes the page originally created by Qbugbot in May, 2018. Last September, the page was updated by Qbugbot. The Catalogue of Life reference was removed. Six of the eight "Further reading" references were removed. There is one left that doesn't include specific information on the species, but I think it's worth including for the species of this genus.
World Spider Catalog and several "Species File" sites are used as references, when applicable, because they are the most complete and up-to-date authorities in their areas.
ITIS is used as a reference if it contains information about the article subject, because the distribution range, common names, synonyms, minor ranks, and other information are often obtained there.
GBIF is used as a reference if it contains information about the article subject, because it is the most complete and accurate general taxonomic reference. Even so, it can be a little out of date sometimes and has limited data for animals from some parts of the world.
Bugguide is used for a reference if it contains information about the article subject, because it usually has relevant information and photos not included in the Wikipedia article, supports the information in the Wikipedia article, and provides additional references.
Encyclopedia of Life is no longer used as a reference by Qbugbot. Catalogue of Life is not normally used as a reference because it rarely includes information not found in ITIS or GBIF.
ITIS, Bugguide, and Species File sites include ranks such as Tribe, Subfamily, Superfamily, and Suborder in their taxonomy. GBIF and World Spider Catalog do not.
Bugguide is published by Iowa State University. The species pages referred to by Qbugbot are created and maintained only by qualified editors, not by the community at large. GBIF.org now uses Bugguide as a source. There are more than 37,000 pages on en.wikipedia that refer to bugguide.
Bob Webster (talk) 16:08, 4 December 2019 (UTC)
@Edibobb: Thanks for the detailed reply! I'm glad to hear that most of these issues have been fixed! I'm also glad to hear that you aren't using Encyclopedia of Life and Catalog of Life as sources anymore as they are basically just tertiary sources that aggregate other sources. I'm still a bit skeptical of citing BugGuide (probably because I'm an editor there myself), but it's probably borderline enough to pass. Thanks for your hard work on this. Kaldari (talk) 19:31, 4 December 2019 (UTC)

I'm busier than expected, but I hope to be reviewing this by the end of the week. Any other BAG member can feel free to step in though. Headbomb {t · c · p · b} 21:52, 4 December 2019 (UTC)

@Edibobb: I notice these sort of follow up edits [5]. Could the bot handle those from the get go? Headbomb {t · c · p · b} 22:11, 4 December 2019 (UTC)

I've looked at that in the past. It would be easy enough to do, but I have not been able to find the categories to use. For example, should it be "Animals described in", "Insects described in", "Beetles described in", or "Scarabs described in"? It was discussed once in TOL, and at that time there wasn't a good way to determine the categories. Bob Webster (talk) 23:33, 4 December 2019 (UTC)
What about creating a new Category:Arthropods discovered in ... category three, of which the above could be subcategories of? Headbomb {t · c · p · b} 00:14, 5 December 2019 (UTC)
I looked into this. About a year ago (and maybe other times) a bunch of the "described in" categories were removed. Now the bot only needs to handle Animals, Crustaceans, Spiders, Insects, Beetles, Moths, and Butterflies. I've added it to Qbugbot. Bob Webster (talk) 04:55, 5 December 2019 (UTC)
Let's do another Symbol tick plus blue.svg Approved for extended trial (10 edits).. Please notify the bug/entomology project and ask to comment on the addition of categories. Headbomb {t · c · p · b} 01:05, 6 December 2019 (UTC)
Trial complete.
I found no problems. For new articles that replace redirects, I added a talk page and the categories "Articles created by Qbugbot" and "Insects (or whatever) described in 1926 (or whenever)". There has been no response in the TOL project on the question of the "described in" categories, but the "Animals described in" category includes the ones I mentioned, and no other arthropods.
Here are the diff links:
Bob Webster (talk) 19:22, 7 December 2019 (UTC)

{{BAG assistance needed}}

@Edibobb: link to TOL discussion? Headbomb {t · c · p · b} 04:56, 14 December 2019 (UTC)
Here it is: TOL Bob Webster (talk) 16:24, 14 December 2019 (UTC)

A user has requested the attention of a member of the Bot Approvals Group. Once assistance has been rendered, please deactivate this tag by replacing it with {{tl|BAG assistance needed}}. Bob Webster (talk) 04:34, 21 December 2019 (UTC)


Approved requests

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


Denied requests

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

Expired/withdrawn requests

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