Wikipedia:Bot Approvals Group/Guide
 | This is an information page. It is not an encyclopedic article, nor one of Wikipedia's policies or guidelines; rather, its purpose is to explain certain aspects of Wikipedia's norms, customs, technicalities, or practices. It may reflect differing levels of consensus and vetting. |
 | This page in a nutshell: This page documents the common tasks and duties of the BAG, as well as useful resources to BAG members. |
Welcome BAG Members (and people interested in the inner workings of the BAG)! This is a small guide for common BAG-related tasks and duties, and how to best perform them. It also includes a few other useful resources.
Guide to BRFAs
[edit]BAG members are expected to use sound judgement and take the full situation and background of every BRFA into account. Precedent can be used to inform judgment, but should never be used as a hammer. Each BRFA requires BAG members to determine both the technical soundness of the proposed bot, and ensure that the requested task has consensus. The more contentious a task, the higher the burden of demonstrating consensus. Non-controversial and technically straightforward tasks may be approved after short trials, while more contentious and technically complex tasks may require formal and well-advertised RFCs accompanied by long trial periods. Typical places to hold such discussions are at the Village Pump, or a relevant WikiProject, but other locations may be suitable as well depending on the nature of the bot task. When in doubt, ask for more community input.
If consensus has been demonstrated, is likely to form, or can reasonably be presumed, BAG members have the discretion to allow the proposed bot to undergo trial to judge its technical soundness. Trials can also be used to help determine consensus if relevant communities have been notified, but failed to engage in dialogue after a reasonable amount of time has elapsed. Bot trials exist so the community has a chance to review a proposed bot's behaviour, suggest improvements, voice opposition, point out issues, discuss the scope of its task, and to break silence. Once technical soundness and consensus are satisfied, bot tasks can be approved. If a new bot requires a bot flag, a bureaucrat will apply the flag after the BRFA is added to Wikipedia:Bots/Requests for approval/Approved.
Typically, a BAG member will oversee a BRFA from trial to closure, and invite (or mandate) involvement from the community. Other BAG members will often participate and comment during the BRFA to give their opinions on various matters, but defer to the trial-granter for closure. This is not an official rule, but more of a recognition that whoever approves a bot for trial is usually more familiar with the background of the task, and has implicitly agreed to review the bot's edit and follow up on any issues raised during the trial. If a BAG member is unable to finish the review, or is unsure on how to proceed, they should leave a note at WT:BAG so others can help.
To ensure the impartial reviews of BRFAs, BAG members should not oversee the process for their own bots, or in other BRFAs where impartiality would be compromised. Such involved BAG members can still participate and comment on the task, however.
Trials
[edit]This is a general overview of the broad categories of trials that are typically granted by BAG members. These do not not constitute 'official types', and when exactly a 'short' trial becomes a 'long' trial is best left to philosophers. In practice, BAG members simply state the specific length and conditions of a trial (Approved for trial, 50 edits), rather than the trial type (Approved for a short trial) with the {{BotTrial}}/{{BotExtendedTrial}} templates.
Additional conditions on trials can always be specified. In particular, a BRFA with multiple subtasks should demonstrate technical soundness and consensus for all subtasks during the trial. BAG members may require the trial to have a specific number of edits for each substask, or require a trial with enough edits that each substask is demonstrated.
| Types | When to use |
|---|---|
| No trial | This should only be done for completely non-controversial extensions to tasks that have already been approved in the past, by an experienced coder in good standing. This is also known as a speedy approval. |
| Short | Most BRFA will have a typical trial length between 10 and 100 edits or 3 to 7 days. This is to be used for non-controversial and technically straightforward tasks, to prove that the bot is both technically sound and works as intended. |
| Long | Long trials typically are anywhere between 100 and 1000 edits or 7 to 30 days. These are typically granted when the task is technically tricky and a large number of edits need to be reviewed before the bot can be considered sound. They can also be granted to allow for more bystanders to give their feedback once they see the bot editing an article on their watchlist. |
| Ramp up | A ramp up trial is similar to a long trial, except with mandated pauses between editing sprees. For instance a bot could be approved for 500 edits (50 edits/day) or 2500 edits (250 edits/day). The main use of a ramp-up trial is to give time for bystanders to participate in the discussion in the case of a presumed or tentative consensus that could prove to be controversial, but also as extra safety against corner cases in tasks that affect a very large number of pages (10,000+). |
| Extended | An extended trial is an additional trial that follows a previous trial. These are usually done to confirm issues flagged in a previous trials have been corrected, and can be of any duration. A bot may be subject to multiple extended trials. |
Closures
[edit]Once a BRFA has run its course, BAG members should close it in one of the following manners. See {{Bot Top}}/{{Bot Bottom}} and User:SQL/How to close a BRFA for the technical details.
| Result | When to use |
|---|---|
 Speedily Approved.
|
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. |
 Approved.
|
If the task is technically sound, has consensus, and no major concerns remain, the task can be approved. |
 Request Expired.
|
If the bot operator has become unresponsive or inactive, the BRFA should be marked as expired. The operator can re-open the request at a later time. Typical waiting time is 2 to 4 weeks. BAG should usually contact the operator (usually using {{Operator assistance needed}}) to see if the operator replies. |
 Withdrawn by operator.
|
If the bot operator withdraws the request, the BRFA should be marked as withdrawn. Those usually happen when the operator agrees that the task is bad, needs time to flesh out the idea, or find themselves unable to fulfill the task for one reason or another. The operator may re-open the request later, especially if the BRFA is withdrawn because of time commitment. Tasks that go back to the drawing board should typically be filed as new BRFAs. |
 Denied.
|
If the task is technically unsound, consensus is unclear (or clearly against the task), or some major concerns remain, the task should be denied. The reason for denying approval should be made clear, in a civil and constructive way. If the idea has potential, the operator should be invited to flesh out the idea with the community and re-submit the task later. |
 Revoked.
|
In the case where consensus has changed, approval of a task may be marked as revoked. The reason for revocation should be made clear, in a civil and constructive way, and the bot operator notified. You may also feel a notice is warranted on the talk page of a bot with high community engagement, such as User:Citation bot or User:AAlertBot. |
Pages to watch
[edit]Bot-focused
[edit]These pages are directly related to BAG's mandate, and every active BAG member should watch them.
| Page | Description |
|---|---|
| WP:BAG | Describes the role of the Bot Approvals Group, with a list of current and former members. Few discussions take place there, but you should watch the page in case BAG's role changes. The talk page serves as a general discussion board for BAG matters. |
| WP:BOTS | Describes the role of bots on Wikipedia. Serves mostly as an overview page. |
| WP:BOTPOL | Wikipedia's Bot Policy. All BAG members should know this page like the back of their hand. Many discussions and requests for clarification affecting several bots take place on the talk page. |
| WP:BOTN | The Bots Noticeboard. Many discussions and requests for clarification affecting specific bots take place there. |
| WP:BRFA | (Bot) Requests for Approval, a list of all active BRFAs. BAG members have the mandate of reviewing BRFAs and determine both the technical soundness of the proposed bot, and ensure that the requested task has consensus. |
| WP:BAG/Status | A summary of all active BRFAs, updated several times a day. It is transcluded at the top of the BRFA page if you would rather not receive watchlist notices every time it updates. |
| WP:BOTREQ | A place for users to make Bot Requests. This is a place where BAG can provide early feedback on whether or not something something should be done, how it can be done, or who could possibly do it. Pinging bot operators who did similar tasks before for their feedback is a good idea. Being involved here can save many coding hours, a lot of frustration, and reduce the number of bot requests that go unaddressed. |
| WP:BOTNEWS | The Bots Newsletter. Sent infrequently. You can subscribe at Wikipedia:Bots/Spam. |
| #wikipedia-en-bag | The official BAG IRC Channel on Libera Chat. BAG members are voiced. It serves as a less formal alternative to WT:BAG or WP:BON. |
Bot-related
[edit]These pages sometimes have issues related to BAG's mandate, or of interest to the bot community. If you notice something bot-related in need of attention from the BAG and/or bot operators, please post a notice at WT:BAG and/or WP:BON. While BAG duties differ from Administrator duties, members are expected to give advice on bot-related matters and to help mediate situations.
| Page | Description |
|---|---|
| WP:ANI | The Administrator's Noticeboard for Incidents. Several bot issues can be reported there. The usual requests are to block malfunctioning or rogue bots. In many ways, BAG's job is to prevent thing from going there in the first place (see the quote in WP:BOTAPPROVAL). |
| WP:VPT | The Village Pump, Technical Division. Several technical issues are discussed there, many related to bots. |
| WP:A/C | The Arbitration Committee Proceedings. A summary of Wikipedia's most contentious disputes. Occasionally involves bots. When things get there, BAG ought to take a deep look at how exactly that happened. |
| WP:GADGETS | Gadgets, Scripts, User Scripts, and Tools will often facilitate bot-like editing, or deal with tedious tasks. They can often be alternatives to bots that don't required full BRFAs. BAG Members should be familiar with what is out there, if only so people don't spend time coding bots for tasks that don't require them. |
| WP:SCRIPTS | |
| WP:USCRIPTS | |
| WP:TOOLS | |
| meta:Tech/News | Tech News, a weekly newsletter covering "recent software changes likely to impact Wikimedians". You can subscribe here. |