Wikipedia:Bots/Approvals group/Message to BAG

From Wikipedia, the free encyclopedia
Jump to: navigation, search

BAG guidelines? Thoughts[edit]

Per my comment on ANI with regards to the NFCC Bot BRFA, I am now undertaking my promise to send a short message to all BAGers to serve as a reminder of the sentiments expressed at the not-so-recent MfD.

The most recent situation is this. A BRFA was closed early, reopened and then clsoed again a relatively short time later. Speedy approval is only rarely appropriate as far as I can see - in very uncontroversial cases where a trial is not needed, eg an uncontroversial clone. The NFCC bot is, for all intents and purposes, a clone. However given the drama which the original BCBot has spawned over time, it should have been clear that this was something that needed input. So be it if that input might end up being "trolling" - action should be taken when that happens and not pre-emptively.

BAG members are chosen for being experts on the technical issues of bot operation. Thus I suppose it is a consequence that we might not take enough account of community consensus for many tasks. This is the key point - where there is any possible controversy, we need to give people the chance to comment. To start with, this is probably best done by posting "spam" messages (or having the requester do it) to various noticeboards. With time I'd hope that BRFA would become watched in its own right by the community at large and thus the need to spamming would be reduced to only the most (potentially?) controversial cases - I'm thinking of NFCC Bot here.

I'd also suggest the following guidelines:

  1. Speedy approvals should only be used as a method of bypassing a trial - not to bypass discussion. There should be a clear consensus (whether via a previous BRFA or through a (short?) discussion in its own right) before a bot is speedily approved.
  2. At least 2 BAG members and at least 1 non-BAG user should comment on any request before it is passed.
  3. Trials should be used to bring a bot's presence to community attention, by means of a message in the edit summary (in appropriate circumstances). They should not be solely a way of gauging the technical safety of the bot.
  4. Use common sense, but err on the side of caution at all times!

This lays out my feelings (based on my interpretations of the MfD) on the issues facing BAG at the moment and how we can overcome them. Let's move forward and discuss (here) :) Thanks, Martinp23 18:17, 7 March 2008 (UTC)


Uhm. Sorry that I missed the recent discussion. Well, I don't think I've ever speedily approved a request, so I do agree that they're exceptionally cases, yes. As for the two BAGgers and one non-member needed to approve, uhm, ok but: what about speedies? Or interwiki bots (I do think that interwiki bots are more non-controversial than the others, usually)? And of course I do agree that trials are not technical tests only. Just my two cents. Snowolf How can I help? 18:59, 7 March 2008 (UTC)

Mm yes I was intentionally ambiguous on the 2 BAG one non-bag point because I'm not too sure. I think for anything but the least controversial speedies there should be an opportuntiy for input (I class interwikis, where the correct options are set, as "least controversial" here). Martinp23 19:01, 7 March 2008 (UTC)
I don't see how controversial and speedies go together :D. For me, everything controversial should be left to normal runs to the normal process. Snowolf How can I help? 19:32, 7 March 2008 (UTC)

Well, I for one have no problem with this list, if only because I think it describes the current process fairly well.

With, perhaps, the caveat that well known bot writers, code bases, or very simple functions are usually given less scrutiny— I think our primary function is to determine if it is likely that the bot will damage the encyclopedia, and those factors do significantly reduce that probability.

The extreme, where we normally enter speedy territory, is a bot that (a) uses code known to work, (b) is run by an experienced operator and (c) performs a function that is already believed to be acceptable (which is almost implicit given point (a)). If an experienced bot operator were to take SineBot's code and wanted to run a spare signer, it'd almost certainly be speedily approved— as should be. (talk) 20:28, 7 March 2008 (UTC)

Bah! I hate it when MediaWiki decides to log me off between edit and save. — Coren (talk) 20:30, 7 March 2008 (UTC)
  • I've been mostly inactive lately, but agree that speedy approvals should typically be reserved for known working code performing tasks that were previously approved (typically to another operator). — xaosflux Talk 15:58, 8 March 2008 (UTC)
  • Good points Martin and thanks for making them. Agree with Xaos; speedies are fine where there's neither any technical issues (straightforward request, operator is known) and in the view of a reasonable observer no likelihood of controversy. Speedying this particular request was spectacularly bad judgement, sorry to say, and has given ammunition against the group despite the absence of any better way of approving bots.
  • Another point that's been raised is that there seems to be no means of appeal a BAG decision, except perhaps ignoring it or going to Arbcom. Perhaps some thought should be directed towards setting up a means of appeal. --kingboyk (talk) 23:14, 8 March 2008 (UTC)