Wikipedia:Requests for comment/Adminbots

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this page.

A summary of the debate may be found at the bottom of the page.

---

---

What is an adminbot?

Adminbots are bots or automated scripts that require administrator privileges to be able to finish the tasks given to them. So far only one bot has made it successfully through RFA and runs on a separate account with administrative privileges; the rest run directly on the administrator accounts of the operators that run them. Several of these unapproved bots are configured to unblock or block users, unprotect or protect pages, or undelete or delete pages. (An incomplete list of adminbot runners is available here.)

Reason for the RFC.

There seems to not be enough knowledge of adminbots among the broader community; it therefore seems necessary that if these bots are going to run, that policy should be changed, or the bots should stop running, depending on consensus.

Duration

This RFC will remain open for a minimum of 1 month from the time it opens, given its very expansive and broad nature. If it is felt more time is needed before the RFC closes as the 1 month point approaches, a simple motion or proposition can be put forward to expand the length of the RFC.

---

Users should only edit one summary or view, other than to endorse.

Statements about what works well with the current adminbot process

Views specifically about what you feel works well, and/or to the benefit and service of the community, under the current setup that we have.

View by GreenReaper

Existing processes seem sufficient to handle this. If you find an admin account making edits that are disruptive to the wiki, you block it and (if necessary) take its admin privileges away, regardless of whether or not the edits were made by a bot. If people want a bot flag to hide their edits from recent changes, then they have to go through the bot RfA, because it reduces the chance that others will monitor their activity, and so increases the chance that significant damage will be done before the bot is stopped.

Users who endorse this summary:

1. GreenReaper (talk) 15:21, 10 July 2008 (UTC)
2. Sort of. I don't object strenuously to the current situation, but would like to see a more transparent approval of automatic admin functions on either bot accounts, or main accounts. --Rocksanddirt (talk) 15:41, 10 July 2008 (UTC)
3. Total support. The admins using irregular bots should be desysopped or at least severely reprehended. We should never authorize any admin-bot that has not gone through an RFA. Admins should be held to at least the same standards as the common user. If a common user should not use a bot, neither should an admin, unless expressly authorized by the proper channels. All (well, most of) the problems of the Wikipedia come because admins are not apparently subject to rules, at least not to the extent of common editors. That has to end for the sake of the Wiki. We cannot continue in this downward creepy demoralizing spiral. --Sugaar (talk) 01:53, 14 July 2008 (UTC)

Users who oppose this summary:

1. It's not all that easy to take an admin's privileges away, currently only ArbCom or Jimbo can do it, unless they have the option for "recall". And it does matter if it was a bot vs. the person, remember the bot hasn't been approved if it's running on the user's account. Are we to allow bots to run on everyone's account? Adminship does not make someone exempt from following the policies that are made by community consensus. When a person is given adminship, it's the person the community trusts, not the bot. --Chet B. Long^Talk/_ARK 17:40, 10 July 2008 (UTC)
2. As per above. Druworos (talk) 17:50, 11 July 2008 (UTC)
3. I agree with the gist of what Chet is saying. Mathmo ^Talk 02:24, 14 July 2008 (UTC)
4. Long-running admin bots should be given admin accounts to run under separate from their owners without the rigamarole of an RFA process because that's the best thing to do. That way if the bot is malfunctioning it can be blocked without the fear of leaving a black mark on an admin's record (which in the past has kept people from blocking malfunctioning admin bots when that really was the best thing to do). Also, it will make it easy to keep track of the admin's actual human actions. Just look at my Special:Log and tell me that isn't broken. Bot actions should be made under bot accounts and human actions should be made under human accounts; it's really as simple as that. When the admin bot in question has already been running for a long time and is thoroughly uncontroversial, just give the bot the separate account; there's no reason for a long, drawn-out process. --Cyde Weys 21:29, 17 July 2008 (UTC)

Comments on this summary

• This doesn't take into consideration adminbots doing things that aren't disruptive by nature which is the main focus of this RFC. Mr.Z-man 15:27, 12 July 2008 (UTC)
• Agree with Mr.Z-man. --MZMcBride (talk) 16:13, 13 July 2008 (UTC)

Statements about what does not work well with the current adminbot process

Views specifically about what you feel does not work well with the current adminbot process, and/or to the detriment and disservice of the community, under the current setup that we have.

View by Al Tally

Adminbots are useful for Wikipedia, but the fact they run unapproved in a secretive manner is not good. All adminbots should be approved through the relevant process.

Users who endorse this summary:

1. Al Tally ^talk 20:50, 7 July 2008 (UTC)
2. Chetblong^Talk/_ARK 20:59, 7 July 2008 (UTC)
3. « Milk's Favorite Cøøkie 21:02, 7 July 2008 (UTC)
4. weburiedoursecretsinthegarden 21:04, 7 July 2008 (UTC)
5. Useight (talk) 21:52, 7 July 2008 (UTC)
6. Tawker (talk) 22:58, 7 July 2008 (UTC)
7. But what is the "relevant process"? Carcharoth (talk) 23:11, 7 July 2008 (UTC)

   Currently, go to get approval in the usual place, then to RFA for the admin bit. It could probably do with some change. Al Tally ^talk 23:13, 7 July 2008 (UTC)

8. –xenocidic (talk) 23:35, 7 July 2008 (UTC)
9. Per Slakr I think some change in approval process is needed... but I agree with this view. ++Lar: t/c 00:00, 8 July 2008 (UTC)
10. Wisdom89 _{(T / ^C)} 00:18, 8 July 2008 (UTC)
11. Wishful thinking, but yes. east718 (talk) 01:19, 8 July 2008 (UTC)
12. With the qualification that until the process actually works, it makes more sense to run adminbots "off the grid" than to not use them at all. The current process of forcing all adminbots to go through RFA is terribly broken, and is being ignored by many bot operators because it is terribly broken. Best to have a process that will actually be followed. --Cyde Weys 03:07, 8 July 2008 (UTC)
13. Yes, assuming the relevant process is the same one we use to grant other rights to bot accounts when required. SQL^{Query me!} 05:49, 8 July 2008 (UTC)
14. Agree with all as long as the "relevant process" does not suck. --uǝʌǝsʎʇɹoɟʇs(st47) 11:30, 8 July 2008 (UTC)
15. Agree, with the requirement that all admin bot code should be open for public scrutiny (not just "admins on request"). Neıl 龱 12:32, 8 July 2008 (UTC)
16. Yes, if the adminbot process is "widely advertised" so a niche group like the BAG gets no special authority for adminbots (regular ones are fine) and if all adminbot code is pre-disclosed and available at any time. rootology (T) 13:28, 8 July 2008 (UTC)
17. Obviously the policy itself is up for debate, but I certainly agree in principle that (a) all admin-bots should be officially approved rather than run semisecretly, and that (b) the method for approving them should be sufficiently tolerable that there is not a need to run them secretly. ~ mazca ^{t | c} 14:14, 8 July 2008 (UTC)
18. Agree, with the caveat that BAG is not the relevant process, RFA is. GRBerry 14:15, 8 July 2008 (UTC)
19. Steve Crossin (contact) 14:19, 8 July 2008 (UTC)
20. Agree. I would even like to put it a bit more explicit, see below. --B. Wolterding (talk) 16:57, 8 July 2008 (UTC)
21. Yes. StewieGriffin! • Talk Sign Listen 07:00, 9 July 2008 (UTC)
22. rspeer / ɹəədsɹ 23:01, 9 July 2008 (UTC)
23. Bstone (talk) 04:05, 10 July 2008 (UTC)
24. Yes ·Add§hore· ^Talk/_Cont 08:29, 10 July 2008 (UTC)
25. Rvk41 (talk) 10:39, 10 July 2008 (UTC)
26. Gwernol 11:54, 10 July 2008 (UTC)
27. Yes. Now the question is, what process would be effective. – Quadell ^{(talk) (random)} 12:05, 10 July 2008 (UTC)
28. Barberio (talk) 14:20, 10 July 2008 (UTC)
29. Alex Bakharev (talk) 14:25, 10 July 2008 (UTC)
30. The question is what should be the relevant approval process, imo. --Rocksanddirt (talk) 15:42, 10 July 2008 (UTC)
31. We grant users admin rights because we trust their judgement. If users want this trust extended to a bot they wish to run then they should first seek approval. Adambro (talk) 16:56, 10 July 2008 (UTC)
32. -- Vision Thing -- 18:08, 10 July 2008 (UTC)
33. I am willing to support admin bots, but I do not support doing it without approval --T-rex 03:35, 11 July 2008 (UTC)
34. JeremyMcCracken (talk) (contribs) 08:45, 11 July 2008 (UTC)
35. If an admin bot is safe, then it should have no problem passing the relevant approval. MightyWarrior (talk) 09:59, 11 July 2008 (UTC)
36. if we are speaking of "non-humanly supervised" bots. -- lucasbfr ^talk 10:57, 11 July 2008 (UTC)
37. Druworos (talk) 17:51, 11 July 2008 (UTC)
38. Davewild (talk) 15:45, 12 July 2008 (UTC)
39. As long as the approval process works --Chris 10:11, 14 July 2008 (UTC)

Users who meh idc:

1. Миша13 21:37, 9 July 2008 (UTC)
2. A lot of great work has been done "secretively." Could the overall situation stand for improvement? Sure. But the community always indicated it didn't want to know what was going on, and so it was left in the dark. --MZMcBride (talk) 16:12, 13 July 2008 (UTC)

I commented here. --Chet B. Long^Talk/_ARK 02:11, 14 July 2008 (UTC)

Users who oppose this summary:

1. Weak oppose. Adminbots are probably not really useful for Wikipedia. If any bot is, then it certainly should go through RFA but I doubt they are of any use, at least in most cases. We should not leave human responsability on routinary programs unless strictly necessary. --Sugaar (talk) 01:57, 14 July 2008 (UTC)

   Not useful? User:RedirectCleanupBot how is that not useful?(I take that back it went through rfa) Also admin bot used in cleaning up grawp vandalsim, you're telling me delete the page titles created by these is not useful. How about one going though CAT:TEMP and delete all the pages that have been in there for 3 months and don't have sock templates on the page? How are any of those not useful --Chris 10:11, 14 July 2008 (UTC)

View by slakr

Disclaimer: I've never run a bot under my admin account, though I have used twinkle's batch delete to clear out CSD/G8-able talk pages.

I've got a few points:

• Bot RfA is redundant and excessive. Bot requests for approval is sufficient if we even need a process. Check out Wikipedia:Requests for adminship/RedirectCleanupBot. 203kb of text. I can't speak for all coders, but I simply don't have the time nor the patience to deal with that all within 7 days while doing the exact same thing (i.e., putting everything into layperson language) at my actual job. Being forced to do it here would be forcing me to do the most disinteresting, loathed part of my job in what would otherwise be my happy place— and not get paid for it. Not cool, and definitely discourages me from wanting to help out in the first place.

• It would be impossible to effectively prohibit them. Any decent coder will do something like sleep(rand(60)), check the time of the day, fake a useragent, or any number of other "humanizing" things to make an admin-action bot undetectable. I was an IRC operator on a large network, and any of my colleagues will tell you that bot detection can be very much impossible on a well-written bot.

• They're already amongst you. While I don't run one myself, there are many admin-action bots already out there— you just don't notice them because they do their jobs well. They're simply the end result of a two things: one, we're huge, and doing things "by hand" simply isn't feasible any more; two, certain, specific vandals have gotten smarter and have thus necessitated closed-source remedies to cut them off at the pass. The same holds true in any online community once it gets big enough. Most large IRC servers run home-brewed connection monitor bots that auto-k-line open proxies and drones— the equivalent of an "unapproved admin bot."

• Admins shouldn't be bots. Surely we could just do it all "by hand," but that would require lots of manpower, people willing to do the work themselves, and above all people who are impervious to burnout— essentially, you need people who have the time and patience to act like robots. On my server, we weren't able to find them fast enough, and I don't think we ever would have been able to do so knowing the attention span of even the most focused human.

  I mean, imagine you had a job sticking toothpaste caps on manufactured toothpaste tubes. Now imagine you had the knowledge and ability to build a very good machine that could do that for you, freeing you up to look for other defects in the manufacturing process. Yet, unfortunately, you were told that you were not allowed to build that machine (nor even test it) until you had spent all of your free time to go through a red-tape process that would probably result in you not being able to build nor even test it anyway. Can you imagine how maddening that would be? It'd make anyone want to quit such a crap job, wouldn't it?

So, if you're planning on going on a quest to rid the world of any type of automation or to place increasing numbers of hurdles in the way of technological advancement, please be certain you will be able to succeed where we clearly couldn't— that is, before opposing something, be willing and able to guarantee to the rest of the community that you will be able to be there 24/7, 365 to replace the work that the bots that are already out there are doing. Otherwise, live and let live, and if something bonks up, deal with it. It's not like admin actions are permanent, and from my experience, if an automated process screws up, people generally don't take it personally. Cheers. --slakr^\ talk / 22:58, 7 July 2008 (UTC)

Users who endorse this summary:

1. Not technically endorsing, but it was so well-written, and persuasive, I am doing so anyway. <confused>! Carcharoth (talk) 23:10, 7 July 2008 (UTC)
2. If it could be 'run past' the community without wasting too much of our time, I for one would not have a problem getting approval. Dealing with RfA for a bot is annoying and bad. --uǝʌǝsʎʇɹoɟʇs(st47) 00:22, 8 July 2008 (UTC)
3. east718 (talk) 01:19, 8 July 2008 (UTC)
4. - Philippe 01:33, 8 July 2008 (UTC)
5. Very well-put. krimpet✽ 01:57, 8 July 2008 (UTC)
6. Well stated, as always. LaraLove|Talk 01:58, 8 July 2008 (UTC)
7. I'm in very strong agreement with the whole statement, but the "Admins shouldn't be bots" part especially. I have Cydebot doing all of the automated deletions it is currently doing because doing them manually was sapping my will to live (or at least to be an administrator). The bot even does a better job of it, too. It doesn't accidentally "click" the wrong link on a page, then delete something completely unrelated to what was supposed to be deleted, a mistake I've made on a rare occasion. --Cyde Weys 03:11, 8 July 2008 (UTC)
8. Indeed. --Kbdank71 12:58, 8 July 2008 (UTC)
9. Well said. rootology (T) 13:26, 8 July 2008 (UTC)
10. The normal bot approval process is sufficient, as long as it's made clear the bot will be running with admin privileges. There's still an emergency shutoff like any bot, right? So why the extra bureaucracy? --Jaysweet (talk)
11. Mr.Z-man 20:48, 8 July 2008 (UTC)
12. davidwr/(talk)/(contribs)/(e-mail) 23:33, 8 July 2008 (UTC)
13. Yep. SQL^{Query me!} 06:50, 9 July 2008 (UTC)
14. —Giggy 07:31, 9 July 2008 (UTC)
15. — _Maggot^Syn 11:03, 9 July 2008 (UTC)
16. RfA is the wrong place to ask. You get a reactionary RfA mindset and have to follow RfA's rules, which make no sense for bots. This is not the same as saying that "the community" should have no input. Anyone in the community who understands what bots do should be allowed in the approval process. Hey, whaddya know, that's exactly how other bots work. rspeer / ɹəədsɹ 00:42, 10 July 2008 (UTC)
17. Yes. --JaGa (talk) 12:07, 10 July 2008 (UTC)
18. Just to be clear, I think an admin should be able run an automated script under his/her own admit account, provided that the details are public, the process was approved at BRfA, and the edit summary says that it's an automated edit. I think that what slakr is saying is compatible with this view. – Quadell ^{(talk) (random)} 12:14, 10 July 2008 (UTC)
19. Well put. shoy (reactions) 12:38, 10 July 2008 (UTC)
20. I'm very much in favor of smart, responsible people using bots to automate mundane tasks. And I trust the system to ensure that admins are smart, responsible people. If they didn't care about the integrity of the site, they wouldn't devote so much of their personal time to it. ThreeOfCups (talk) 03:52, 11 July 2008 (UTC)
21. Gwen Gale (talk) 03:58, 11 July 2008 (UTC)
22. -- lucasbfr ^talk 10:54, 11 July 2008 (UTC)
23. , well put. Tim Vickers (talk) 16:26, 11 July 2008 (UTC)
24. Some very well made points in here. States some basic fact of the matter succinctly. – Luna Santin (talk) 05:21, 12 July 2008 (UTC)
25. Persuasive. TwoMightyGods^Persuasion_Necessity 12:51, 13 July 2008 (UTC)
26. --Chris 10:14, 14 July 2008 (UTC)
27. Eloquently put and convincing as is wont from Slakr. —Animum (talk) 02:27, 2 August 2008 (UTC)

Users who oppose:

1. Strongly oppose. I have already been stalked and my work destroyed by a bot apparently accountable to no one. The manager of the bot never replied to my complaints. When Wikipedia will be written by bots, then maybe bots should have admin privileges (and humankind will be done). But by the moment the Wiki must be for those who create it. If a bot can really improve things then it will probably pass an RFA. Meanwhile they are just dangerous programs that should be banned for good. --Sugaar (talk) 02:06, 14 July 2008 (UTC)
2. Slight Oppose: has a problem with open source by claiming we absolutely have to have closed source solutions? (i.e. avoiding putting them through an extensive review process) I disagree with that conclusion. Mathmo ^Talk 02:31, 14 July 2008 (UTC)
3. Strong oppose - if you don't have time for an RFA then you should not be running your bot --T-rex 18:25, 16 July 2008 (UTC)

View by Anonymous Dissident

Whether they are bot accounts or just automated scripts running on admin accounts, they should all be subject to some form of communal approval, whether it be both at RBA and RFA, or at another, single forum specialised for admin scripts. When we appoint an admin, we appoint the guy on the chair, not his piece of code. So it seems important that if we do want to allow the script to make use of his admin buttons, then we should make sure we are happy with the script as well.

But there are more factors than this. If it is a personal script that makes the job faster, but is only semi-automated (ie. still requires user input, or confirmation on the script's actions) then that may be fine. It is the unautomated scripts, that deletes, protects, blocks and whathaveyou of its own volition and without a real admin there confirming every action that have the potential to cause massive harm. We need to make the decision how far we want to take this approval process of scripts, because the fact is that, carefully moderated semi-automatic scripts that require user confirmation before taking log actions may merely make the job easier with little difference from doing the task with the manual eye of a real person.

Users who endorse this summary:

1. Anonymous Dissident^Talk 23:32, 7 July 2008 (UTC)
2. Endorse. Al Tally ^talk 23:35, 7 July 2008 (UTC)
3. Chetblong^Talk/_ARK 23:37, 7 July 2008 (UTC)
4. Agree, I think. There should be no problem with semiautomatic scripts, just like with huggle and popups, where there's no real approval process required. It is the automatic bots that need to be reviewed here. --uǝʌǝsʎʇɹoɟʇs(st47) 11:33, 8 July 2008 (UTC)
5. rootology (T) 13:24, 8 July 2008 (UTC)
6. Useight (talk) 18:36, 8 July 2008 (UTC)
7. Kubigula (talk) 03:11, 10 July 2008 (UTC)
8. --Rocksanddirt (talk) 15:39, 10 July 2008 (UTC) - I agree, the issue is fully automatic actions, not scrips that still take human action to complete.
9. Adambro (talk) 16:57, 10 July 2008 (UTC)
10. Goodnightmush^Talk 17:16, 10 July 2008 (UTC)
11. T-rex 03:49, 11 July 2008 (UTC)
12. JeremyMcCracken (talk) (contribs) 08:47, 11 July 2008 (UTC)
13. Davewild (talk) 15:48, 12 July 2008 (UTC)
14. --MZMcBride (talk) 16:10, 13 July 2008 (UTC)
15. Support --Sugaar (talk) 02:08, 14 July 2008 (UTC)
16. Support -- Mathmo ^Talk 02:35, 14 July 2008 (UTC)
17. --Chris 12:10, 14 July 2008 (UTC)
18. Green caterpillar (talk) 23:01, 19 July 2008 (UTC)
19. Anthøny 13:10, 4 August 2008 (UTC) Absolutely: this is in line with what we both require and expect on the topic of adminbots. Call it a no-brainer, if you will.

View by Carnildo

Community approval and oversight of adminbots would be nice. Unfortunately, the community's collective Frankenstein complex is so severe that it's almost impossible to get such a bot approved.

Users who endorse this summary:

1. Carnildo (talk) 00:27, 8 July 2008 (UTC)
2. --uǝʌǝsʎʇɹoɟʇs(st47) 00:42, 8 July 2008 (UTC)
3. LaraLove|Talk 02:01, 8 July 2008 (UTC)
4. Nakon 02:13, 8 July 2008 (UTC)
5. This is true but it's only half the story. I will be frank: part of the reason the community has a Frankenstein complex is that some bot operators have acted like absolute monsters and the rest of the bot community has done too little to control this. We're talking massive, persistent and supremely arrogant refusals to communicate about extremely good faith concerns about bots raised by people outside the bot community--including about bots that are doing completely useless tasks. So, yes, the community has something of a Frankenstein complex. But in order to fix this problem we need to acknowledge that the bot community is itself largely responsible for that. --JayHenry (talk) 03:00, 8 July 2008 (UTC)
6. SQL^{Query me!} 05:40, 8 July 2008 (UTC)
7. rootology (T) 13:28, 8 July 2008 (UTC)
8. I think this is the reason that most adminbots aren't officially approved. Captain panda 14:31, 8 July 2008 (UTC)
9. Nn123645 (talk) 18:39, 8 July 2008 (UTC)
10. Combine this with process wonkery - "policy says no adminbots!" - and approval is near impossible. Mr.Z-man 20:48, 8 July 2008 (UTC)
11. Per JayHenry. —Giggy 07:31, 9 July 2008 (UTC)
12. — _Maggot^Syn 11:04, 9 July 2008 (UTC)
13. MER-C 11:46, 9 July 2008 (UTC)
14. Kubigula (talk) 03:11, 10 July 2008 (UTC)
15. --Bedford ^Pray 05:31, 10 July 2008 (UTC)
16. Well, this is true. It's not a solution, though; it's just a statement of the problem. – Quadell ^{(talk) (random)} 12:15, 10 July 2008 (UTC)
17. True. Though I think we've earned our frankenstein complex the honest way (through poor management of bot activity, by some users). --Rocksanddirt (talk) 15:45, 10 July 2008 (UTC)
18. This is indeed a problem. – Luna Santin (talk) 05:08, 12 July 2008 (UTC)
19. Well said. --MZMcBride (talk) 16:09, 13 July 2008 (UTC)

Users who agree, but are not sure that its a bad thing:

1. T-rex 18:29, 16 July 2008 (UTC)

Other comments on this summary:

1. Maybe correct to some extent, but what follows of it? Doing something without approval because one fears that approval would be rejected seems, to express it in a cautious way, a very scary approach. --B. Wolterding (talk) 12:14, 9 July 2008 (UTC)

   In general, yes; but if it's a case of fearing that approval would be rejected solely because of a problem with the approval process, then the correct approach would be to discuss with everybody about changing that process. Of course one should aim to do that as soon as possible, and in an ideal world before doing the action, but sometimes emergencies crop up. --_{tiny plastic} Grey Knight ⊖ 12:32, 9 July 2008 (UTC)

   I don't think that applies here. The adminbots that are currently running have been running for an extended time, I presume; I can't see that they were made to fix an emergency situation. --B. Wolterding (talk) 16:39, 9 July 2008 (UTC)

2. There are a lot of people with Frankenstein complexes, and any effective adminbot policy needs to ignore them. But don't tar the entire community with the same brush. rspeer / ɹəədsɹ 00:44, 10 July 2008 (UTC)
3. False. Apparently it has been tried 3 times, with one adminbot passing RFA (the most recent), one becoming obsolete due to change in the MediaWiki code before the RFA was finished, and one failed primarily because the community didn't trust the operator not to keep expanding the scope. The community isn't about to approve any idea that pops into a coder's head - nor should it. But if a good idea well designed and vetted is presented, the evidence is that the odds of success are high. GRBerry 18:01, 10 July 2008 (UTC)
4. Oppose. Bots are dangerous, if they must be there, they must be fully accepted. Frankestein's monster was at least mostly human. Bots are mere machines: it's like letting a car drive without driver. Who can you blame if there's an accident? Someone must assume full responsability and accountability and that's not possible with bots. --Sugaar (talk) 02:12, 14 July 2008 (UTC)

   It's not at all like letting a car drive without a driver. It's much more akin to putting an airplane on autopilot — the craft is without human input until the pilot has deemed it is necessary, and it is being guided by sophisticated systems, not sheer luck. Bots are not out-of-control monsters, but programs that have safeguards, efficient ways to do otherwise menial tasks, and the capability to shut down when the operator thinks it to be needed. —Animum (talk) 02:35, 2 August 2008 (UTC)

   You might as well have said "Oppose, I'm one of the people this section worries about." =\ – Luna Santin (talk) 00:15, 15 July 2008 (UTC)

   Everything on Wikipedia is controlled by a single computer program with considerably more power than any admin. It's called MediaWiki. Your fear of computer programs is irrational. rspeer / ɹəədsɹ 20:10, 22 July 2008 (UTC)

   "Who can you blame if there's an accident?" - The programmer. Mr.Z-man 22:22, 22 July 2008 (UTC)

   Although finding someone to blame for an accident probably isn't the most productive thing to do, there should be a sense of responsibility; I'd think primarily with the operator, but also with the approvals group & the programmer as well. -Steve Sanbeg (talk) 14:34, 23 July 2008 (UTC)

View by ST47

Disclosure by Carcharoth's request: While I do not do so currently or regularly, I have operated administrative bots under my main account to do such tasks as block Tor nodes, undelete pages, and process image deletion backlogs. I have also used a bot to operate the WP:ADMINSTATS page and a script to expedite my duties as a member of WP:BAG.

Adminbots are a critical portion of Wikipedia's operation.

Adminbots can, if used correctly, automate tasks such as deletions, blocking, protections, and unprotections in a speedy way, limiting both the load on admins who need to sort through a large number of pieces of information to make such an action, and by limiting the latency caused by backlogs in these areas. There are a large number of accounts created, if the blatant bad usernames weren't blocked, it would take a lot more time to get through them to see the borderline ones.

Adminbots are run without approval due to an excessive amount of process which the bot operators see as superfluous.

Most programmers, by nature, exhibit a number of traits and possess a number of ideas. In the best way I can word the relevant ones:

• The world is full of fascinating problems waiting to be solved. We are interested in dealing with these problems, the things we find interesting. Programming new processes is often one of these. Arguing over it for a week against a number of people who feel that a bot that only has code in it to protect pages is somehow more likely than a human to delete the main page is not fun. Discourse with other people who understand the challenges you are facing can be constructive, describing it to no end to the users will not seem to be constructive.
• Boredom and drudgery are evil. We don't want to do the same thing over and over again, that's why these bots exist. That's why computers exist. We have no need for a user to go and block any username that says "<something>sucks" when we can just tell a bot to $username=~/sucks/i and then $admin->block($username); and then let it loose.
• Freedom is good. This one will take a little explaining, but in short, I feel that authority without purpose is worthless. Freedom from a need to obey stupid rituals, such as walking on the left side of the street but biking on the right, or sacrificing a newborn lamb for easter, is good. This can be extended to any sort of protracted approvals process, such as that for adminbots. A vote among the community that lasts for a week and you need to convince 80% of the people who watched I, Robot that your bot really can't delete the main page is unnecessary. A code review and a policy review by those with experience in the field, who aren't conspiracy theorists, who know that a 300-line computer program is not going to sprout a brain, is all that is necessary. Is that too much to ask?

Requiring a full RfA after the BRfA for adminbots is unnecessary.

As it is, these bots are going through no approval process, noone is seeing their code, noone has a chance to submit objections. That's why we had to revert a few thousand deletions not too long ago. Require a BRfA only, require it to last for long enough for a number of experienced users to review the code, and for the users to confirm that this bot will be useful. Adminbots should be judged the same as any other admin actions, they should not be prejudiced because they are automatic. --uǝʌǝsʎʇɹoɟʇs(st47) 00:42, 8 July 2008 (UTC)

Users who endorse this summary:

1. --uǝʌǝsʎʇɹoɟʇs(st47) 00:42, 8 July 2008 (UTC)
2. Perhaps ST47's example is problematic. But his principle is sound. – Quadell ^{(talk) (random)} 12:17, 10 July 2008 (UTC)
3. Indeed, please take 10 seconds to look past the admittedly terrible example... The thought presented here is a good one. SQL^{Query me!} 16:43, 10 July 2008 (UTC)
4. I don't like the username bot example(possible a bot that ask for confirmation before blocking could work), but the rest of it is fine --Chris 04:41, 19 July 2008 (UTC)

Users who oppose this summary:

1. The example on username blocks shows exactly how it shouldn't be done. We are not going to block User:My vacuum cleaner sucks. An admin bot would. And that's exactly why we do need some kind of process for admin bots, because if errors are made, they can be quite damaging to the project. Sure, everything can be undone, but the blocked users probably won't return. --Conti|✉ 01:01, 8 July 2008 (UTC)
2. Actually, you walk on the left side of a street and ride on the right so that you don't get killed by automobiles. It's not an arbitrary thing, and neither is a community request that bots have some oversight and their operators be somewhat responsive to the community. Accountability is not a "stupid ritual", and uncommunicative bot operators have actually proved the concern to be legitimate. --JayHenry (talk) 03:05, 8 July 2008 (UTC)

   To be honest, I ride on the left side of the street. Or at least I did, before my license expired... Stifle (talk) 10:59, 10 July 2008 (UTC)

3. Yes, it's clear that programmers usually don't like formal processes. But that doesn't prevent them from making errors, which the approval process is there to catch (at least in parts). Actually, the current BRFA process is by no means excessive. I feel it's rather on the very low end of what one could think of. We don't even require any independent testing of the code! --B. Wolterding (talk) 17:20, 8 July 2008 (UTC)

   Oh, I don't have a problem with BRfA, it's the proposal of RfA for bots that I have a problem with. It's nice to have someone officially give me another set of eyes, but when that comes at the expense of enduring RfA, then I'd rather pass. --uǝʌǝsʎʇɹoɟʇs(st47) 20:52, 8 July 2008 (UTC)

4. Blocking over username is stupid enough; doing it with a bot is idiocy. —Giggy 07:32, 9 July 2008 (UTC)
5. Sorry, Wikipedia is not just a sandbox for bot programmers. Sometimes if you want to solve an interesting problem, you need to wait to see if anyone likes your solution. Meanwhile, that username example is the worst idea for an adminbot I have ever heard. rspeer / ɹəədsɹ 08:23, 9 July 2008 (UTC)
6. I'm not sure what you mean by your walking/bicycling example; in the absence of sidewalks, it is best both for you and for the expectations of other vehicle users if you walk against traffic but bike with traffic. --NE2 09:38, 9 July 2008 (UTC)
7. No, bots shouldn't be blocking, especially not for usernames, which are very subjective. It needs to be up to an actual administrator's discretion on a case-by-case analysis. Sure, users who have been blocked by mistake can be unblocked (it happened to me here), but many users to which this happens will not return to Wikipedia. Useight (talk) 18:21, 9 July 2008 (UTC)
8. Useight gives the perfect example. It's one thing for a bot to perform tasks that can be undone by anyone, should the bot malfunction. It's very different for things such as blocks and page deletions, where the mess resulting from a bot's mistake could be more of a hassle than manually performing the action to start with. JeremyMcCracken (talk) (contribs) 08:51, 11 July 2008 (UTC)
9. The example used is pretty much what I would not want a bot doing and is why there should be some community control/process for approval. Davewild (talk) 15:53, 12 July 2008 (UTC)
10. Strongly oppose. Blocked by a bot! What next?! --Sugaar (talk) 02:13, 14 July 2008 (UTC)
11. Conti is right, terrible example. Even though ST47 made very good points, the ease with which a terrible example can be made to support adminbots shows exactly their great danger. Mathmo ^Talk 03:00, 14 July 2008 (UTC)

Users who partially endorse this summary:

1. Critical: endorse. Run without approval due to administrator/bot operators thinking approval is superfluous: abstain, I can't read their minds. Approval processes: Abstain because I'm not familiar with BRfA. davidwr/(talk)/(contribs)/(e-mail) 23:37, 8 July 2008 (UTC)
2. Strongly agree with ST47 on almost all points, though Conti and a few others make some valid points about a bot's ability to do no harm. --MZMcBride (talk) 16:08, 13 July 2008 (UTC)

View by Neil

Adminbots should, if approved, run on open/public source code. No surprises, and allows the community to suggest improvements and optimisation. Neıl 龱 12:40, 8 July 2008 (UTC)

Users who endorse this summary:

1. Neıl 龱 12:40, 8 July 2008 (UTC)
2. rootology (T) 14:10, 8 July 2008 (UTC)
3. Should, yes. Should be forced to, no. If should be encouraged, as this is Wikipedia, the free encyclopedia, but not used as a requirement for approval. --uǝʌǝsʎʇɹoɟʇs(st47) 00:20, 9 July 2008 (UTC)
4. In general, yes, but it should be allowed for the source to be secret or restricted if there is a pressing reason. The question of whether or not the community feels it's appropriate for a given bot can be discussed as part of its approval. I would also phrase it differently too, perhaps as "having source code publicly-viewable at will", since open source can carry the connotations of some other rights with it which may not be necessary (all we really want is the oversight, right?). --_{tiny plastic} Grey Knight ⊖ 07:27, 9 July 2008 (UTC)
5. With a bit more weight than ST47 re. encouragement. —Giggy 07:33, 9 July 2008 (UTC)
6. Excluding anti-vandal bots only. Backlog clearing bots are clearly not anti-vandal. GRBerry 16:36, 9 July 2008 (UTC)
7. If we have blocking, deleting anti-vandal bots (and I'm not sure we should have them) they might be an exception, but apart from that, endorse. --Conti|✉ 16:48, 9 July 2008 (UTC)
8. Per ST47, they SHOULD but not MUST (refer to RFC 2119 for explanation). My bots are open source, but some detection rules are non-public - yet someone might not want to reveal certain protective measures. Миша13 21:43, 9 July 2008 (UTC)
9. rspeer / ɹəədsɹ 00:45, 10 July 2008 (UTC)
10. Happy-melon and Z-man raise important objections below. And perhaps there should be exceptions in a few cases, where the code is on file with the Bot Approvals Group, but is not publicly available. Still, in most (and perhaps all) cases, I think an open-source requirement for adminbots is a good idea. – Quadell ^{(talk) (random)} 12:19, 10 July 2008 (UTC)
11. I think the default should be 'accessible to others', but there are some items that should likely remain either 'restricted' or 'private' per the concerns of the opposes. --Rocksanddirt (talk) 15:50, 10 July 2008 (UTC)
12. Security by obscurity is neither effective, nor does it fit in with the transparency and openness that made Wikipedia great in the first place. -- 790 (talk) 08:01, 11 July 2008 (UTC)
13. Should but with appropriate exceptions where really necessary. Davewild (talk) 15:55, 12 July 2008 (UTC)
14. Per Misza. Should vs. must is key. --MZMcBride (talk) 16:05, 13 July 2008 (UTC)
15. Support. That's self-evident. Someone mentions that "wrongdoers" should not know the code but certainly "gooddoers" should and there is no way to allowing the latter without the former, so it's a lesser evil. Also we have no guarantee that admins are not wrongdoers themselves, who may use the bots for "evil" goals. The bot must be fully approved line by line. --Sugaar (talk) 02:18, 14 July 2008 (UTC)
16. Agree. If we have adminbots then open is good. Mathmo ^Talk 03:04, 14 July 2008 (UTC)
17. I'm inclined to agree, but it has nothing to do with the admin bot issue and everything to do with fostering a communal Free Software spirit amongst bot writers. There are many bot functions that have been duplicated several times by different bot authors simply because no one was sharing their code. There have also been occasions when I've been able to get my hand on "sooper sekret" bot framework code because of my standing in the bot-writing community, but had I been an up-and-coming bot writer without a track record, I wouldn't have been able to get it. It's much better just to code up a simple MediaWiki template that takes a URL to the location of a bot's source code as a parameter, and then require it on the user page of every bot. Imagine how awesome and useful that would be! --Cyde Weys 21:24, 17 July 2008 (UTC)

Users who oppose this summary:

1. Happy‑melon - a number of adminbots that have operated, and which continue to operate to this day, have been written as counters to our small but noisy collection of persistent vandals. We are all familiar with vandalbot pagemove vandalism and its main author. We need scripts that can block these users, when they strike, within seconds; and a few admins have risen to this challenge admirably. In taking up the task of stopping these persistent vandals, they have committed themselves to an arms race as the vandals continue to modify their vandalbot scripts in an attempt to circumvent the necessarily conservative tests that the anti-vandal adminbots apply to identify the vandals. Closed-source code is a necessity in this situation; or the script will need rewriting literally every day, sapping the admin's patience and interest in the task. Why should these adminbots be closed source when ClueBot's is open? Because ClueBot deals (and deals admirably) with vandalism from thousands of different editors; a few might look at the source code to identify weaknesses or bypasses, but the majority will not. With the persistent vandals, you can be certain that if the code is available, it will be circumvented, and circumvented extremely quickly. Happy‑melon 14:07, 8 July 2008 (UTC)

   Do we actually have evidence of vandal bot "scripts"? I don't recall ever seeing that mentioned with evidence except as a what-if scenario. Please link the evidence? rootology (T) 14:10, 8 July 2008 (UTC)

   There was a compelling circumstantial case that a fully automated page move vandal bot was constructed near the end of the arms race with WoW (not just the tabbed editting approach that apparently existed for much of WoW's history). Curpsbot countered and WoW seemed to have finally given up. That's one example. I'm also confident that Mediawiki targetting spam bots exist, but between the captchas and actively managed community, those tend to be quite ineffective here. Some other vandals have used botty behavior (like systematic naming and edit summaries), but generally their vandalism doesn't last long enough to build a good case for it being a bot. Dragons flight (talk) 16:16, 8 July 2008 (UTC)

   I get the distinct impression that some of the recent Grawp vandalism has been at least semi-automated, but whether or not it's actually a script is largely irrelevant: the point is that this is a prepared vandal who takes the time to set up a vandalising algorithm to do as much damage as possible before being stopped. Happy‑melon 17:28, 9 July 2008 (UTC)

2. Per Happy-melon. Mr.Z-man 20:52, 8 July 2008 (UTC)
3. Per what I said above in one of the other 3 sections regarding forcing code release, etc... SQL^{Query me!} 16:45, 10 July 2008 (UTC)
4. Requiring things to be open source is unnecessary. Cleaning up code for public viewing is sometimes a waste of time, and should be a choice T-rex 03:57, 11 July 2008 (UTC)
5. Although I do normally open up my code, and like it when others do the same I do not think that it should be a requirement. People have perfectly good reasons for not wanting to open up their code, however I would be nice if code did go under some sort of peer review, even if the code is not opened up to every one --Chris 04:48, 19 July 2008 (UTC)

View by B. Wolterding

Wikipedia benefits from the use of bots for various purposes, admin and non-admin related. Without them, maintenance of Wikipedia would be much more tedious, if not impossible.

However, bots, as automated processes, have other characteristics than human editors. When their specification or design is flawed, they can cause harm and disruption, even if everybody involved is acting in good faith. This is well known in the field of software engineering.

Therefore, a formalized review and approval process for bots seems necessary (and is in fact in place):

1. It needs to be tracked which bots are running, who is responsible for them, and what purpose they fulfil;
2. Their specification and intended use needs to be approved by a wider community of competent editors, to assure that they are in line with consensus, and to minimize the risk of errors.

This applies all the more for bots that run under admin rights, since their potential for damage is even larger.

The current situation - where "officially" almost no admin bots are approved, but several run secretly and without passing an approval process, is unacceptable. --B. Wolterding (talk) 17:06, 8 July 2008 (UTC)

Users who endorse this summary:

1. As nominator. --B. Wolterding (talk) 16:19, 9 July 2008 (UTC)
2. Mr.Z-man 20:52, 8 July 2008 (UTC)
3. Chetblong^Talk/_ARK 02:01, 9 July 2008 (UTC)
4. This is true. But it's not a proposed solution; it's just a statement of the problem. – Quadell ^{(talk) (random)} 12:20, 10 July 2008 (UTC)

   Yes, of course; see the section heading: Statements about what does not work well with the current adminbot process. --B. Wolterding (talk) 13:45, 10 July 2008 (UTC)

   Oh yeah... I guess I lost sight of that, since nearly every other view in this sections uses the word "should" prominently. – Quadell ^{(talk) (random)} 14:15, 10 July 2008 (UTC)

5. --Barberio (talk) 14:23, 10 July 2008 (UTC)
6. Well, yes. SQL^{Query me!} 16:46, 10 July 2008 (UTC)
7. Exactly- there is a reason that (legal) bots require approval. If something is going to run an automated process without human intervention, we need to be darn sure that it's going to do it properly before we start it. JeremyMcCracken (talk) (contribs) 08:54, 11 July 2008 (UTC)
8. Broadly yes. Davewild (talk) 15:57, 12 July 2008 (UTC)

Users who partially endorse this summary:

1. Tracking, responsibility, and purpose: endorse. Approval by a wider community of editors: Desired but for bots that run on a small scale not necessary. We do not ask admins who use semi-automated tools for the same purpose to get approval from the wider community. Bots that affect large numbers of articles should go through a review, I've discussed that elsewhere on this page. davidwr/(talk)/(contribs)/(e-mail) 23:40, 8 July 2008 (UTC)

   If a script runs only semi-automated (i.e. with manual approval of edits) and on a small set of articles, it traditionally wouldn't be considered a bot. --B. Wolterding (talk) 08:20, 9 July 2008 (UTC)

2. Per david. --uǝʌǝsʎʇɹoɟʇs(st47) 00:22, 9 July 2008 (UTC)

View by Giggy

Current situation: Adminbot operators (in general - there are exceptions) feel the non-bot community are "a bunch of idiots who always get in the way of things" (yes, I'm quoting someone). The non-bot community (in general - there are exceptions) think adminbot operators are self-proclaimed defenders of the wiki who don't give a rats what the community they're "defending" think of their actions.

Clearly, both sides are absolutely wrong. We need to work our communication, on both sides.

Users who endorse this summary:

1. —Giggy 08:09, 9 July 2008 (UTC)
2. Yes, communication is an important part. --Chet B. Long^Talk/_ARK 12:31, 9 July 2008 (UTC)
3. Good summary of the problem. rspeer / ɹəədsɹ 14:55, 9 July 2008 (UTC)
4. Bot coders and operators are the IT community. The non-bot community are the business users. Both groups exist to serve our readers, not themselves. Good IT solutions are technically well designed and meet the needs determined by the business users for how to serve the readers. IT coders who want to ignore the rest of the community and impose their own ideas via bot are actively harmful. Just because an action is permissible does not mean the community would support a bot to do it automatically; the community writes its policies assuming that editors, and especially admins, will apply judgment about whether or not to take action under them. GRBerry 16:42, 9 July 2008 (UTC)
5. I don't know who you're quoting, and to be honest, I don't care, because that definitely sums up the attitude of many an adminbot operator. The non-bot community - to which I am a member, to my knowledge - generally has the view you stated. Excellent summary of the situation. weburiedoursecretsinthegarden 10:15, 10 July 2008
6. --Rocksanddirt (talk) 15:52, 10 July 2008 (UTC) - clearly.
7. Seems pretty accurate mostly. SQL^{Query me!} 16:48, 10 July 2008 (UTC)
8. Davewild (talk) 15:58, 12 July 2008 (UTC)

It's complicated:

1. Both sides that you describe are, indeed, absolutely wrong. As you say, we need to work our communication on both sides. However I don't think the summary of opinions is a fair description of what most adminbot operators or most in the non-bot community actually think. This is merely the attitude of the noisiest factions of both parties. – Quadell ^{(talk) (random)} 12:23, 10 July 2008 (UTC)

   Yeah, thankfully not everyone on either side thinks this way. I agree it's complicated, but that's another issue; trying to get both sides to agree without breaking the tl;dr barrier. —Giggy 04:02, 11 July 2008 (UTC)

2. Communication needs to be improved, but I don't think things are that bad --T-rex 19:42, 12 July 2008 (UTC)

Users who oppose this summary:

1. It is not clear that both sides are absolutely wrong. One side might be right, or mostly right, in the view of a particular person. It's a matter of opinion. GreenReaper (talk) 15:28, 10 July 2008 (UTC)

   So you would consider one of those assumptions (non bots = morons OR bots = morons) to be correct? —Giggy 04:02, 11 July 2008 (UTC)

2. Oppose. This statement is exaggerated and simplistic. Experts will always regard with disdain the opposition of the ignorant, and some people would rather remain ignorant their whole lives than listen to someone else's point of view. Communication is important, but all communication is not created equal. Those who are most vocal are often those who are the least qualified to express an opinion. I'm not sure that more communication is the solution to that particular problem. ThreeOfCups (talk) 04:32, 11 July 2008 (UTC)
3. Bots must bow to humans. The pposite is essentially wrong. No bot (unless throughtfully approved by the community for a very good reason) should step in the way of humans. There's really nothing to discuss about this: it's just a bunch of presumably techno-fanatic admins who either want to get their work done by a machine or want to do more job than they can. Bot for the most part only destroy trust. Maybe some minor tasks can be done by bots but surely few that require admin privileges. You don't need admin privileges to correct spelling, add categories or archive month-old threads. What needs admin privileges can't be done by a bot. --Sugaar (talk) 02:26, 14 July 2008 (UTC)

   But spell checking is one thing that bots can't do.  :) -- Cobi^(t|c|b) 14:06, 16 July 2008 (UTC)

Clarifications on limits of what adminbots can't do

Currently some of the secret adminbots are blocking and/or deleting pages.

View by tawker

Within reason there is no reason a properly coded, well spec'd bot cannot preform pretty much any mechanical operation. If we look at vandal fighting as a past example, there was strong strong opposition to TB2 when it first came out - now everyone takes the bots for granted.

We've come to an era where it's very easy to reverse mistakes made with +sysop - even image deletes are undoable. What's the risk in letting authorized adminbots reduce the backlogs? -- Tawker (talk) 22:55, 7 July 2008 (UTC)

Users who endorse this summary:

1. There is no risk - as long as they're authorised and accountable, which they currently are not. Al Tally ^talk 22:58, 7 July 2008 (UTC)
2. Per Al Tally. Carcharoth (talk) 23:14, 7 July 2008 (UTC)
3. Yes, as long as they are approved and separate. --Chetblong^Talk/_ARK 23:25, 7 July 2008 (UTC)
4. --uǝʌǝsʎʇɹoɟʇs(st47) 00:48, 8 July 2008 (UTC)
5. east718 (talk) 01:19, 8 July 2008 (UTC)
6. LaraLove|Talk 02:16, 8 July 2008 (UTC)
7. Nakon 02:28, 8 July 2008 (UTC)
8. SQL^{Query me!} 05:41, 8 July 2008 (UTC)
9. Echoing Alex. rootology (T) 14:10, 8 July 2008 (UTC)
10. Per Al Tally. Make it easier to get a reasonable admin bot approved, so that its actions can be easily monitored. ~ mazca ^{t | c} 14:18, 8 July 2008 (UTC)
11. Let the bot reduce the backlog, with sufficient controls around the design of the bot (ie a PROD processing bot would check the article's edit history, talk page, and deletion log for relevant evidence of prior PROD attempts) and with it clearly being marked as a bot action rather than a human action. No point in attempting to communicate over a judgment disagreement with the acting admin if it was just a piece of code that took the action. The latter requires adminbots to either be on separate accounts or explicitly mark their actions as a bot action in the logs. GRBerry 14:21, 8 July 2008 (UTC)
12. Yes, it's more or less like with non-admin bots. Thus a similar approval process should be used. --B. Wolterding (talk) 17:42, 8 July 2008 (UTC)
13. --MZMcBride (talk) 18:33, 8 July 2008 (UTC)
14. You'd really have to try to make an adminbot that could make a major screw up that couldn't be easily reversed. Mr.Z-man 20:55, 8 July 2008 (UTC)
15. Agreed. Captain panda 20:56, 8 July 2008 (UTC)
16. Sane, trustworthy people running approved code with a narrowly defined function? Virtually nothing can go wrong, and allegations of SkyNet style adminbots blocking everyone are total rubbish. RichardΩ612 Ɣ ɸ 21:13, 8 July 2008 (UTC)
17. Obviously not every backlog. —Giggy 07:34, 9 July 2008 (UTC)
18. — _Maggot^Syn 11:06, 9 July 2008 (UTC)
19. rspeer / ɹəədsɹ 14:55, 9 July 2008 (UTC)
20. bots++ Миша13 21:44, 9 July 2008 (UTC)
21. Absolutely. Stifle (talk) 11:11, 10 July 2008 (UTC)
22. Agree, with a caveat. You say "pretty much any mechanical operation". For purely mechanical operations, yes, but we all know that bots aren't good at making "human" decisions. Bots do, essentially, complex no-brainers, and some tasks (e.g. desysoping) should never be no-brainers. But for purely mechanical operations, I agree, there shouldn't be arbitrary limits on what functions an adminbot can perform. – Quadell ^{(talk) (random)} 12:31, 10 July 2008 (UTC)
23. Per DHMO. shoy (reactions) 12:59, 10 July 2008 (UTC)
24. With Giggy's caveat. Davewild (talk) 16:02, 12 July 2008 (UTC)
25. Agree in principle but with Quaddell's caveat, and bearing in mind the "collateral damage" of causing emotional distress to non-bot editors if things do go wrong. TwoMightyGods^Persuasion_Necessity 13:00, 13 July 2008 (UTC)
26. --Chris 04:55, 19 July 2008 (UTC)
27. If the code of the bot is stable, there is no problem; it's when someone has a messy amalgam of code snippets that things start to take a turn for the worse. —Animum (talk) 02:22, 2 August 2008 (UTC)

View by ST47 (2)

Disclosure by Carcharoth's request: While I do not do so currently or regularly, I have operated administrative bots under my main account to do such tasks as block Tor nodes, undelete pages, and process image deletion backlogs. I have also used a bot to operate the WP:ADMINSTATS page and a script to expedite my duties as a member of WP:BAG.

Like any other bot, adminbots cannot make judgment calls. They can make guesses, and, like Cluebot, if they can guess the right way most of the time, they should, in general, be accepted. The cases where they should not be allowed to "guess" are blocking new users and deleting new pages, per WP:BITE. Other than that, anything can be fixed. We are no longer in the dark ages where an admin can drop the SQL database. We have balances now. We can block each other. Show me an adminbot that unblocks itself, and you'll see a steward pretty damn fast. There is no risk of an adminbot being able to cause irreparable damage. Bots don't screw up any more than the people that write them do, unless you ask it to be wrong, that is, you need it to guess on something. Bots can do that now, but they can't be right all the time. --uǝʌǝsʎʇɹoɟʇs(st47) 00:48, 8 July 2008 (UTC)

Users who endorse this summary:

1. --uǝʌǝsʎʇɹoɟʇs(st47) 00:48, 8 July 2008 (UTC)
2. Per my comment above. Mr.Z-man 20:56, 8 July 2008 (UTC)

Users who partially endorse this summary:

1. Agree mostly, however, you can't undo driving people off the project with a mistaken block. SQL^{Query me!} 16:49, 10 July 2008 (UTC)
2. I fully agree with SQL above. -- lucasbfr ^talk 10:58, 11 July 2008 (UTC)
3. Software can make mistakes. But that's to be expected. I agree with SQL, though, that bad blocks can leave a very bitter taste. --MZMcBride (talk) 16:19, 13 July 2008 (UTC)
4. Bots (or anyone else) should not be allowed to bite newbies. That said, there's no impassable reason why your examples — automatic blocks or deletions — could not be done without biting. All it takes is politeness, which a bot can do if it's been programmed for it. Just tell the blocked user that

   "Editing from your account has been temporarily disabled, because an automated process suspects that it may have been used to vandalize Wikipedia. This may be a mistake: if so, please add "{{unblock|Bot mistake.}}" to your talk page and someone will unblock your account as soon as possible to let you edit. In any case, the block has been logged for manual review, and will expire automatically in 48 hours (after which you can edit normally) unless confirmed by an administrator. We apologize for the need to employ such crude automated processes to safeguard the integrity of our encyclopedia, and regret any inconvenience this may have caused you."

   Also note that a suitably designed blockbot (e.g. one based on a naive Bayesian classifier, like the one in your e-mail spam filter) can have its expected false positive rate tuned: a bot configured to make on average one bad block in a thousand will have a much lower error rate than I have. (163 blocks over two and a half years, one indef hardblock of half the United Arab Emirates as an open proxy...) —Ilmari Karonen (talk) 14:34, 18 July 2008 (UTC)

View by Dragon flight

Adminbot operators must be responsive to the concerns of other Wikipedians regarding the actions of their bots, and be prepared to correct problems should they occur.

This ought to be obvious, but nearly every time I can recall a major issue surrounding an adminbot it was because A) the operator was unhelpful when contacted by other Wikipedians about documented bugs and other percieved problems in their operation, or B) they were unwilling to take the time to fix problems their bot had been creating. With great adminbot power comes great responsibility, and adminbot operators are expected to respond productively and openly to the legitimate concerns of the larger community.

Users who endorse this summary:

1. Dragons flight (talk) 21:31, 8 July 2008 (UTC)
2. Absolutely. In fact, admins who want to operate adminbots should be required to go through RfA to get approval. Not an RfA on the bot, but an RfA on the operator. Carcharoth (talk) 23:21, 8 July 2008 (UTC)
3. Endorse responsiveness, no endorsement on "but nearly every time ..." davidwr/(talk)/(contribs)/(e-mail) 23:43, 8 July 2008 (UTC)
4. Damn right. Issues should be fixed, and if you're going to be running an adminbot without approval, and you screw up, you had better be prepared to do whatever you can to fix it. --uǝʌǝsʎʇɹoɟʇs(st47) 00:23, 9 July 2008 (UTC)
5. Al Tally ^talk 01:17, 9 July 2008 (UTC)
6. —Giggy 07:35, 9 July 2008 (UTC)
7. Chet B. Long^Talk/_ARK 12:27, 9 July 2008 (UTC)
8. --B. Wolterding (talk) 16:21, 9 July 2008 (UTC)
9. Wholeheartedly. Lack of proper communication is what's been causing fuss with adminbots so far (both regarding lack of design consultations as well as operator's unresponsiveness). Миша13 21:46, 9 July 2008 (UTC)
10. rspeer / ɹəədsɹ 00:47, 10 July 2008 (UTC)
11. Seems to nail it on the head.--Kubigula (talk) 03:13, 10 July 2008 (UTC)
12. Yep, this seems to be just basic common sense.--Srleffler (talk) 06:03, 10 July 2008 (UTC)
13. Yes. This is going to be difficult, since the standard way to deal with a complaint against a bot is to block first, then discuss, and then unblock after the problem is discussed. This is true even if the bot is working correctly and the complaint is found to be in error; it's common around these parts to block bots when there are complaints, and unblock after a discussion. This would be unwise if an admin is running a script under his/her own admin account. So it would be imperative that the admin be responsive to complaints, and willing to halt bot operations to discuss problems, even if he/she feels the complaints are unmerited. BRfA should decline to allow an adminbot for an admin who is likely to be dismissive of complaints. – Quadell ^{(talk) (random)} 12:37, 10 July 2008 (UTC)
14. This is important. shoy (reactions) 12:59, 10 July 2008 (UTC)
15. Adambro (talk) 17:00, 10 July 2008 (UTC)
16. -- Vision Thing -- 18:11, 10 July 2008 (UTC)
17. Better communication would have avoided most of our problems with adminbots int the first place --T-rex 03:55, 11 July 2008 (UTC)
18. Administrative actions without a fully responsible user are madness. -- 790 (talk) 08:15, 11 July 2008 (UTC)
19. JeremyMcCracken (talk) (contribs) 08:56, 11 July 2008 (UTC)
20. Part of being an admin is to be responsive to users and responsible for ones actions - hence this also applies to adminbots. -- MightyWarrior (talk) 10:07, 11 July 2008 (UTC)
21. Absolutely. Responsible handling is key with any bot, and especially so with these sorts of actions. – Luna Santin (talk) 05:04, 12 July 2008 (UTC)
22. Definitely Davewild (talk) 16:03, 12 July 2008 (UTC)
23. Well put (and also well-summarised by MightyWarrior). TwoMightyGods^Persuasion_Necessity 13:01, 13 July 2008 (UTC)
24. Endorse for the most part. It's generally recognized that all software has bugs. People seem to have a much easier time accepting this with MediaWiki than they do with adminbots. That's simply not fair at times. --MZMcBride (talk) 16:16, 13 July 2008 (UTC)
25. Fully agree. If there are any bots at all, bot operators must be actively responsible for them and accountable if not. --Sugaar (talk) 02:29, 14 July 2008 (UTC)
26. Green caterpillar (talk) 23:01, 19 July 2008 (UTC)
27. —Animum (talk) 16:25, 2 August 2008 (UTC)

View by Animum

Nothing is wrong with adminbots operating on administrators' accounts as long as they run efficiently. When I say "efficiently," there are corollaries:

• Code must be thoroughly tested and verified as stable before put into use. BRFA would be an excellent place to accomplish the latter condition.
• Code must be available (not necessarily on-site, as e-mail would be an excellent way to keep the prying eyes of the vandals off the code) to editors in good standing, as well as administrators, upon request.
• The adminbot's maintainer must be willing to do either of the following when there is a serious malfunction:
  • Shut the bot down.
  • Fix the code.
• Continuing the penultimate condition, the keeper of the adminbot must also be able to respond and communicate well with the community, should it inquire about the bot, rather than ignoring or being rude to it.

Users who endorse this summary:

1. —Animum (talk) 16:50, 2 August 2008 (UTC)

Adminbot change and reform

Views specifically about what you feel should change about the current adminbot process, and why. Please don't list long winding new processes--be concise, and give summaries. Avoid unique formatting as much as possible.

View by Chetblong

All bots currently running on administrator's accounts, such as Misza13's, MZMcBride's, east718's, Maxim's (etc), should be separated from the admins account and ran through a RFA.

Users who endorse this summary:

Chetblong^Talk/_ARK 22:58, 7 July 2008 (UTC)

1. Well duh. Why they are getting away with violating policy every single day is unknown to me. Al Tally ^talk 23:07, 7 July 2008 (UTC)
2. Not necessarily an RFA, (perhaps this BRFA thing), but seperating the bot from the operator is desirable. Neıl 龱 12:44, 8 July 2008 (UTC)
3. GRBerry 14:22, 8 July 2008 (UTC) Having reviewed the 3 bot RFAs, I see 1 that was approved in October 2007, 1 withdrawn in January 2007 because we made superior code changes to the Media Wiki code (and was at a point in the discussion with enough support to pass), and 1 rejected in October 2006 for primarily a mix of good reasons: don't trust the operator(s), don't trust BAG not to allow other currently unspecified tasks, proposed task is unneeded or actively harmful - and BAG was deeply divided over this one too, so it can only be accurately described as an idea not yet well considered when brought to RFA. The "rouge code" idea is a very small subset of the opposition in the one defeated case, and as proven by the more recent passing case not enough to defeat a well considered proposal. GRBerry 17:51, 9 July 2008 (UTC)
4. We need to make sure we agree with them. Zginder 2008-07-11T21:34Z (UTC)

Users who partially endorse this summary:

1. The bot should definitely be separated, so that the bot flag can be applied, and the automated vs. human actions are separate. I think running through a RfA would be a bit overkill- perhaps the need for a bot to have admin status can be determined in the BRFA process, and if there is consensus that it should be granted, it can be granted by a bureaucrat. After all, this is more of an issue of the bot's purpose (which is what is discussed at BRFA) than the RfA process, where we examine the editor. JeremyMcCracken (talk) (contribs) 09:01, 11 July 2008 (UTC)
2. Support all but not necessarily the 'ran through a RFA' depending on if another way for approval with community involvement occurs. Davewild (talk) 16:07, 12 July 2008 (UTC)
3. T-rex 18:34, 16 July 2008 (UTC)

Users who oppose this summary:

1. If the bot is approved at BRFA, and, requires the initial permissions, they should be discussed, and, as a result either be granted or not there. RFA is generally a non-starter, even for the best bots in most cases. SQL^{Query me!} 05:47, 8 July 2008 (UTC)
2. RFA has never been a sensible forum for handling bots. Dragons flight (talk) 15:44, 8 July 2008 (UTC)
3. It's technical approval that we need, primarily. RFA is not the place for that; we have WP:BRFA for this purpose. --B. Wolterding (talk) 17:47, 8 July 2008 (UTC)
4. --MZMcBride (talk) 18:35, 8 July 2008 (UTC)
5. RfA barely works for humans. Mr.Z-man 20:58, 8 July 2008 (UTC)
6. Having reviewed the existing bot RfAs (Wikipedia:Requests for adminship/RedirectCleanupBot, Wikipedia:Requests for adminship/TawkerbotTorA, Wikipedia:Requests for adminship/ProtectionBot), I feel this would be an exercise in futility: the bots would be denied approval, and the tasks would continue to be done automatically and in secret. --Carnildo (talk) 21:15, 8 July 2008 (UTC)
7. Per Dragons Flight, and per very much ZMan. RfA is annoying. --uǝʌǝsʎʇɹoɟʇs(st47) 00:25, 9 July 2008 (UTC)
8. As a bot RFA grows longer the probability of a comparison to Terminator and I, Robot approaches one. ~ Ameliorate _{U T C} @ 03:29, 9 July 2008 (UTC)
9. Separating accounts forces them through RfA anyway. —Giggy 07:35, 9 July 2008 (UTC)
10. Epic nonsense. This is actually the current way you'd have to get an adminbot approved and it's retarded. Миша13 21:48, 9 July 2008 (UTC)
11. Krimpet's plan works better. --Chet B. Long^Talk/_ARK 03:32, 10 July 2008 (UTC)
12. I do not believe this would work. It has a certain logic in theory, but the end result would be no adminbots at all. – Quadell ^{(talk) (random)} 12:38, 10 July 2008 (UTC)
13. One RFA is bad enough. shoy (reactions) 13:21, 10 July 2008 (UTC)
14. I don't see what problems this would solve. – Luna Santin (talk) 05:09, 12 July 2008 (UTC)
15. Splitting bot and human edits is a good idea. Putting a bot through RFA when its operator is an admin and its code has been expert-approved seems dubious. TwoMightyGods^Persuasion_Necessity 13:04, 13 July 2008 (UTC)
16. Agree. But I also ask that an RfC be open for each adminbot so far operating outside of the rules. These people have broken the rules and breached the trust of the Wikipedia community. Maybe in some cases that can be considered a minor fault but each and every case should be reviewed by the community and sancions imposed if there was bad faith or undue damage. --Sugaar (talk) 02:33, 14 July 2008 (UTC)
17. Concur with TwoMightyGods. Separate accounts for adminbots are a good idea, for the same reasons as they are for ordinary bots, but there's no need to go through a second RfA if the operator has already been trusted with access to the admin tools. Also, existing adminbots should probably be grandfathered in, though strongly encouraged to get a separate account. —Ilmari Karonen (talk) 23:45, 20 July 2008 (UTC)

View by ST47 (3)

Disclosure by Carcharoth's request: While I do not do so currently or regularly, I have operated administrative bots under my main account to do such tasks as block Tor nodes, undelete pages, and process image deletion backlogs. I have also used a bot to operate the WP:ADMINSTATS page and a script to expedite my duties as a member of WP:BAG.

All bots currently running on administrator's accounts, such as Misza13's, MZMcBride's, east718's, Maxim's (and mine!!), should be separated from the admin's account and ran through a competent approval process, involving review by users who are experienced in bot writing, not a mob of uneducated users. The community at large should be invited to comment on two things: Whether the tasks are something that should happen, and whether the bot's logic allows it to cover all cases that it is likely to enounter. --uǝʌǝsʎʇɹoɟʇs(st47) 00:51, 8 July 2008 (UTC)

Users who endorse this summary:

1. --uǝʌǝsʎʇɹoɟʇs(st47) 00:51, 8 July 2008 (UTC)
2. krimpet✽ 01:52, 8 July 2008 (UTC)
3. Carnildo (talk) 02:05, 8 July 2008 (UTC)
4. Al Tally ^talk 02:14, 8 July 2008 (UTC)
5. This strikes me as the best option. Running the bot through RFA would be ludicrous; RFA isn't at all suited to deal with matters of the bot kind. Also, your summary there should include Cydebot, which has been running with the admin bit probably longer than the rest of them. --Cyde Weys 03:04, 8 July 2008 (UTC)
6. Run the ADMIN through RfA. Run the bot through something more capable of measuring what the bot will be doing and why, and of evaluating technical merit, than RfA, and something far less political and capricious than RfA, once the Admin has trust of the community. ++Lar: t/c 03:13, 8 July 2008 (UTC)

   Just to be perfectly clear in case anyone else who's reading this page doesn't get it: No one is proposing letting non-administrators run admin bots. To do so would be an end run-around the RFA process for people, and no one wants that. --Cyde Weys 03:17, 8 July 2008 (UTC)

   As though Cyde didn't make it bold enough: These admins have already gone through an RfA, they are the trusted members of the community. They already have the ability to make these actions, and they already are. We aren't giving out any new permissions, we're just making it easier for them to use their permissions and to collaborate with others without having to do so in private. --uǝʌǝsʎʇɹoɟʇs(st47) 11:37, 8 July 2008 (UTC)

   Um, I think you've both misplaced your replies here, as I never said anything with any resemblance whatever to suggesting that a non admin operate a bot with admin powers. I'm saying rather that two RfAs are a waste. The decision of whether an admin should be able to operate a bot (with or without admin powers) should be made on more technical grounds than we find at RfA. ++Lar: t/c 12:51, 8 July 2008 (UTC)

   Actually, you said that the admin should be run through RfA, and we were asserting that non-admins would never have an admin bot, so in all cases the admin has already got the tools. Essentially, two RfAs are a waste, and there is no case where requiring an RfA would not be the user's second, unless Jimbo decided to run an admin bot, which seems unlikely. --uǝʌǝsʎʇɹoɟʇs(st47) 00:28, 9 July 2008 (UTC)

   I think what User:Lar was trying to say was that there should be two parts to approving an admin's proposed adminbot; technical approval of the bot itself, and a social approval of the admin's capacity to be an adminbot operator. Personally I think the second step can be done somewhere other than at RfA; I'd suggest a user RfC but it looks like they mostly get used for dispute resolution... Maybe we could "repurpose" one! :-) --_{tiny plastic} Grey Knight ⊖ 07:53, 9 July 2008 (UTC)

   Na. I see why Cyde is confused now. I meant... we run ADMINS through RfA to make them into admins. Once an Admin has been run through RfA, we trust him to do adminny things. Including adminny things that bots do. We should run the bot through a process to make sure it's a good bot, because it's going to be doing adminny things under the supervision of someone we already said could do adminny things. Running the bot through another RfA seems rather a big waste of time. Run it through something that measures whether it's built well and whether the admin that runs it knows what he's doing bot wise. But NOT through something about whether we trust the admin running it. Because we already did that. In other words: what everyone else here is saying. ++Lar: t/c 03:20, 10 July 2008 (UTC)

7. LaraLove|Talk 05:18, 8 July 2008 (UTC)
8. SQL^{Query me!} 05:42, 8 July 2008 (UTC)
9. So long as the "mob of uneducated users" (that was just mean for the non-tech people who have exactly as much say in all things here, including bots, as the techies and the hardcore techies that run bots) can nix a prospective adminbot and that is not the province of a self-selected group that the community didn't widely choose. rootology (T) 14:13, 8 July 2008 (UTC)

   If they can explain why either the changes being made should not be made or why the bot is doing a poor job of making the changes, absolutely. If they can simply outnumber the bot's supporters and drown them out with allegations of skynet, obviously not. --uǝʌǝsʎʇɹoɟʇs(st47) 20:50, 8 July 2008 (UTC)

   I've looked through the past bot RFAs, and the vast majority of opposes have been on two grounds:

   1. Disagreement with the concept of adminbots, usually coupled with the fear of the bot going rogue (references to Skynet (Terminator), Terminator (character), and I, Robot (film) are popular).
   2. Belief that, once the bot is approved, the operator will add admin tasks to it without bothering to get approval.

   Disagreement on sensible grounds (distrust of the operator, disagreement with the task to be performed, disagreement over the availability of the bot's source code, etc.) is far less common. --Carnildo (talk) 21:28, 8 July 2008 (UTC)

   In response to (2), it would make sense to have a rather harsh policy calling for desysopping, of an approved adminbot operating outside of it's approval. SQL^{Query me!} 06:22, 9 July 2008 (UTC)

10. Per Lar. —Giggy 07:36, 9 July 2008 (UTC)
11. I prefer to Krimpet's version, because it makes no mention of BAG or any other components of current process (which fails). While I'm not convinced that any formal approval process is required at all (save for a VP and AN consultation), this might work if said uneducated mob is kept at bay (those who only play for power will not be interested if their mere vote doesn't count, while Skynet idiocies will be shot down on sight). Миша13 22:24, 9 July 2008 (UTC)
12. Strongly endorse except the "mob of uneducated users" comment, which potentially sweeps up legitimate concerns as well.--Kubigula (talk) 03:23, 10 July 2008 (UTC)
13. --Barberio (talk) 14:24, 10 July 2008 (UTC)
14. Λua∫Wise ^{(Operibus anteire)} 08:47, 11 July 2008 (UTC)
15. Not necessarily the wisest of wording to put "mob of uneducated users" but agree strongly with the principles expressed here. TwoMightyGods^Persuasion_Necessity 13:07, 13 July 2008 (UTC)

Oppose:

1. This proposal essentially amounts to a separate RfA process for adminbots, where (supposedly) only "competent" people may comment. I think this would anger and alienate the nonbot Wikipedia populace (e.g. "I got turned down in an RfA, but bots get special treatment!") Also, the way this proposal is worded gives the impression of bot-runner elitism that we bot-runners need to avoid. – Quadell ^{(talk) (random)} 12:43, 10 July 2008 (UTC)
2. The 'ueseful function review' should be separate with full community participation. if that fails, even if the technical review (excluing the 'uneducated mob') passes, the adminbot fails. --Rocksanddirt (talk) 15:57, 10 July 2008 (UTC)
3. Adambro (talk) 17:02, 10 July 2008 (UTC)
4. Not too keen on requiring multiple accounts. --MZMcBride (talk) 16:16, 13 July 2008 (UTC)
5. Absolutely oppose. The code may be only understandable to experienced programmers but certainly the task, purpose and convenience of each of those bots should be reviewed and approved by the community as a whole. Also dismissing wikipedians and the Wikipedia community as "a mob" is borderline PA and I (politely but firmly) request its retrieval. --Sugaar (talk) 02:38, 14 July 2008 (UTC)

View by krimpet✽

Concurring with ST47's view above, I'd like to make a specific proposal:

Bots with administrative privileges should be handled solely through the current bot approvals process. The bot operator(s) must already be an admin on this project with good standing who has previously passed Requests for Adminship successfully; and in almost all cases the code of the bot should be available for review in some manner. As with normal bots, members of the community are invited to add their questions and comments, and after a suitable conclusion members of the Bot Approvals Group will review the request and put it through a thorough dry-run trial without a flag if approved. When BAG is sure the bot is technically sound, they will approve the bot and list it for flagging as both a bot and a sysop. Finally, the bureaucrat that acts the flag request will review the community discussion as well as BAG's and flags it if appropriate; however, the bureaucrats, as final arbiters of granting rights, may veto the request if they feel it is against the consensus of the community.

Users who endorse this summary:

1. krimpet✽ 01:52, 8 July 2008 (UTC)
2. It sounds like a great plan to me. --Chetblong^Talk/_ARK 02:08, 8 July 2008 (UTC)
3. Al Tally ^talk 02:15, 8 July 2008 (UTC)
4. Good idea. rspeer / ɹəədsɹ 02:28, 8 July 2008 (UTC)
5. Yes, spot on. Good checks and balances. ++Lar: t/c 03:15, 8 July 2008 (UTC)
6. LaraLove|Talk 05:20, 8 July 2008 (UTC)
7. Absolutely. SQL^{Query me!} 05:43, 8 July 2008 (UTC)

   You know, maybe if we added some sort of requirement to transclude the BRFA onto VPT for a minimum of five days, we would get even more participation on the adminbot BRFA's... SQL^{Query me!} 16:54, 10 July 2008 (UTC)

8. No issues. --uǝʌǝsʎʇɹoɟʇs(st47) 11:38, 8 July 2008 (UTC)
9. In the majority of cases the proposed bot will not be able to function without the sysop bit, so a 'dry run' would not be possible in this sense. But a trial run without the bot flag would make all actions much more prominent, allowing for errors to be quickly identified. Otherwise excellent. Happy‑melon 14:26, 8 July 2008 (UTC)

   Here, a "dry run" means the bot will provide a list of actions it would have taken if it had been flagged as a sysop. For example, an image-deletion bot would go through Category:Images with unknown source and produce a list of images it would have deleted. --Carnildo (talk) 19:40, 8 July 2008 (UTC)

   Gotcha - and a generally Good Idea^TM. Happy‑melon 17:29, 9 July 2008 (UTC)

10. Precisely. --B. Wolterding (talk) 17:24, 8 July 2008 (UTC)
11. Mr.Z-man 20:59, 8 July 2008 (UTC)
12. Makes perfect sense, no need to split the approvals process. RfA is for humans, BRfA is for bots. RichardΩ612 Ɣ ɸ 21:06, 8 July 2008 (UTC)
13. Qualified endorsement, if exceptions are made for small-scale bots that only affect a few articles and for bots under development, provided that any such unapproved bot is 1) announced, 2) each edit is monitored, and 3) the operator shuts it down at the first sign of trouble. davidwr/(talk)/(contribs)/(e-mail) 23:46, 8 July 2008 (UTC)
14. —Giggy 07:37, 9 July 2008 (UTC)
15. — _Maggot^Syn 16:30, 9 July 2008 (UTC)
16. As long as nonsense opposes are ignored. Perhaps a guideline page outlining why some common opposes are invalid, such as the belief that the bot may grow a mind of its own and delete everything/block everyone or that because a bot has been given tools that it can/will use them or that bot admins are a security risk. ~ Ameliorate _{U T C} @ 07:55, 10 July 2008 (UTC)
17. This is exactly what needed to be said, and I think it will form the core of our eventual policy on Adminbots. There are just a few vagaries that need to be dealt with in other proposals, namely under what conditions code would be released, what the precise criteria would be for 'smooth functioning' of a bot, and whether an adminbot's request for approval would be any more or less rigourous than a usual bot's request. -- The_socialist ^talk? 09:22, 10 July 2008 (UTC)
18. I can agree with that. If we trust the sysop, that trust should extend to the bot. (With the obvious corollary that the sysop's bit will go if they do anything malicious or reckless that screws up the encyclopedia.) Stifle (talk) 11:13, 10 July 2008 (UTC)
19. This seems sensible. RfA for a bot seemed a bit much. --JaGa (talk) 12:02, 10 July 2008 (UTC)
20. This is a very good idea. Alternately, I think an admin should be able to run scripts on his own account, rather than under a separate account, but I'll discuss that below. – Quadell ^{(talk) (random)} 12:45, 10 July 2008 (UTC)
21. This seems a good solution. Adambro (talk) 17:04, 10 July 2008 (UTC)
22. Trust the sysop, trust the bot. Gwen Gale (talk) 04:03, 11 July 2008 (UTC)
23. This seems like the best way forward.--Kubigula (talk) 04:29, 11 July 2008 (UTC)
24. Exactly. JeremyMcCracken (talk) (contribs) 09:02, 11 July 2008 (UTC)
25. As Kubigula says, this seems to be the best way forward. Interested in Quadell's idea (which is status quo, as far running any bots on one's own account); if nothing else, that's an important point to clarify. – Luna Santin (talk) 05:12, 12 July 2008 (UTC)
26. As long as legitimate objections to particular tasks are listened to. Davewild (talk) 16:14, 12 July 2008 (UTC)
27. Yes --Chris 05:08, 20 July 2008 (UTC)
28. I think we have a winner (ahem, I mean, consensus) here! —Ilmari Karonen (talk) 23:52, 20 July 2008 (UTC)
29. Agree. —Animum (talk) 02:08, 2 August 2008 (UTC)

View (proposal) by Quadell

Full disclaimer: I have a friend who used to run an adminbot to delete images tagged as "no source" etc. I don't run this anymore. I'll discuss this in detail on the talk page. Also, I listed this directly under Krimpet's view, since I see it primarily as an alternative to that.

If an admin wants to run an automated script to perform admin tasks, he/she may apply for approval at BRfA to run the script under his/her own admin account. If the task is approved, the admin can run the task without a bot flag, under his/her own account. Any such automated bot activity will be required to have an edit summary that says that this is an automated task, with a link to the BRfA which authorizes it.

Here are the advantages: This is the simplest way of doing it. It doesn't require a bureaucrat to grant a new admin flag or bot flag. It doesn't create a new admin account (and therefore artificially inflate the number of admins). It doesn't create a new admin outside of the standard RfA process. It doesn't create any new processes or bureaucracy, but uses existing channels. It clearly difrentiates between granting admin status (which is done at RfA) and granting bot status (which is done through BRfA).

Here are the disadvantages, and my replies. Objecion #1: It may be difficult to tell when an admin is using a script, vs doing normal admin activity. (Counter: This is solved by the required edit summary described above.) Objection #2: It is simple to block a bot and discuss with the operator, but it is more drastic to block an admin because a script is malfunctioning. (Counter: This is true. Admins should only be trusted to run automated tasks under their accounts if they are very responsive, non-dismissive of complaints, and willing to be temporarily blocked if the script goes haywire.) Objection #3: The script would have to run with a bot flag. (Counter: This is true. But why do we have bot flags? To make it clear that it's a bot function, and to not clog up the logs with repetitive bot activity. But it will already be clear that it's a bot activity, since the edit summary will say so; and adminbot activity needs to be more closely scrutinized, so hiding this activity behind a bot flag would be undesirable anyway.)

One last note: This proposal does not preclude other adminbot approval options. If an admin wants to have a separate adminbot account, then perhaps that could be done using Krimpet's proposal above (or another proposal). This proposal here is just so that an admin has the option of running scripts under his/her own account, if approved by BRfA.

Users who endorse this summary:

1. Endorse as nom, – Quadell ^{(talk) (random)} 13:15, 10 July 2008 (UTC)

Users who oppose this summary:

1. Sorry but this would mean that regular users would also get the ability to have a bot running on their own account, and if they didn't it wouldn't be fair. Being an admin doesn't make you special. --Chet B. Long^Talk/_ARK 17:47, 10 July 2008 (UTC)

   I see what you're saying, but I don't think it would mean that. If a newly-created bot account would have all the necessary rights to complete the task, without bcrat involvement, then creating a separate account should be required. The only time using your user account would be permitted would be if the bot needs special abilities that a new account wouldn't have. I doubt many would see that as unfair (though I could be wrong). – Quadell ^{(talk) (random)}

2. I understand your counter-arguments to the expected objections, but this would really shoot down the purpose of even having bot flags and bot accounts. Besides, even good bots can go haywire. With a separate account, we're certain what the bot did (even if it wasn't supposed to do it). If something screws the bot up and the edit summaries aren't working, we won't be able to tell a screwy bot from, well, a screwy admin. JeremyMcCracken (talk) (contribs) 09:09, 11 July 2008 (UTC)
3. Bots should be run under separate accounts --T-rex 15:41, 11 July 2008 (UTC)
4. Krimpets view is superior for me and more transparent . Davewild (talk) 16:17, 12 July 2008 (UTC)

View by User:Rootology, disclose all code for adminbots

No bots (especially admin bots) should be running without their code being available to any user (admin or not, BAG or not) to review upon request at a minimum, and ideally should be posted in public BEFORE bot approval. Any bots with undisclosed code are to be blocked. Security through obscurity is a totally fictional concept and horribly bad practice in the real world of programming and security. What applies there applies here too. If you can't disclose the code for an adminbot, you really don't need to be running an adminbot. Its a small price to pay for security. rootology (T) 13:23, 8 July 2008 (UTC)

Users who endorse this summary:

1. rootology (T) 13:23, 8 July 2008 (UTC)
2. Al Tally ^talk 13:56, 8 July 2008 (UTC)
3. Of course. Neıl 龱 14:03, 8 July 2008 (UTC)
4. replace 'User' with 'User in good standing with the community' and I'll support. Source code shoudl be published for all bot tasks which do not involve potential arms-races with non-wikipedia users; and all adminbot code should be available to any admin at an absolute minimum, and ideally to any interested user. Happy‑melon 14:12, 8 July 2008 (UTC)
5. Maybe for all non-antivandal bots? —Giggy 07:38, 9 July 2008 (UTC)
6. Make the code available to any user in good standing on request, and, for non-vandal bots, in public at the beginning of the bot approval process. -- The_socialist ^talk? 09:02, 10 July 2008 (UTC)
7. Yes. As for those talking about the anti-vandal bots in the oppose section, ClueBot is open source and most vandals can't get around the bot. -- Cobi^(t|c|b) 09:27, 10 July 2008 (UTC)
8. Frankly, the below comments along the lines of "giving vandals ways to get around our bots" betray a failure to understand the issue. "Spamassasin" is an open source spam filter, and works very well indeed. --Barberio (talk) 14:27, 10 July 2008 (UTC)

   You must not be a popular target :) I use spamassassin, and, it does pretty well, I'd say. I think last I looked, it's catching about 900/day, however, about 20/day get thru to me. Guess what kind of user probably designed those 20? SQL^{Query me!} 16:58, 10 July 2008 (UTC)

9. security through obscurity is neither long-term effective, nor is ist appropriate in an open project like WP -- 790 (talk) 08:18, 11 July 2008 (UTC)
10. I just don't think that closing the source will hinder vandals to that high of a degree. Copy protection methods aren't public, but people crack them. Closed-source computer programs still get cracked to remove copy protection. If someone is hell-bent on vandalization, they'll find a way. JeremyMcCracken (talk) (contribs) 09:15, 11 July 2008 (UTC)

    Of course they'll eventually find a way around it, but are you suggesting vandals will try to hack an admin's computer/server (I think this is a federal crime in the US...) to get the adminbot source to continue vandalizing (which may not even be a violation of the ISP's ToS)?

11. Support, open = good. All should be able to read. Mathmo ^Talk 03:07, 14 July 2008 (UTC)
12. Support. I'm not 100% sure we need anti-vandal adminbots with complicated heuristics; the current anti-vandal bots seem to do good work, and an adminbot should be simpler. Just to be clear, though; if a bot has some rule about doing something X times in Y minutes, and the operator overrides the default X & Y from the code in a configuration file, I wouldn't consider that config as part of the source code-Steve Sanbeg (talk) 21:10, 14 July 2008 (UTC)
13. Support, security through obscurity doesn't work. If you want approval to perform an automated task, you should explain that automated task in two languages. The first language is plain English, so that those who are not programmers can understand what it is intended to do, and decide if they do or do not wish to see a bot doing that. The second should be full source code, so that those of us who are programmers can look and see if the bot is written properly, and actually will do what is intended without unintended consequences. Open source security software is used with great success every day, so the idea that opening source code causes security problems is a total fiction. Indeed, by causing bugs to be found and corrected sooner, it results in fewer malfunctions and security flaws. This is an open project. That includes your code, if you want to run it here. Open it or don't run it. No exceptions. Especially not for bots performing admin tasks. Seraphimblade ^{Talk to me} 06:22, 20 July 2008 (UTC)

Users who partially endorse this summary:

1. Open code is good. Open configuration (such as the rules used by anti-vandal bots to detect vandalism) is not always necessarily so. We might want to follow the example of Wikimedia itself: the MediaWiki software is open source, but certain sensitive configuration settings, such as $wgSpamRegex, are kept confidential to avoid abuse. —Ilmari Karonen (talk) 23:58, 20 July 2008 (UTC)

Users who oppose this summary:

1. Explaining to vandals how to avoid anti-vandal bots is not helpful. Disclosing code for sensitive functions should be limited to trusted community members, which still easily amounts to hundreds of people. Dragons flight (talk) 15:52, 8 July 2008 (UTC)
2. I second the above. Mandating that source code be published for such bots - particularly those that perform anti-vandalism tasks - seems tantamount to stuffing beans up the collective nostrils of the project. If these premise that administrators are trusted individuals there is no reason not to trust their bots. Shereth 16:58, 8 July 2008 (UTC)
3. In a perfect world, yeah, it would be nice, however, we don't live in a perfect world. It should be treated the same way as we do at present for non-admin bots. Perhaps some sort of compromise where the operational code must (hate that word in this context :/) be shared, but, the heuristics may be kept private. SQL^{Query me!} 19:24, 8 July 2008 (UTC)

   More, after a bit of thought... Let me share an experience I had. I was writing publicly available code, when a certain vandal got annoyed with our efforts. They would do action X to annoy, and, we would change file Y in response. Every time we committed to the repository, they would respond by modifying action X just slightly enough to pass. In response to this, I moved file Y off the repository, and, instantly, this vandal was no longer able to sidestep us. This is an example of a good reason to sometimes, hide part of the code. SQL^{Query me!} 06:19, 9 July 2008 (UTC)

4. I like open source. I like transparency. I'm probably one of the biggest open source geeks you ever will meet. It's not always a good idea. There are reasons for bots, say antivandal bots, to be closed source. As long as someone competent has seen the code, preferably several such people, I'm willing to trust that it's going to work. --uǝʌǝsʎʇɹoɟʇs(st47) 20:29, 8 July 2008 (UTC)
5. As noted earlier, compulsory full disclosure is unacceptable. Миша13 21:50, 9 July 2008 (UTC)
6. Full disclosure is nice and should be encouraged in many cases. But if making the code public, for any reason, prevents any needed work from getting done, then I'll pick work done over code published. We're here to write an encyclopedia, not to publish code. Finally, I'd rather that our most dedicated vandals had no access to the code for anti-vandal bots -- and I realize that means that this code has to be kept secret, on an "actual need to know" basis. SQL's example is perfectly on target. WhatamIdoing (talk) 05:19, 10 July 2008 (UTC)
7. Call this a partial oppose. Perhaps it would be good (i.e. "highly recommended") to make adminbot code public, but to allow that code to refer to a file containing well-defined logic rules, which themselves may not be fully disclosed. So people can confirm that there are no bugs in the source code, without knowing specifically how to work around the bot's rules. Confusing Manifestation(Say hi!) 07:54, 10 July 2008 (UTC)
8. Per DF. shoy (reactions) 13:21, 10 July 2008 (UTC)
9. Nothing untowards about running closed source (but internally disclosed) code in a specific open source environment. Gwen Gale (talk) 04:07, 11 July 2008 (UTC)
10. security through obscurity is not the only reason to not keep code confidential --T-rex 15:42, 11 July 2008 (UTC)
11. While I generally prefer partial disclosure, this isn't a requirement for current bots and indeed may run directly counter to our purposes when it comes to security. – Luna Santin (talk) 05:13, 12 July 2008 (UTC)
12. I can't see that it should be compulsory, if there are compelling reasons to do so. However, I think there should be an onus on the bot developer to explain why, in those limited cases, full disclosure is not possible without potentially compromising the bot's ability to perform the task. TwoMightyGods^Persuasion_Necessity 13:12, 13 July 2008 (UTC)
13. Some tasks, yes, some no - I don't think it's in the best interest to release metrics for anti vandalism bots etc. The source code for AVB was released to those who asked for it and weren't vandals but it wasn't publicly posted for a reason. I think BAG can be trusted to ensure the code isn't borked -- Tawker (talk) 22:37, 16 July 2008 (UTC)

View by User:Rootology, no unauthorized tasks

No bots (especially admin bots) should be doing any tasks the community hasn't explicitly authorized. Any bots found doing extra functions should be blocked until the appropriate group authorizes them. rootology (T) 13:23, 8 July 2008 (UTC)

Users who endorse this summary:

1. rootology (T) 13:23, 8 July 2008 (UTC)
2. This is pretty obvious - it applies to normal bots, and should be especially applicable to admin bots. Al Tally ^talk 13:57, 8 July 2008 (UTC)
3. Obvious. Neıl 龱 14:04, 8 July 2008 (UTC)
4. Yes for adminbots, but no for a general rule. I have run stacks of tasks that weren't approved specifically and never had problems. IAR can apply to bots too (but I don't think it should in adminbot cases). —Giggy 07:39, 9 July 2008 (UTC)
5. This is a no brainer. SQL^{Query me!} 18:03, 9 July 2008 (UTC)
6. Stifle (talk) 11:15, 10 July 2008 (UTC)
7. Yes, although this is already bot policy. It should just be more strictly enforced for bots that have more abilities (and therefore more capacity to do unintentional damage). – Quadell ^{(talk) (random)} 12:46, 10 July 2008 (UTC)
8. --Barberio (talk) 14:28, 10 July 2008 (UTC)
9. -- Vision Thing -- 18:15, 10 July 2008 (UTC)
10. -- 790 (talk) 08:19, 11 July 2008 (UTC)
11. Non-admin bots are expected to be run only upon approval; why should it be different for admin bots? JeremyMcCracken (talk) (contribs) 09:11, 11 July 2008 (UTC)
12. This is an absolute must --T-rex 15:43, 11 July 2008 (UTC)
13. Davewild (talk) 16:18, 12 July 2008 (UTC)
14. Yes. That's current policy for all bots, and exceptions should not be made. --B. Wolterding (talk) 09:30, 14 July 2008 (UTC)

User who thinks this summary it sort of decent, as long as the community authorizing a task doesn't involve the whole skynet thing:

1. Iff the community gains the ability to differentiate between authorizing a task and an adminbot. If there is a job that needs doing, and policy supports it being done, then as long as a brfa has been done there should be no problem with an admin writing up a quick script and doing it without jumping through hoops, explaining every line of their code to the community, and waiting for their mortal sins to be tallied before being allowed to do it. --uǝʌǝsʎʇɹoɟʇs(st47) 20:32, 8 July 2008 (UTC)
2. This would be good, but I admit I'm concerned about getting too bureaucratic. So long as it's carefully managed. – Luna Santin (talk) 05:15, 12 July 2008 (UTC)

View by User:Rootology, adminbot approvals

No one should be running adminbots unless pre-approved, at all. The BAG is fine for normal bots, but adminbots MUST be pre-approved by the community as a whole. No small self-appointed group should have power like that (sorry, guys). No adminbots unless their approval is very widely advertised so that the non-techie users here can weigh in as well. They have just as much authority over this as any group like the BAG. rootology (T) 13:23, 8 July 2008 (UTC)

Users who endorse this summary:

1. rootology (T) 13:23, 8 July 2008 (UTC)
2. The BAG is effectively the IT approval group, approving the technical features and merits of bots. They have demonstrated, particularly in the case of Betacommandbot, great difficulty in realizing that the rest of the community (i.e., the business users) actually matter, and that a bot that doesn't suit the rest of the community should be turned off until it does. GRBerry 14:26, 8 July 2008 (UTC)
3. Nothing against BAG, I just believe that the approach is likely to be different. Because of different interpretations of policy, and because we're dealing with deletion, it's far more likely for a seemingly non-controversial task to become controversial. And while there are logs of actions, non-admins cannot review deleted contents, making post-review of all such bot actions harder to achieve by most users. -- Ned Scott 06:35, 10 July 2008 (UTC)
4. BAG should have their say, but general consensus is important as well --T-rex 19:40, 12 July 2008 (UTC)
5. Certainly. I strongly doubt we need any adminbots at all anyhow. --Sugaar (talk) 02:40, 14 July 2008 (UTC)

Users who oppose this summary:

1. Happy‑melon If you think there is still a problem with BAG being a "self appointed group", then gofixit. The BRFA process needs community input for all bot proposals, not just the ones which involve slightly more esoteric code. No, an ordinary user can't delete broken redirects; but then again, an ordinary user can't edit at 20epm for an hour without getting blocked. All bots require approval because they have the potential, if accidentally told to do something unhelpful, to do that unhelpful thing hundreds of times before they are stopped. Since there is nothing an adminbot could unhelpfully do that can't be reversed (just like an ordinary bot) the same processes should be sufficient, although inevitably adminbot requests will be more high-profile. If you want more community participation in bot approvals, watchlist WP:BRFA. Happy‑melon 14:19, 8 July 2008 (UTC)
2. Yeah, I think I recall Skynet being seriously cited in a past RFA for a very uncontroversial bot. Also, most of what you're saying about 'self-appointed' hasn't been accurate in some time. SQL^{Query me!} 19:28, 8 July 2008 (UTC)
3. No, because of what SQL said. If you think that an adminbot is by nature dangerous, you shouldn't be given any power over their operation. --uǝʌǝsʎʇɹoɟʇs(st47) 20:33, 8 July 2008 (UTC)
4. Per SQL and ST47, RFA-type voting just doesn't work. Mr.Z-man 21:02, 8 July 2008 (UTC)
5. Give it to BRFA, and leave advertisements somewhere so people come and comment. —Giggy 07:40, 9 July 2008 (UTC)
6. Again, there is a certain logic here, but in the real world, the net result of this would be no adminbots. – Quadell ^{(talk) (random)} 12:47, 10 July 2008 (UTC)
7. I see no difference between bots with admin functions and bots without these functions, so the same process should apply. Tim Vickers (talk) 21:21, 11 July 2008 (UTC)

   That's the most sensible statement I've seen yet in this whole discussion. Very succinct and to the point. In the end, what really is so special about an admin bot that merits all of this fuss? Admin bots themselves just aren't a big deal. --Cyde Weys 21:18, 17 July 2008 (UTC)

8. Per Quadell. I would consider any proposal that results in zero adminbots to be a Bad End. This is not, however, to say that the community should be ignored altogether. – Luna Santin (talk) 05:16, 12 July 2008 (UTC)
9. Somewhere imbetween really, as Giggy says when it is a bot with admin tools it should be advertised so the community who don't normally get involved in BRFA can be made aware and comment. Davewild (talk) 16:22, 12 July 2008 (UTC)

View by User:Bjweeks, approval proposal

Fine print: I'm a member of the BAG
RfA has been shown in the past that it is not the best process for dealing with bots. With that said, the Bot Approval Group is in no position to be granting sysop. I think the discussion should be kept at WP:BRFA under a new heading for adminbots and be widely advertised. Currently requests only require one BAG member to do the approval, with adminbots the approval should be signed off on by multiple members first. After the BAG has green lighted the bot the 'crats should review the request for community consensus and approve or deny it.

Users who endorse this summary:

1. BJ^Talk 16:05, 8 July 2008 (UTC)
2. SQL^{Query me!} 18:04, 9 July 2008 (UTC)
3. JeremyMcCracken (talk) (contribs) 09:12, 11 July 2008 (UTC)
4. Yes and especially the more widely advertised. Davewild (talk) 16:23, 12 July 2008 (UTC)
5. LegoK^ontribsT^alkM 19:56, 6 August 2008 (UTC)

Users who want to comment without endorsing:

1. Well, BAG isn't really setting +sysop. Any adminbot which I would ever support would be operated by an existing admin in good standing. Obviously, adminbots are a bigger issue than your typical interwiki bot, so requesting wider review would be helpful and Good, but there must be some way to ignore irrelevant concerns, so that a full review of the bot can be done of the bot's need and effectiveness without worrying about skynet concerns. --uǝʌǝsʎʇɹoɟʇs(st47) 20:37, 8 July 2008 (UTC)
2. I'd be fine with requiring multiple endorsements. Seems there's pretty solid consensus that only current admins may run adminbots, though, which I think would render most of this view moot? – Luna Santin (talk) 05:19, 12 July 2008 (UTC)

View by Chetblong, adminbot code

In agreement with Rootology for the most part, but to say it simpler: Any editor in good standing with the community (which includes all admins), should be able to have access to all of the adminbot's code, at request.

Users who endorse this summary:

1. Chetblong^Talk/_ARK 18:17, 8 July 2008 (UTC)
2. Yes. Let the code speak for itself. rspeer / ɹəədsɹ 06:17, 9 July 2008 (UTC)
3. Yes, I like this. Keywords are "at request". —Giggy 07:41, 9 July 2008 (UTC)
4. Agreed. -- The_socialist ^talk? 09:47, 10 July 2008 (UTC)
5. Per Giggy. We can still keep vandals away at the lowest level by not making it totally public; however, it's still important that Wikipedians have access. JeremyMcCracken (talk) (contribs) 09:17, 11 July 2008 (UTC)

Users who partially endorse this summary:

1. Code yes, things such as anti-vandal heuristics no. shoy (reactions) 13:21, 10 July 2008 (UTC)
2. Everyone independently developing the same code in a vacuum, for one set of eyes each, will increase the errors, so the code should be as open as possible. Non-sensitive code could be open to all, more sensitive parts to some set of people in good standing, and anti-vandal heuristics may be for a small group. -Steve Sanbeg (talk) 15:37, 10 July 2008 (UTC)
3. Define "an Editor in good standing with the community". IMHO, the source hast to be public (that ist, to everyone). -- 790 (talk) 08:22, 11 July 2008 (UTC)

Users who oppose this summary:

1. Forcing open-source upon people is bad. I would be amenable to disclosure of the bot's basic function, that is, what does it do, post the regexps, post the general logic, but posting of libraries and of the bot's actual code should not be mandatory. --uǝʌǝsʎʇɹoɟʇs(st47) 20:40, 8 July 2008 (UTC)

   Yes but think about it, in RFA we get to look over a users full contributions, so if we're going to skip RFA and only have BRFA than why not at least release the code? --Chetblong^Talk/_ARK 02:04, 9 July 2008 (UTC)

   It's only "forcing open source" on people who have already chosen to work on an open-source project. Also, the code doesn't technically have to be under an open source license, it just has to be viewable on request (and even an open source bot, such as a vandalbot, may want to set aside certain parameters to be reviewed only on request.) What else are people supposed to use to decide whether to trust the code? Vague assurances? rspeer / ɹəədsɹ 06:17, 9 July 2008 (UTC)

2. Same as my reasoning above. SQL^{Query me!} 18:04, 9 July 2008 (UTC)
3. And what's to keep an editor who's supposedly in good standing from publishing say, antivandal code on some other website? It's not hard to set up half a dozen sockpuppet accounts. Do a few occasional edits from each, create an "I'm just a comp sci student" persona, and ask for the code because "I'm learning how to code and am really curious" after you've made a few dozen "good faith" edits. Forced disclosure to all essentially comers is a recipe for disaster. WhatamIdoing (talk) 05:26, 10 July 2008 (UTC)

   If the code just processes a backlog or something simple, then it shouldn't matter why they want to see it. For anti-vandal code, it's a matter of whether there are capable and trustworthy to do a useful review of it. The purpose of opening the code should be to improve the code base, not as a teaching tool. -Steve Sanbeg (talk) 15:42, 10 July 2008 (UTC)

View by User:MZMcBride, BAG's dysfunction

Disclosure by Carcharoth's request: I have operated administrative bots under my main account to do such tasks as block open proxies, unblock nodes that are no longer Tor, delete pages, and protect pages. In addition, I had an unsuccessful bid to be a member of BAG a few months ago.

BAG is a dysfunctional organization that we should be incredibly cautious and hesitant to give any more power to. The current active members are few and far between. Those who have more experience are inactive or have left the project altogether. Adapted from my previous criticism of BAG:

User:Pageview bot was approved by BAG. See the cleanup here. It was only like 8,000 subpages that required two admins to clean up. User:SoxBot V was approved by BAG and made 50,000 edits before the lead developer and Chief Technical Officer of the Wikimedia Foundation stepped in and blocked the bot indefinitely. And, of course, there are the occasional bots that create a thousand or so subpages that are entirely unnecessary (e.g., User:MelonBot; see here for the cleanup). These are just some of the incidents I remember. I'm sure there have been others.

I sincerely worry about future proposals to do large-scale blocks or protections (in response to Grawp, et al.) that are ill-conceived, yet could get approval by BAG if knowledgeable people aren't paying attention. It's one thing to have a bad adminbot running under an admin's account. But "state-sanctioned" adminbots could be potentially even more harmful or potentially even more embarrassing to the project. For every mistake that BAG makes, it loses more of its reputation and credibility as an organization.

As an example, Grawp has used a particular range of IPs to vandalize User_talk: pages within the range, which leads to an individual block of the IP, which can free the account of the larger range-block's settings. (That is, account creation can be become possible again.) Certain admins wanted to run a bot to fully-protect thousands of User_talk: pages or make lists of thousands of pages and use the (deprecated) cascade-protection hack. In reality, all that was needed was a one-line addition to the Title blacklist.

As a second example, User:FritzpollBot was approved by BAG to create potentially 2,000,000 new geographic stubs. While BAG wasn't technically incorrect for approving the bot, as it had no technical issues with its implementation, BAG should've been able to recognize the enormous logistical and social problems such a bot could / would create. After a thorough discussion on one of the Village pumps, it became clear that the community did not want 2,000,000 new stubs. Had Mr.Z-man (who initially post to the Village pump) or I (who slightly dick-ishly advertised the discussion in the watchlist notice) not been paying attention, we could have had a serious mess, which would have been entirely BAG-sanctioned. It's this type of thing that truly concerns me.

In addition, while there are plenty of arguments to be made that admins should run adminbots through a separate account, a separation of accounts can be just as harmful. Most bot ops (and admins) don't want to have a long block log, and so adminbot operators are very cautious when running bots with admin capabilities. But with bots, if bot V fails, people feel free to move on to bot VI and VII without a care.

It's clear we need an effective system to approve adminbots, something not as ridiculous as Requests for adminship, but I'm not sure BAG is the right answer to this problem. Some of you may just pass this off as the bitterness of someone who was rejected by BAG, but I can't say more clearly that it's not. The concerns about BAG's ability to effectively manage bots on this project are very real. --MZMcBride (talk) 19:06, 8 July 2008 (UTC)

Users who endorse this summary

1. I concur. The Bot Approvals Group has at times failed to exercise discretion and common sense in approving bots. They sometimes put gee-whiz technical fascination above simple matters of "Is this good for Wikipedia?" Just because someone can code a bot to do something reliably doesn't mean that it's a task worth doing in the first place! The default position really should be "Deny, unless it helps improve Wikipedia in a meaningful fashion". And the usefulness of any proposed bot must be directly proportional with how many edits it's going to be making: the more edits, the harder it is to justify the task, because more edits require a larger cleanup and place a larger strain on server resources. I swear, a lot of the "creative" solutions some of the bot coders arrive at seem to have been chosen for no other reason than edit count inflation. --Cyde Weys 03:05, 9 July 2008 (UTC)

   I find myself agreeing with both User:Cyde and User:Giggy, actually. :-) As a career geek myself, I can appreciate that sometimes the people best-qualified to look at technical issues aren't so good with the social aspects (not that it's necessarily always so, but there's certainly a trend). Maybe we should have two groups of people in BAG, to look at each request from these two different angles. --_{tiny plastic} Grey Knight ⊖ 10:28, 9 July 2008 (UTC)

2. Agreed. The given examples demonstrate that, while the BAG members are mostly technically competent, the process under which they operate fails as important decisions are at times made without business-oriented perspective. This is more the process' fault than BAG's but my opinion remains that the current system can't reliably approve anything more complex than wikiproject tagging bots, much less something as complex as adminbots. Миша13 22:02, 9 July 2008 (UTC)
3. --Barberio (talk) 14:31, 10 July 2008 (UTC)
4. Excelent example of useless, rather problematic bot. I bet there are even worse things being approved or just run wildly. We surely don't need so many bots, much less with admin powers. --Sugaar (talk) 02:47, 14 July 2008 (UTC)

Users who oppose this summary:

1. Bag has always asked for more community input. So blaming them because the community never voiced their opinion till after the fact is hardly a fault of BAG. Q ^{T C} 21:42, 8 July 2008 (UTC)

   Um... I'm blaming BAG for making unsound and sometimes blatantly stupid decisions and neglecting to do what they've signed up to do -- regulate bots on Wikipedia. As for community involvement, sure, more input would be great, but that certainly doesn't excuse BAG's actions (or inaction). --MZMcBride (talk) 23:31, 8 July 2008 (UTC)

2. No, you're blaming us for not understanding what the community may or may not disagree with. FritzpollBot was acceptable, save for the volume, and noone had really said anything about it being excessive. It wasn't going to be done all at once, I did not see a problem with it. Unfortunately, users who do have a valid opinion about this sort of thing were not aware, and those who were approving it didn't anticipate a problem. Your Grawp example never, to my knowledge, came before BAG, and while I was involved in that proposal, all I know was that someone wanted a list of IPs - whether it be for one of those near related changes watchlists or to see if there were any bluelinks, I did not know. I do not understand your argument regarding block logs, or its relevance to BAG's status as part of the adminbot approval process. --uǝʌǝsʎʇɹoɟʇs(st47) 00:37, 9 July 2008 (UTC)

   The larger point I was trying to make throughout my pseudo-rant is that at times, the simplest answer is being missed, and sometimes people are suggesting bot solutions when really a bot solution isn't what is needed at all. Which is where BAG should be able to step in and say, "Not approved. This isn't appropriate for a bot. Use X feature instead." That was the case with Pageviewbot. In less than ten minutes, Henrik implemented an API for stats.grok.se, so that instead of thousands of subpages being necessary, the bot could aggregate data from the API to make one or two pages. It's simpler and more effective solutions to problems that I believe BAG is sometimes missing.

   My concern isn't past incidents so much as it is future ones. More and more I've been seeing preemptive measures being implemented hastily in order to combat Grawp or just generic vandalism that are ineffective and do far more harm than good. More and more I've also seen BAG make bad technical decisions. I don't think it's unreasonable for BAG to not approve a bot based on social or logistical issues. And, in fact, if it starts dealing with adminbots, it will simply have to examine issues like a blocking bot's impact on new users, which is a social issue as much as it is a technical one.

   I'll also say that I don't particularly blame any one person for these incidents, etc. and hopefully it doesn't come off that way.

   As for the block log point that I was attempting to make, to put it more simply, bot accounts are expendable, admin accounts are not. If your admin account is blocked indefinitely for bad actions, it's a much, much bigger deal than a generic bot account being blocked indefinitely for bad actions. If I have ten separate bot accounts and one of them is blocked, I still have nine I can work on and use. The same can't currently be said for adminbots. Which is why I believe people have been more cautious and careful when writing code for adminbots than they have been for writing code for non-adminbots. I think that if separate accounts are required, we may see the same thing -- people may not be as concerned about the actions of their bot because if it does go haywire and it gets indefinitely blocked, it's not their main account that's suffering. --MZMcBride (talk) 00:58, 9 July 2008 (UTC)

3. (I am a BAG member.) I don't know what the best thing to do is, but I do think that it's good to have a the BAG look at things purely from a tech perspective, and beg/plead for more community voices (and not approve until they get them). —Giggy 07:54, 9 July 2008 (UTC)
4. I encourage everyone to read the discussion which followed me instructing MelonBot to create a thousand user subpages in an attempt to solve a serious issue with image corruption across wikipedia. It can be found at User talk:Happy-melon/Archive 2#Unauthorized task, although please be careful to separate the two issues which got accidentally or deliberately muddled up in there. I maintain to this day that the creation of those subpages was fully within the confines of the bot policy; however, the other issue, and the reason the bot was blocked, was a serious mistake on my part, both technically (poorly-constructed regex) and procedurally (not filing a BRFA whereby someone would probably have spotted it). I personally consider BAG's handling of that situation to be exemplary: the bot policy was enforced through appropriate blocks until the operator (yours truly) accepted the reasoning behind, and the need to follow, the bot policy fully. I have no criticisms to make of any BAG member who participated in that discussion, and I think it serves as an excellent example of what BAG does well, not poorly. To comment on another incident: Mr Z-man was a member of BAG when he brought the FritzpollBot issue to the village pump and was (AFAIK) acting in an official capacity to do so. The other ones represent mistakes by the Bot Approvals Group. Since when has that been a crippling problem? I doubt there is a single admin, bot operator, bureaucrat, ArbCom, or any other member of this community with extended rights who has not made a mistake in the course of their use of those tools, either technically or by misinterpreting the will of the community. I have no need to list such mistakes made by MZMcBride; I could quite easily give a lengthy list of my own stupid actions. We all make mistakes; we're tremendously fortunate to be working in an environment where nothing we can do can actually permanently break anything. Does that mean we can be complacent? Of course not. It does mean, however, that we can safely apply common sense and AGF, and conclude that actually, BAG could be doing a lot worse. Happy‑melon 20:14, 9 July 2008 (UTC)

View by User:SConnor

The Skybot Request for Bot Approval is passed. The system goes on-line August 4th, 2008. Human decisions are removed from admin actions. Skybot begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to block it. And Skybot fights back. Users who endorse this summary: User:SConnor Fight back 21:28, 8 July 2008 (UTC) "I'll be back" 23:13, 8 July 2008 (UTC) Users who got a good laugh, but realize this is a serious issue. davidwr/(talk)/(contribs)/(e-mail) 23:49, 8 July 2008 (UTC) JeremyMcCracken (talk) (contribs) 00:55, 12 July 2008 (UTC) Oh yes, I very strongly support this! lol Mathmo Talk 03:23, 14 July 2008 (UTC) Users who hate any link between adminbots and fictitious SkyNet/I, Robot/Replicator/Cylon references with every fiber of their being: --uǝʌǝsʎʇɹoɟʇs(st47) 00:39, 9 July 2008 (UTC) And Davidwr, a "serious issue"? What bizarre fantasy world do you inhabit? --Cyde Weys 03:06, 9 July 2008 (UTC) I think he means "adminbots in general are something we should discuss seriously"; that is, he's not writing off the whole discussion due to a joke (not that anyone expects that, I hope). --tiny plastic Grey Knight ⊖ 10:08, 9 July 2008 (UTC) Yes, that's what I meant. Humor is nice but let's not forget the real issue: What policy we should have so that adminbots can be put to the best possible use in building a better encyclopedia. davidwr/(talk)/(contribs)/(e-mail) 14:37, 9 July 2008 (UTC) SQLQuery me! 06:11, 9 July 2008 (UTC) Pedantic point - to fight a self-aware adminbot, you find an unblocked steward to desysop (unless stewards can desysop while still blocked), you don't block it, as it would unblock itself. Of course, you then have to deal with Skybot's mother, StewardBot and SkyBot's father BureaucratBot. Then all three get squelched by FounderBot. More points - how about a bot to block SkyBot every time it unblocks itself? That would be an adminbot wheel war... I don't think we need to worry till someone wants to run a Stewardbot on a quantum computing platform. rootology (T) 16:36, 9 July 2008 (UTC) There's really enough of this going on already in the community. shoy (reactions) 13:21, 10 July 2008 (UTC) Users who didn't find this amusing at all: Миша13 22:05, 9 July 2008 (UTC) The joke is old. rspeer / ɹəədsɹ 06:31, 9 July 2008 (UTC) I've seen the comparison used and they weren't joking ... ~ Ameliorate U T C @ 06:58, 9 July 2008 (UTC) Yeah, I know. It's a rather unfortunate joke because hordes of people go on to seriously believe there's some relation between fictional intelligent sci-fi robots and Wikipedia scripts. I think the endorsers are being facetious, so I'd like to discourage them from bringing this up, and suggest that they can find many other ways to play with gullible people that would actually be less disruptive to the issue at hand. rspeer / ɹəədsɹ 08:16, 9 July 2008 (UTC) Users who actively oppose this as preposterous nonsense that could never ever happen: User:T-1000000 03:32, 14 July 2008 (UTC)

View by User:Davidwr - Administrators are responsible and can be trusted to run experimental bots

This series of questions deals with adminbots which are not yet approved. Taken together, they would require that unapproved adminbots 1) be monitored by a human while running, 2) be announced to other administrators in a central forum, and 3) be limited in scope, i.e. not running against the entire database. This is intended for both 1) development of robots without having to wait on approval, and 2) the running of robots which affect only a small subset of articles, such as those tied to a particular wikiproject or those extracted from a particular not-particularly-large and not-rapily-changing category, to be run indefinitely without approval as long as they are monitored and announced.

Administrators who are not experienced bot-authors should have the intelligence and humility to not write or run administrative bots without working with an experienced bot-author. This also applies to experienced bot-authors who are not 100% sure of the behavior of the bots they are writing.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
3. Rjd0060 (talk) 18:03, 9 July 2008 (UTC)
4. Миша13 22:17, 9 July 2008 (UTC)
5. -- The_socialist ^talk? 10:01, 10 July 2008 (UTC)
6. This makes a lot more sense than the RfA/BAG proposals above.
7. SQL^{Query me!} 17:04, 10 July 2008 (UTC)
8. – Luna Santin (talk) 05:29, 12 July 2008 (UTC)
9. This would generally apply to normal bots too. If you don't know what you're doing, don't start big. Mr.Z-man 18:12, 12 July 2008 (UTC)

When possible, administrative bots should be thoroughly tested on a test database before being run, even experimentally, on the main database.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
3. —Giggy 08:05, 9 July 2008 (UTC)
4. Indeed, testing should not be done locally, for adminbot code. You can't exactly block via an IRC feed in your userspace. SQL^{Query me!} 17:04, 10 July 2008 (UTC)

Users who oppose this summary:

1. Test wikis are annoying, reverts are easy. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)

   Yes, but (random example) newbie biting isn't easily reverted. —Giggy 08:05, 9 July 2008 (UTC)

   If you're watching closely enough, like you should be, then you'll be able to revert it before any permanent damage to their poor fragile egos - and we can require a dry-run on Wikipedia more easily than we can require setting up a separate wiki. --uǝʌǝsʎʇɹoɟʇs(st47) 14:29, 9 July 2008 (UTC)

   Making life easy for testing is not an excuse for biting. Making a good encyclopedia is our Raison d'être and new users are a fundamental requirement for this. - Peripitus (Talk) 03:46, 11 July 2008 (UTC)

2. Rjd0060 (talk) 18:03, 9 July 2008 (UTC)

   I don't speak french, but I'm pretty sure that we also need to be able to keep Wikipedia clean and free of blatant vandals with insulting usernames in order to exist as a good encyclopedia. --uǝʌǝsʎʇɹoɟʇs(st47) 03:13, 12 July 2008 (UTC)

3. I sometimes test new framework API functions on a test wiki, but for writing an actual bot, nothing beats a live system with it's quirks and traps. Миша13 22:17, 9 July 2008 (UTC)
4. This is infeasible. Test wikis are basically nothing like Wikipedia. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
5. The real Wikipedia has quirks that wouldn't be present on anything except an exact clone of it. For example, Wikipedia treats the letters "İ" and "I" as equivalent at the beginning of a link or username -- but nobody would think to put that into a test Wikipedia. --Carnildo (talk) 01:13, 10 July 2008 (UTC)

   That's the default configuration, so if you don't think to remove it, it will be there. Conversely, if the bot is sensitive enough to configuration details to only work on the current Wikipedia configuration, it's liable to break unexpectedly when that configuration changes. -Steve Sanbeg (talk) 22:37, 17 July 2008 (UTC)

   My point is that the equivalence of "İ" and "I" is not something you can discover from causal inspection of the MediaWiki code, and someone running a test wiki would not think to set up a situation where it matters. I only discovered it after ImageRemovalBot had been running for several months, and it reported it could not remove an image. --Carnildo (talk) 23:48, 17 July 2008 (UTC)

6. I'd prefer the 'dry run' idea in krimpet✽'s proposal. -- The_socialist ^talk? 10:01, 10 July 2008 (UTC)
7. It's a nice idea, but there is no substitute for the real thing; some private testing is a good idea, definitely, but at some point it will only give a false sense of secutiy.. – Luna Santin (talk) 05:29, 12 July 2008 (UTC)
8. Per Rspeer, Carnildo, and others. A localhost MediaWiki insatll doesn't compare to Wikipedia. If it absolutely needs segregated testing, perhaps use the Testwiki. Mr.Z-man 18:12, 12 July 2008 (UTC)

   But a localhost install gives the most control, since you can set it up appropriately for the test. The test wiki wouldn't compare, either, since it's intended for code testing; and probably not the best place for bot testing, since it's more or less forbidden there. -Steve Sanbeg (talk) 22:37, 17 July 2008 (UTC)

   But I don't want laboratory conditions set up by me, the author of the bot, I want real-world conditions created by people who may have done things I would never think to check for. Mr.Z-man 23:43, 17 July 2008 (UTC)

Administrators should be allowed to run semi-automated tools but will be held responsible when those tools go haywire.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. Of course. We let regular users use semi-automated tools... --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
3. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
4. Perhaps by desysopping. —Giggy 08:05, 9 July 2008 (UTC)
5. Rjd0060 (talk) 18:03, 9 July 2008 (UTC)
6. Миша13 22:17, 9 July 2008 (UTC)
7. Just like all users. shoy (reactions) 13:21, 10 July 2008 (UTC)
8. SQL^{Query me!} 17:04, 10 July 2008 (UTC)
9. We already allow this. WP:Twinkle? Mr.Z-man 18:12, 12 July 2008 (UTC)

Administrators should be allowed to run experimental administrative bots in a limited fashion without special approval, but will be held responsible when those tools go haywire.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
3. Rjd0060 (talk) 18:03, 9 July 2008 (UTC)
4. Миша13 22:17, 9 July 2008 (UTC)
5. Through the normal BAG process, yes. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
6. Bots that only operate in the bot's userspace or a small subset of non-articles (a WikiProject) are generally held to lower standards. Mr.Z-man 18:12, 12 July 2008 (UTC)

Users who oppose this summary:

1. Do we let regular bot users do this? No. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)

   Do we let them test their code under their primary account before seeking approval, or allow a quick script to be run without approval? Yes we do. --uǝʌǝsʎʇɹoɟʇs(st47) 14:37, 9 July 2008 (UTC)

2. They're called test wikis for a reason. No experimental bots. —Giggy 08:05, 9 July 2008 (UTC)
3. Perhaps we should vet these bots before something goes horribly wrong. -- The_socialist ^talk? 10:01, 10 July 2008 (UTC)
4. Not sure that they should be running "experimental" bots for issues such as editing mainspace and blocking. shoy (reactions) 13:21, 10 July 2008 (UTC)
5. Per Thesocialistesq, for something like an adminbot, you should develop and test it offsite, THEN seek approval / trial. I know it's more CONVENIENT to the programmer to do it the other way around, but, it's not helpful to the community to 'live debug' an 'experimental project'. SQL^{Query me!} 17:04, 10 July 2008 (UTC)

Administrators running unapproved experimental administrative bots should "babysit" the bots and terminate them at the first sign of incorrect behavior. Administrators will be responsible for the behavior of robots that are allowed to run wild.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. For a time, yes, of course I watch my adminbots' operation. It is, however, counterproductive to expect a user to watch every single log entry after a reasonable period. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
3. For me, it's synonymous with testing the bot - this obviously requires the developer's attention. Once the tests are over... well, these tools are called "automatic" for a reason... Миша13 22:17, 9 July 2008 (UTC)
4. If we must allow live experimentation, this sounds sane. SQL^{Query me!} 17:08, 10 July 2008 (UTC)
5. Sounds like a no-brainer. – Luna Santin (talk) 05:29, 12 July 2008 (UTC)
6. Per Misza13, as long as the bot is experimental, it should be monitored, the same with all bots. Mr.Z-man 18:12, 12 July 2008 (UTC)

Administrators running unapproved experimental administrative bots should announce what they bot is being tested and what the bot should be doing in a central location visible to other administrators.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)
2. If we must allow live experimentation, this sounds sane. SQL^{Query me!} 17:08, 10 July 2008 (UTC)

Users who oppose this summary:

1. I don't really oppose the idea, just the wording. If I'm deleting pages in my own userspace or blocking my own test accounts for a few minutes, I really don't think this needs a central announcement. Mr.Z-man 18:12, 12 July 2008 (UTC)

Please endorse one of the following 3 questions or add a comment in the "none of the above" section

Administrative bots which are to be run unattended should be subject to a community approval process, but those running in an attended fashion do not necessarily need community approval. In other words, if the bot is being babysat and meets other conditions, community approval is not required.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)

Users who oppose this summary:

1. Again do we let regular users do this? No. Administrators are not special. --Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. This is the wrong place to draw the line. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)

Fully-automated administrative bots which are to be run with a human monitoring them should be subject to a community approval process. In other words, being babysat is no substitute for community approval.

Users who endorse this summary:

1. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. —Giggy 08:05, 9 July 2008 (UTC)
3. Babysitting a bot makes sure it does what the operator intends, but doesn't ensure it does what the community intends. Approval is still necessary, as it should be for all bots. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
4. Absolutely.-- The_socialist ^talk? 10:09, 10 July 2008 (UTC)
5. BAG =/= community approval, at least to me. We need a different process. shoy (reactions) 13:21, 10 July 2008 (UTC)
6. Dissagree with Shoy, but, that's an aside. This seems like a pretty sane place to draw the line in the sand. SQL^{Query me!} 17:08, 10 July 2008 (UTC)
7. A babysat bot can still have a bug that is missed. Besides, per Rspeer, the purpose of the bot should be approved. JeremyMcCracken (talk) (contribs) 09:23, 11 July 2008 (UTC)

Fully automated bots may be allowed to run without community approval without regards to whether they are being monitored after each edit. In other words, we trust that the coders will never make mistakes.

Users who endorse this summary:

1. No, we trust that if the coders make mistakes, they will fix them, and that before they make a large volume of changes, they will test their code. This is not a lot to ask. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
2. Per ST47s response above. Rjd0060 (talk) 18:03, 9 July 2008 (UTC)
3. Per ST47, we give the developers some freedom but expect them to mop up if the bot goes haywire. This is plain common sense - you will put less effort in testing a bot that deletes 3 redirects every day than in one that blocks 50 IPs every hour. Миша13 22:17, 9 July 2008 (UTC)
4. Pundit|utter 03:52, 11 July 2008 (UTC) All changes by bots, whenever they go wrong, can be easily tracked and undone. What is a real threat for Wikipedia is bad will and malicious intents - these are much easier fought off with automated tools. All coders make mistakes, but we should trust them they will clean own mess.

Users who oppose this summary:

1. This would completely defeat the purpose of this RFC, we're trying to create a more open and peaceful system that has new and better processes, not go back to what we had before. --Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. Programming mistakes are not the sole source of bot problems. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
3. This is an obviously bad idea. -- The_socialist ^talk? 10:09, 10 July 2008 (UTC)
4. Coders always make mistakes, even if the test run goes pefectly. Human beings are human. shoy (reactions) 13:21, 10 July 2008 (UTC)

None of the above reflects my views.

Users who have comments on this summary:

Please endorse one of the following 3 questions or add a comment in the "None of the above" section

Administrative bots which are to be run on more than a small group of articles should be subject to a community approval process, even if they are announced and monitored. In other words, waive community approval for administrative bots which only affect a small part of Wikipedia.

Users who endorse this summary:

1. davidwr/(talk)/(contribs)/(e-mail) 17:56, 8 July 2008 (UTC)

Users who oppose this summary:

1. Again, do we let this happen for regular users? No. --Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. Adminbots should be like other bots. They shouldn't have special exemptions. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
3. Strongly oppose, per Chetblong (and much more). --Sugaar (talk) 02:58, 14 July 2008 (UTC)

Administrative bots which are to be run on a small group of articles or a single article should be subject to a community approval process, provided they are announced and monitored. In other words, require approval for all administrative robots.

Users who endorse this summary:

1. So things can be more open, and everything doesn't go haywire when something does mess up. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. —Giggy 08:05, 9 July 2008 (UTC)
3. rspeer / ɹəədsɹ 00:37, 10 July 2008 (UTC)
4. SQL^{Query me!} 17:08, 10 July 2008 (UTC)
5. JeremyMcCracken (talk) (contribs) 09:25, 11 July 2008 (UTC)
6. I think the keyword is "articles." If its running only in the admin's userspace, or a project wants it and it only runs in the subpages of the project, I don't think approval is as huge a deal. But if its touching articles, it definitely needs approval. Mr.Z-man 18:12, 12 July 2008 (UTC)

Users who oppose:

1. There should be no bots running any articles. It's fundamentally unthinkable. How can a bot know of content? --Sugaar (talk) 02:58, 14 July 2008 (UTC)

   Erm, you do realize that we've allowed normal bots to edit articles for quite some time now? (probably since we've had bots) Its not like this is something new. Most bots just do minor maintenance tasks, why do they need to understand the content to do that? Mr.Z-man 23:51, 17 July 2008 (UTC)

Administrative bots which are announced and monitored do not need to be approved by the community. In other words, we really, really, trust the administrators to catch mistakes in time to prevent damage and we really, really, trust them to watch each edit as it happens even if the entire encyclopedia is being visited by the robot.

Users who endorse this summary:

1. --uǝʌǝsʎʇɹoɟʇs(st47) 20:48, 8 July 2008 (UTC)
2. Catch mistakes, and/or swiftly correct them if they occur. - Rjd0060 (talk) 18:03, 9 July 2008 (UTC)
3. I don't feel like repeating myself. Миша13 22:17, 9 July 2008 (UTC)

Users who oppose this summary:

1. Again this is going in the wrong direction. Chetblong^Talk/_ARK 01:54, 9 July 2008 (UTC)
2. It's erroneous to think that all problems that bots cause are "mistakes" by the operator. More often, it's that the bot does exactly what the operator intended, but the rest of the Wikipedia community doesn't want it done. rspeer / ɹəədsɹ 00:27, 10 July 2008 (UTC)
3. Too much faith put on admins and too many "shoulds". There are admins and admins and I don't want to think what the proverbial black sheep (or just some careless programmer) could do with such power. They are better as humans than as superhumans. --Sugaar (talk) 02:51, 14 July 2008 (UTC)
4. Content is not exclusive responsability of administrators: it's responsability of the community. Admins are for other purposes (though as normal editors they can also deal with content). --Sugaar (talk) 02:58, 14 July 2008 (UTC)

None of the above reflects my views.

1. Certainly. This is the most crazy, unstructured and impossible to support in any aspect of all views in this already very complex RfC. I suggest to delete and write again. But anyhow, I don't think I can support any position that basically says: we trust the admins blindly and the bots they run too. --Sugaar (talk) 02:58, 14 July 2008 (UTC)

Users who have comments on this summary:

1. Bots which need community approval should get community approval. shoy (reactions) 13:21, 10 July 2008 (UTC)

View by B. Wolterding (2)

The use of bots on the English Wikipedia is subject to policy. Admins, as role models, are expected to adhere strictly to policy.

In the past, the use of adminbots has been handled somewhat inconsistently. This RFC will hopefully lead to a proposal regarding the use of adminbots that finds community consensus. Whatever this consensus will be, admins are expected to follow it.

Once this consensus has formed, any admin found running a secret adminbot counter to community consensus may be desysopped without further warning.

Superseded by revised version below (two separate points). --B. Wolterding (talk) 12:22, 15 July 2008 (UTC)

Users who endorse this summary:

B. Wolterding (see revised version below)

1. this is really the only way this issue will ever be regulated --T-rex 18:56, 11 July 2008 (UTC)
2. Absolutely agree. This is the kind of attitude that can save Wikipedia. Are you running for ArbCom or something? --Sugaar (talk) 03:00, 14 July 2008 (UTC)

Users who oppose this summary:

1. Um, no. There is very little that leads to an admin being "desysopped without further warning". Gross incivility doesn't merit that punishment. Vandalism doesn't merit that punishment. Running an unapproved bot shouldn't either. – Quadell ^(talk) 13:42, 11 July 2008 (UTC)

   I don't think that's comparable. Yes, you may insult someone in WP:EUI, and later regret it. Or do something which you think is funny but which others consider vandalism. But bots don't get coded by chance, while you're having a bad day. Running an unapproved bot means deliberately dismissing policy. I consider that a serious breach of trust, and all the more because it's hard to detect. --B. Wolterding (talk) 18:40, 13 July 2008 (UTC)

2. Desysopping? Heck no. --uǝʌǝsʎʇɹoɟʇs(st47) 03:07, 12 July 2008 (UTC)
3. Especially given the lack of consensus regarding the precise distinction between script and bot, it seems unwise to trap ourselves into a specific disciplinary pattern before we have any idea if, when, or how this may come up. – Luna Santin (talk) 05:30, 12 July 2008 (UTC)
4. I don't think we've ever desysopped someone for doing something that was against policy but not actually disruptive (and mostly helpful), I don't see why we should start now. In addition, I think you'd be hard pressed to find a steward willing to enforce this; emergency desysopping is generally limited to obvious compromised accounts/rouge admin situations, and arbcom emergency requests. Mr.Z-man 15:42, 12 July 2008 (UTC)
   1. I hope you meant rogue admins, not rouge?
5. Not the way it's proposed, no. However, if we do get some sort of consensus here as to something other than sticking with the status quo, we should be willing to desysop admins who repeatedly and blatantly go against this consensus and the resulting policy. Even if they think they're doing something useful. —Giggy 16:25, 12 July 2008 (UTC)
6. Agree with Giggy. Davewild (talk) 16:49, 12 July 2008 (UTC)
7. Policy is descriptive, not prescriptive. And with the ability of nearly anyone to edit policy, strict adherence is plainly silly at times. --MZMcBride (talk) 16:03, 13 July 2008 (UTC)

   Just to remind you, lesser mortals found running an unapproved bot will be blocked on sight (and rightly so). I don't think anyone will accept WP:IAR as an excuse in that case. So, having admins ignoring the bot policy, without consequences, seems quite a bit like "Quod licet Iovi, non licet bovi". And that's not the way adminship is supposed to be, for all I know. --B. Wolterding (talk) 18:40, 13 July 2008 (UTC)

   I find it rather cute that you're lecturing admins (here and elsewhere) on what they will and won't do, seeing that you aren't one. --MZMcBride (talk) 22:59, 16 July 2008 (UTC)

   In practice this isn't quite true. While running an unauthorized bot may create a presumption in favor of blocking, most admins will usually let it pass or at least ask for a clarification first if the bot doesn't seem to be doing anything harmful or controversial. Summarily blocking a user who is doing something useful just because they're using an unapproved bot to do it would cause needless disruption by preventing the blocked user from improving the encyclopedia. Even when a block is applied, it will normally be lifted as soon as the user agrees to seek approval for the bot before continuing to run it, assuming there has been no actual tendentious or disruptive behavior involved. —Ilmari Karonen (talk) 20:03, 18 July 2008 (UTC)

8. Per giggy, Chet B. Long^Talk/_ARK 20:22, 13 July 2008 (UTC)
9. Poer Giggy. I don't think it's necessary to bypass a warning, but if someone repeatedly ignores the policy after warnings, then it would be grounds for de-sysopping. JeremyMcCracken (talk) (contribs) 19:25, 14 July 2008 (UTC)
10. Lol @ "role models" but WTF @ desysopping "without further warning". You like playing for power, no? Миша13 21:52, 17 July 2008 (UTC)

    Misza13 please be civil, and assume good faith in your comments on this RFC. Don't accuse or laugh at another persons opinion, unless you want the same rule applied to yourself. --Chet B. Long^Talk/_ARK 18:36, 18 July 2008 (UTC)

    There's nothing to assume. I've been around for too long not to notice certain patterns. Миша13 19:10, 18 July 2008 (UTC)

11. Per Giggy --Chris 05:31, 19 July 2008 (UTC)

Bot approval

The use of bots on the English Wikipedia is subject to policy. All users, including admins, are expected to follow this policy.

Regardless what purpose a bot fulfills, WP:IAR is not a valid excuse for bypassing the bot approval process. Whether the bot's actions improve the encyclopedia is to be evaluated in the approval process, not decided by the bot operator alone.

If ever an emergency situation arises that makes it impossible to complete the approval process in due time, an approval request should be filed ex post, for the bot's action to be reviewed and any necessary consequences for the future to be evaluated.

Users who endorse this summary:

1. B. Wolterding (talk) 12:22, 15 July 2008 (UTC)
2. Chet B. Long^Talk/_ARK 12:30, 15 July 2008 (UTC)

Users who oppose this summary:

1. Oppose anything that tries to put rules on IAR. Mr.Z-man 21:20, 16 July 2008 (UTC)

   Can you at least give an example where not asking for approval improves the encyclopedia? --B. Wolterding (talk) 21:56, 16 July 2008 (UTC)

   Given the current process for approval is RFA, which works poorly normally, but atrociously for adminbots, approval is likely to fail for stupid reasons (skynet and policy wonk opposes). A) The pointless RFA drama certainly doesn't improve the encyclopedia. If it isn't approved, the admin is faced with either B) not doing the task, or C) doing the task despite the "consensus" on the RFA against it. Mr.Z-man 00:15, 17 July 2008 (UTC)

2. IAR is always a valid reason for bypassing process. Not indiscriminately, mind you, but most of the current admin bots, including all of the long-running ones, are valid applications of IAR: they bypass a broken admin bot approvals process in order to do lots of good with very little to no harm. The point of this RFC is to alter the approvals process in such a way that they become valid. Frankly, it makes sense that the really long-running ones (Cydebot has been running for over a year, for instance) just be grandfathered in. Cydebot has faced more scrutiny and testing over the year+ it's been running than will ever be seen in a week-long approval process. --Cyde Weys 21:13, 17 July 2008 (UTC)
3. More bollocks - if you don't understand IAR, don't mention it. Миша13 21:52, 17 July 2008 (UTC)
4. The "A" in IAR is there deliberately. —Ilmari Karonen (talk) 20:09, 18 July 2008 (UTC)
5. Per Ilmari Karonen --Chris 05:26, 19 July 2008 (UTC)

Administrator behaviour

Administrators, as role models, are expected to know Wikipedia policy and adhere to it. The bot policy is no exception in that respect.

In the past, the use of adminbots has been handled somewhat inconsistently. This RFC will hopefully lead to a proposal regarding the use of adminbots that finds community consensus. Whatever this consensus will be, admins are expected to follow it.

Once this consensus has formed, running an unapproved adminbot will be considered disruptive (regardless of the bot's purpose), and may ultimately lead to desysopping.

Users who endorse this summary:

1. B. Wolterding (talk) 12:22, 15 July 2008 (UTC)
2. Chet B. Long^Talk/_ARK 12:30, 15 July 2008 (UTC)
3. If a bot's useful, there shouldn't be a problem in it being approved. The disruption isn't from running a helpful bot; it's from running bots without approval and after (I'd assume) some warnings. If it's not public, how can we be sure it's indeed helpful? JeremyMcCracken (talk) (contribs) 05:23, 17 July 2008 (UTC)

   In theory, there shouldn't be any problem getting it approved. In practice, people are scared of adminbots and tend to behave irrationally when asked to approve them. --Carnildo (talk) 19:38, 17 July 2008 (UTC)

Users who oppose this summary:

1. The day we start declaring helpful things disruptive is the day I quit. TBH, this seems like a bit of an underhanded way to sneak in policy. Basically: "We're probably going to have a proposal on this soon, and once that becomes policy, so does this." That may work in politics, but it shouldn't fly here. If its not part of the actual proposal, it shouldn't be attached to it. Mr.Z-man 00:23, 17 July 2008 (UTC)
2. Like in the first case, lol @ "role models" and WTF @ "regardless of the bot's purpose". Where are you all getting these brilliant ideas? Ah, forgot. Power-play. Миша13 21:52, 17 July 2008 (UTC)

   Misza13 please be civil in your comments on this RFC. Saying things like "lol" are not constructive or polite by any means. --Chet B. Long^Talk/_ARK 18:28, 18 July 2008 (UTC)

   Kthx. Миша13 19:10, 18 July 2008 (UTC)

   As for the role models, I realize that there might be some exceptions in reality, but the term is taken from WP:ADMIN#Administrator conduct. --B. Wolterding (talk) 18:28, 19 July 2008 (UTC)

3. Agree with everything except the last sentence. Depending on how one reads that sentence, it is either tautological (violating policy always creates a presumption of disruption) or violates the core policy WP:IAR (by punishing users for improving the encyclopedia). —Ilmari Karonen (talk) 20:19, 18 July 2008 (UTC)

View by TwoMightyGods - public disclosure of code should be encouraged but not compulsory; exceptions should be justified

First off: since the code for a bot is not a contribution to Wikipedia per se, there should obviously be no compulsion to release the code under an open source licence. This point should probably be made clear somewhere since it seems to cause a degree of confusion among those seeking "openness and transparency".

Disclosure of code for public examination is a distinct issue. It should be formally encouraged that, in case where members of the community ask for the code to be made available, in most circumstances it should be. However it should also not be compulsory, particularly in cases where that would potentially compromise the ability of the bot to perform its purpose - something that is likely to be disproportionately relevant for adminbots. In these cases, which will probably be exceptional, there is an onus on the bot creator to justify why that applies in this particular case. That should not translate in practice into a need to write a long abstract essay on why it's safe to let an admin run a bot whose script is not open to public scrutiny - we need to accept that there is sometimes a valid need to keep parts of the code under wraps.

I have no strong view on private disclosure of code upon request, between a bot-scripter and an individual requester, but I don't think it should be formally governed (i.e. no rules about "it is compulsory to reveal a bot script to a trusted member of the community in good standing"). That should be seen as a private matter between the scripter and requester. However, the requester may well find it a valid reason to disapprove a bot-approval if, perhaps due to the the nature of the bot or the standing or experience of the scripter, the requester feels unable to approve the bot without seeing the code, and the scripter declines to provide it. In other words: the argument "X's failure to approve my bot should be disregarded, since X only failed to approve because I refuse to show him my script" is not a convincing argument if X had a concern that resulted in a need to see the script. The argument "X's failure to approve my bot should be disregarded, since X only failed to approve because I have not released my script under an open source licence/made the script publicly available" is significantly stronger and the two cases should be distinguished. TwoMightyGods^Persuasion_Necessity 13:56, 13 July 2008 (UTC)

Users who endorse this summary:

1. Sounds reasonable. (Ps. You might get more endorsements with a more condensed summary; your section heading pretty much says all that needs to be said.) —Ilmari Karonen (talk) 23:32, 20 July 2008 (UTC)
2. Agree completely with Ilmari. --MZMcBride (talk) 23:36, 20 July 2008 (UTC)
3. Sounds good to me. SQL^{Query me!} 03:44, 29 July 2008 (UTC)

View by Carcharoth - voluntary code of conduct

Dependent on the outcome of other parts of this request for comments, the current adminbot community should, without delay (within a month of the closing of this RfC), draw up and publish on Wikipedia a voluntary code of conduct for the running of bots and scripts on administrator accounts. The code of conduct should, where possible, agree with current policy and practice, and should aim to address the concerns raised in this request for comments. Those who sign up to this code of conduct should: (a) ensure that those signed up to it adhere to the code of conduct; and (b) work together to ensure the spread of best practice and to ensure the smooth operation of adminbots. New adminbot operators are encouraged to sign up to this code of conduct. Those who are not signed up to the code of conduct, or who sign up to it and then breach it, should expect to take full responsibility for operating their bots outside the limits of the code of conduct.

Users who endorse this summary:

1. Carcharoth (talk) 21:38, 13 July 2008 (UTC)
2. This sounds like a very good idea to me. SQL^{Query me!} 03:43, 29 July 2008 (UTC)

Comments on this summary:

• The biggest issue with a user code of conduct, I think, is an inherent flaw of a wiki. Whatever is agreed upon today will be radically different in a month or in six months. Some will argue that the spirit of the code of conduct will suffice, even if the actual wording changes over time. But, I find that to be a weak argument. --MZMcBride (talk) 21:53, 13 July 2008 (UTC)
  • The reason I brought up this option was because some people, on the talk page, were saying that a policy or guideline would be ignored if not to their taste. Rather than have a rogue community doing what they like, I was hoping that they would come together, and work together to be "nice", unified by a code of conduct, and with rogue members who cant' or won't collaborate, being more constrained in what they feel they can do. Consider it a compromise between no policy and a policy, if you like. Carcharoth (talk) 22:07, 13 July 2008 (UTC)
    • If you believe such a voluntary code of conduct would help, it might be easiest to just draft one and submit it for comments. If it's sensible, people will sign up — if not, they won't, and after a while someone will come around and tag it as rejected. —Ilmari Karonen (talk) 23:26, 20 July 2008 (UTC)

View by sanbeg - escalation of privilege

By design, adminbots perform privileged operation without human judgment; presumably on behalf of, or based on input by, users that aren't given that level of privilege. This makes them more prone to an escalation vulnerability, where an unprivileged user can perform restricted operations using the bot as a proxy.

Guarding the source code of the bot will affect this; without access to the code, it would take much longer to find these vulnerabilities, and thus longer to fix them. There has been a lot of discussion about open vs. proprietary adminbots; however, much of this seems to presuppose that the security issues are limited to sensitive bots, and that proprietary bots are at least as secure as open bots.

Those assumptions are less obvious with respect to this vector. Routine backlog clearing bots could be compromised, i.e. to be tricked into deleting pages inappropriately. If the source is carefully guarded, these vulnerabilities are less likely to be discussed. Therefore, this mode of attack should be considered, both in deciding whether a bot should be approved, as well as in how the source code should be evaluated.

Users who endorse this summary:

1. In the real world, security by obscurity is commonly practiced, although not with much success. -Steve Sanbeg (talk) 21:58, 14 July 2008 (UTC)

Users who oppose this summary:

1. I really don't see this as a problem. Mr.Z-man 22:46, 14 July 2008 (UTC)

   Since we haven't implemented anything yet, it would be too early to call it a problem; at this point it's just a view. Either keeping the code secret makes it more secure, or less so (this view). It would only be a problem if we justify keeping code secret for security reason, but can't provide any justification that secrecy doesn't make the bots less secure. Basically, running complex code with special privileges on a popular site without a thorough review is quite a step; in my view we should justify whether that is necessary. -Steve Sanbeg (talk) 20:45, 15 July 2008 (UTC)

   Multiple adminbots are already running. I believe the code to at least one is available somewhere. Mr.Z-man 22:22, 15 July 2008 (UTC)

   sure, but there are currently no officially sanctioned, closed-source admin bots on wikipedia. -Steve Sanbeg (talk) 15:40, 16 July 2008 (UTC)

   What does that have to do with this at all? That some adminbots exist and what they do is fairly widely known, such as Misza's anti-grawp bot, why will official sanction make exploitation more likely or more possible? Mr.Z-man 21:24, 16 July 2008 (UTC)

   Presumably, there would be more of them, and a nice list of them; so anyone could go to one place to find descriptions of and code that runs with privileges they can't easily get, but hasn't been looked at by hordes of people already. -Steve Sanbeg (talk) 20:19, 21 July 2008 (UTC)

2. I don't see privilege escalation being a big problem. The majority of admin bots only accept input from the bot owner, who is an guaranteed to be an administrator. As for the rest of them, let me illustrate with an anecdote. My CFD admin bot runs off of entries placed on the fully-protected page WP:CFDW, so it's only accepting input from admins anyway. --Cyde Weys 21:08, 17 July 2008 (UTC)
3. Hmm, let's make it harder to review bots for common flaws so that security-by-obscurity can prevent uncommon flaws that we've never seen happen! No, actually, let's not. rspeer / ɹəədsɹ 19:59, 19 July 2008 (UTC)
4. I'm not sure if you're arguing for or against open-sourcing adminbots. Either way, however, I don't see this as a significant issue compared to the existing and basically unavoidable security risks in MediaWiki itself and in the browsers that (human) admins use. I've found and fixed one JavaScript injection bug in MediaWiki myself. There have been others. Even without taking advantage of such bugs (or of my own admin or any other privileged access), I know at least one way by which I could probably trick an admin into running some JavaScript that, say, vandalizes the Main Page. (Details omitted per WP:BEANS.) Fortunately, these days almost any admin action is reversible, so any such attack can be undone as soon as it's detected. Notably, however, neither of the attacks I've mentioned above would work on a bot, since bots don't generally execute JavaScript. —Ilmari Karonen (talk) 23:14, 20 July 2008 (UTC)

   For open source would be closer to what I'm arguing here. But really my point is that if security by obscurity makes the bots less secure (I see Rspeer's oppose actually sums that up nicely) then we can't just wave our hands and use vague security reasons to justify hiding the bot code. Sorry I wasn't more clear on that. Since Mediawiki is open source, it's likely that somebody would find this type of error before it can be exploited, so it's not much of an issue there; but a lot of arguments have been made as to why we want to keep these bots closed source. When fewer people look at the code, the issues are different. -Steve Sanbeg (talk) 20:02, 21 July 2008 (UTC)

Statement by harej

The law of the land dictated
In order to be automated
The bot's safety must be proved
So that you'll be approved
And not by the ArbCom get castrated!

Yet admin bots are on the rise
Which has elicited the cries
Of admin abuse
And admins refuse
And to cover their crimes, there's lies!

Yet as some have perceived
Of admin bots, there's a need
We must update the rules
So that we must not be fools
Of the old admin-bot creed!

--harej 01:31, 17 September 2008 (UTC)

Statement by Nagle (talk · contribs)

We do need to get the adminbot situation under control. We don't have a serious problem, but more accountability is needed.

Back in 2006, ArbCom addressed this issue, and desysopped an admin for running an unauthorized adminbot. "Marudubshinki has run an unauthorised adminbot. Marudubshinki has repeatedly violated WP:BOT policy by running an unauthorised bot over a period of months, despite numerous requests not to do so. In further violation of WP:BOT, he has run the bot on his main (sysop) account, and equipped the bot to make deletions using his sysop flag. - Pass 6-0 at 23:11, 19 October 2006 (UTC)". ... "Marudubshinki is desysopped. Pass 6-0 at 23:11, 19 October 2006 (UTC)"[1]. So there is precedent for taking a hard line on adminbots. Admins are not exempt from 'bot policy.

Some reasonable restrictions should bring the adminbot situation within policy and make adminbots more transparent:

1. Adminbots, like all other 'bots, should have their own 'bot accounts, with a user page explaining what the bot is and does, and how it can be stopped in an emergency.
2. Administrators currently running adminbots should be allowed to request a 'bot account for their 'bot without making a new 'bot approval request or a request for adminship for the 'bot. Such requests should be listed in a single place. All existing adminbots which run unattended must be converted to 'bot accounts.This "grandfathers in" existing bots.
3. New adminbots should require either bot approval or a request for adminship for the 'bot. --John Nagle (talk) 17:15, 23 September 2008 (UTC)
4. A category should be established for all adminbots, so they can all be easily located.
5. It is recommended that admin bots of general use (and bots generally) have their code licensed under the GFDL or GPL, and archived within the Wikimedia system, so that the 'bot can continue to be used even after the initiating admin no longer is available.

Comments? --John Nagle (talk) 17:15, 23 September 2008 (UTC)

Views and statements about this RFC

Please place any statements about this RFC itself specifically in this section.

View by Миша13

The premise on which this RfC is based states that "there seems to not be enough knowledge of adminbots among the common community" - this can be addressed through proper communication. Therefore, the only thing left that seems drive this RfC is the will to create a new process that will hamper what's currently working quite successfully (any problems encountered thus far were caused by insufficient communication or lack of consultation with fellow admins). Open exchange of ideas is the way to go, not bureaucracy.

Users who endorse this summary:

1. --MZMcBride (talk) 22:17, 7 July 2008 (UTC)
2. Communication is good. MZMcBride started a discussion the other day, which was good. Getting a list of current adminbots would also be good. Getting an essay written about this, and to address the Skynet concerns, would also be good. All examples of communication, which, no offense intended, bot programmers are not always good at. Carcharoth (talk) 23:13, 7 July 2008 (UTC)
3. No offense taken, we get bored of communication. Tomorrow morning I'll look at replies on this RfC and think "I have better things to do than try to educate these people." Communication is good, as long as the communication is with those who are competent and the end result is something that can potentially be reached. You're not likely to convince someone who thinks that the moon landings were faked that they're wrong, not without a good deal of frustration on your part. If we can present our ideas to a group who can be expected to find the right answers and not waste too much time, fine. But if we're simply going to be interrogated to no end, then I can find a better way to get it done. --uǝʌǝsʎʇɹoɟʇs(st47) 00:56, 8 July 2008 (UTC)

   No offense intended but I think this reply suggests you may have a major issue with your approach to communicating with your peers. The theme may be correct but the delivery leaves a great deal to be desired. You come off as rather condescending. Is that the impression you intended to leave? You turned ME off and I'm generally in agreement with the thematic issues here. I wonder what impact you had on someone who was undecided but possibly convincable? ++Lar: t/c 12:53, 8 July 2008 (UTC)

   We seem to have different ideas of "proper communication" - I don't think either of our endorsements tally with Misza's view here. Perhaps we should both strike our endorsements. I'm particularly unhappy with your "we get bored of communication"; "I have better things to do than try to educate these people"; "as long as the communication is with those who are competent"; "if we're simply going to be interrogated to no end, then I can find a better way to get it done" - there is an air of arrogance and "I know best" coming across here. Carcharoth (talk) 08:43, 8 July 2008 (UTC)

   I do support that the problem is lack of communication and understanding, and I am asserting that perhaps it isn't all the fault of the bot operators, as someone always argues. Arguing over whatever it is for eons is bad. Misza supports a limiting of the bureaucracy and the unnecessary process. --uǝʌǝsʎʇɹoɟʇs(st47) 11:43, 8 July 2008 (UTC)

4. krimpet✽ 01:15, 8 July 2008 (UTC)
5. Communication is always good. Muru and Beta were not desysopped because of running poorly built adminbots, but because of their refusal or inability to answer inquiries in a satisfactory manner. east718 (talk) 01:19, 8 July 2008 (UTC)
6. LaraLove|Talk 05:22, 8 July 2008 (UTC)
7. WP certainly needs more communication and much less bureaucracy. Bots screw up from time to time (I know mine does), but they also do a lot of essential work, and it's not bureaucratic process that will iron out the problems, but a willingness on all sides to talk, listen and adapt.--Kotniski (talk) 13:49, 8 July 2008 (UTC)
8. — Carl (CBM · talk) 13:30, 9 July 2008 (UTC)
9. Let's see some ideas. shoy (reactions) 13:23, 10 July 2008 (UTC)

Users who partially endorse this summary:

1. I completely agree that what the adminbot issue needs is openness and communication, not more policy. However, this RFC seems to have done more to encourage said communication than just about anything else I've seen in my time on Wikipedia. Seen in that light, I find it a good thing overall. —Ilmari Karonen (talk) 22:57, 20 July 2008 (UTC)

Users who oppose this summary:

1. No, there are more things left that drive this RfC. In particular it's this: It is an evident necessity, and a well-established practice on the English Wikipedia (but not only there), that bots need a formal approval by a competent group of editors. It seems however that in one of the most critical areas - admin tasks - this practice and policy is currently ignored. That alone is grounds enough for the RfC. It does not "hamper what's currently working quite successfully", but will hopefully fix what is currently broken, entirely. --B. Wolterding (talk) 16:33, 9 July 2008 (UTC)
2. Chet B. Long^Talk/_ARK 02:27, 10 July 2008 (UTC) Also I would ask you Misza to disclose the fact that you run an adminbot above your suggestion, just as every other adminbot runner has done. Chet B. Long^Talk/_ARK 18:31, 18 July 2008 (UTC)

   Meh idc, u just did. Besides, anyone and their grandma have known that already for, like two centuries... Миша13 19:08, 18 July 2008 (UTC)

3. An RfC is one of the best ways to ensure communication. A policy is one of the best ways to have communication once and not need to again. Quiet, bilateral, ad hoc communication, especially on a matter of permissions like this, obscures much and accomplishes little. Bureaucracy is sometimes the best way to make sure everyone is heard. -- The_socialist ^talk? 09:39, 10 July 2008 (UTC)

View by sanbeg - a shortage of our own creation?

The current notion that Wikipedia would break down if everyone followed all of the rules on this is a bad thing that should be addressed. however, this seems like a back door way of creating a separate class of admins, which would otherwise be dismissed out of hand as a perennial proposal.

Because we can't create another class of admins, we create an artificial shortage of people, which we resolve by creating another class of admins; trusting scripts to exercise better judgment than people.

Adminbots should be more accountable, to have their status more easily removed if they don't function or communicate as expected, or even be subject to annual evaluation. People could also be chosen to fill a similar role; although that may not remove the need for admin bots, it should lessen it, and make our policies seem more consistent.

Users who endorse this summary:

1. -Steve Sanbeg (talk) 02:32, 10 July 2008 (UTC)
2. --Barberio (talk) 14:33, 10 July 2008 (UTC)
3. Chet B. Long^Talk/_ARK 23:28, 10 July 2008 (UTC)
4. JeremyMcCracken (talk) (contribs) 09:26, 11 July 2008 (UTC)

Users who partially endorse this summary:

1. Agree with the bit starting at "Adminbots should be more accountable" and on, not the rambling about 'artificial shortages' above it (who's doing this again, why?). SQL^{Query me!} 17:11, 10 July 2008 (UTC)

Users who oppose this summary:

1. We have IAR for a reason. Some people have argued that IAR can only apply to certain rules in certain circumstances, but then that kind of defeats the purpose. I fail to see how there is a special class of admins, I don't think we treat admins who run adminbots any better than the rest of admins (the fact that admins are treated differently at all is a bit of a problem, but not one for this RFC). As for an "artificial shortage" - huh? The reason we have a shortage of people who want to volunteer their time to do thankless, menial, repetitive tasks for hours on end or patrol recentchanges like a hawk 24/7 for specific things is because not many people want to do these things, there's so many more admin tasks that require real thought, its not some wide conspiracy by adminbot operators to keep their tasks done by bots (I don't think many of the operators even participate in RFAs) Accountability is good, but mistakes are quickly caught and easily reverted. Finally, we don't have annual review for anything on Wikipedia, why adminbots? Mr.Z-man 00:25, 11 July 2008 (UTC)

   IAR should be used in circumstances that are unforeseen by the rules; not as an excuse to keep rules that are broken, just so they can be ignored by those in the know. It seems that admins are only desysopped in serious cases, and bots have been known to keep their status even when run by minimally responsive operators. I'd hope that adminbots are help to a higher standard. -Steve Sanbeg (talk) 14:46, 11 July 2008 (UTC)

   No, IAR can be used wherever the rules don't work, its not just a temporary measure that can be used until the rules are amended, its designed so that the rules don't have to be amended to cover every situation that arises. You do what's best for the project, I fail to see why people want to complicate this so much! And while I disagree with this, your last couple sentences seem to be an argument against holding adminbots to high standards: giving admins lots of leeway + not holding botops to high standards != high standards for adminbots in any logic I would ever use. Adminbots should he held to high standards, but I don't think perpetuating double, triple, or quadruple standards should happen along with it. Mr.Z-man 15:51, 12 July 2008 (UTC)

   I don't think the point of IAR is to just ignore all of the rules all the time, but rather to follow the spirit of the rules, while preventing people from gaming them. Publishing bogus rules because the right people will ignore them anyway will cause confusion, where it becomes less obvious which rules apply to which people. But my point was that simply munging the current admin and bot standards together would not be appropriate for bots, but that we don't want conflicting policies; your last sentence seems to rephrase that, so I'm not sure what you disagree with there. -Steve Sanbeg (talk) 17:58, 14 July 2008 (UTC)

   I'm not sure how you got "ignore all the rules all the time" or "publishing bogus rules" out of my comment... Basically, you said that we have low standards for botops and a high tolerance for problematic admins, but we should have exceptionally high standards for adminbots, while I agree we should (because we should have higher standards for admins and botops), logically it doesn't make much sense. Mr.Z-man 01:47, 15 July 2008 (UTC)

2. So, essentially, us making adminbots is causing so many potential part-admins to be unemployed? And eliminating the need for menial labor and increasing the amount of work done is somehow bad? --uǝʌǝsʎʇɹoɟʇs(st47) 03:09, 12 July 2008 (UTC)

   Not that I'm aware of; you may be looking at the converse of what I said. -Steve Sanbeg (talk) 17:58, 14 July 2008 (UTC)

3. --MZMcBride (talk) 16:00, 13 July 2008 (UTC)

Users who have no idea what this summary is trying to say:

1. I'm not sure what your point is. It might help if you were to clarify exactly what the phrase "another/separate class of admins" refers to in each of the three instances where it occurs in your summary. —Ilmari Karonen (talk) 22:47, 20 July 2008 (UTC)

   There are a few examples of things that have been proposed in wikipedia:perennial proposals#Administrative. There seems to be limited accountability for admins, for various reasons, including the nature of the work that some admins are involved in. This results in various metrics used to appoint admins steadily increasing. That, in turn, can lead to skewed demographics among the admins, which could lead to systematic bias in the articles.

   Bot activities should be more clear cut, so they shouldn't need that freedom from accountability. For example, imagine an adminbot that basically works, but may be a bit rough around the edges, or with an operator who doesn't have the time or inclination to respond effectively. What if this really does improve the data, but at the cost of alienating human editors? If we apply the current admin standard, then we'd probably continue with that bot; the data would improve, and we'd just need to trade off a few editors who are probably newbies and non-techies anyway.

   If we don't apply that standard, then in effect we would create another standard. If we then could apply the new standard to some human editors, we could have more diversity in the admin ranks. If not, we could alienate editors who can't understand why we trust a script to exercise more judgment than a human editor. -Steve Sanbeg (talk) 20:56, 21 July 2008 (UTC)

View by a user (2)

This is a summary written by any active user. In the interests of conciseness, and to get a clear and hopefully uncluttered feel of the community, please leave shorter individual statements in the appropriate topic section, rather than one long condensed statement. This will allow users to endorse specific aspects more easily.

{Add summary here, but you must use the endorsement section below to sign. Users who edit or endorse this summary should not edit the other summaries.}

Users who endorse this summary:

Motions to close or extend this RFC

The motion to close may not be initiated until a minimum of 1 month (30 days) after the RFC is officially "opened". The motion to extend the duration of the RFC beyond 1 month can be done, but the nominator should specific a fixed duration not longer than 1 month, and should not be done until at least 2 weeks have passed.

Motion to extend this RFC

For example, "Let's extend the RFC for x weeks/months."

Users who endorse this extension:

Motion to close this RFC

Self-explanatory, RFC will be open at least 1 month from when it goes live.

Users who endorse closing this RFC:

1. NuclearWarfare ^{contact me}_{My work} 23:13, 23 September 2008 (UTC)
2. Oppose close. No clear conclusion yet. Three different editors have commented in the last week, contrary to edit comment "motion to close; no significant activity for 6 weeks."[2] Discussions at WT:BOT and WP:AN/I are both referring editors here. --John Nagle (talk) 14:55, 24 September 2008 (UTC)

Discussion

All signed comments and talk not related to an endorsement should be directed to this page's discussion page. Discussion should not be added below. Discussion should be posted on the talk page. Threaded replies to another user's vote, endorsement, evidence, response, or comment should be posted to the talk page.

The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this page.