Wikipedia:Bot Approvals Group/Guide: Difference between revisions

order
(order)
 
Welcome [[WP:BAG|BAG Members]]! This is a small guide for common BAG-related tasks and how to best perform them. It also includes a few other useful resources.
 
==Guide to BRFAs==
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 '''[[WP:BOTREQUIRE|technical soundness]]''' of the proposed bot, and ensure that the requested task has '''[[WP:CONSENSUS|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 [[WP:VP|Village Pump]], or a relevant [[WP:PROJ|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 [[WP:SILENCE|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 both for the community to have a chance to review a proposed bot's behaviour, suggest improvements, voice opposition, point out issues, discuss the scope of its task, and to [[WP:SILENCE|break silence]]. Once technical soundness and consensus are satisfied, bot tasks can be approved. If a new bot requires a [[WP:BOTFLAG|bot flag]], ping a [[Wikipedia:Bureaucrats#Current bureaucrats|bureaucrat]] to request it.
 
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===
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 [[Sorites paradox|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'').
 
{|class="wikitable"
! 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 case]]s in tasks that affect a very large number of pages with (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===
Once a BRFA has run its course, BAG members should close it in one of the following manners.
{|class="wikitable"
! width=200 | Result
! When to use
|-
| {{BotSpeedy}}
| 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.
|-
| {{BotApproved}}
| If the task is technically sound, and has consensus, and no major concerns remain, the task can be '''approved'''.
|-
| {{BotExpired}}
| 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 {{tl|Operator assistance needed}}) to see if the operator replies.
|-
| {{BotWithdrawn}}
| 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.
|-
| {{BotDenied}}
| 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 [[WP:CIVIL|civil]] and [[WP:BITE|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.
|-
| {{BotRevoked}}
| In the case where [[WP:CCC|consensus has changed]], approval of a task may be marked as '''revoked'''. The reason for revocation should be made clear, in a [[WP:CIVIL|civil]] and [[WP:BITE|constructive]] way, and the bot operator notified. You may also feel a notice is warranted on talk page of a bot with high community engagement, such as [[User:Citation bot]] or [[User:AAlertBot]].
|}
 
==Pages to watch==
| '''Tech News''', a weekly newsletter covering "recent software changes likely to impact Wikimedians". You can subscribe [[meta:Global message delivery/Targets/Tech ambassadors|here]].
|-
|}
 
==Guide to BRFAs==
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 '''[[WP:BOTREQUIRE|technical soundness]]''' of the proposed bot, and ensure that the requested task has '''[[WP:CONSENSUS|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 [[WP:VP|Village Pump]], or a relevant [[WP:PROJ|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 [[WP:SILENCE|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 both for the community to have a chance to review a proposed bot's behaviour, suggest improvements, voice opposition, point out issues, discuss the scope of its task, and to [[WP:SILENCE|break silence]]. Once technical soundness and consensus are satisfied, bot tasks can be approved. If a new bot requires a [[WP:BOTFLAG|bot flag]], ping a [[Wikipedia:Bureaucrats#Current bureaucrats|bureaucrat]] to request it.
 
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===
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 [[Sorites paradox|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'').
 
{|class="wikitable"
! 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 case]]s in tasks that affect a very large number of pages with (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===
Once a BRFA has run its course, BAG members should close it in one of the following manners.
{|class="wikitable"
! width=200 | Result
! When to use
|-
| {{BotSpeedy}}
| 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.
|-
| {{BotApproved}}
| If the task is technically sound, and has consensus, and no major concerns remain, the task can be '''approved'''.
|-
| {{BotExpired}}
| 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 {{tl|Operator assistance needed}}) to see if the operator replies.
|-
| {{BotWithdrawn}}
| 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.
|-
| {{BotDenied}}
| 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 [[WP:CIVIL|civil]] and [[WP:BITE|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.
|-
| {{BotRevoked}}
| In the case where [[WP:CCC|consensus has changed]], approval of a task may be marked as '''revoked'''. The reason for revocation should be made clear, in a [[WP:CIVIL|civil]] and [[WP:BITE|constructive]] way, and the bot operator notified. You may also feel a notice is warranted on talk page of a bot with high community engagement, such as [[User:Citation bot]] or [[User:AAlertBot]].
|}