Wikipedia talk:Bot Approvals Group

Active discussions
  (Redirected from Wikipedia talk:BAG)

Requests for BAG membershipEdit

Requests to join the Bot Approvals Group are currently made here, although other methods have been proposed. Users wishing to join BAG, or to nominate another user to become a member, should start a new nomination page via the form below (replacing "UserName" with the nominee's) and transclude the discussion in a section below. Please note that notification to WP:AN, WP:VPM, WT:BOT, and WP:BON is required. After a suitable length of time (usually one week unless the nomination has not received a reasonable level of support), the discussion will be closed by a bureaucrat.


BAG Nomination: ProcrastinatingReaderEdit

Hi everyone! Since I often see the BAG overloaded, and it's not unusual for requests to wait a long time for action, I'd like to volunteer myself to help keep BRFA flowing. It's important work and I feel I'd be good at it, so here I am.

I understand a BAG member needs two key qualities: the technical expertise to judge the soundness of a bot, and a good understanding of community norms and the bot policy to evaluate the consensus for one.

For the technical part, most of my on-wiki activity is in the areas of bots and templates. I've been through BRFA half a dozen times with my bot, and off-wiki have a CS background. I'm also familiar with most of the common programming languages used to develop bots. For the latter, I've been active in helping out at BRFAs and WP:BOTREQ in the past few months, providing gentle advice and picking out possible issues. I'm also used to evaluating consensus when patrolling TPERs, closing TfDs (~150-200 closed to date), and the odd RfC.

I've recently reviewed WP:BOTPOL and WP:BAGG. ProcrastinatingReader (talk) 01:50, 17 November 2020 (UTC)

QuestionsEdit

  • 1: What are your views on whether source code of bots should be made public? – SD0001 (talk) 18:06, 17 November 2020 (UTC)
    I'm a fan of open source code. I think software would be very different today (in a bad way) if folks took a different approach to OS and things like GitHub didn't exist. On Wikipedia, I think it should be encouraged but not required. It's not uncommon for botops to leave or become inactive and bots to end up with no active maintainer. Having source code public means continuity is easier (verses someone having to recode the tool from scratch), and it means people can find bugs and add features even when botops are somewhat active, but cannot get around to the task themselves. I think greater collaboration in the area of bots would be a plus in many ways.
    For the not required part, there's a couple of reasons I hold that view. The first, and most common I suspect, is that botops haven't yet found the time (or are too lazy) to clean up their code to make it neat enough (in their eyes), and to remove any credentials lingering around in history and whatnot. I don't think it's worth holding up an otherwise OK BRFA until the botop finds time to do that. The second is security concerns, e.g. User:ProcseeBot. A third, less common one, is that some bots could be sufficiently advanced to have commercial value and/or the main developers could be external (eg User:SuggestBot). I know we have an ethos on open-source collaboration, but historically it hasn't been applied to bots in the same way, and I don't personally believe it's worth possibly limiting our selection of bots for that sake. SuggestBot is open source in this case, but it's the same principle. If a university or company wants to commercialise their work but is willing to offer it to Wikipedia for free, I don't personally see that as being exceptional compared to eg CVDetector using Google's proprietary APIs.
    If you're asking about ProcBot specifically, open sourcing it at some point is indeed on my todo list (it isn't done already due to point #1). ProcrastinatingReader (talk) 18:31, 17 November 2020 (UTC)

DiscussionEdit

  • Support. I interact with ProcrastinatingReader frequently. They have sound judgement, technical proficiency, and I'm sure would be an overall boon to the BAG. {{u|Sdkb}}talk 23:32, 17 November 2020 (UTC)
  • Support. Proc is trustworthy and technically competent. I think they will be a solid addition to BAG. GeneralNotability (talk) 00:58, 18 November 2020 (UTC)
  • Support Thanks for the response PR. Indeed I have no concerns other than my pet peeve of ProcBot being closed-source. – SD0001 (talk) 05:57, 18 November 2020 (UTC)
  • Support LGTM --DannyS712 (talk) 00:29, 19 November 2020 (UTC)
  • Support -FASTILY 00:26, 20 November 2020 (UTC)
  • Support Liz Read! Talk! 04:30, 21 November 2020 (UTC)
  • Support No issue. Headbomb {t · c · p · b} 17:33, 23 November 2020 (UTC)

BAG Nomination: SD0001Edit

Nominating myself for BAG membership as I'd like to help out more in this area. While there are good reasons for BRFA being slower than the average process given the potential for disruption, I think faster service here can inspire more creative automation ideas to be brought forward.

I want to bring to BAG my broad expertise with tools and technologies used in bot-building – eg. I'd be a good one to tell whether something is better done using the API or the database dumps or database queries. I have been taking a keen interest in bot requests and approvals for some time. I love to read and write code, and have worked with Python, JavaScript, C++ and Java, and have reading familiarity with other common bot languages like PHP and C#.

I run SDZeroBot whose favourite task is compiling a popular collection of reports that has brought me a number of barnstars! I'm more proud of writing its underlying framework – a rich JS bot framework and the only one out there that also works with TypeScript – a promising new language that's fast becoming popular. My other technical work on WP includes writing user scripts, improving gadgets, and helping out at VPT. I am a major contributor to Twinkle and am also working on a funded project to expand it to other wikis.

I am familiar with WP:BOTPOL and WP:BAGG, and understand that consensus is an essential requirement for bot tasks. Thanks for your consideration! – SD0001 (talk) 17:01, 17 November 2020 (UTC)

QuestionsEdit

DiscussionEdit

Other discussionEdit

Inactivity discussionEdit

I started a thread over here about (semi?)automating the inactivity checks. Please feel free to give your opinions. Primefac (talk) 21:19, 1 September 2020 (UTC)

Using GitLab for code review?Edit

As was recently mentioned in Tech News, the foundation is currently holding a consultation about moving development from Gerrit, the current code and patch review system, to GitLab (for reasons, other systems are not being considered). I'm in the working group steering this consultation and we are also very interested in the opinions of those outside the core development team. Bot writers, gadget developers etc. Do you have concerns or enthusiasm about gitlab ? Do you think you might contribute more or less or even if it might be easier for you to be informed with Gitlab instead of gerrit ? What do you think about the gerrit patch review system vs the gitlab pull request system ? Please take a minute to think about it and maybe leave some comments at mediawiki.org or if you really prefer to do so, leave them Wikipedia:Village pump (technical)#Using GitLab for code review WP:VP/T and I will later summarise them there. —TheDJ (talkcontribs) 07:47, 21 September 2020 (UTC)

When to recuse from approvalEdit

This is something I've been thinking about on and off for a while now; at what point is it no longer appropriate for a BAG to approve a bot task?

  • Scenario 1, it's their bot
  • Scenario 2, they have proposed or otherwise heavily pushed for this bot task
  • Scenario 3, they respond or assist with a BRFA

Scenario 1 is a pretty clear "recuse" to me, and Scenario 3 is a pretty clear "no issue", but what about Scenario 2? If a BAG member says "I have this idea, we should do this" and someone says "sure", does that BAG now have a duty to let a different BAG member review the case and determine if all of the "boxes" have been ticked? Since they're not the one running the bot, is it not an issue? What if there's opposition to or concerns about the initial proposal? I know it kind of comes down to a case-by-case basis, but I have seen in the past where the BAG member was both BOTREQ proposer and BRFA accepter, despite concerns being expressed (and largely not addressed). Curious to see what others think about this. Primefac (talk) 21:47, 1 November 2020 (UTC)

Speaking for myself, 1) is a clear case that a BAG member should recuse. For 2) and 3), it IMO depends to what extent objectivity is compromised, and how controversial the task is. I know I've certainly danced in the area a few times, recently in the case of Bot to purge/null edit pages/ProcBot 5. I don't know if this discussion was prompted by that approval and my involvement in it, but I do stand by it (and equally stand with letting someone else re-close the BRFA if someone objected with reasonable reasons). For me, in that case, it was a task where something similar has already been approved plenty of times (e.g. Joe's Null Bot, JCW-CleanerBot, etc.), and which pretty much zero potential for disruption, and my involvement is little more than 'I want a bot to do a null edit / purge on a set of <10 pages once a day' and realizing that existing null bots didn't have a way of specifying a time for null edits/purges to be made.
Which to me, is a fairly different case from the, IMO still non-controversial, DYK blurb filling bot/MajavahBot 4 situation. There, I'm involved in a lot more places. The request is essentially so that the WP:RECOG DYK listings compiled by User:JL-Bot (both of which are brainchildren of mine) have fewer empty entries. And since this interacts with a lot more pieces ({{Article history}}, {{DYK talk}}), while I'm comfortable supervising a limited trial for the technical aspects, I'd rather have a fully uninvolved third party review for final approval to ensure that my blind spots are covered, either for the consensus aspect, or some technical aspect I overlooked.
If that's still too much involvement for some, I'm suppose I could fully recuse in all cases of 2, however remote my involvement, even if I feel my objectivity isn't compromised. But that, to me, feels pretty WP:BURO, and would just needlessly slow down trials and approvals of completely non-controversial bots, and needlessly consume out already-limited BAG ressources. Headbomb {t · c · p · b} 22:53, 1 November 2020 (UTC)
This quote (which I wrote) from WP:BAGG IMO sums up the situation nicely. 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. As long as BAG members follow the spirit of the guide, everything should be fine. Headbomb {t · c · p · b} 23:03, 1 November 2020 (UTC)
Well, as I said, I've wondered about that on and off over the years, but yes, it was prompted by the BRFA you mention (though not necessarily because I strictly feel you did anything improper); mostly just the impetus to post. Primefac (talk) 23:20, 1 November 2020 (UTC)
Heh. I'm also, ironically, reminded of ProcBot task 2 reading this. That approval took about 1.5 months. And that too because you decided to close it. If you didn't, it may well still be pending. I don't think we have enough active BAG to have the luxury of being overtly picky w.r.t. 2/3, but it depends on the extent maybe. At the same time, I think the closing BAG can be trusted to know when their judgement may be compromised. I don't think the BAGs responsible for my task 2, or my task 5, had compromised judgement due to their (relatively) minor roles in the tasks. It also becomes a bit of a cycle: there's only a few active BAG, so if turning to one for advice in their capacity as offer[ing] sound bot-related advice to bot operators, admins, bureaucrats, and editors alike, or in their capacity as technically proficient in a certain area, makes them have to recuse it's a net negative to the bot's BRFA and also a net negative to its good development (if it makes an operator avoid seeking advice, so they won't have to wait months for review).
At the same time, I think minimal involvement (eg just in proposing a BOTREQ) may be a positive. It means a person has perhaps already done a bit of vetting on the proposal's technical feasibility, and where technical errs may arise, and perhaps thought about some edge cases too. That seems an advantage in BRFA review, compared to someone having to jump in blind. Depending on extent, again, of course. ProcrastinatingReader (talk) 01:14, 2 November 2020 (UTC)
With regards to (2), I think the standard should be similar to closing any other discussion, i.e., avoid using BAG authority wen WP:INVOLVED. So if a BAG member has given an opinion similar to a support or oppose !vote, that member should not be approving the bot as they're pretty classically involved. I think this is weaker for interim actions like trials and responding to requests (per WP:NOTBURO), but for final actions such as approval and rejection, the appearance of impartiality should be maintained. Wug·a·po·des 01:12, 2 November 2020 (UTC)
IMO the interpretation of WP:INVOLVED there is too strict. If a BAG member saying "I think this is a good idea" somewhere is enough to disqualify them, we'd quickly run out of BAG members available to approve things since it's not uncommon for people to run their ideas by other editors before putting in all the work of actually coding a bot and starting a BRFA. Anomie 01:31, 2 November 2020 (UTC)
Yeah, there's enough nuance and leeway that it's a lot more obvious now to me (as per usual) that it's something best dealt with on a case-by-case basis. Thanks all for the thoughts. Primefac (talk) 02:16, 2 November 2020 (UTC)

Edit summariesEdit

Someone pinged me on IRC the other day to discuss edit summaries; they had seen a bot not linking to a related BRFA and wasn't sure if it was "legally" operating (it was, but it took some digging). However, it got me thinking that we should be better enforcing either mandatory links to BRFAs in edit summaries, or mandatory links to BRFAs on the bot's userpage. Personally, I think both should be happening, but I know for some long-term bots like lowercasesigma or AnomieBOT they're well-established and don't necessarily need to link to specific runs. That being said, I've been encouraging new bots/operators to be linking in their summaries.

Should we be mandating either of these disclosures, and if so do we have the authority to block bots if their operators are not complying? I know we're in the CREEP land of instruction, because BOTPOL implies that these links should be provided but don't really go into detail about where and how, but I think it's a reasonable point of clarification. Primefac (talk) 11:03, 16 November 2020 (UTC) For what it's worth, I posted it here instead of at BOTPOL because it's more about clarifying how we as BAG deal with these issues than necessarily updating the policy

WP:BOTPOL only requires that the userpage specify (directly or via link) details of the bot's tasks, including whether it's manually assisted or runs automatically and how often it runs. The easiest way to do this is to link to the BRFAs, but such links are not actually required. As for edit summaries, it only requires "informative messages, appropriately worded". Unless the bot's approval (or other community consensus) required something more than that for a bot, I don't think we have authority to block bots not going beyond these requirements. Anomie 14:03, 16 November 2020 (UTC)
I'm not a huge fan of instruction creep, but it should be easy for an editor to find out why a bot is making an edit; this shouldn't require jumping through a lot of hoops. A link to the BRFA in the edit summary is fine, but prominently linking the bot's tasks on the bot userpage should suffice as well. If a bot does many different things, we should enforce (at least on NEW bots) that this is easy to tell. I'm preferential to to using a task link for any edit/log like I've done here: Special:Contributions/Fluxbot on my own bot. As far as single function bots, they generally have a bot template on their userpage that links to their BRFA already. — xaosflux Talk 14:56, 16 November 2020 (UTC)
Edit summary linking can get complex fast for bots that are doing many things at once. A bot could be taking care of Task #4 and Task #18 in one edit, and then Task #3 and Task #12 in another. Depending on how a bot is coded, having a dynamic edit summary linking to specific BRFAs depending on which specific tasks happened to trigger an edit is either impossible to implement without refactoring the entire codebase, or a huge time sink with little to no payoff. If you have your BRFAs listed on the bot talk page, that's enough. If you have a question about a specific edit, you can always ask the bot op. Headbomb {t · c · p · b} 02:04, 18 November 2020 (UTC)
It doesn't need to be perfect, but imo an indicator would be ideal. It's also more appropriate in some situations than others. For example, User:AnomieBOT clerking a projectspace noticeboard with a clear edit summary, or User:HBC AIV helperbot5 clerking WP:AIV with "4 reports remaining. Noticeboard is backlogged." - neither of which needs a link imo - is quite different from a bot like User:Citation bot or a similar bot with a lot of approvals, many of which have overlaps in scope with another, and is actively operating in mainspace. A big point of BRFA, imo, is transparency. Yes, one can go to the bot's userpage and look at the tasks, but there are times when it's unclear which task actually relates to an edit.
Two big effects of this I think. First, it takes more effort to find the BRFA behind an edit and read up more on the task, perhaps comments there address a concern the person was about to raise. Second, it becomes harder for editors to tell if a bot is making (un)authorised edits. When you have a complex web of BRFAs, it's very easy for a non-technical editor to mistakingly believe an edit is authorised (when it isn't), or vice versa think that an edit isn't authorised (when it actually is). I agree on Headbomb's point that for bots doing multiple tasks in one edit this may be technically more difficult. I think it's worth discussing in relation to BOTPOL though, and would be an improvement in transparency. ProcrastinatingReader (talk) 19:59, 20 November 2020 (UTC)
Return to the project page "Bot Approvals Group".