Wikipedia talk:Bots/Requests for approval

Process

Should we have another section for when a trial is concluded and awaiting BAG feedback? Rich Farmbrough, 13:19 27 April 2007 (GMT).

Review of RfBA BetacommandBot Task 8

In the light of the discussion going on at Wikipedia:Administrators' noticeboard/Incidents#BetacommandBot "rating" articles and leaving notes about it, it may be necessary to review at some point whether there is community consensus for this task. I don't know what the procedure is, but I thought that the people running RfBA should at least be aware of this discussion. -- Jitse Niesen (talk) 20:04, 10 November 2007 (UTC)

I'm guessing the procedure (if required, although from my glance at ANI it won't be) would be to run another BRFA, and to invite broader discussion than this one received. If the community approves the task, BAG approves it. If not, no bot. Dihydrogen Monoxide 02:53, 11 November 2007 (UTC)

Oh. I complained to him about that recently. Everywhere I go I see those infernal messages, and it seems to me that 1) they're not needed 2) judicious use of templates could have the same effect. Didn't know it had been raised on ANI...

SkiersBot has been doing a similar thing but his was somewhat worse, as I posted elsewhere on this page I believe. --kingboyk (talk) 17:22, 24 January 2008 (UTC)

Per this conversation, I created this process Wikipedia:Requests_for_comment/User_conduct#Use_of_bot_privileges, but in the the specific case of BCB, another user already started WP:AN/B, so that would be the correct forum for all BCB editing issues IMHO. If they reach consensus, then it should probably go to a WP:BOTS/Subpage for the BAG to review the bot situation and tell the crats whether or not this bot has community backing, etc. MBisanz ^talk 01:52, 26 February 2008 (UTC)

Looks good, though I am not convinced it would get much use. I think it would belong better at WP:BRfC like WP:BRFA. I think with the general slow pave of things around BAG it will be hard to get many opinions about this. Is there a more formal discussion of the proposal going down? -- maelgwn - talk 03:54, 26 February 2008 (UTC)

Well the shortcust can point anywhere, right now the only discussion is at Wikipedia:BN#Bot_change and its more about my motives than the proposal. I think I hit Wikipedia:Village_pump_(proposals)#-BOT_forum with no comments, so I guess here is as good a place as any. MBisanz ^talk 04:00, 26 February 2008 (UTC)

Code publishing?

Just out of curiosity, why don't we publish the code of the bots for community review? What are the pros and cons of publishing vs. not? Lawrence § t/e 14:09, 4 February 2008 (UTC)

It's up to every programmer.

• Pros : Allow others to check and add improvements, allow others to use it.
• Cons : Allow others to use it (sigh, depends on the bot), exploits, abuses. You have to clean your code before publishing it. You can not longer claim to be the only one running this particular bot.

NicDumZ ~ 14:24, 4 February 2008 (UTC)

Would the open source requirements for WP extend to bots, and require code release if asked for? Lawrence § t/e 14:25, 4 February 2008 (UTC)

It seems very hard to enforce as a policy. It's better to discuss it with individual bot operators, and convince them to release their bot code. — Carl (CBM · talk) 14:50, 4 February 2008 (UTC)

its always been that coders are requested to make their code open source, but we dont force it. β^_command 15:10, 4 February 2008 (UTC)

I'm wondering though if ona going forward basis, the disclosure of source code could be made a pre-requisite to Bot flagging. For bots with sensitive code (vandal bots), the code could be sent to OTRS. I'm imagining that the efficiency of most bot swould increase, since more eyes would find more ways to improve the code. Also, when a person left the project, it would be rather easy to replace them, as opposed to waiting until someone new can re-code a new bot that looks likes its doing the same thing (as happene to either an archiver or vandal bot I beleive.) MBisanz ^talk 19:56, 4 February 2008 (UTC)

Im opposed to forcing users to publish their code, Like I said feel free to request it, as for archiving bots, we have not had any issues. their is one that comes stock in pywikipedia. As for anti-vandal bots, you might ask cobi, but the AVB's that tawker and co. used to run, where rendered useless to changes in mediawiki. β^_command 20:04, 4 February 2008 (UTC)

This would be a good idea. Lawrence § t/e 20:00, 4 February 2008 (UTC)

(outdent) The vandal bots aren't sensitive and ClueBot is already open source. I have two objections to releasing my code, first I would have to clean it up as mentioned above and second I don't want to be liable for fixing more that one copy of the code. If I leave and a botop that knows what their doing takes over my code that is fine but I don't want 10 clones of BJBot screwing up everywhere. BJ^Talk 21:33, 4 February 2008 (UTC)

I'm not suggesting current bots be required to release code, only that new bots, as part of the approval process should be required to release it, at least to the BAG mailing list (if that actually exists) or OTRS. And of course, approval for 1 bot to do 1 task wouldn't empower any other bots to do that task, even using the identical code, so if someone installed it and started using it, I'd say they should be blocked on sight. What about even archiving code somewhere? I seem to remember that Gurch had a bot updating the ARBCOM elections and took a lot of heat when he needed to travel during the elections. If there was a common repository, it would've been easier to fix. MBisanz ^talk 21:44, 4 February 2008 (UTC)

• I'm opposed to a "private release" to some local instance, because bot ops from other projects would benefit a lot from a public release.
• Bjweeks, I think that the second point you raised is easy to avoid. You can license your code, or simply request that when you're still active, no one has the right to run another BJBot on en: (and on every project where you are) : Since BAG would request, for approval of new bots, the source, I don't see how a clone of BJBot could run here :) . Also, bot ops are responsible for their edits, whoever wrote the script : you shouldn't worry about an outdated version of your code running somewhere else, the other bot op should :þ
• From my personal experience, I'd say that those curious to look at a source of a bot don't really care about how messy the code is : They just want to know roughly how it works, or will clean the code by themselves if they want to reuse it elsewhere. But sure, right, I do hate submitting dirty code, and that's maybe why I mentioned that point. :( NicDumZ ~ 22:33, 4 February 2008 (UTC)

I'll start cleaning up my code for release, some of the code I need to bring back into working order on enwiki first. I'm nowhere near was dedicated as Betacommand and others so long absences from me are a possibility and that is why I should start publishing my code. BJ^Talk 23:54, 4 February 2008 (UTC)

Also, documentation is almost nonexistent in my code, which makes it harder to reuse. BJ^Talk 23:56, 4 February 2008 (UTC)

Though still under development, I have published the code for User:XLinkBot (see User:XLinkBot/Code). I don't see any harm in others to see the code, if they want to use it, feel free, any comments are also welcome (though Versageek and I will be the ones to see if it is really implemented, or there must be strong opposition to certain features). Also, be aware that the code there may not be totally up-to-date, as I am still developing the wiki-interface of the bots (something that did not exist at all in User:AntiSpamBot, that bot only listened to IRC). There is no explanation in the code, and it is far from 'clean', it works at the moment 'properly' (which does not mean that there is no improvement possible).

In a way, it would be good to see if spammers now will try to 'use' the code to circumvent the bots (they would need to see exactly where and how it uses perlwikipedia, and to understand the inner workings of wikipedia) .. that leads to a nice way of improving the code of said bots. --Dirk Beetstra ^{T C} 15:39, 6 February 2008 (UTC)

I suggest that we discuss whether it is appropriate to encourage bot code to be released under GFDL.

GFDL-published bot code should of course be approved before anybody is allowed to run it, and it should only be run by approved bot operators. Currently used bots may not be released under GFDL, either because some parts of the code are taken from a non-free source, or because the developer does not want to release the code. However, this can be treated similar to how we treat copyrighted/free images. For instance: A proprietary bot should not be allowed if a free (and approved) one is available that does the same task. A long-term goal may be to use only GFDL-bots. Oceanh (talk) 22:22, 25 February 2008 (UTC).

I think the GPL is better suited for programs than the GFDL, though. The ClueBots are released under the GPL. -- Cobi^(t|c|b) 22:28, 25 February 2008 (UTC)

The GFDL isn't any more suited for code than the GPL is suited for documents. --Carnildo (talk) 22:29, 25 February 2008 (UTC)

Thanks. The point is to publish under a suitable GNU license, and I agree that GPL probably is better suited. If the ClueBots are already released under GPL, that's a good start! We don't need to rely on proprietary bots doing tasks that GPL-bots already do. And these bots may be inspiration for other wannabe bot programmers. I can see some problems with "version explosion", which should be avoided. And also, since bots are powerful tools, certain skills and insights are required to make good bots, or good modifications of existing bots. Oceanh (talk) 22:46, 25 February 2008 (UTC).

BRFA table...

Hey, is it just me, or, is the bot that normally maintains the table near the top of the BRFA's MIA? (You know, the one that shows when blah was last edited, and, then, when blah was last edited by BAG etc etc) SQL^{Query me!} 13:52, 15 February 2008 (UTC)

Unregistered bot

User:AtidrideBot registered on Dec 10, 2007 and thus far as made a single drive-by edit of the editabuse template [1]. 2 things, one the edit itself seemed to target a bot owner, two the user's name looks like a bots, even though it isn't flagged as such. MBisanz ^talk 20:52, 25 February 2008 (UTC)

Block and point to WP:BRFA β^_command 20:57, 25 February 2008 (UTC)

I notified, but did not block since I wanted to see what would happen. They've repeated the edit to the template (and I've reverted) [2]. They've also told me "why" on my talkpage [3] and gone and moved the BC subpage to a formal noticeboard title [4]. Could the owner of the WP:SPA please stand up? Only registered users would know of BC and BCB's image work. I agree a block is called for BC, but I'd like a less involved user to confirm it for me. MBisanz ^talk 14:16, 26 February 2008 (UTC)

Dead bots

For bots that are inactive for very long periods of time (year+) should they be de-flagged? Not as much of an issue as with admin accounts left laying around, but it would seem to be simple housekeeping. MBisanz ^talk 08:57, 7 March 2008 (UTC)

Sounds like a good idea. We fire stewards for inactivity, why not bots.

Geoff Plourde (talk) 16:06, 7 March 2008 (UTC)

Sounds reasonable. I'd go with shorter... maybe 6 months? SQL^{Query me!} 16:12, 7 March 2008 (UTC)

we just cleared some of them out not too long ago. β^_command 17:21, 7 March 2008 (UTC)

Bot list

(ec)Ok these are the ones I ID' to start with as not having been active since at least 01/01/2007

1. AFD Bot (talk · contribs)-notified March 6, 2008-deflagged
2. LinkBot (talk · contribs)-notified March 6, 2008-deflagged
3. NotificationBot (talk · contribs)-notified March 6, 2008-deflagged
4. Pending deletion script (talk · contribs) (Dev bot, requires Tim Starling's approval)-notified March 6, 2008-deflagged
5. Portal namespace initialisation script (talk · contribs) (Dev bot, requires Tim Starling's approval)-notified March 6, 2008-deflagged
6. StubListBot (talk · contribs)-notified March 6, 2008-Flag removed De-flagged by user request. SQL^{Query me!} 07:06, 8 March 2008 (UTC)
7. VandalCountBot (talk · contribs)-notified March 6, 2008
8. Wikipedia Signpost (talk · contribs) (userpage notes it is still a bot)
9. ZsinjBot (talk · contribs)-notified March 11, 2008 - deflagged
10. Zbot370 (talk · contribs)-notified March 11, 2008 - deflagged
11. YurikBot (talk · contribs)-notified March 11, 2008
12. XyBot (talk · contribs)-notified March 11, 2008
13. Whobot (talk · contribs)-notified March 11, 2008
14. ABot (talk · contribs)-notified March 11, 2008 - I plan to start up again once I can find the time – ABCD✉ 01:36, 13 March 2008 (UTC)
15. Beastie Bot (talk · contribs)-notified March 11, 2008 - I plan to start this one up again when I have time —Pengo 07:02, 11 March 2008 (UTC)
16. BenjBot (talk · contribs)-notified March 11, 2008
17. Bgbot (talk · contribs)-notified March 11, 2008 - deflagged
18. Chris G Bot 2 (talk · contribs)-notified March 11, 2008 - still active, just some obscure problem with staying logged in --Chris 08:06, 11 March 2008 (UTC)
19. CrazynasBot (talk · contribs)-notified March 11, 2008
20. CricketBot (talk · contribs)-notified March 11, 2008-User intends to keep active
21. Danumber1bot (talk · contribs)-notified March 11, 2008
22. Dark Shikari Bot (talk · contribs)-notified March 11, 2008
23. DarknessBot (talk · contribs)-notified March 11, 2008
24. DinoBot (talk · contribs)-notified March 11, 2008 - don't de-flag
25. DisambigBot (talk · contribs)-notified March 11, 2008
26. Elissonbot (talk · contribs)-notified March 11, 2008-staying active
27. Eybot (talk · contribs)-notified March 11, 2008
28. Fetofsbot (talk · contribs)-notified March 11, 2008
29. Fetofsbot2 (talk · contribs)-notified March 11, 2008
30. Fritzbot (talk · contribs)-notified March 13, 2008-deflagged
31. Gdrbot (talk · contribs)-notified March 13, 2008 — I may use it again some time. Gdr 10:18, 13 March 2008 (UTC)
32. Geimas5Bot (talk · contribs)-notified March 13, 2008
33. Grammarbot (talk · contribs)-notified March 13, 2008
34. GrinBot (talk · contribs)-notified March 13, 2008
35. Halibott (talk · contribs)-notified March 13, 2008
36. Heikobot (talk · contribs)-notified March 13, 2008 - I still have the plan to use it. Heiko Evermann. 85.177.140.123 (talk) 17:39, 14 March 2008 (UTC)
37. IW-Bot-as (talk · contribs)-notified March 13, 2008
38. Janna (talk · contribs)-notified March 13, 2008
39. JdforresterBot (talk · contribs)-notified March 13, 2008-keep active
40. JoeBot (talk · contribs)-notified March 13, 2008 - Should be deflagged. It was a semi-automated spellcheck bot made to distract myself from finals through procrastination. 25k edits later, I still somehow managed a good grade. Funny to look back on it now. Anyways, I'll probably never run it again, there are better projects out there right now doing that job more efficiently. JoeSmack ^Talk 12:05, 13 March 2008 (UTC)-deflagged
41. KevinBot (talk · contribs)-notified March 13, 2008-deflagged
42. Kurando-san (talk · contribs)-notified March 13, 2008-keeping active
43. KyluBot (talk · contribs)-notified March 13, 2008 - Currently used to read pages, MedCab bot functions have yet to be needed as the current bot for the function is stable. ~Kylu (u|t) 13:11, 13 March 2008 (UTC)
44. M7bot (talk · contribs)-notified March 13, 2008 - Should be deflagged. I'll probably never run it again. --M/ (talk) 12:17, 13 March 2008 (UTC)-deflagged
45. Mairibot (talk · contribs)-notified March 13, 2008
46. MarshBot (talk · contribs)-notified March 13, 2008-deflagged
47. MBot (talk · contribs)-notified March 13, 2008
48. MichaelBillingtonBot (talk · contribs)-notified March 13, 2008-staying active
49. MoriBot (talk · contribs)-notified March 13, 2008
50. N-Bot (talk · contribs)-notified March 14, 2008
51. NekoDaemon (talk · contribs)-notified March 14, 2008-keeping active
52. Nobot (talk · contribs)-notified March 14, 2008
53. NohatBot (talk · contribs)-notified March 14, 2008-keeping active
54. NTBot (talk · contribs)-notified March 14, 2008
55. Pearle (talk · contribs) - Keeping active
56. Peelbot (talk · contribs)-notified March 14, 2008-deflagged
57. Pfft Bot (talk · contribs)-notified March 14, 2008
58. PlangeBot (talk · contribs)-notified March 14, 2008
59. Planktonbot (talk · contribs)-notified March 14, 2008
60. PoccilScript (talk · contribs)-notified March 14, 2008
61. Rambot (talk · contribs)-notified March 14, 2008 (I plan to use this for an approved task in a couple years. See my post below. -- RM 21:23, 20 March 2008 (UTC))
62. RBSpamAnalyzerBot (talk · contribs)-notified March 14, 2008-deflagged
63. RoboDick (talk · contribs)-notified March 14, 2008
64. RobotE (talk · contribs)-notified March 14, 2008 - deflagged
65. RobotJcb (talk · contribs)-notified March 14, 2008 - I'm planning to reactivate it within a few weeks, so please keep it flagged - Jcbos (talk) 14:07, 17 March 2008 (UTC)
66. RoryBot (talk · contribs)-notified March 14, 2008-deflagged
67. Selmobot (talk · contribs)-notified March 14, 2008
68. Sethbot (talk · contribs)-notified March 14, 2008
69. Sgeo-BOT (talk · contribs)-notified March 14, 2008
70. Werdnabot (talk · contribs)-notified March 14, 2008
71. Werdnabot (irc) (talk · contribs)-notified March 14, 2008
72. Snobot (talk · contribs)-notified March 14, 2008
73. StatsBot (talk · contribs)-notified March 14, 2008
74. StefanBot (talk · contribs)-notified March 14, 2008-deflagged
75. Syrcatbot (talk · contribs)-notified March 14, 2008-deflagged
76. The Anomebot (talk · contribs)-notified March 14, 2008-deflagged
77. TheJoshBot (talk · contribs)-notified March 14, 2008-deflagged
78. Topjabot (talk · contribs)-notified March 14, 2008 Can be deflagged. --Gerrit ^CUTEDH 10:48, 14 March 2008 (UTC)
79. TPO-bot (talk · contribs)-notified March 14, 2008-deflagged
80. Vina-iwbot (talk · contribs)-notified March 14, 2008

Comments

Do I grab a crat or SQL, will you grab them as a BAGer? MBisanz ^talk 17:22, 7 March 2008 (UTC)

I'm actually not a BAG'er, sorry... We'll need BAG to ok de-flags, before a crat does it... I'd suggest a note at WP:BOWN and/or WT:BAG, to try to grab some attn... SQL^{Query me!} 18:39, 7 March 2008 (UTC)

Might I suggest that before flags are withdrawn, operators are contacted if still active. It might be worth asking them if they still need a bot account, and when they are likely to use it again. People may be offended by flags being withdrawn without it being discussed with them first, and there's no great rush to do this. WjBscribe 19:05, 7 March 2008 (UTC)

Asked around, will wait a week or so for infrequent editors. And I'll start processing the entire list of flagged bots. Not a critical task, but still something I know I have the skills to do and needs to be done by someone. MBisanz ^talk 20:23, 7 March 2008 (UTC)

Need any help? Geoff Plourde (talk) 20:56, 7 March 2008 (UTC)

Thanks, I think I've got it set. Just checking through contrib pages, already 1/4 done. MBisanz ^talk 06:08, 8 March 2008 (UTC)

If anyone responds that they no longer need a flag, feel free to drop me a note on my talkpage and I'll remove it. WjBscribe 20:24, 7 March 2008 (UTC)

I don't intend to use Stublistbot, so go ahead. (For all I care, the whole concept of using stub templates can be abandoned, but that's a different story) Han-Kwang (t) 21:46, 7 March 2008 (UTC)

Thanks, I have removed the flag. WjBscribe 00:04, 8 March 2008 (UTC)

Ok I've processed all Bot flagged bots. There are 72 listed at User:MBisanz/Botlist#Inactive_bots_for_notification. I'll begin notifying them, but some have been dead since 2005, so I wouldn't hold my breath. MBisanz ^talk 07:13, 8 March 2008 (UTC)

Deflag Zbot370; it's blocked anyways. I blocked it since I lost the password and didn't want anyone to hijack that. User:Zscout370 ^{(Return Fire)} 06:46, 11 March 2008 (UTC)

Bgbot (talk · contribs) will stay inactive. You can freely take away its bot flag. — Borislav 08:11, 11 March 2008 (UTC)

ZsinjBot (talk · contribs) has been made obsolete, hence it's inactivity. I have no problem with its flag being removed. Zsinj^Talk 17:04, 11 March 2008 (UTC)

Thanks. Flags removed from Zbot370, Bgbot & ZsinjBot. WjBscribe 18:06, 11 March 2008 (UTC)

Thanks for the notification. CricketBot (talk · contribs) has been inactive for a while but might be revived when I have more time. I'll go with whatever the consensus is in that situation. Stephen Turner (Talk) 10:43, 12 March 2008 (UTC)

Thank you for the notification. While ABot (talk · contribs) has been inactive, I do mean to revive it once I have some more time. – ABCD✉ 01:36, 13 March 2008 (UTC)

Thank you MBisanz and co for chasing this up, and yes, LinkBot (talk · contribs) is inactive, and can be deflagged. If I do find I ever need to reactivate it again, I'll request that via the normal processes. -- All the best, Nickj (t) 04:47, 13 March 2008 (UTC)

Hey, thanks for the message. MichaelBillingtonBot (talk · contribs) is inactive because of an OS change, but will be operating again once I eventually get around to porting it. Cheers. --Michael Billington (talk) 09:11, 13 March 2008 (UTC)

Fritzbot (talk · contribs) can be deflagged. --Fritz S. (Talk) 09:22, 13 March 2008 (UTC)

Elissonbot (talk · contribs) has been inactive since I've been quite inactive (sadly), I would probably find chances to use it in the future again but I guess I could just reactivate it then. Go with whatever you find suitable. – Elisson • T • C • 12:43, 13 March 2008 (UTC)

Hey there! RBSpamAnalyzerBot (talk · contribs) is not flagged as far as I know. Ugh, it appears it was given a bot flag (I thought it wasn't). It can be deflagged, I don't have the resources to run him anymore. -- ReyBrujo (talk) 01:45, 14 March 2008 (UTC)

Thanks for responding, I have removed the flag. WjBscribe 01:51, 14 March 2008 (UTC)

You can deflag TheJoshBot (talk · contribs), as long as its status as being previously flagged is recognised, and it can get re-flagged easily when its needed for active service in the future. --TheJosh (talk) 03:36, 14 March 2008 (UTC)

I would prefer that NohatBot (talk · contribs) keep its bot status. If I leave the project with no intention of using the bot again, then I will request for its flag to removed at that time. Nohat (talk) 03:45, 14 March 2008 (UTC)

Please de-flag User:The Anomebot: I stopped operating it when I lost its password some time ago, and am currently operating through another more recent bot account. -- The Anome (talk) 07:09, 14 March 2008 (UTC)

Peelbot (talk · contribs) can be deflagged; if I decide to start it up again (which is a big if) it will probably be on a different task, hence can be reflagged during the request for approval process. Thanks. Mike Peel (talk) 09:04, 14 March 2008 (UTC)

I'm fine with TPO-bot (talk · contribs) being deflagged. Could you please add a note on the talk page when this is done. Thanks. --TheParanoidOne (talk) 13:50, 14 March 2008 (UTC)

StefanBot (talk · contribs) can be deflagged, will apply again if I ever make some a new bot code. --Stefan ^talk 14:22, 14 March 2008 (UTC)

Syrcatbot (talk · contribs) can be deflagged. I'm unlikely to do work with it again. Thx. Syrthiss (talk) 16:54, 14 March 2008 (UTC)

Thanks to those who have responded above. TheJoshBot, Anomebot, Peelbot, TPO-bot, StefanBot and Syrcatbot all deflagged. WjBscribe 18:58, 14 March 2008 (UTC)

JdforresterBot (talk · contribs) isn't unused, merely temporarily inactive. Given that it's job is to do editing on my behalf which isn't appropriate to claim as human editing (disambiguation, etc.), it would be best to keep its status. James F. (talk) 19:18, 14 March 2008 (UTC)

RoryBot (talk · contribs) can be deflagged, since to my knowledge its task is more or less complete, so if I decide to use it again I'd be going back to BRFA anyway. --Rory096 20:04, 14 March 2008 (UTC)

NotificationBot (talk · contribs) can be deflagged, as well as AFD Bot (talk · contribs). Please do not deflag Kurando-san (talk · contribs) and NekoDaemon (talk · contribs) as I will be revising the scripts over the next two weeks to get the two bots operable. --AllyUnion (talk) 21:29, 14 March 2008 (UTC)

Thanks. RoryBot, NotificationBot and AFD Bot now deflagged. WjBscribe 21:49, 14 March 2008 (UTC)

RobotE can be deflagged. It worked on interwiki, but I stopped it, because there are so many people working on that. Ellywa (talk) 12:39, 17 March 2008 (UTC)

Ok, done. Thanks for letting us know. If you'd like to use it again, you know where to request it of course. There are a lot, but they are still useful. - Taxman ^Talk 06:48, 22 March 2008 (UTC)

Werdnabot is now active again. Werdnabot (irc) can be deflagged. — Werdna talk 11:43, 22 March 2008 (UTC)

NFCC BRFA

I'd like to suggest reopening it. It really wasn't open for long enough at all. I'd suggest a minimum term to guage community consensus of 7 days. If the bot fails, then so be it - clearly the community doesn't want it. We should therefore, perhaps, get over it and not try to push a bot which seems to have support within BAG through the system. Thoughts? Martinp23 23:32, 7 March 2008 (UTC)

that is not a good idea. most of the issues have been addressed. its just a simple BCBot clone. β^_command 23:47, 7 March 2008 (UTC)

Well maybe my questions can be dealt with without reopening it. 1. Will it respect a NoImageBots tag once I create oen on the model of NoBots? 2. Will you consider adding a tagging notification feature for the phase 4 implementation. MBisanz ^talk 02:17, 8 March 2008 (UTC)

I'm thinking about the questions of the community at large. Whether or not it is a clone, if they don't want it we won't run it. Martinp23 07:04, 8 March 2008 (UTC)

Thats one I don't have an answer to. I guess its just not an issue we've faced that frequently. I see there is a debate on the boards about Cambridge U's computer security dept having a role account. And I think there is some BOCES-style program that operates what I can only guess is a role account. And I discovered that User:WP 1.0 bot can be run by anyuser from a web interface. MBisanz ^talk 07:15, 8 March 2008 (UTC)

I'm OK with re-opening it, but, I'd prefer not to have another tarpit-slugfest. Would you be OK with me (I'm not sure I have to ask -- I'm not BAG, so, in theory, I shouldn't be editing closed discussions) cleaning up the proposal a bit, to get rid of any offensive terminology? I'd also like to make it clear from the get-go. This is a discussion on if or if not the bot should run on the English Wikipedia. While feature requests are often nice, and very helpful, ofttimes, the operators are not the bot developers. We never ask people running interwiki.py, if they'd please have the bot leave a message on the talkpage of the article it's modifying, for instance. In this instance, I'd like to treat this bot in the same manner, as a feature-frozen program. Now, this is not to say, that bugs can't be addressed, by the upstream developer (Betacommand), as in any other normal software package (AWB, Pywikipedia, etc). Also, I would like to keep discussion about betacommand to a minimum, should this discussion be re-opened. While yes, he is the developer of this software, this isn't about betacommand. If we can stick to these points, I see no issues with re-openening the BRFA. SQL^{Query me!} 11:17, 8 March 2008 (UTC)

Furthermore, I think, at this time, any serious concerns about the bot's username, would probably be best discussed in a username RFC, as the bot is, at present an existing user, and, so far as I can tell, not a blatant violation of the username policy. SQL^{Query me!} 11:19, 8 March 2008 (UTC)

This request should NOT be reopened because it will simply become another flame war which none of the bot operators are interested in dealing with. This bot is the same as BCBot. It is a clone. This is why it was speedy approved. Certain members of the community have proven that they are not capable of discussing BCBot in a reasonable way or allowing it to be discussed reasonably by others. --uǝʌǝsʎʇɹnoɟʇs(st47) 12:05, 8 March 2008 (UTC)

The request definitely needs to be reopened with a minimum amount of time for community discussion. The "approval" for this bot was simply ridiculous, the account was given bot status almost immediately and despite ongoing discussion. When someone attempted to add more discussion (something that should never be discouraged on Wikipedia), they were reverted and the page was protected. This just screams to be done again. —Locke Cole • t • c 11:08, 9 March 2008 (UTC)

Re-opening it would be a minimum. Regarding the current WP:RfAr#BetacommandBot, one of the Arb's comments involves having "too many issues" for being able to make a manageable RfAr case out of it. Re-opening the BRFA would at least split off one of these issues, via normal community process. And please, BAG members take some time to give those raising concerns the impression that their concerns are heard. I'm not talking about that that didn't happen, but maybe there was a perception problem. Concerns were heard at WP:ANI, but when looking solely at Wikipedia:Bots/Requests for approval/Non-Free Content Compliance Bot it gives the impression that for a hot issue, those making decisions preffered not to give too much attention to objections, and went straight for the "speedy" decision. --Francis Schonken (talk) 14:09, 9 March 2008 (UTC)

this bot was approved 10 months ago. the NFCC bot is just a clone of that. there is no reason to re-open it. β^_command 15:21, 9 March 2008 (UTC)

Re. "there is no reason to re-open it", there is: that reason is WP:RfAr#BetacommandBot, and the suggestions given there by arbitrators. --Francis Schonken (talk) 15:54, 9 March 2008 (UTC)

so your saying FT2's comments about supporting the actions of BAG is a reasion to re-open? this is just a clone of an existing bot, and BAGs actions where made to avoid a flamewar. β^_command 16:24, 9 March 2008 (UTC)

Bypassing community discussion is unacceptable. That alone is reason to re-open it and allow for a reasonable amount of discussion. —Locke Cole • t • c 21:27, 9 March 2008 (UTC)

If BAG will not permit re-opening the discussion, there is a simple solution:create a separate place for such discussions. --BrownHairedGirl (talk) • (contribs) 02:32, 14 March 2008 (UTC)

Kddankbot

I posted this on the main talk, but could someone go ahead and approve this? Geoff Plourde (talk) 07:56, 8 March 2008 (UTC)

KevinBot

KevinBot is no longer active and can be de-flagged. I may reactivate it sometime in the future but I'm just too busy these days. Kevin Rector (talk) 01:18, 14 March 2008 (UTC)

Review of a Betacommand task

Per my comments at Wikipedia:Administrators' noticeboard/Betacommand#How_can_a_BCbot_task_be_rescinded.3F, I want to ask BAG what their procedure is for reviewing a bots' approval for a particular task.

I am interested in two aspects of the approval, which may be considered together or separately:

1. a technical review by BAG itself of a task's authorisation (as is done when an application is made for authorisation of a task),
2. a review of the community consensus for a task.

In the interests of clarity, I want to make clear that I have raised the operation of BAG as one of the issues to be considered in my statement on the RFAR on Betacommand. Arbcom members have expressed the hope that community can resolve these issues without the need for an arbcom case, so I want to see whether and how BAG can consider the issues which I want to raise.

So, please can BAG tell me what procedure I should follow for each of these points ... or alternatively, whether BAG has no process for re-examining a bot's authorisation.

I believe that the answer will be relevant to the question of whether arbcom accepts a case on these matters. However, I am asking not as hypothetical test, but out of genuine concern for a review of a particular task. --BrownHairedGirl (talk) • (contribs) 02:03, 15 March 2008 (UTC)

Like I have said before, yet you seem not to listen to. Post a request here and there will be a discussion. β^_command 03:51, 15 March 2008 (UTC)

BC, I would have hoped that you would have recused yourself from a matter relating to your own bot. I want to know whether BAG members other than the bot-owner are prepared to review one the bot's tasks. --BrownHairedGirl (talk) • (contribs) 05:23, 15 March 2008 (UTC)

I already offered a suggestion on the page you specified (which, was apparently ignored). I'm not sure, why Betacommand's not allowed to suggest, basically the same thing? He may well be involved, and, I would expect him not to decide the outcome of the discussion. However, he was just trying to help you here, to point you towards the right place to start the discussion you seek.

So, yeah, I'd say calmly and rationally, start a discussion here. I'd suggest using facts, a good amount of links, and, generally make it easy to follow, for us (Most of us don't follow all 39,194 places this discussion is going on at). As I said at the other place, I wouldn't have a problem with a 'reverse BRFA', either, however, I haven't heard from any of my colleagues on that idea. One thing, however -- please be patient with us. Not everyone notices right away, that discussion is going on here. However, if something serious like you are suggesting comes up, I can leave messages with the various members, to alert them to it. Thanks, SQL^{Query me!} 05:43, 15 March 2008 (UTC)

There is no written out procedure. We really don't do this kind of thing very often. If you've got a problem, and can get a BAG member or two to endorse your complaints, I would not be adverse to an ORGANIZED review of the issues. However, this page is backlogged, and none of us is interested in wading though megabytes worth of mostly useless content, and I don't believe that a simple poll would be sufficient to gauge the actual merits and technical issues. --uǝʌǝsʎʇɹnoɟʇs(st47) 23:21, 17 March 2008 (UTC)

A proposal - more community input

A perennial problem facing the BRFA process as a whole is a lack of input from the community during a BRFA. Such participation is often impossible to solicit in the course of the BRFA, and we only see complaints after the bot has been approved. These complaints often go straight to ANI and do result in bots being blocked and cement the view held by many that the whole BRFA process is totally ineffective. To make things worse, after a bot has been approved there is no set process to re-examine that approval or to change it.

The only real way to resolve these issues is to get more community input in the course of a BRFA. Links cross-posted to community noticeboards often serve no purpose other than to annoy, and we still see no real increase in participation in a BRFA. Indeed, the only time that members of the community care about a bot's approval status is when it does something they don't like and, invariably, this time falls after the bot is fully approved (and thus the flamewars start). We do assign short trials as a matter of course in BRFAs, however my feeling is that a 50 edit, or even a 2 day trial, only offers us a gauge of the technical merits of a bot (ie that it doesn't cause the wiki to die whenever it runs), and doesn't "touch" enough members of the community at large to give them the opportunity to complain.

My proposed solution to this is an extension of the BRFA process. Following a short trial to assess the technical merits of a bot, the bot is placed into a probationary period of around 1 month in length. During this time, the bot's edit summary for every edit should contain notice that it is in an "extended trial" and a link directly to the BRFA. The BRFA will remain linked from the main request listing page for the duration of this trial, and will remain open to community participation for the full period of the trial. If, at the end of the extended trial, any issues raised by the community have been addressed, the bot is approved. The same "probation" requirement would apply for new task BRFAs.

My feeling is that although approval wouldn't be granted, bots could be given (temporary) flags for the duration of the extended trial if their edits are likely to clog up recent changes too much. Exemptions to the rule are something that should be discussed - my feeling is that there should be none, just to ensure that any potential issues are spotted and addressed (because, believe it or not, even interwiki bots can go wrong!).

The second issue I raised above is that of re-examination of approvals. The proposal is that any BAG member who feels that there is a valid reason to request it can place a bot back into a probationary period, and have the obligatory notice put into its edit summary. This should only be done on discussion here and, if BAG can't come to a consensus, the crats can, as is the established method, make the decision for us. A bot put into probation would, as earlier, have its BRFA request linked from the main BRFA page, and would be unarchived so not to hinder participation.

I hope that we can discuss and agree upon the above. I must credit WJBscribe for helping to formulate these suggestions, and apologies for my use of the first person making the whole idea look like my own -- I think I perhaps got carried away ;). No doubt others will have ideas for how to improve things, and these should be welcomed. Thanks, Martinp23 18:52, 16 March 2008 (UTC)

I strongly support Martin's suggestions- that may not be especially surprising as I helped him develop them. There is in my opinion, a perceived gulf between BAG and the wider Wikipedia community at present - and frustration caused by unclear processes as to the review of disputed bot functions. That has I think been one of the factors that has lead to ArbCom deciding to accept the BetacommandBot case - ideally many of those matters could have been investigated and resolved by the Bot Approvals Group. These proposals seem like a good way to channel community input into the BRFA process and to have a clear mechanism - through probation - to make it clear that BAG's oversight of bot operations goes beyond simply giving them the technical nod. WjBscribe 18:58, 16 March 2008 (UTC)

I definitely support idea of a bot approval being re-examined via a 'probationary period'. I don't think it is necessary for the approval of every bot though. How would non-BAGers request a bot approval to be re examined? -- maelgwn - talk 22:17, 16 March 2008 (UTC)

I'd think along the lines of it being requested here and actioned if not a frivolous request. Martinp23 23:27, 16 March 2008 (UTC)

On the matter of "every bot?" - I think my feeling is that we should err on the side of requiring it unless absolutely unnecessary. Speedy approvals should only be issued very rarely, and I think they're the only case that the extended trial should be dropped. Can you think of any other examples? Martinp23 18:42, 17 March 2008 (UTC)

The idea of re-examination of bots sounds good to me. One alternative is to approve bots only temporary, say for six months, after which a re-approval may be given. In the case of no serious issues with the bot, and no objections, re-approval can be given straight away. Problem bots can then be thoroughly re-evaluated and discussed. This would also mandate a proper overview of which bots/bot tasks that are approved and running at a given period of time. Oceanh (talk) 02:00, 17 March 2008 (UTC).

My only fear with that is a rather large administration overhead - we'd need people checking which bot needs reapproving today, and still need the community input, which is sadly lacking. The proposal above is basically giving users (via a BAG member) the opportunity to get a bot discussion reopened if they feel consensus has changed -- so it's close to your idea on an "as-needed" basis. Martinp23 18:39, 17 March 2008 (UTC)

Good idea, Martin :) Sounds workable to me, and addresses re-evaluating bots when required.... SQL^{Query me!} 02:30, 17 March 2008 (UTC)

And that "when required" caveat mustn't hinge on technical reasons, but should instead hinge on whether valid non-technical concerns have been addressed. We will know what this means when it happens. Carcharoth (talk) 14:16, 17 March 2008 (UTC)

One of the points to note is that it only takes one BAG member to agree there is a problem that needs to be looked into further for a bot to be on probation - and being on probation doesn't affect the bot's daily running. This short prevent frivolous complaints disrupting things, but the one BAG member is a reasonably low threshold. At the moment it seems BAG needs to form a consensus that a task should cease, the proposal is intended to have a structured review process with a lesser hurdle to kick it off. WjBscribe 16:22, 17 March 2008 (UTC)

Yes - if indeed the bot is working fine and the probationary period's outcome is that it should continue as normal, then nothing has been lost. The only time that the bot-op must take is to add the link to the BRFA to the edit summary of the bot. As WJBscribe says, this would kick start the process... I can say from experience that trying to get BAG members together to form a consensus is like herding cats. Martinp23 18:35, 17 March 2008 (UTC)

I'm not going to bother with all the threaded discussion just yet, but here are my comments:

Both proposals seem reasonable, though I question the drama-causing potential of a retrial on demand. Perhaps the retrial could require some sort of discussion or (dare I say it) vote before occuring? Also, I'd prefer to see a means by which experienced operators can just be given the green light after a cursory review and minimal hassle. --uǝʌǝsʎʇɹnoɟʇs(st47) 23:18, 17 March 2008 (UTC)

I wholeheartedly approve of this proposal. It increases the authority of BAG, increases community awareness of which bots are new, and doesn't really add much bureaucracy. How hard is it to check that a link appears in an edit summary? Just go the bot's contributions, set it to 500 and scroll down looking for a "(in trial)" note. If the small additional overhead is too much for BAG, there are plenty of bot operators willing to join. I think this proposal should be supported by a review of the approval process for BAG membership, but that's another story.

I think that under this system, "speedy approval" should be a shortcut only to the "in trial" status. If a task is similar enough to another to warrant speedy approval, the only issues are likely to be technical, which an "in trial" status run should catch easily. If a task is controversial but has been previously approved, then that approval should be linked from the current approval discussion. Remembering that consensus can change, there's no reason to exclude discussion on a topic just because it's been discussed before.

I do not approve of automatically-required reconfirmation; if a bot is operating consistently effectively and uncontroversially, why do we need to keep checking that? Six-monthly reconfirmations for Sinebot or MiszaBot would be pointless bureaucracy. However, I think that a reconfirmation-on-demand process would be very effective. It again upholds the authority of BAG, reminding bot operators that they are answerable to BAG and the community not only during the approval process, but whenever they are running their bot. I think that reconfirmations should be ordered by BAG at the request of the community, and that (unlike the messy WP:AOR process) the policy and procedure for bot reconfirmations should be centrally ordained. Happy‑melon 10:07, 18 March 2008 (UTC)

Moar creep?

Okay, you may have addressed the issue called "not enough community input" but at the same time you walk further down the slope called "bureaucracy". I'm very interested how you'd address this issue. Your proposal is adding an extra process overhead to (possibly) each BRfA (not to mention the extra work with making edit summaries compliant). This may ease the BAG-community front, but possibly unleash more of said frustration but between BAG and the bot operators? It's been to date said that there is more process than it's worth - now there's potentially even more of it (please fill out form 33499XJ-alpha in three copies, along with attachments DD7-Q4X/34b and 7FG-3R/174v, plus one copy of evaluation form V5H44SF-56673/AAAQ-3e for each edit done by the bot, unless someone with trust level QS-54/4Z or higher files a protest BQ56L-55e in which case we invoke discussion protocol TY11-WP/3a). Faced with that I don't think I'm willing to change my status quo (read: develop and run bots on my own and pretend the BAG doesn't exist) on this matter. Mind you, I'm not pointing out a better way (not sure yet how exactly I'd envision it) but rather pointing out that your solution is far from perfect as well, so don't get overexcited over it. Миша13 21:38, 17 March 2008 (UTC)

Valid point. My thoughts run that these extended BRFAs would just be linked from the main page - not transcluded, and wouldn't necessarily need any form filing or input unless a problem was noticed and the point raised... in which case it's surely worth it. Martinp23 21:46, 17 March 2008 (UTC)

Okay, Martin, your idea certainly has merit but it definitely does not completely solve the problem. The question to be resolved should be framed as "How do we avoid bot complaints made at AN/I?" not as "How do we avoid bots being blocked?" The core of the issue is the former, not the latter, from what I am reading. It should be Administrators who collectively decide that the AN/I is not the place to complain about bot behavior. It was a few years ago that the Wikipedia:Bot page was the place to complain about a bot's behavior, and not AN/I. Certainly, a user should have the right to list that a bot's behavior is gone awry on AN/I, but the result for an Administrator should not be to block the bot right away. As the Wikipedia is built on a community of discussion and active consensus, in the same spirit, those Administrators who wish to be involved should move the discussion from AN/I to a subpage of Wikipedia:Bots for a review discussion on an approved bot. Adding the "additional" trial period is meaningless, in my opinion, because you will always have someone complaining about some thing or another -- you aren't going to make everyone happy unfortunately. The purpose of the technical review is to assert that the bot is harmless and is useful. Primarily the former than the latter. The reason why the period was given a "if no one objected" kind of setup is because, admittedly, the lack of involvement of monitoring bots on the Wikipedia by editors. Administrators do not have all the time in the world to monitor every aspect of the Wikipedia, unfortunately. Not giving bots the bot flag after the technical review will affect those on RC patrol. It is my feeling that the current bot policy should remain standing as is.

It is my feeling that the solution should be:

Person Alice complains about Bot Bob on AN/I. Administrator Carol sees the complaint about Bot Bot, summarizes the complaint, and moves the complaint off the AN/I board to a subpage here. Active members of the technical bot review committee along with the bot owner should be notified that the bot's actions have been disagreed by Alice. Whether the bot's actions should be halted or blocked should be subject to consideration and review by Carol if Carol understands whether the complaint holds any merit and whether Carol can immediately answer 'yes' to the question: "Is the bot harmful?" If Carol views Alice's complaint to be of a highly technical nature, or of one Carol is unable to immediately answer the question of whether the bot is being harmful or not, then the bot should be subjected to an immediate re-review process. Should a member of the technical bot review committee deem that the bot is being harmful, then the bot should be blocked until a decision is made of the re-review process. Should the bot owner believe that his/her bot was blocked in error, they should also have the right to call for a re-review process involving the member who had a complaint in the first place.

The review & re-review process primarily needs to answer the two core questions that have been essentially part of the bot policy:

Is the bot harmless? Is the bot useful?

It is likely that a complaint is made to either one of those questions.

In any case, the section that has Dealing with issues should be reorganized. It should stress that issues should be discussed with the bot owner and only when the bot owner is unwilling to cooperate is when the complaint should be made at AN/I. On the same level, a bot owner needs to reasonably understand that a complaint about their bot should be taken seriously, and should make all attempts to involve someone from the approvals group.

The matter, ultimately, should be resolved not by more policy, but through the standards of practice that has been the core principles of the Wikipedia. The dispute regarding a bot should be between the person making the complaint and the bot owner first. Both parties need to recognize when the matter is beyond their scope to include a member of the approvals group, then Administrator(s). --AllyUnion (talk) 05:57, 18 March 2008 (UTC)

The problems arise when a bot operator either carries on operating the bot in the face of valid complaints, or fails to respond to valid complaints. At that point, a block may be needed to stop the bot. The ideal result short of blocking is that the bot operator stops the bot and discusses the issues. Admins are perfectly capable of judging whether a non-technical issue is a good reason to stop a bot, just as BAG members are best place to judge on technical grounds. What is not acceptable is to keep the bot running while discussion is still taking place. That may just result in the bot operator having to revert all the edits anyway, so is pointless, and, given the impact thousands of bot edits can have, can be very disruptive. The recent case of BetacommandBot and the redlinked categories is a case in point. Betacommand was told by several people that these actions were not helpful - he disagreed and carried on anyway. It was this that got the bot blocked (I'm referring to Ryan's block). In general, I support any changes that prompt bot operators to be more responsive to concerns from editors, not less. Even after approval and trial, bugs or unforeseen problems may be raised. Bot operators should always be patient and prepared to wait a little bit longer, and improve the bot run a little bit more before going ahead. Also, edit summaries can be very poor. I've been looking at some files of BetacommandBot's edit summaries, and there are some that are not informative enough. I will be comparing BCBot and BHGBot at some point to demonstrate how widely bot operating practices differ. Carcharoth (talk) 09:32, 18 March 2008 (UTC)

That, unfortunately, and I can't say to be certain, Betacommand perhaps dismissed those people's comments on the grounds he didn't believe them or that they weren't his intellectual equals. I think he dismissed those people's comments because he believed they weren't valid. The problem that I wish to avoid is that I don't want Betacommand's actions to be the edge case defining bot policy. Nor do I wish to ignore that the problems arising from Betacommand's actions. It should be noted that the bot policy has been revised several times since the last time I saw it... and I thought that the main goal and concept was when there was a problem, bot operators should take upon themselves as outstanding Wikipedia members to stop their bot, and listen to other Wikipedia's valid concerns. --AllyUnion (talk) 03:18, 21 March 2008 (UTC)

A really good idea, but but but ...

I warmly welcome Martin's proposal, as a genuinely helpful attempt to find a better way to resolve some of the problems which have arisen with bots, and hopefully to identify potential problems before they cause actual difficulties. However, while I know that Martin really is sincere in trying to defuse the conflict which has lately surrounded some bots, and I think this is a really good start, I'm not sure that it goes quite far enough … so I want to offer some suggestions to build on Martin's proposal.

The first point is that while notices to community noticeboards may not elicit a response, they should still be required as part of a BRFA request. They should not be verbose, and could probably be kept to one or two template-generated lines, something like

"Approval is being sought for a bot to perform a task which may be related to this page/project. For more details, see Wikipedia:Bots/Requests for approval/FixSomeThingsBot, where your comments are welcome."

Yes, some people may find them irritating, but as long as they are not splattered everywhere, then I hope that the irritated people will be outnumbered by those who welcome the opportunity to comment, even if they choose not to use that opportunity. When I sought approval for BHGbot, I posted a notice at WT:IE, and was pleased to find a number of useful points being raised.

Sometimes the points raised will just be misunderstandings, but having the discussion to clarify things in advance is helpful to everyone, and may help to identify ways in which a useful task may be misunderstood. But even if nobody responds, I think that a "your comments are welcome" notice would have a really important confidence-building effect. It would be a clear signal that both BAG and the bot owner understand that a bot is not just a tool owned by one editor, but a device whose use may have a wide impact on the work of many editors.

Martin's suggestion of initial approval being followed by a probationary period seems to me to be a great idea, because it recognises that many editors may not appreciate the significance of a bit until they encounter it in action. If they then find that the file is still open and that comments are still welcome, we have a very good chance of resolving issues without the heat-and-fury which is generated when people feel that they have no way of making their voice heard.

I have a small technical concern here: the "extended trial" link in the edit summary is a great idea, but space is often at a premium in edit summaries, and this may grab too much of that space, squeezing out other info on the nature of the edits. (One example of this is CFD work: "moving Category:X to Category:Y per CFD link" can require a lot of characters if the category names are long). So it might be better in practice to leave it out of the edit summary, but to require a prominent "bot-on-extended-trial, please discuss at this link" notice at the top of the bot's user page and talk page.

As to what happens when there are complaints about a bot, I'm not quite so sure about that process. I don't have a better idea upfront, but I am very unhappy about relying on a BAG member to put a bot on probation, because, sadly, at the moment I have little confidence in BAG :(

My conclusion from the BRFA for the NFCC bot is that BAG is simply broken. The BRFA was shut down while discussion was underway and the concerns I raised have been cited at arbcom as evidence that I was of "engaged in disruption". Hmmm. If politely raising a concern in a discussion is "disruption", then I'm a banana.

I can understand and accept that we all make mistakes and that people can learn from episodes of conflict. If the BAG members involved in that BRFA were able to say that they can see that shutting down discussion was counterproductive because it simply shifted the debate elsewhere and raised the temperature, then we coukd all move on and concentrate on the solutions. However, sadly, so far as I am aware only Martin has done so. If BAG members not only reject community input but subsequently label objectors as disruptive, then I simply cannot trust BAG to have a decision-making role in a bot-review process.

I think the crucial underlying principle here is that a bot should not be WP:BOLD, and that bot-owners need to remember that a) they do need consensus for their bots tasks, and b) that consensus can change. I know that Martin genuinely does want to open up the bot-approval process, and to find more effective ways of building and sustaining that consensus, but the sticking point here is BAG itself. If BAG continues to include both the most controversial and uncivil bot operator and someone who not only curtails discussion but labels community input as "disruption", then why should the community have any confidence that BAG can successfully operate an improved process?

I'm sorry folks, but while improved procedures are a necessary step, they are not a sufficient step; we also need to know that the people who operate those improved procedures really do want to work with the community. So far so far I see one BAG member (Martinp23) proactively working hard to do just that, another (Cobi) who commendably reopened a closed discussion, two who seem to reject all discussion, and apparent silence from the rest.

That split in approach broke the community's confidence in the existing approval procedure, and so long as it persists I cannot have confidence that it will be any more effective in maintaining community confidence in any improved procedure. --BrownHairedGirl (talk) • (contribs) 12:08, 18 March 2008 (UTC)

Thanks for the points. For posting to noticeboards - this is something I require a lot of the time when looking at BRFAs for non-routine (interwiki) tasks. It would perhaps be handy to put that as a requirement into the boilerplate instructions. For the technical issue of using the edit summary - I think it can be worked around. If absolutely impossible, that the userpage should be used, but that increased visibility offered by having a link in the edit summary is very attractive, and so perhaps the CfD summary you cited could be changed to ([[brfa link|BRFA in progress]]) moving categories ([[Cat:adfgh|A]] -> [[Cat:asfghe|B]]) per [[WP:CFD link|CfD]], for the duration of the trial at least.

For the re-examination/probation idea - I think we should look at it like the issue of assigning rollback permissions (in a strange way, using a terrible simile). Any member of BAG can throw the bot into BRFA again, with or without discussion among BAG members here. If they think that discussion should take place before reopening it, then discussion can take place here - we'll trust members' judgement for this. If they so repeated errors of judgement, then the solution is obvious. Martinp23 13:08, 18 March 2008 (UTC)

I fully support BHG's well-worded comments above. She has covered practically everything I wanted to say, and more, raising some good points and offering some solutions. The issue of whether some bot operators only want a BAG on their terms is still worrying. It speaks to the underlying inability to work with others, and more importantly, an inability to work with those they disagree with. Carcharoth (talk) 14:45, 18 March 2008 (UTC)

To BHG, one of the planks of this proposal was that only a single BAG member would be needed to agree that a complaint warranted probation for it to happen. The idea being that this would rule out frivolous complaints. If you do not have confidence in any members of BAG (it would surprise me if you have had dealings with all them), then there is no proposal for more intensive review of bots by BAG that you are likely to agree to. Are you saying that your concerns could only be addressed if BAG were removed from the process? WjBscribe 15:46, 18 March 2008 (UTC)

You're right, I have had dealings with only a few BAG members, at least in a BAG context (e.g. I have dealt with Reedy Boy (talk · contribs) on other issues and he was very helpful).

However, I didn't say (and didn't mean) that I have no confidence in any members of BAG, but rather that I don't have confidence in BAG as presently composed to handle this process in a way which will maintain the community's confidence.

I think that we do need a BAG, and I don't object to the principle of a BAG member being the one to press the "go" button on a review, but when we still have BC and ST47 defending the previous curtailment of discussion, I don't have any confidence that that requests for review will get a fair hearing or that they reviews will not be summarily closed if they offend those users. (After ST47 closed the NFCCbot BRFA, the only BAG member who I have seen to object was Martinp23, in his arbcom evidence. Other discussions may have taken place elsewhere, but if so, they didn't change the situation).

The solution is not to remove BAG from the process, but to remove from BAG the members who are actively hostile to community input. --BrownHairedGirl (talk) • (contribs) 20:38, 18 March 2008 (UTC)

I think that it would also be fair to summarise for the members of the BAG who are reading that there is more than a little confusion within the community that the issues with Betacommandbot do not actually appear to have even been addressed by the BAG. There are references to off-wiki communication, but this is counterproductive to the appearance of impartiality by the BAG. In particular, there does not appear to be a precise list of rules and procedures for bot approval and operation. The role of the BAG during the operation of approved bots needs to be better defined, since at the moment complaints are bounced between ANI and Arbcom without ever approaching a BAG page. Wikipedia:Bots#Dealing_with_issues does not deal with systematic problems of a bot or operator. The following are points which I think are particularly important to address:

1. Splitting of bots into multiple user accounts
2. Adding additional tasks to an approved bot which are not related to previous tasks
3. Taking into account the community's weighting of advantage vs damage for bot tasks which must necessarily be imperfect (spellbots, category correction)
4. What does the BAG do if the community objects to a particular bot?
5. What does the BAG do when an operator uses his bot for an unapproved task?
6. What is the BAG's view of non-interactive, unsupervised scripts without a bot flag?

As I have made clear to betacommand, I think that the problems which have arisen with his bot are primarily due to a failure to the BAG to address the points above. In particular, I think that the BAG needs to move away from the idea that all approved bots are operating under community consensus. To this end, I would encourage members of the BAG to consider the idea which is floated elsewhere to have a Request for Bot Approval, on the RFA page, but only for bots which already have the bot flag, and which have been shown to be troublesome. I can't imagine sinebot needing to go there, but I think it would help a lot if there was a clear standard for community approval for such bots. If, as the BAG claims, a bot such as the Fair Use Bot is essential for the survival of wikipedia, but couldn't pass such an approval process, then the operator should have no problem getting the Wikimedia foundation to approve the bot (and even give the bot an admin flag), much as the foundation does for its employees. AKAF (talk) 13:38, 19 March 2008 (UTC)

Comment by CBM

I'm treating this as an RFC and leaving a comment without directly replying to the comments above.

My main concern with the proposals is that they don't appear to distinguish between the majority of bot requests that have a chance of getting approved, which are uncontroversial in every way, and the small minority of viable requests that might warrant broader discussion. Requests for interwiki bots, talk page archiving bots, AWB bot flags, etc. don't need a lot of community discussion. They just need an experienced person to review the technical details, and that's the point of the BAG process.

Most of the requests that would be unacceptable more broadly (such as spelling bots) are routinely denied without need for long discussion. That only leaves a small handful of tasks that might actually be approved but would also be controversial. The easiest thing to do for these is to start an RFC about the task.

So I don't see a need to revise the bot approval system. Everyone should remember that the goal is to have a system that bot operators will voluntarily follow before adding new tasks to their bots. The more complex the BAG system becomes, the more operators will simply ignore it. — Carl (CBM · talk) 12:36, 18 March 2008 (UTC)

Point taken, but I suggest that CFD is a useful comparison. The procedure is there for extended debate, but people don't have to use it, and very often don't. I suspect that many (perhaps most) bot probationary periods would pass without comment, and that's fine: what matters is that if there are concerns about a bot, that there is a lightweight way of raising those concerns withiut the necessity to open an RFC. --BrownHairedGirl (talk) • (contribs) 13:00, 18 March 2008 (UTC)

Mmm yes - it's worth me noting again that the probationary period can pass by without a hitch at all, and not be any hiccup at all to the operator or the BAG. If however an issue is raised that shows community upset about the proposal, then we've saved a lot of the bureaucracy of an RfC and the system has worked well. The only times that there could be a hint of intervention required in a probation periods is at the end, and if a problem comes up. And, it must be said, if a problem does come up then it is all worth it. Martinp23 13:11, 18 March 2008 (UTC)

I remember that the last time there was talk of making the bot approval process stronger, it seemed quite possible it would simply result in the dissolving of the BAG altogether. The process is on shaky ground as it is; we have essentially voluntary compliance by established operators, and additional restrictions are unlikely to help the situation. I don't see why we can't simply ask the BAG to be more firm in their discretion to seek outside comment for the few requests that warrant it. — Carl (CBM · talk) 14:09, 18 March 2008 (UTC)

Those who ignore the approvals process are going against the word of WP:BOT: "Bots must be approved before they may operate." Rather than taking this stance, perhaps they could serve the community better by helping to refine BAG/BRFA operating procedures. Martinp23 14:16, 18 March 2008 (UTC)

I'm thinking of comments like this one by Cyde [5] who as he points out was running an "approved" bot. There was also the discussion at the MFD last year. A common thread I have seen throughout these discussions is that BAG continues to exist only by being sufficiently convenient that not too many bot operators choose to ignore it. Personally, I only continue to file new "task requests" because the hoop is sufficiently low for my taste. — Carl (CBM · talk) 15:48, 18 March 2008 (UTC)

Cydebot is one of the better bots, doing a clearly important job and doing it with a very low error rate, and Cyde (talk · contribs) is both civil and helpful when it questions arise about the bot; I have sometimes dropped in to lend support when Cyde faces a why-did-your-evil-bot-delete-my-category-you-swine rant. But I'm disappointed that in the linked comment Cyde took such a casual attitude to BRFA, because the process isn't that tedious and getting approval is a policy with a very useful purpose in maintaining community support for bots.

So I'm wondering if there could be some synthesis here of the concerns of bot owners and the concerns of the community. The lengthy threads at ANI indicate a need for greater community input on bots, but some bot-owners (who perform a valuable service) find the BRFA process cumbersome. Could we perhaps review the process to see how it could be simpler to use, while still allowing more community input?

I'm thinking of something along the lines of the reforms made about a year to the AFD process, where smarter templates made the task of opening a nomination very much easier. Before then, I used to dread making an AFD nom, because it involved reading a complicated instruction page and tabbing back-and firth between difft pages. Now, I just put {{subst:AFD}} in the article and all the links and instructions appear in the article ... and Twinkle automates the while thing so smoothly that I will probably AFD myself one of these days.

Without going for something as elaborate as Twinkle, could we consider a template redesign to make a BRFA request easier?

One of my suggestions above was for a template pointer on noticeboards, and that wouldn't have to be done by bot-owners — it could be done by BAG members (if they have the energy), or by others taking on a helping role much as the clerks do formally at arbcom.

However it's done, some synthesis is needed. It is important not to create unnecessary hassles for bot owners, but I hope that responsible bot-owners such as CBM and Cyde can also that we do need to find a better way of pre-empting off the sort of conflicts that have arisen over less responsible bot-owners, as well as a better way of resolving conflicts when they do arise. I do hope that those two objectives can be shared objectives. --BrownHairedGirl (talk) • (contribs) 16:16, 18 March 2008 (UTC)

My piece to add is that it does not seem that the existing BRFA process is broken (maybe backlogged), so much is the process to un-approve bots nonexistent and that post-approval monitoring of Bots is rather hit or miss. Maybe if we could define the procedures for a reverse BFRA to the same extent we've done with the Admin RFC (essentially a reverse RFA), then when these threads pop up on ANI, we can just say "Go write up at page X and see if anyone else feels its a concern."

As far as post-approval monitoring, short of making Bot ops link their edit summary to each task approval, I'm not sure how this can be monitored. I've been working with WJBscribe to deflag inactive bots, which should make the Bot flag list shorter, but without some sort of Bot logging function, I don't have an answer.

And I know I don't operate a bot or have programming knowledge, but I'd be willing to volunteer my time helping with the backlog at BRFA is anyone thinks it would be helpful. MBisanz ^talk 18:23, 18 March 2008 (UTC)

Minimizing bureaucracy

In general, I think we should move incrementally to strengthen controls over new bots, while being careful about the amount of extra work those controls can cause. Extra work for BAG means less time contributing in other ways to the project. If we put in some new controls, and then don't prove adequate, then (and only then) should be add yet more.

In that light, I suggest something like this:

• Distinguishing between bots that are flagged (because they're doing non-controversial edits) and bots that are not. The system for flagged bots could stay as is.
• For bots that would not be flagged, posting not to community noticeboards but rather to the talk page of the most relevant policy or guideline, with a brief description of what the bot is doing and a link to the BRFA page. It would be up to the bot owner to indicate what talk page he/she proposes to post at, and what the text would say.
  • Doing the posting at the point where the bot has been approved for a trial run.
  • Waiting for five days after the trial run is completed to see if any objections are raised.
• For bots that would not be flagged, having a probationary period, as mentioned above. (I suggest 2 weeks rather than a month.)
  • Bots in the probationary period would have a link to BFRA in all edit summaries
  • At the end of the probationary period, formal approval is needed; until that is given, the bot should not continue to operate.

I think reconfirmation is just too much work/bureaucracy - if there problem is with less than (say) five percent of bots, why do reconfirmation for 100%. (Even for non-flagged bots, I think reconfirmation is excessive. At the minimum, we should wait to see how other changes work out before taking such a drastic step.) -- John Broughton (♫♫) 22:46, 19 March 2008 (UTC)

No one is suggesting a full reconfirmation - just reconfirmation on a case by case basis where issues are raised. Flagged bots need to go through the same approvals process as unflagged bots - after all both types should have community approval. The flag is just something used to hide the bot in rc. Martinp23 00:12, 20 March 2008 (UTC)

Existing practice and what to do about it

As far as I can tell, current practice is to direct potentially controversial bots to a suitable forum to discuss what it proposes to do (as opposed to how it proposes to do it, which is unarguably the mandate of the BAG). Perhaps codifying this would be a good idea, but adding an extra layer of approval process will not be of any significant help.

I know that I've sent more than one request to the VP (and, indeed, one to RFA) when there was doubt that the task itself might have been problematic— which is not that often when you look at the archives. Almost invariably, those forwarded discussions either generate absolutely no comment, or a very tiny handful of comments— certainly not enough to make more than a blind guess at what consensus really is.

Which leaves us at the BAG in an odd position— we either rule on "likely to be uncontroversial" or let bot proposal for potentially valuable and useful bots rot because of lack of interest either way by the community at large which is, and always will be, generally unconcerned about bots.

I know this isn't going to be liked much more that the proposal above, but at least the scope of added bureaucracy and drama will be reduced: Have an RFA-like process for BAG membership but otherwise give BAG members wide latitude in approving bots. There is no way we can get the community to pay attention to bot approval— especially since the vast majority of bot requests are trivial, boring and uncontroversial— because, frankly, it is boring crap for the most part.

Let the community pick a number of editors that are trusted for their technical acumen and judgment, and actually trust them. But open that process of selection to the wide public and give it enough exposure that a more significant fraction of the community gets to chime in; the current process admitedly does give too much weight to in-group thinking regardless of how much good faith goes behind it.

It's bureaucracy, but BAG membership "election" would be infrequent (unlike actual bot approval which is high-volume comparatively). And I would expect that, in practice, a dozen or so BAG members is all that's needed at any one time to take care of business. — Coren ^(talk) 23:32, 20 March 2008 (UTC)

I like this idea since its a medium between anyone can join BAG and only BAGers select future BAGers. Sorta like crats and admins. Once they've proven their trustworthiness and ability to the wider community through RfX, their given wider latitude in things like CSD and renames. MBisanz ^talk 23:35, 20 March 2008 (UTC)

Automated and semi-automated

Since we're discussing bot policy revisions, I would like to bring up again the distintion between automated and semi-automated bots. According to WP:BOT, semi-automated ("assisted") bots do not need approval. I've seen editors making repetitive questionable edits defended from a block citing this part of policy. Without an operational definition of semi-automated and automated editing, there is a loophole. The distinction seems to me related to the response time of the operator. I propose an operational definition of an automated bot is any repetitive edits where the operator does not respond within some reasonable time, and I think a reasonable response time is 15 minutes or less. Therefore, if an "urgent" query doesn't get a response in 15 minutes, we would presume the operator is offline and the policy for an "automated" process applies. Comments? Gimmetrow 22:37, 18 March 2008 (UTC)

I'd wonder if this wouldn't be easier to police on an edits per minute basis. As in, if an editor is making 10 edits per minute using AWB for 40 minutes straight, I'd say he's approaching Bot speed. MBisanz ^talk 03:19, 19 March 2008 (UTC)

That's another consideration, but I think the essence of an automated script is that it runs without the operator (to check and approve each edit). I have in mind a situation where a user's account was tied up for an hour while javascript in his monobook made edits. The user was unable to respond to comments. Even if the script only performed 2 edits per minute, because the operator could not respond, I would think the script ought to be reviewed for technical problems first.

I also think fast scripts should be reviewed for the technical issues, but for slightly different reasons. Fast edits are difficult to review by hand. Until the maxlag feature was added, unapproved (unflagged) scripts were limited to something like 2 edits per minute by policy. One aspect of the first BRFA is to review whether the operator can be trusted to run bots; bot approval partly means the operator is trusted to make good use of fast automated editing. Subsequent tasks tend to be reviewed quickly if there are no technical concerns. Gimmetrow 04:11, 19 March 2008 (UTC)

I don't know the technical end of it, but maxlag has always scared me to some extent, as it permits almost unlimited editing speeds at certain times of the day. And we've seen problems before with scripts that aren't fast, but are long and unmonitored, such as Maxim's deletion script that until recently wouldn't detect changes made after the script started. I'm beginning to wonder if all edits over a certain speed and all unmonitored editing should be included in the definition of a Bot. MBisanz ^talk 05:20, 19 March 2008 (UTC)

That's basically what I'm saying. I think either unmonitored or fast editing scripts should be reviewed and "approved by someone". Gimmetrow 06:04, 19 March 2008 (UTC)

Maybe the 2 epm restriction should be re added to the policy? I know it is perfectly possible to edit the normal way at a greater rate but is not very common. People wanting to use a semi automated script/bot at greater than 2epm need to get it approved? (But probably not flagged) -- maelgwn - talk 06:14, 19 March 2008 (UTC)

There's no such thing as bot speed. Bot-like editing means automated (usually repetitive) tasks, not a particular speed. Semi-automated editing can at least reach a dozen edits per minute (especially anti-vandalism work), and a bot could perform repetitive tasks at one edit per day: "bot-like speed" really is a misnomer. I'm not sure what the point of limiting semi-automated editing is, since by definition, every edit is approved and the responsibility of the editor. If he/she makes a mistake, it is entirely his/her fault. (Disclaimer: I do a fair amount of semi-automated editing, and am not exactly neutral on this issue.) Do you have any examples of editors using the semi-automated editing card to fend off blocks? Gracenotes^T § 15:41, 19 March 2008 (UTC)

The main reason I have heard to slow down semi-automated editing is that it can overwhelm the recentchanges queue, making it hard for vandalism patrollers. Flagged bots are easier for them to ignore, apparently, as are admins. It would be possible to make a multithreaded version of AWB that edits at enormously high rates, but there isn't any reason to do that. My rule of thumb is that if so many edits need to be made that an average rate of 5/min is too slow, then a bot account is warranted. — Carl (CBM · talk) 15:50, 19 March 2008 (UTC)

Yes, Grace, an editor making arbitrary style changes on hundreds of articles has been defending from a block on the grounds the edits were "assisted editing". I'm assuming an automatic bot making non-consensus style changes would never be approved. Gimmetrow 21:39, 19 March 2008 (UTC)

The editor in question should have the same responsibility for the edits as if they were committed manually. Because, they were in fact (if truly semi-automated) committed with manual approval. Do you mean style changes like this, or something more controversial? Gracenotes^T § 01:53, 20 March 2008 (UTC)

It was something else. But I ought to point out that moving refs can be controversial, and the regexes commonly used by AWB users have flaws. I'll discuss your regexes on my talk page, if you like. I can't find them in your .js files. Gimmetrow 02:11, 20 March 2008 (UTC)

I should point out that, in my mind, at least, there is no ambiguity. A semi-automated task is one where every edit (or, at the very least, every series of directly linked edit) requires positive input from the operator. AWB comes to mind in its usual operation mode (see change, click to save). I doubt there are any members of BAG that operates with a significantly different definition. — Coren ^(talk) 01:46, 20 March 2008 (UTC)

Would an assisted script include one where an editor "approves" every edit and then lets the script run for an hour? Gimmetrow 02:11, 20 March 2008 (UTC)

"Approving" an edit means that each edit is approved (normally by visual inspection, either of the resulting new version, or diffs, or both) shortly before it is saved. Your case "... then lets the script run for an hour" seems more like a bot mass-storing preprocessed edits, which is something else. The quality of an approval process is of course never guaranteed, some are better proofreaders than others. If the inspection is done by a program, then the process is no longer semi-automated but fully automated. Oceanh (talk) 04:22, 20 March 2008 (UTC).

Of course people make mistakes, and that's understandable. The concern is when people use AWB or some semi-auto tool to do large numbers of potentially controversial but undiscussed edits, to the point that it becomes a de facto "standard". Do we deal with such tasks as a bot task needing approval? Or some other way? Gimmetrow 05:01, 20 March 2008 (UTC)

I see your point. Programs/bots/scripts are great tools when applied "correctly" (and with care), but can do much harm if they perform a "wrong" (unwanted) task, or if they operate in a buggy way that mess up articles. I think an important question is, how easy is it to revert unwanted edits/results. An editor should always be prepared to (and able to) revert unwanted edits herself, if "asked by the community". I would say that for a task that is not approved, one single objection is enough to stop the process, and discuss how to proceed further. Oceanh (talk) 05:30, 20 March 2008 (UTC).

I think thats actually a rule (Martin?) - Or at least, a community accepted rule, that someone should at least offer to either revert bad edits, or assist in reverting them. Sometimes more experienced users can do it easier, and this happens. —Reedy Boy 08:10, 20 March 2008 (UTC)

If the problem is that the recent changes log is getting overwhelmed, then the answer is to make the recent changes log bigger, not to put bureaucratic obstacles in the way of people trying to make Wikipedia better. I've certainly approached "manual" 15 epm when WikiProject tagging with AWB - restricted to 2epm it would have taken all day to tag a couple of hundred articles. There's already an "approval" mechanism for "fast manual editing" built in to Wikipedia in the form of AWB approval, so I'd suggest that if people have that, then they have licence to edit as fast as they want (and AWB approval is revoked if there's a problem). Then you're just left with people rolling their own edit bots; but given how fast people can edit without AWB or anything I'd suggest the default definition of "too fast" should be nothing less than 6epm, possibly more. FlagSteward (talk) 11:04, 21 March 2008 (UTC)

Trial periods...

So, it seems to me, that sometimes, trial approved bots kinda... get lost... Feel free to revert me, but, I made a new section for bots that have completed the approved trial, that re-transcludes them on this page, to allow for further community discussion. [6] SQL^{Query me!} 02:58, 20 March 2008 (UTC)

For right now, I've changed the status of those bots to Open. Someone more knowledgable than I should probably implement a |TrialComplete parameter (and, fix whatever generates the report, to reflect it too) SQL^{Query me!} 03:01, 20 March 2008 (UTC)

Um im not sure how it is any different from 'Open', except where it is located. And who is going to move it? It is rare that much discussion occurs after the trial, so it would make little sense for a BAG member to move it before approving it and it would complicate it too much for an operator have to do it because they wouldn't know they have to. Unless a bot is going to do it? (Maybe a trial completed template would work, this would then show up on the listing on the page also.) -- maelgwn - talk 08:25, 20 March 2008 (UTC)

Having just taken 12 days from trial completion to approval, I'm quite aware of this. :-)) Just as a general comment, it would be good to make it a bit more explicit (in section III - or IV?? - of the instructions) what happens after a potential bot owner has run his trial. I kinda assumed that the person who approved FlagBot's trial would be watching the page for changes, but after nothing happened for a week, I first left him a message, and then a day or two later slapped a "needs attention" flag on it. It didn't help that my "BAG contact" was Betacommand I guess, I imagine he's got other things on his plate at the moment. ;-/ But in the first instance, some more explicit instructions would help (once you've finished the trial, mark it "needs attention" presumably? And in the longer term, a "trial complete" tag would make a lot of sense, to distinguish them from bot approval processes that need attention in some other way. FlagSteward (talk) 11:26, 21 March 2008 (UTC)

Rambot

It's always been my stated intention to run the rambot again after the next U.S. census, but that's still a couple years away. I also had some other approved tasks that I wanted to eventually perform. I don't see the need to de-flag it and I may want to run it again sometime, since it isn't hurting anything, but it's also not the end of the world if it is deflagged. I'll request it again as needed if I have to, so long as the process to get the flag isn't endless and mundane, otherwise I'll just do something else. In any case, bot policy was essentially formed as a result of my bot anyway. I have a very long history of useful results, so there is no reason to remove the bot flag simply because you think it could be abused in the future. That's just totally ridiculous. Also, there is always work to be done. The fact that I rarely have time now to do any such work does not mean that I won't in the future. -- RM 21:16, 20 March 2008 (UTC)

Current Bot Policy

Okay, this is a summary of what we have so far, from what I gather on this page. There is a consensus that something needs to be done about current bot policy without necessary adding more bureaucracy to the whole issue. This is not new before, but the policy discussion regarding the bot policy has never been highly involved, honestly. I have separated the issues raised into sections that can be discussed in further in-depth.

It seems like the bot flag, from historical reasons, stems from importing census data into the Wikipedia. Since then, the bot policy page has been defined and refined many times over in order to clarify what it meant to get a bot flag. With such projects as pywikipedia, the perl wikipedia framework, and AWB, the definition changed and had to allow for the development of newer bots and tools. --AllyUnion (talk) 02:43, 21 March 2008 (UTC)

Avoiding more bureaucracy

Several users, and myself including, wish to avoid further complications to the bot approval process. We don't wish to make it long and more complex than it is. --AllyUnion (talk) 02:53, 21 March 2008 (UTC)

Proposal: Add an additional trial period

Martinp23 has suggested to add another trial period.

Proposal: Leave the policy as is

I have suggested this, and that the policy should be left alone based on technical grounds, which this policy page is ultimately for the approval of the bot flag and the technical aspects thereof. --AllyUnion (talk) 02:53, 21 March 2008 (UTC)

Proposal: Monitor Talk page

I'm all in favour of minimising bureaucracy, having just gone through the process myself. ;-/ I was wondering, would one way to flag up bots with "issues" be to monitor the Talk page of the bot? More than "x" Talk edits per month and there could be a problem. An even neater way to "involve" the "ordinary", less technically aware Wikipedians would be to roll some kind of form which had to be transcluded at the top of every bot Talk page where registered users could vote: Do you think this bot is doing a good or bad job? Once there's more than "y" complaints per month, someone looks into it. That way you'd get fewer false positives and hopefully more ordinary punters contributing to the process, they might vote in a poll even if they were reluctant to write a formal complaint. FlagSteward (talk) 11:16, 21 March 2008 (UTC)

Believe it or no, not all bot talk page edits are complaints, so I don't think this is itself automatable. I think there should perhaps be a clearer "escalation route", for when someone fails to get satisfactory resolution of their issue, or if someone happens to note a large number of complaints about the same bot. (It's not like there's an actual lack of venues to discuss such matters, but I couldn't definitely say which should be the 'first port of call.) Alai (talk) 05:05, 22 March 2008 (UTC)

I suppose it should be clarified the steps needed to flag attention to shut down a bot. At the current moment, it's rather vague and people tend to read it as... "report it to AN/I anyway" --AllyUnion (talk) 11:36, 22 March 2008 (UTC)

Sure Alai, that's why I said an active Talk page could indicate a bot that the community had problems with. But it would be easy to come up with something that filtered bot Talk pages with >x edits in the last 3 days say, where x was set differently per bot, low (10?) for bots in their first month, rising to say 100 for WP 1.0 Bot or something. Most problems should show up in the first month - but we want to at least have a chance of catching an established bot that "goes rogue". It would then take somebody just a few seconds to check the half-dozen bots with "unusual" levels of Talk activity, to see if they're being showered with barnstars or going down in a hail of flame. That human then gets to decide whether to forward the bot to a complaints procedure or not, or otherwise perhaps increase x for that bot. Don't forget, we're looking to minimise bureaucracy, minimise the work involved, and involve ordinary Wikipedians as much as possible. The ordinary Joe doesn't know about BAG, they expect to interact with other "users" via their Talk page. FlagSteward (talk) 12:51, 22 March 2008 (UTC)

Proposal: BAG election

Coren has suggested that elections be held by the community to deal with violations of bots and bot owners, much like the ArbCom deals for normal people. --AllyUnion (talk) 02:49, 21 March 2008 (UTC)

Bot owners have ceased to be normal people? Oh. :) I feel that this might be going a little too far, but I think that something has to be done to increase the interaction between the community at large, and the bot approvals process. Firstly, the whole "technocrat" thing has to go. Having leet programming skilz is all well and good, but it has only a relatively small bearing on the approval process -- or at any rate, on what the approval process should be. Given the that bureaucrats have made it explicit that they're essentially just going to be rubber-stamping what the BAG decides, it's all the more crucial that the approval process is, and is seen to be, determining the consensus for a given bot task, whether in the form of established policies and guidelines, or explicitly on a case by case basis. Perhaps we should take this to its logical conclusion, and ask that flag-setting be split out from the BC role, and assigned as a separate permission (or if we end up talking to the dev hand on that one, at least make the distinction in on-wiki process). That might induce the community to pay a bit more attention to "approving the approvers". Alai (talk) 04:44, 22 March 2008 (UTC)

Well, specifically, I think what Coren meant was, and he'll need to correct me if I'm wrong here, the BAG is essentially an ArbCom for bots. Any problems with the bot owners should still be handled by the ArbCom, should normal dispute resolution processes fail. In regards to the technical aspect, well... if you really want to boil down control, bots are permitted because the developers allow it. The way I see it, BAG should consist of some people of technical knowledge to lessen the burden of the developers. --AllyUnion (talk) 11:42, 22 March 2008 (UTC)

I would strongly agree with cutting out the middle-man by allowing members of the bot approval group to set/unset bot flags. Any delegation of power (but with reasonable community input into the decisions) is ultimately a good thing, provided those who we delegate power to know what they're talking about, and are trustworthy. — Werdna talk 12:53, 22 March 2008 (UTC)

I don't know if it's needed to have BAG members be able to give or take back the flag themselves anymore than it is needed for AC members to be able to desysop directly; but yes, I did mean that the BAG should be elected at large then given real authority over bots— this would give a clear place to bring grievances, and would increase general confidence that someone is keeping an eye on bots. The 'crats are responsive to bot-related requests from the BAG so I don't think we need to worry about the extra step. — Coren ^(talk) 14:20, 23 March 2008 (UTC)

Dealing with "semi-automated" definition

The history behind this is stemming from the development of AWB. The reason why it definition was added was for the purpose that editors, although doing the task manually, were still assisted to the point that a bot flag was necessary for some users. --AllyUnion (talk) 02:43, 21 March 2008 (UTC)

Proposal: Bot operators must prove the same definitions as their bots

Before, I recall that there was a discussion that we had to prove that bot operators had to prove that they were useful and harmless. In light of recent events, it seems like this discussion may have some merit. --AllyUnion (talk) 02:46, 21 March 2008 (UTC)

• Requests for approval by very new or problematic users are already being denied, what else could be done? MaxSem^{(Han shot first!)} 06:31, 21 March 2008 (UTC)

• • This is true, but it's not explicitly outlined in the policy. --AllyUnion (talk) 07:01, 21 March 2008 (UTC)

Proposal: Problematic bots should use the RFC process

"The easiest thing to do for these is to start an RFC about the task." — Carl (CBM · talk) 12:36, 18 March 2008 (UTC)

Issue: Deflagging bots

RM has raised the issue about deflagging inactive bots. Personally, I don't see what the harm is leaving an inactive flagged bot, especially if the bot hasn't had any problems, and we have already gained trust with the bot operator. --AllyUnion (talk) 02:58, 21 March 2008 (UTC)

You can blame this one on me. Last month there was a discussion of Bots with official sounding names possibly being a bad idea, since Bot policy says a bot name should specify its a bot and relate it to the owner's name, like Z-Bot being related to Z-man. So I went and compiled a list at User:MBisanz/Botlist of all the bots that seemed to have official names. In doing so, I realized a bunch of these bots (8/74 actually) hadn't edited ina really long time. So I had the idea to contact the bot ops and see if they didn't mind deflagging dead bots (bots that will never operate) just to keep the house of accounts that have the Bot flag current/in order. Once I was done with those 8, I realized it would be an easy task to check all ~400 bot flagged, accounts, which led to the 80 accounts I notified. Working with crat WJBscribe, we agreed to only deflag bots where the operate explicitly said they could be deflagged. It wouldn't be overturning their BRFA or revoking their status as a bot op, just a housekeeping sweep. Sorry for any confusion. MBisanz ^talk 06:20, 21 March 2008 (UTC)

Issue: Dealing with bot edit summaries

The issue has been raised that some kind of standardization should be imposed on bots. There are, of course, technical limitations to this, however the point is valid. --AllyUnion (talk) 03:03, 21 March 2008 (UTC)

Issue: Splitting bots into multiple user accounts

I think this isn't something we should insist on in every case, otherwise we'd get a profusion of bot accounts, and get into all sorts of semantic games about what a "new task" is (which already comes up, given the approval process, but isn't exactly hard and fast). But for tasks that have are anticipated, or in the course of events prove to be controversial, or indeed where the operator has attracted such concerns, the BAG (or its hiers and successors) should definitely look at making approval of a task, and come to that, continued approval of a task, contingent on separation of functions into multiple accounts. Otherwise, there's a clear risk of running into "take it or leave it"/"my bot is effectively unblockable" issues. Which of course, we potentially have to address anyway, since some ops might refuse to comply with such a regime, but... Alai (talk) 04:27, 22 March 2008 (UTC)

No bot is unreplaceable. Most of them are only a few hundred lines of code, and we have plenty of operators willing to play by the rules. — Werdna talk 12:50, 22 March 2008 (UTC)

I entirely agree with you as regards actual replacability and complexity. (Possibly with the exception of the anti-vandal bots: I have no idea how those are actually operating, and they could be made as elaborate as one wished.) But in practice, there seems to be a great reluctance for a bot performing a "controversial" task -- or indeed, a manifestly unapproved, counter-consensus, and technically wonky one -- to get blocked, and moreso to remain blocked, if it's also performing some other "useful", or allegedly "essential" task, or set of tasks. It'd do no harm to try to grease the wheels of bot policy enforcement, which currently seems to be extremely patchy. Often, there seems be a large "bureaucratic" delay in the approval of fairly straightforward tasks, while other tasks that never go near the approval process, or whose subsequent issues transpire not to have been anticipated in same, sail on merrily, . Alai (talk) 18:14, 22 March 2008 (UTC)

I will personally re-code any bot that is considered to be "irreplaceable". We have no time for people who think themselves above the bot policy because nobody is game to block their supposedly essential bot. — Werdna talk 23:49, 22 March 2008 (UTC)

OK, this is a good thing. But are you suggesting this in this context, by way of a counter-argument to splitting, or do you agree that it can be appropriate to ask for this? (With my rationale, or otherwise.) Alai (talk) 00:46, 23 March 2008 (UTC)

Personally, different bots split out the tasks it does, and whatever breaks, can break on a separate bot account. I created separate bot accounts because they helped tracked down cleaning and such. Sandbot was specifically separate for that reason. --AllyUnion (talk) 09:05, 23 March 2008 (UTC)

I agree that this should be a requirement. A different bot account should be created for every distinct function; if only because then it's easy to undo accidental damage with a mass revert. — Coren ^(talk) 14:32, 23 March 2008 (UTC)

Issue: Adding additional tasks to an approved bot which are not related to previous tasks

I think, for the purpose of scope and narrowing down problems, separate user accounts should be created. --AllyUnion (talk) 09:02, 23 March 2008 (UTC)

Issue: What does the BAG do if the community objects to a particular bot?

In my opinion, the bot should be blocked until further notice until BAG reviews the reasons for the objection, which has been my opinion of the standing policy. --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

There are two classes of objections:

Objections to the task

Should result in the bot's approval being temporarily revoked while the issues are sorted out. Bots should absolutely only ever run approved tasks (i.e. tasks that would not attract issues if they were done by a human). This is particularly important because bot edits need to be mass-reverted.

Technical objections

Should result in an immediate revocation of approval if critical (i.e. security). Otherwise, discussion should occur first (as the BAG's approval is prima facie evidence that the bot is technically sound).

— Werdna talk 12:50, 22 March 2008 (UTC)

Issue: What does the BAG do when an operator uses his bot for an unapproved task?

Per the bot policy, the bot should be blocked. Specific unapproved tasks require approval by the BAG. The approval process to me has been a technical oversight in the ability whether a task can be reasonably completely automated. Essentially, the process was put in place to prevent spell bots and the like from appearing. The primary idea was to prevent a bot from doing tasks that had a high rate that would require manual intervention and undoing. --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

This is something I think could be improved. The first BRFA checks, among other things, the operators qualifications. Other tasks within the range of that expertise ought to be considered OK technically. That doesn't really address consensus, so some time ago I proposed that subsequent tasks be posted somewhere and given adequate time for comment; if a few days go by without objection, the task would be considered approved. The benefit is that only tasks which significantly expand the range of operations of the bot would need an "additional task" BRFA, reducing paperwork and encouraging better documentation of bot operations. "Adequate time" would also mean tasks shouldn't be done minutes after a BOTREQ. Gimmetrow 19:50, 22 March 2008 (UTC)

Ideally, no BRFA should go by for several days without some sort of comment; during that time, some sort of link to a reasonably-appropriately-scoped local consensus, or a relevant guideline or policy should be produced. If it's not, someone should prompt for something along those lines. If it is, and it isn't otherwise fishy, it starts to become reasonable to wonder why it's not been approved yet. However, I'm not sure we should be moving towards "approval by default", so much as being more speedy and proactive in getting to that point. If necessary, having some more BAG members might be helpful (especially if they're focused on determining said consensus, as opposed to seeing the role as some sort of mini-dev position...). Alai (talk) 21:27, 22 March 2008 (UTC)

In point of fact, I have come to BOTREQ to find some task proposed and already complete, often without technical problems, that I object to on consensus grounds. Gimmetrow 22:18, 22 March 2008 (UTC)

Approval by default was actually the status quo two years ago. --AllyUnion (talk) 09:01, 23 March 2008 (UTC)

Again, most bot tasks are uncontroversial even if they do not have a discussion leading to consensus— the trick is to make sure that BAG member have an explicit mandate (and trust of the community) to make that judgment call in the simple cases. — Coren ^(talk) 14:28, 23 March 2008 (UTC)

Issue: What is the BAG's view of non-interactive, unsupervised scripts without a bot flag?

Personally, it should be brought to the attention of BAG, and reviewed a case by case basis. Particularly, members of the RC patrol should weigh in on this particular point of the discussion --AllyUnion (talk) 03:11, 21 March 2008 (UTC)

I may be missing something, but why wouldn't this be "block on sight"? Or at least, block if speedy resolution is required, and discuss with the op in the first instance if not. If someone insists on running such a script, and not requesting approval, or a flag... Do you have any particular instances in mind? Come to that, I'd suggest much the same thing for unapproved tasks being run on flagged accounts, but I suppose that's a different issue. Alai (talk) 04:20, 22 March 2008 (UTC)

There are instances where such bots are permitted to do their thing, but in no way they should be left unchecked -- and therefore should be patrolled by RC group. The speed, however, of the edits should be kept to a reasonable limit so as not to flood the RC feed. --AllyUnion (talk) 11:44, 22 March 2008 (UTC)

I'm still not quite sure what sorts of cases you're getting at here: are you speaking of bots that have been "grandfathered in", and you're suggesting they should be explicitly re-examined? All of those that I can think of do have bot flags, though, so are better covered in your later question. Alai (talk) 18:21, 22 March 2008 (UTC)

I'm saying that, according to the bot policy, there are some bots that are running without bot flags with the full intention that they should be reviewed by the RC patrol --AllyUnion (talk) 08:57, 23 March 2008 (UTC)

If unapproved, they should be blocked on sight. We have a bot policy for a reason. — Werdna talk 12:46, 22 March 2008 (UTC)

Some bots have been approved to run without a bot flag. I can't remember the exact cases. Gimmetrow 19:39, 22 March 2008 (UTC)

If the question here is actually "should the BAG be approving bots to run without a flag?", then yes, it already is, and I don't see any problem with this, assuming that there are no other "issues" with the task, and the edit rate is low. Alai (talk) 19:53, 22 March 2008 (UTC)

I don't think the issue is "bots without flags" so much as "unapproved bots". There are a number of cases where it is desirable for an approved bot to not get a bot flag (anti vandal bots come to mind, as their edits showing in recent changes are a requirement). Unapproved automated bots should normally result in an immediate block— the amount of cleanup a misbehaving bot can cause in a few minutes of operation can take hours to clean up. — Coren ^(talk) 14:25, 23 March 2008 (UTC)

Issue: Bot names

Just as a comment from an ordinary user, it would be helpful if there was a rule that all bot user names ended in -bot. It's not immediately apparent that eg User:RoboMaxCyberSem is any different to a human editor - you shouldn't need to go to its user page to find out that it's a bot when it could so easily be made clear from the name. And conversely humans were banned from user names with -bot on the end. FlagSteward (talk) 12:22, 21 March 2008 (UTC)

I think that's reasonable... but only to a point. Given if the edit summaries are standardized, this might be a moot point. --AllyUnion (talk) 08:56, 23 March 2008 (UTC)

Come one... There is already a rule that they should include it, not all does, but come on! Snowolf ^{How can I help?} 10:19, 23 March 2008 (UTC)

Issue: Approved bots that unintentionally mess up articles

Here is a funny example, which illustrates both a malfunctioning bot and an imperfect process. Take a look at WP:BIO footnotes messed up Sept 5, 2007. I was a bit curious how long it would take before someone fixed it, but after 3 months and more than 80 edits on that article (and 15000 page-views), I just fixed WP:BIO Dec 10, 2007. I had earlier filed a report to AN/I: "500 articles messed up.." (see section 19), after which roughly half of the articles were reverted (with "undo") while the rest were left messed-up. The bot was originally speedily approved by BAG, rather strange since all five diffs provided from the trial showed messed-up footnotes. Now, half a year later, a few hundred of the bot edits are still not fixed. The edits are easy to find (with perfect edit summaries): First edits; Latest edits (with overlap). For the status of the bot: The bot operator has silently abandoned his account, and the approving BAG member has left his account after some drama. The bot probably still has BAG-approved status, a sleeping bot/bomb. Maybe somebody could just disapprove the task/bot. And maybe someone could organize cleaning up the messed-up edits. It is rather straightforward, but with my normal edit speed it will take me two months, and I have other priorities. After the observation of this case, I followed the BAG-related activities for a while, and concluded that normally the processes are good, and the handling of bot approvals look fine to me. This case is just an exception, but also illustrates what kind of "harm" exceptions can make. Oceanh (talk) 18:47, 23 March 2008 (UTC).