Wikipedia talk:BOT
This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Wikipedia_talk:BOT".

This is not the place to request a bot, request approval to run a bot, or to complain about an individual bot To request that a bot be created, see Wikipedia:Bot requests. To request approval to run a bot, see Wikipedia:Bots/Requests for approval. Bot operators should be contacted at their user discussion page. If a bot appears to be malfunctioning and the operator does not respond, contact an administrator.

Archives
Archive 1	Archive 2
Archive 3	Archive 4
Archive 5	Archive 6
Archive 7	Archive 8
Archive 9	Archive 10
Archive 11	Archive 12
Archive 13	Archive 14
Archive 15	Archive 16
Archive 17	Archive 18
Archive 19	Archive 20
Control proposals
Archive policy
Archive interwiki (also some approvals for interwiki bots)

Bot Talk pages

User:Anomie claims that Wikipedia:BOT#Bot accounts entitles him to revert without limit or needing to give justifications any comments he doesn't like about AnomieBOT - see discussion at User_talk:Philcha#3RR Warning and history of Talk:AnomieBOT. Unfortunately a literal reading of Wikipedia:BOT#Bot accounts appears to give his claim some support. However bot Talk pages are not purely personal Talk pages as their actions affect all editors. They are also the only feedback mechanism provided by bot entries in article histories. I do not see that my comments could be interpreted as vandalism or personal attacks. OTOH I do not think User:Anomie's responses could be described as "prompt and civil help from the bot's operator if queries arise" per Wikipedia:Bot policy#Good communication. I think Wikipedia:BOT#Bot accounts should be revised to make it clear that uncontrolled reversion of feedback from editors is not allowed. -- Philcha (talk) 00:02, 13 September 2008 (UTC)

Anomie was perfectly justified in removing that. Complaining because a bot causes edit conflicts is simply ridiculous, complaining with an uncivil and belligerent tone about a bot causing edit conflicts is ludicrous. Additionally, making such a change to the bot policy would be arbitrary; it would only encourage botops to redirect their bot's talkpage to their own. ~ Ameliorate! _{U T C} @ 04:31, 13 September 2008 (UTC)

Agreed. Edit-warring to replace threats to shut a project down if demands aren't met would be frowned upon even in regular talkspace, but this is completely clear-cut. Bots aren't even required to have their own talk pages: they are the responsibility of their masters, and anything addressed to the bot is obviously for the benefit of said master. Chris Cunningham (not at work) - talk 10:34, 13 September 2008 (UTC)

I did not start an edit war.

The bot has caused twice caused a problem for me.

It could have been fixed in the time User:Anomie has spent reverting my comments and posting an incredibly brazen 3RR warning on my Talk page.

Wikipedia:Bot#Good_communication requires "prompt and civil help from the bot's operator if queries arise".

Are you claiming that editors are not permitted to express dissatifaction with a bot operator's response? -- Philcha (talk) 10:57, 13 September 2008 (UTC)

I am not "claiming" anything. I am stating that bot accounts are, for all intents and purposes, alternate accounts for the owning user - and that said user has the right to remove commentary he disagrees with from the bot's talk page as with his own. Your comment was inflammatory and threatening, and Anomie was perfectly right to give you 3RR notice after you ignored a polite, explicit request not to post in that way by reverting your comment back in three times. The suggestion that the bot's timeout be changed to 30 minutes was advanced politely by another user and will probably end up being implemented, and your comment about the bot respecting in-use tags was answered promptly and correctly, so your actual issues with the bot have been addressed. You don't have any more right to attack the bot than you do the owner. Chris Cunningham (not at work) - talk 11:10, 13 September 2008 (UTC)

I considered User:Anomie's "go read the code as I suggested instead of accusing me of lying" uncivil: the code is not my responsibility and I am not familiar with Perl; I had not accused User:Anomie of lying, I pointed out that, whatever the code says, the bot had caused me 2 edit conflicts in as many days.

{{inuse}} is the only template mentioned in "edit conflict" messages and at Help:Edit conflict, i.e the only relevant template visible to the the great majority of editors who are not bot operators.

Your repetion of the current wording of Wikipedia:BOT#Bot accounts does not deal with the problem of censoring expressions of dissatisfaction with a bot operator's response. -- Philcha (talk) 11:29, 13 September 2008 (UTC)

You can find whatever you like uncivil, but that in no way permits you to edit war with a user on his talk page, and the allegation of censorship doesn't pass the laugh lest. You've taken this whole thing too personally since your first response to Anomie, and that's the thing that really needs to be addressed here, not talk page policy. Chris Cunningham (not at work) - talk 12:32, 13 September 2008 (UTC)

Ill make my point short and sweet, Philcha go get a life and stop harassing bot ops. so what you get edit conflicts, we all do get over it. If you cannot you know where the door is. two edit conflicts per two days is not an issue, had it been edit conflicting every five minutes I might understand. but once a day? also if you cannot maintain a civil respectful discussion with a person , expect that you will be ignored as users who cannot maintain general etiquette will be reverted/ignored. β^_command 13:57, 13 September 2008 (UTC)

That might have made some sense if it didn't start with "go get a life". Those four words kind of killed the credibility of you talking about etiquette and civil discussion. You came close, though. rspeer / ɹəədsɹ 05:15, 23 September 2008 (UTC)

adminbots proposal

This has been a proposal for a long time. I'm going to remove the proposal tag. — Carl (CBM · talk) 01:18, 17 September 2008 (UTC)

I look forward to the adminbot BRFAs; for one thing, we get to find out what these adminbots actually do. rspeer / ɹəədsɹ 07:22, 17 September 2008 (UTC)

The policy is meaningless unless the 'crats agree with it. BJ^Talk 07:29, 17 September 2008 (UTC)

Then why doesn't someone spam WP:BN to make sure? On the other hand, the 'crats are bound to the will of the community, which seems to be very clearly in favour of this new policy. (also)Happy‑melon 08:11, 17 September 2008 (UTC)

Also, if we're going to go with the "about two weeks" clause, someone really ought to notify all the current adminbot operators about it. An announcement on WP:AN and WP:VPP would also be nice. —Ilmari Karonen (talk) 09:46, 17 September 2008 (UTC)

That piece has subsequently been removed. --MZMcBride (talk) 20:17, 17 September 2008 (UTC)

By someone who runs unauthorized adminbots. What a coincidence. rspeer / ɹəədsɹ 07:10, 18 September 2008 (UTC)

And you are obviously suggesting that adminbot operators are excluded from editing the policy. How convenient for your crusade. Cut the bollocks please, that ridiculous piece had no consensus and was (as it usually happens) slipped when people whom it concerns weren't looking (because they were building an encyclopedia, for instance, or enjoying real life). Миша13 11:13, 18 September 2008 (UTC)

"alternative method"

I'm not thrilled with the "alternative method" addition. The point of BAG is entirely to give bot operators a small hoop to jump through before they run their bot. In practice, adminbots have been running for years with public knowledge of them; adding a RFBOT page is a pretty minor step for the existing operators to take.

And, like before, adminbots are quite unlikely to be blocked for unapproved tasks if they approach the tasks professionally, take criticism well, and have an acceptably tiny number of mistakes. Since a back-room approval is effectively the same as no approval at all, which is already an option, there's no reason to try to set up some backroom system (in which the participants aren't even known).

As I see it, the goal is for the adminbots to have some sort of public approval, but one that is not unduly burdensome or vulnerable to manipulation. — Carl (CBM · talk) 23:37, 17 September 2008 (UTC)

For the record, it's not not supposed to "thrill" anyone, and neither is it a pointy mockery. It's been suggested on several occasions (including the currently-brewing RfAr request) that perhaps the policy should be updated to reflect current practice instead. Thus I have; and everyone is welcome to improve the description with accordance to their perception of the situation. Миша13 23:56, 17 September 2008 (UTC)

Current practice, as in other areas, is inconsistent: adminbots are allowed to run without formal, documented approval, and unapproved bots are allowed to be blocked. The adminbot RFC seems to show there is growing acceptance of the role of adminbots, and a corresponding willingness to resolve the inconsistency. So while I do think that you're doing a decent job of explaining how things are presently done, I also think there's enough discomfort with the present situation that the proposal should be viewed as a way forward rather than a reflection of the status quo. — Carl (CBM · talk) 00:09, 18 September 2008 (UTC)

Misza, we just had an RfC where we came to a conclusion with a broad consensus. You participated in it. Where did you pull this other method from? I don't support it. rspeer / ɹəədsɹ 06:52, 18 September 2008 (UTC)

I wrote it myself to describe the current practice (ammending the policy this way has been suggested by several parties, including on RfAr). You may disagree with it, but it's nevertheless the way things have been done for the last two years with great success. It certainly has more support than the thing that's been distilled from the RfC (which, by the way, seems to me like it's based on only one proposal and ignores most other views which gathered significant support). Миша13 10:07, 18 September 2008 (UTC)

The phrasing "suggested on RfAr" makes it sound like they actually took up the case and examined it. You're quoting their rejection reasons, quick suggestions that they made without looking at background such as the RfC. The current practice, as we know, is inconsistent and unsustainable, and the RfC contained a very reasonable proposal for moving forward that the consensus solidified behind. (Don't just count votes, read the discussion.) Finally, if secret adminbots were the "great success" you think they were, we wouldn't have needed the RfC. rspeer / ɹəədsɹ 16:18, 18 September 2008 (UTC)

RfAr is not yet Arbitration proper. Also, yes, it was great success. In my humble case that's over 100K fair use images deleted because they were in violation with copyright policy, 100s of username creation vandals contained at square one so that fellow admins could focus their grey matter on more complex issues and 100s of Grawp incarnates stopped after 1-2 moves instead of 10-20. Pardon my ego if I call that a success. And in fact, I didn't need the RfC - the policy wonks did, because how's it being done doesn't fit their perfect world of paperwork, and is apparently a cause of insomnia. Миша13 16:40, 18 September 2008 (UTC)

Successful in that you got to do whatever you wanted, then. I have a different measure of success, and it involves cost versus benefit. How many non-EDP-violations did you delete? (Remember that the old line about image tagging bots was that it didn't matter if they messed up, because a human admin would check the image before deleting.) How many non-abusive newbies did you block? rspeer / ɹəədsɹ 20:13, 18 September 2008 (UTC)

It's not something I wanted as in my private agenda. Something the community wanted and needed. At the time the image deletion bot was created we had a serious problem - the "...may be deleted after 7 days" categories had two week (and longer) backlogs. There were thousands of images, most of which were pretty clear-cut cases, so I quickly figured that a bot could easily delete the most obvious ones (easily 80-90% of all), so that humans are left with a not-so-monstrous backlog. I started with the simplest case, orphaned fair use images, then moved on to others, the cycle being: first I do some by hand, observe others, deduct patterns, then an algorithm is born, I run it and double-check a few hundred by hand. For some time I continued to do periodical sample testing. With that in mind, I can't recall there were any images that shouldn't have been deleted, or at least none that any other admin wouldn't delete (I'm talking about images that were for example orphaned due to an article being vandalised).

The username blocking bot has a similarly low error ratio, prolly the most prominent blunder being DennisGay (talk · contribs) who fell victim of an isgay$ regex (which I have imemdiately removed). In the two-year history I recall there were few (2? 3?) borderline cases that I consulted with other admins and opinions were divided (I'd have to dig deep for specifics).

There was one innocent victim of the pagemove blocker (other than people testing it), which I happened to notice immediately; I apologized and rectified immediately (blacklisting any url as an edit summary happened to be slightly too strong), thus it didn't gain any "publicity". Миша13 21:04, 18 September 2008 (UTC)

Quick thought

I'm visiting here after opinioning at RFAR, with an idea I thought might be worth running past this page as a possible idea. Might work, might not (I'm not a bot coder). Rough overview is that for all except certain classes of bot, we probably could "trust first, restrict or manage if problems". Overview:

1. High risk automation - Bots that will perform controversial or sensitive tasks using admin tools (eg tasks requiring non-trivial judgement or which may give rise to a high level of complaints), or tasks at high speed, require advance approval before being used in this manner.
2. Lower risk automation - All other bots and scripts that require little judgement or complexity, have a human reviewing each admin action, work at slow speed, and are unlikely to be controversial, may be operated as follows.
3. Any admin is by default entitled to create and operate a lower risk automation tool, provided they have not been restricted from doing so by a decision at BAG. This is a good faith presumption, not a right. They may do this at their own risk (whoever writes the tool), and on the clear understanding that if the tool misperforms significantly they are likely to be held personally responsible for the actions performed in their name, and may have their right to operate lower risk tools restricted or withdrawn. They are expected to carefully test the tool and ensure it works correctly before and during usage. They are expected to be highly responsive to feedback, and should strongly consider asking for peer review of the code.
4. A lower risk tool operator who gives rise to significant concerns that the actions done in their name by the tool are proving contentious or problematic, is expected to cease or correct immediately, and may have their right to operate that tool, or any other tools, restricted or withdrawn. Restriction might involve a requirement to gain full approval, review and approval of code, or complete prohibition.

Any mileage in that kind of format? The idea being, if it's high risk it gets full eyeballs, but if a lower risk tool misbehaves, correction's easy - hence no need to make writers and users of such tools jump through hoops so much. If there is a problem, then it gets handled.

Suggested as one possible way to get the best of both worlds :)

FT2 ^{(Talk | email)} 02:13, 18 September 2008 (UTC)

An interesting idea, I think the issue will be defining low and high risk. For instance, I have no problem with a low risk bot that deletes old PRODs and disputed images, but an inclusionist would probably consider such a bot a very bad idea. Although saying that deletions and protections are low risk, and userrights and blocking are high risk, is a possible separator. MBisanz ^talk 02:23, 18 September 2008 (UTC)

Wait. Deleting old PRODs is fairly high risk. There's always supposed to be an assurance that an admin will at least review the page before deleting it, so that someone doesn't just try to sneak through a PROD on a valid, under-watched page they don't like. That's what I don't like about deletion adminbots in particular; those who throw around deletion tags liberally (perhaps with bots) use the justification that "it's okay, I'm not doing the deleting, an admin will look at it", which isn't necessarily true. rspeer / ɹəədsɹ 16:23, 18 September 2008 (UTC)

Interesting view. I initially was about to second MBisanz' concern that it's not easy to define what's "non-trivial judgment".

But let me share an afterthought that occured to me. What's desribed above is essentially how things have been done so far, with the following differences:

1. the BAG has not been playing with putting restrictions on running adminbots specifically (not to my knowledge anyway),
2. it's been the admins themselves who made the decision whether a particular task is trivial enough so it can be transmuted into an algorithm (thus qualify as a low risk tool) and ran on its own (which may not be that bad as it sounds given that admins are supposed to have good judgment).

Seems to me that it boils down to one question: who is to assess the risks (both on technical and business level) involved in a particular adminbot? I think you know my answer to that, but that's just my thought. Миша13 10:45, 18 September 2008 (UTC)

It's more a case "if your bot does these things, or is being modified to do these things, then you need to get it checked first. If not, and you haven't been restricted on bot operation, then just go ahead but be very careful because if it does mess up and you didn't take good care in bot handling, you might be restricted on bots/automation in future, and it'll also be treated as your own personal edits and actions in any event."

For example a buggy or poorly conceived low speed bot may do 1-3 bad actions before being caught. A high speed one may do 50-500. Some kinds of action are probably less risky than others as well.

FT2 ^{(Talk | email)} 12:44, 18 September 2008 (UTC)

I don't think we can sanely distinguish "low risk" from "high risk". Better to have all bots go through the same process (which is, you know, the proposal we got from the RfC). As we've seen, low risk bots tend to pass through BAG very quickly, so it's not even a problem. rspeer / ɹəədsɹ 16:20, 18 September 2008 (UTC)

Argumentation here is moot

Everything that is being debated here and elsewhere regarding adminbots is entirely pointless. (How's that for a hook? ;-)

Now I'll try to justify that statement.

When Chet and Peter were found to be sharing their admin accounts, Kim Bruning justified their actions by looking only at the actions of the account. He said that it is always a possibility that an account will trade hands or be under the control of a different person tomorrow than it is today. He said that all that matters is whether the admin actions that happened were good ones or bad ones (under our policies).

It has never been possible to detect whether or not an admin is using an automated script. We can make guesses, we can assume; but short of CAPTCHA'ing every admin form, it's not possible to know whether I pressed the button or a script did (or a neighbor did).

At the end of the day, all that matters is whether or not the actions are good or bad. We entrust an account with the ability to do extra functions on our project. Regardless of whether it's me, someone impersonating me, my neighbor, a Python script, the only thing that matters is the goodness or badness of the actions.

Which leads us to the conclusion that the entire controversy over adminbots is pointless, so to speak. It doesn't matter. --MZMcBride (talk) 05:05, 18 September 2008 (UTC)

Of course it matters. We had an entire RfC explaining why it matters. It particularly matters because admins should not be special; when a user is caught running a secret bot on their main account, they get blocked for it. And they must, if BAG is supposed to mean anything at all.

I'm sorry you didn't like the outcome of the RfC, but you're not going to get your way just by declaring the position you disagree with "pointless". rspeer / ɹəədsɹ 06:55, 18 September 2008 (UTC)

Rspeer is correct; we block people who share accounts and we block people who use unauthorised bots; there is no reason admins should be different in this respect. I honestly don't understand why there is opposition to having to request approval for an admin bot. Tombomp (talk/contribs) 08:11, 18 September 2008 (UTC)

Often the case is, the actions of the bot are harmful. But because the bot is unauthorised, it has no rightful place here. We have no choice but to block the admin to prevent further damage being done. It's nice that adminbots sometimes work well, disasterous if they don't. What's the problem with having a BRFA? Majorly ^talk 08:22, 18 September 2008 (UTC)

(edit conflict) We (should) only be blocking bots that are harmful. It just so happens that most users who run unapproved bots also seem to have a tendency of making very bad edits with said bots.... And both of you make the assumption that it's possible to detect whether or not someone is using an adminbot which is exactly the crux of my argument — it isn't. --MZMcBride (talk) 08:24, 18 September 2008 (UTC)

Once upon a time, long long ago, bots were defined as any method of editing faster than X times per minute, on the theory that fast moving actions are inherently dangerous regardless of how they are accomplished (even if done manually). We got away from that, but if you really want to be pedantic we can always go back to pragmatic definitions like that for defining what behavior is regulated as an "adminbot" (and let's be serious, some patterns of behavior are almost always the result of heavily automated processes). The argument that one can't regulate adminbots because there is no overt behavior that could be detected is a silly one. Dragons flight (talk) 08:42, 18 September 2008 (UTC)

Because it's difficult to set a sleep timer that uses a rand() function? --MZMcBride (talk) 10:10, 18 September 2008 (UTC)

It's not difficult, but it is unethical. And it's extremely naive to think that the only difference between people and bots is that people edit at more random times. rspeer / ɹəədsɹ 16:06, 18 September 2008 (UTC)

Argumentation here is moot because there has already been an RFC about adminbots. And now we have people who don't want to disclose what they really do with their accounts trying to counteract the consensus at the RFC, in a place where very few people will look. Policies are formed with the hope that they will be followed; we AGF that a person is following the relevant policies, so declaring the adminbot policy moot because it will be difficult to tell if someone is running an adminbot is a load of WP:BOLLOCKS. ~ User:Ameliorate! ^{(with the !) (talk)} 09:27, 18 September 2008 (UTC)

Wrong. If you took a minute to read the talk page of the RfC and knew some background you'd know that most present bot operators have disclosed details of their bots in the past months. Mine were open source nearly from the very beginning (which dates almost two years ago). The point is, if it works (and it does), going through additional paperwork (and that's all I see proposed) won't improve it any further. Миша13 10:35, 18 September 2008 (UTC)

I have read the RFC, I followed it quite closely. Now I'm seeing you try to push your view from the RFC, that gained very little support, over-top of the view that gained a far-reaching consensus. You're effectively forum shopping; RFC said no but maybe WT:BOT will say yes. ~ User:Ameliorate! ^{(with the !) (talk)} 14:11, 18 September 2008 (UTC)

When your bot goes wrong (which it does), what do you do? Majorly ^talk 10:37, 18 September 2008 (UTC)

Shall we remove the BAG process then? Why do some users get to bypass it ? Majorly ^talk 10:38, 18 September 2008 (UTC)

What do we do when a non-zomg-adminbot admin makes a mistake? The admin apologizes for the inconvenience and we move on.... --MZMcBride (talk) 10:39, 18 September 2008 (UTC)

It's alright for you to say that, I doubt the blocked editor is as pleased. And yeah, the admin apologises... that'll be something interesting to watch! Majorly ^talk 10:41, 18 September 2008 (UTC)

Admins never apologize when they accidentally block someone. And though you probably won't believe me, when I was blocked, I wasn't running a bot or script; I was just using tabs. --MZMcBride (talk) 10:47, 18 September 2008 (UTC)

In my experience, bot operators are never to blame for their actions: either the person was "acting like a bot" or their was a bug. No matter now though, it's just a block, easily reversible... no so much so when the user quits in disgust. Majorly ^talk 10:52, 18 September 2008 (UTC)

(e/c with above) The blocked editor is displeased regardless of whether he's been blocked by a bot that had a too broad regex installed or by a tired admin, who pushed the wrong button (or too fast). Too much bile in your words; I've seen adminbot operators apologize for mistakes (so did I) should they indeed happen. One that refused to acknowledge mistakes springs to my mind, Betacommand; he got desysopped; seems to me like the process worked after all. Миша13 10:53, 18 September 2008 (UTC)

How is approval going to make a difference in this case? Approval does not guarantee that a bot will have a 0% error rate, nothing, not even manual approval for each action, can guarantee perfection. Accidental blocks are bad, but are unavoidable whether we have adminbots or not. But approval isn't going to make a difference on a bot that's been operating for years, especially one that's open source. I don't think the user who is accidentally blocked is going to care whether he was blocked by an admin screwing up, an adminbot screwing up, or an approved adminbot screwing up. He just cares that he was blocked. While I'm not arguing against approval, I think arguing for it based on this reason makes no sense, this is an argument to do away with blocking or have a zero tolerance policy for admin mistakes. Mr.Z-man 13:03, 18 September 2008 (UTC)

If a bad block is made, that's bad. If an admin makes the block, well that's bad. But it's understandable because admins are human. Everyone makes mistakes. A bot should never make a mistake. If a person found out they got blocked wrongly by a person, they'll be upset, but more likely to understand the concept humans make errors. They're less likely to understand the concept a computer program makes a mistake. They'll wonder "why is Wikipedia allowing an automated process to block legitimate accounts?" The fact is we aren't, and these are running illegally. Can you imagine how bad that would look to an outsider? You don't seem to realise the damage one bad block can do. Majorly ^talk 13:15, 18 September 2008 (UTC)

A bot should never make a mistake? Really? Where are these perfect computer programs? Companies can spend years and millions of dollars developing software and it will still have bugs. These bots are generally the product of one person spending a few hours. And your reply didn't really address my point at all, why is the accidentally blocked user going to care whether they were blocked by a bot, or blocked by an approved bot? If anything, an approved bot would be worse because then they are being blocked by something that has an official stamp of approval. Mr.Z-man 15:46, 18 September 2008 (UTC)

Openness is how you avoid mistakes. And when someone gets incorrectly blocked, it's better to know what rule produced the incorrect block so we can talk about fixing it, than to say "Oh, that was Misza13, we have no idea how he makes his decisions because they're actually made by a secret computer program". rspeer / ɹəədsɹ 16:09, 18 September 2008 (UTC)

You can have a full idea, as long as you can program in python. My bots were always open source, but I think I mentioned that some 20 times by now. Миша13 16:57, 18 September 2008 (UTC)

Sure. Could you please link to the source? rspeer / ɹəədsɹ 20:03, 18 September 2008 (UTC)

Here you are. The pagemove/username bot is called "eyebot", current version being eyebot4/. The image deletion bot located in imagetools/ (the daily_deleter.py script is run by a cron). Миша13 20:17, 18 September 2008 (UTC)

I have issues and questions about your code. Since you won't run it through a BRFA, how would you prefer that I raised these issues? rspeer / ɹəədsɹ 20:35, 18 September 2008 (UTC)

How about here or here? Миша13 21:15, 18 September 2008 (UTC)

Could you finally throw that "0% error rate" thinking out of the window? You've been told many times that such programs don't exist. If a programmer tell you his software makes no mistakes then either a) he wrote a Hello World or b) he lies and tries to sell you something or c) he means that he's done extensive testing and put all the effort he could into assuring the program in question behaves according to its functional specification, notwithstanding that it may still be prone to an occasional error, though certainly not as often as a human would (that's how they invented industrial automation). Миша13 16:57, 18 September 2008 (UTC)

Um I know bots aren't going to have a 0% error rate. I've run bots, and have experience in programming. This is the ideal situation. We have redirect deletion bot that does a good job. It only affects redirect page. This bot affects a person. I don't think we should be having bots that block people, when there's always the slight chance of a mistake. If a wrong page is deleted, that's a shame, but it's undeletable. A person blocked may never come back. What my issue is, the community has no say in whether these bots are run. And some people seem to think that's perfectly OK. Majorly ^talk 17:51, 18 September 2008 (UTC)

The community had their say a zillion times - virtually every time I got a mention on AN/I because of a block someone did not understand (and this did happen often). Did someone ever prove a consistent pattern of bad blocks? No. Bad and borderline blocks were few and far between, the community agreed that they wish human admins were so accurate and with a "good job, keep up" pat in the back we moved on. Миша13 20:17, 18 September 2008 (UTC)

We didn't ask before you decided to start using an illegitimate bot. We shouldn't be discovering your bot running on AN/I, after there's an issue. We should discover it on RfA, or at least BRfA. We should have the chance to iron out any issues before you start running it. Since you don't bother to tell the community you want to start running, we can't do anything until a mistake is made. That's the issue here. Majorly ^talk 20:22, 18 September 2008 (UTC)

Again you (falsely) assume that every time I was mentioned on AN/I it was because of a mistake. More often than not it was the vandal himself trolling to draw attention to me (hoping I get "shut down" so they continue along their merry way) or someone not understanding that a right thing's been done (either images or an obscure username vandal meme). Also, at the time these bots were written, Wikipedia was still full of paranoia towards the very idea, so no public proceedings could take place. Миша13 21:15, 18 September 2008 (UTC)

Lack of options

Let's be clear, the only way to definitively stop an adminbot operated on an admin's account is to block (or de-sysop) the admin. Any proposal that adminbot operators must go through some new form of an approval process, requires that you are willing to block admins who refuse. The community supports dealing harshly with bad adminbots, but personally I don't see a lot of support for blocking well-behaved adminbots. Unless and until the community is willing to make and stand behind blocks like that, any approval process will fundementally be voluntary. Dragons flight (talk) 16:54, 18 September 2008 (UTC)

Just for the technical record, unless something changed, admins can still block and unblock anyone while blocked themselves; correct me if I'm wrong. Миша13 17:11, 18 September 2008 (UTC)

Hence the nebulous "stand behind". Repeatedly removing a block against yourself would be a fast path to desysoping, but experience suggests that blocks against admins are rarely supported by the community and hence tend to be short-lived. Dragons flight (talk) 17:18, 18 September 2008 (UTC)

I was rather thinking of a situation where an admin gets blocked but the bot continues to (correctly) block Grawps etc. without unblocking himself (because he's offline/on vacation while the bot still runs unaffected by the block) - creates an interesting, if not humorous, situation. CSCWEM got desysopped eventually, but he continued a path of bad blocks while not responding to queries. Миша13 17:26, 18 September 2008 (UTC)

To elaborate, I don't support blocking well-behaved adminbots; however, I would like to know if the other parties to this do think we should be moving towards blocking admins? Do you believe the rest of the community would stand for that? I don't. Dragons flight (talk) 17:02, 18 September 2008 (UTC)

A blocked admin can only unblock themselves. They can't block/unblock anyone else while blocked (or do anything, other than read). Majorly ^talk 17:52, 18 September 2008 (UTC)

Sry d00d, u seem 2 b rong. Миша13 18:28, 18 September 2008 (UTC)

Oh, seems I was wrong about that. I'm certain they can't block anyone else though. And why are you talking like that? Majorly ^talk 18:31, 18 September 2008 (UTC)

Cuz diz page cud use moar lulz to relieve the tension that's built up. And note that I indeed have blocked and unblocked "someone else" - that is Misza (talk · contribs), my alternate account - while blocked myself. Миша13 18:40, 18 September 2008 (UTC)

That really isn't good at all. I have filed a bug request to get that ability removed. That isn't right. Majorly ^talk 18:49, 18 September 2008 (UTC)

It's somewhat consistent with how group permissions in MediaWiki work. Besides, even if an admin can only unblock himself (this feature will prolly never be removed), then he can always block/delete/unprotect anything/anyone else a split second later (given that it's a devious bot specifically designed to cause mayhem, whose reaction time is uncomparable with that of a human), so in case of a rogue admin you should rather storm straight for an emergency desysopping, not bother with blocking. Миша13 19:18, 18 September 2008 (UTC)

Actually, on large wikis with dozens/hundreds of admins, there is no reason that the feature to unblock yourself couldn't be removed. The risk is that someone could seize control by blocking all other admins, which is unlikely on large wikis. For added insurance against coups, one could allow blocked admins to unblock any admin but himself. But these sorts of nefarious admin countermeasures are really something of a solution in search of a problem, and so not exactly a developer priority. Dragons flight (talk) 19:29, 18 September 2008 (UTC)

A possibly better solution would be if admins could desysop other admins by sacrificing their own bits in the process (and let the community mop up afterwards, i.e. agree who was right and who should get his toys back). I think it's been suggested before but didn't quite pass - this however requires a more "No Big Deal"/"easy come, easy go" approach to adminship than we currently exhibit (since it's a de facto compulsory recall process for everyone). Миша13 19:45, 18 September 2008 (UTC)

That's actually a really interesting idea. Mutually assured destruction to stop someone abusing the tools, and would instantly stop any major problem lightning fast. rootology (C)(T) 16:07, 21 September 2008 (UTC)

I barely remember it being mentioned quite a while ago (during the long series of compromised admins' accounts) and I thought "oh, that would be interesting". That even might've been not on the wiki but rather in #wikipedia-en-admins. You think this idea would be worth publicizing? Миша13 16:46, 21 September 2008 (UTC)

It never hurts. It's so outrageous, fair, and simple it might even work. Anyone misusing it is probably guaranteed to not get their tools back, while the improperly emergency desysopped person is guaranteed to get it back. rootology (C)(T) 17:05, 21 September 2008 (UTC)

Dragon: Goodness, we've had a breakthrough. :-) You seem to get at least some of the point I was trying to make in the section above. Excellent. --MZMcBride (talk) 18:08, 18 September 2008 (UTC)

Do you mean to propose, as a legitimate outcome, that adminbot operators just say to the community "screw you, you can't block me anyway"? All we have asked for is the same review that every other bot gets.

Also, the situation isn't quite that black and white, with all bots being either "good bots" or "bad bots". There are circumstances in which even "good bots" need to be blocked sometimes. The nice thing about other bots is that blocking them is no big deal, and I mean this seriously as opposed to the false platitude "adminship is no big deal". You can block a bot without drama if it seems to be doing something unintended -- even if it's not a fault in the bot, just changing circumstances on the wiki. That's because bots don't get offended when they're blocked, and good bot owners don't get offended by the block either. There is absolutely no way to block an admin's main account without causing much more drama than the original problem is worth. No matter how you do it, it's going to be a very big deal. This is why the bots should be run on separate accounts like all other bots are. rspeer / ɹəədsɹ 20:14, 18 September 2008 (UTC)

I mean to say that "screw you" (hopefully more diplomatically phrased) is a likely outcome in any effort to demand well-behaved adminbots be put through a newly constructed approval process.

As to your other point, why not give all adminbot operators free +sysop +bot second accounts. I believe most adminbot operators would segregate their actions if given a chance, but if you make obtaining it A Big Deal, then I doubt most would want the trouble. Dragons flight (talk) 20:48, 18 September 2008 (UTC)

/me giggles a bit. That requires that the bureaucrats go along with this. I've seen no indication of a willingness from them for this specific proposal. Though if one is willing, I would be fine with running my adminbot under User:MZMcBot. :-) --MZMcBride (talk) 21:07, 18 September 2008 (UTC)

Since when is it up to the bureaucrats? The community decide how to deal with things, bureaucrats merely implement it. It's not up to them if they flag your alt account or not. Majorly ^talk 21:12, 18 September 2008 (UTC)

The bureaucrats have access to the restricted 'sysop' and 'bot' portions of Special:UserRights. The "community" doesn't. Duh. :-) --MZMcBride (talk) 22:58, 18 September 2008 (UTC)

So no one will mind if I ask my friend WJBscribe to +sysop me? Since it's the bureaucrat's decision isn't it...? You're missing the point completely. Majorly ^talk 23:15, 18 September 2008 (UTC)

Right, one big problem with admin bots is that it gets so much drama if anyone as much as mentions that some (unintentionally malfunctioning) admin bot should be blocked, since it means blocking the admin account. And having separate admin bot accounts would be an easy solution to that problem. I haven't read up on the RFA you guys mention here yet (could someone link to it please?), but I agree that for starters why not ask the bureaucrats to just hand out such admin bot accounts to the current admin bot users in a very non bureaucratic manner?

And regarding desysoping: I don't know the background on this so I don't know how much need there is for it. But I like the idea that any admin could be able to desysop any other admin, at the cost of himself being "temporarily" desysoped. Since I guess we can be pretty sure that the vast majority of admins are good people then the good admins will win over the bad ones within minutes. Of course this should only be implemented if there is a need for it, since it will perhaps occasionally be misused by admins who have decided to leave Wikipedia. (I have no idea how many bureaucrats we have and how many of them are usually available for action at any given time of day.)

Oh, here's an idea: If not too messy to implement it could perhaps even be an actual temporary desysoping? That is, both admins get desysoped for say a week. That gives the bureaucrats time to come in and handle the actual definite desysoping when they have the time.

--David Göthberg (talk) 20:08, 21 September 2008 (UTC)

The "hand out an extra bit" option probably wouldn't work because of the interpretation that +sysop is given to an account, not a person, which dominates on Wikipedia. A while ago I tried to find a 'crat that would do that, to no avail.

The sacrificial desysopping is basically what I already mentioned in this very thread few replies above, in discussion with rootology. Seems this might get some support after all. Миша13 20:22, 21 September 2008 (UTC)

Well, bot accounts are already seen as connected to the corresponding user account. If they prefer to think "account" not "person", then why not just think of it like the admin bot account is a sub-account of that admin account? I don't see the problem, it's just a technical means so we can block a part of an account, the bot part. But I see there is a problem if the bureaucrats don't want to see it that way. But I won't take your word for it since you seem to prefer to run your bot from your main account, thus you are partial. Anyway, if we get a consensus for admin bot accounts then I think it shouldn't be too hard to convince the bureaucrats to implement the consensus.

And you misunderstood me about the idea of a sacrificial desysopping system. What I meant above is that I agree with the that idea. I didn't come up with the idea, I read your comment about it above. What I added was the idea of perhaps making it automatically be a temporary one week desysoping, instead of an indefinite one.

--David Göthberg (talk) 21:29, 21 September 2008 (UTC)

New adminbots

Is there general agreement that the current version is acceptable for new adminbots? If the dispute is solely about how to deal with existing adminbots, I propose making a new subsection for that and moving the proposed tag to it. — Carl (CBM · talk) 02:49, 19 September 2008 (UTC)

It still baffles me that a couple of admins are so opposed to getting approval the same way that all other bots get approval. Are they concerned that the community wouldn't support their task? If so, isn't that a sign that maybe they shouldn't be doing it? rspeer / ɹəədsɹ 07:31, 19 September 2008 (UTC)

Cut the rhetorics. My bots are approved and the community supports their tasks. Миша13 09:59, 19 September 2008 (UTC)

It's mostly the block bots that the community is opposed to and when the abuse filter comes on line they will no longer be needed. Also this is basicly what krimpet suggested at the rfc which IMO has consensus. --Chris 09:29, 19 September 2008 (UTC)

This may have a general consensus per the RfC, but it's baddly written for a policy and leaves too many elements and details of the proces up for interpretation (by whom? the 'crat?). Also, as I said already, before I even consider retroactively approving my bots under a new system (read: jeopardizing them because of a badly-designed approval process), I'd like to see some new bots run through it. And yes, I very much count on the abuse filter to obsolete my blocking bot - it's nothing new; the username blacklist made the newuser blocking component pretty useless - the anti-You-know-who subroutines are all that's left. Миша13 09:57, 19 September 2008 (UTC)

Chris, Rspeer, Misza: what do you think about the part of the proposal that relates to new adminbots? — Carl (CBM · talk) 13:12, 19 September 2008 (UTC)

I see several minor and major issues

1. First of all, what Krimpet proposed was a sketch of an idea. But now it's been copied almost verbatim as a policy text, which doesn't work so well.
2. "administrator in good standing" - Always made me wonder what that good standing stands (no pun intended) for. Now that this would become a part of a policy that could potentially affect me, I ask it to be defined precisely (in terms of tenure or whoever decides on that or whatever else) or removed altogether (there are A-class admins and B-class admins?).
3. "code should also be made available to all contributors in "good standing"" - See above.
4. "After a suitable consensus that the task is both useful and technically sound" - I think we more or less agreed that bots should be approved on two levels: the business level (task appropriateness) reviewed by the community and the IT level (technical viability) by the BAG or its equivalent. Now the quoted part of the policy (and the one before: "As with normal bots, members of the community are invited to add questions and comments to the BRFA.") suggests this is combined. Believe me, if you want the process to run smooth, these must be separated - there is a reason for which corporations segregate duties so that the business only produces a functional specification while the IT department implements it. Also, who is to decide if there is a consensus? A BAG member? Doesn't feel good. Should be a 'crat, unless its only about the IT part - the policy doesn't make it clear.
5. "the bot will either run 'dry' without a 'sysop' bit" - I may be missing something, but it seems to be like we're talking software testing here. So, we should either set up a testing environment (an entire test Wikipedia, but for bot testing) or test it on the live system (the latter preferable - you can't simulate all the real life quirks in a sandbox). Either way, the bot must have access to the tools it's testing. I would need an example of what's a "dry run" and how's it useful.

Lastly, a note unrelated to the policy itself, but to BAG in relation to the proposed policy. It is my observation that BAG in its current form is not competent to make decisions this policy requires. Let me explain. I perceive BAG as a free-form collection of mostly-internally-appointed people who happen to be above-average computer-literate or have a history of operating bots. So far, it's been okay, because they server more of an advisory role to the 'crats. But now, it appears that the policy requires their members to make actual executive decisions regarding adminbots (which, theoretically, they have not been trusted with explicitly). Thus, I see two ways from here: a) abolish BAG (as in taking it out of the policy) and reduce it to a WikiProject-type community and let the 'crat assess consensus on both levels, but this wouldn't play well with the current process of regular bot approval or b) elect a subgroup of BAG that's explicitly fingered (by a wide community) as trusted to give a technical "go" to adminbots.

Just some thoughts. You all process wonks should love it. Миша13 13:52, 19 September 2008 (UTC)

Misza, we already had a full RFC on this matter and your thoughts are and were not exactly on the lines of what the consensus was there. The obvious next step after Krimpet's proposal got a lot of consensus, would be to attempt to propose it as policy. Also we have no need to change around BAG's role in the process when there seemed to be a lot of support for it being the main factor in adminbot approval (as it was part of Krimpet's proposal), heck I thought you adminbot runners didn't want to have to go through an RFA of sorts. Now, I find it unnecessary to open an entirely new RFC on her proposal alone, but I will if this discussion doesn't start to actually get towards a goal of some sort, instead of going in circles and as if the previous RFC hadn't happened. --Coffee // talk // ark // 05:21, 21 September 2008 (UTC)

Hey, admit it, you just tl;dr my post, didn't you (except the BAG part)? Let me say this in a nutshell - the policy as it is proposed is unusable until at least the questions I have posed are addressed (note: I'm merely suggesting answers to some of them, not imposing them). And I don't see how they are addressed by the RfC either - if you can point it out, go ahead, we're discussing it here.

Second, I still don't care a lot if you make up a new process or not (I can always ignore it should it stand entirely in my way of improving Wikipedia) but if you really need it that badly, I'm helping you make the proposal (Krimpet's idea stands in fact as proposed right now) usable. You're welcome. Миша13 09:11, 21 September 2008 (UTC)

I've read your post, but I don't see anything in it that makes the proposal "unusable". Most of your concerns don't seem to be actual problems, and the fact that the policy can be incrementally refined shouldn't be a reason to sink it.

• On "administrator in good standing", that is indeed a silly phrase. I'd be fine with removing "in good standing", because hopefully that comes with being an administrator.
• Users in "good standing", however, are a concept that the BAG has used for a while. It means, for example, that you don't have to show your list of HAGGER-detecting rules to some random new user who might be Grawp.
• Bots frequently do dry runs. Typically, they post a list of the changes they would make to a project page.
• Your concern about approval doesn't make sense, because it has little to do with the way BAG works, and your proposal doesn't make sense either. Perhaps these mythical beasts, "process wonks", who enjoy unnecessary bureaucracy would get a kick out of your proposal, but they're not here. Krimpet's proposal involves nothing more than doing what the BAG normally does, plus one more sanity check by the bureaucrats.

rspeer / ɹəədsɹ 15:49, 21 September 2008 (UTC)

Misza is correct that "in good standing" is quite vague. I agree that, ideally, all admins should be in good standing, but I don't think that's the case. Would an admin under some sort of arbcom restriction be "in good standing?" What about a brand new admin? Should there be some sort of waiting period to make sure they're competent with using the tools manually first? Non-admins in good standing varies depending on where you are. Its different for rollback, accountcreator, ipblockexempt, RFA, etc. Which definition do we use for this? Mr.Z-man 16:31, 21 September 2008 (UTC)

(e/c with Mr.Z-man) I'm not trying to sink anything, but I don't like how it's only a footnote in the policy either.

• Is the "good standing" as used by BAG defined anywhere?
• Ok, so I didn't exactly understand what a "dry run" is.
• Regarding approval, I still am of the opinion that community business approval (for the task) should be separated from the technical assessment (done by BAG), both to segregate duties and to reduce noise on both forums. This could be done in one of two ways:
  • A separate subpage of BRFA (they don't come that often), heavily advertised.
  • A discussion on the Village Pump (or other high-visiblity forum, with additional advertising). In this case, it becomes crucial that the 'crats determine the consensus - because it might've been arrived upon from an unrelated discussion.

I'm stressing the business approval because it's been pointed out that BAG happens to make decisions without that perspective. Миша13 16:42, 21 September 2008 (UTC)

And I've often been the one pointing it out. Publicizing the BAG request and making sure that the community is okay with it is essential. And it is the bureaucrats that determine the consensus in Krimpet's proposal. The only difference you're arguing for is whether to have two segregated discussions, a detail that I think is rather unimportant. rspeer / ɹəədsɹ 17:27, 21 September 2008 (UTC)

Why I'm pushing towards this separation is because of two things: 1) it's been supported on the RfC that the current bots be revised by a body separated from the "mob of uneducated users", which I don't see why shouldn't be applied to new bots as well and 2) speaking from experience, I can tell that separation of business and IT help both groups keep a better focus on their part. Миша13 21:18, 21 September 2008 (UTC)

I don't think of a BAG discussion as being the same as the "mob of uneducated users", if that's what you're referring to. That was certainly the problem with having the discussion on RfA. But here on the BAG board -- even though we would be publicizing it -- I think the audience is different, and the BAG should be able to keep the discussion under control, and tell those people who give us bad sci-fi scripts instead of reasonable discussion to kindly shut up. Perhaps we can have a discussion with a "business" section and a technical section, sure. Separate pages seem like an unnecessary bit of process, as there will be many people who wish to discuss both. rspeer / ɹəədsɹ 21:35, 21 September 2008 (UTC)

I think this is workable. I think there's sufficient support for admin bots to be approved by BAG, with concurrence and +bot flag from a crat. And yes, the question of what to do with the pre-existing admin bots, especially those that aren't well-written is a stickier issue. — Rlevse • Talk • 01:00, 22 September 2008 (UTC)

Responding to WP:AN request to look at this

WP:TLDR. Stifle (talk) 14:12, 21 September 2008 (UTC)

There once was a Stifle, he's a user

Who saw news of a wiki abuser

Deciding to read

He sees too much screed

And for refusing to read, he's a loser.

--harej 15:01, 21 September 2008 (UTC)

I was going to give you a barnstar for that, but the last line lost it for you :) Stifle (talk) 15:17, 21 September 2008 (UTC)

Grace period

Shouldn't there be some sort of period that current adminbot runners should have to put their bots through the process? It was, in not the best way ever, put into the proposal and then removed. It is vital to have some sort of chosen "grace period" that adminbot runners are allowed to have, so that they can separate their bots from their admin account, otherwise the process will be in a state of confusion. I would say about 2-4 weeks would be a good time, what are your thoughts? (and no, not having one at all isn't an option...) --Coffee // talk // ark // 20:49, 21 September 2008 (UTC)

I would opine that the longer the better. Not only because that would give everyone time to prepare their code and ideas for public review (writing verbose documentation for software is not as trivial a task as it may seem) but also I would like to avoid a situation where we have a sudden rush of requests and confuse the community. A shock implementation won't do any good - this should be a gradual process (we might need to iron out the policy on the way).

Another thing you don't seem to take into account is that we're all volunteers here, have real lives etc. As such, we don't devote full-time to Wikipedia, and certainly will not spend any extra time because of something that's suddenly being imposed. I say that a month is a realistic minimum, but I'll push for at least two - there is no urgency; some bots have been running for two years without this process, they can run some more.

As a closing note, I'll just reiterate that I'd prefer new bots walk the process first. Миша13 21:09, 21 September 2008 (UTC)

That sounds fine to me. rspeer / ɹəədsɹ 21:36, 21 September 2008 (UTC)

More input, plz! Adminbot operators, comment, darnit. Two months should be enough for me but I don't want to put others on a tight schedule. Миша13 18:39, 23 September 2008 (UTC)

IMHO two months is fine, and of course there can be exceptions such as if the person is on wikibreak etc., but I'd gladly take that just to make this process smoother, which has been my intention since I opened the RFC, because frankly I like the work that you adminbot coders do and I want to see it keep on going, having it more open just removes all of the problems that people have had with the adminbots for a long time now. So I would like to see other adminbot runners comment, but I think that 2 months is a perfectly good timeframe. --Coffee // have a cup // ark // 18:53, 23 September 2008 (UTC)

Yes, whatever is required to get Cydebot its own admin account already. Its deletions have been clogging up my Special:Log for over a year now. I've had enough! --Cyde Weys 19:11, 23 September 2008 (UTC)

Two months sounds fine. --MZMcBride (talk) 05:54, 24 September 2008 (UTC)

Anything that gets the damn bots out of my logs and contributions. I probably won't work up the time or motivation to provide documentation, but am working on making the source public and looking somewhat respectable. If anybody's got any questions now, just leave a message for me. east718 // talk // email // 05:30, 25 September 2008 (UTC)

Bold attempt on adminbots

Ok, since I feel we have stalled a bit, I went bold and have rewritten the policy to reflect what I perceive as consensus (both here and the RfC). Significant changes worth mentioning:

1. Split of the approval discussion into the two planes that were mentioned before.
2. The "business" part may happen outside BRFA. This clause I draw from experience - the bot might not be born solely in the programmer's mind - it may happen to be mentioned in some obscure part of Wikipedia, start rolling, get a wider and wider input and finally establish a consensus. Since we leave it to the 'crats anyway to decide on the consensus, with this I suggest adding one other minor duty: decide whether the discussion was publicised enough.
3. I have thrown out any mention of "good standing", because it's not defined and therefore meaningless. If at any point Wikipedia arrives at a definition of a "user in good standing", it may be added back. Instead, I have included a clause that it must be made available to any administrator on request. The user may also choose whom they would like to include into the discussion.
4. The BAG don't "reqest", they "recommend". :)

I might've overdid some parts, feel free to point out. I would also very much welcome some damn input from other bot operators. Миша13 18:16, 23 September 2008 (UTC)

I like it, and I must say I'm very pleased with what you came up with here (and surprised frankly). I like the move on taking away more of BAG's power over the discussions, and having the crat follow other discussions to gather consensus. Now let me comment down below. ;) --Coffee // have a cup // ark // 18:40, 23 September 2008 (UTC)

I recognise that "editor in good standing" is not rigorously defined, but it is by now a familiar notion, and I expect most of us would be able to decide whether a particular user falls into this category. Thus I don't think its vagueness is a reason for not using it at the risk of undermining all the hard-working non-admins in good standing on this project :) MSGJ 13:56, 25 September 2008 (UTC)

Again, if it's not defined then it's useless. It may be that most of us would agree on the most extreme cases but there's a wide grey area where people would have different opinions. If it's subjective to animosities and friendships between particular users (you think Prodego would consider me to be in good standing? doubtful), it can't be used as a basis of a policy. Unless you point out who decides who is in good standing and who's not (because I can't imagine opening a discussion for every user about whom we must decide this). Миша13 20:22, 25 September 2008 (UTC)

As a first vetting of the new admin bot policy I'm putting Cydebot through the process. It seems to be working fine so far, so hopefully we'll get some precedent out of it. If anyone else feels like they want to comment there, go right ahead. --Cyde Weys 03:20, 26 September 2008 (UTC)

Rule files

I feel there's still one more issue that should be addressed somehow. Adminbots may have a significant amount of backscene configuration not available to the public. Take my blocking bot as an example. It has a database of regular expressions applied to edits to detect vandalism. For obvious reasons, I will never make them public, but I'm willing to show them to interested parties. Thus, these two alterations: [1], [2]. Миша13 18:35, 23 September 2008 (UTC)

Well the Regular Expressions could be one of the faultiest parts of the bots (as I know), so I'm leaning a little towards not allowing change of the bot's code (including the regexs it uses to find vandalism) without asking first at BRFA, however I could see having BAG review the code weekly or monthly (depending on the type of bot of course) to make sure you haven't missed anything and that it's safe for it to continue running. Just my 2 cents, --Coffee // have a cup // ark // 18:47, 23 September 2008 (UTC)

I don't have to change the bot's code to modify the regexes. They are stored in an SQLite database that could be treated as a configuration file - these are not considered to be a part of the bot's source code. The problem is that it would be retarded to require every single change to go through a full approval process (in the past I had to update these almost daily to contain the username vandals) - this really has to be much simpler. I've been doing this on my own for two years and only one regex has to date hit an innocent user (isgay$ and DennisGay (talk · contribs)). That's why I suggest we recommend extreme caution and possibly a consultation with another administrator/BAG member? Let's assume some good judgment the admins are supposedly known for.

A periodic review of code changes proper (if there were any) is a good idea, but I'd hold off with specific periods until we see how much workload would that generate for the BAG. Also, if a bot is build upon a framework, say pywikipedia, should they also include review changes to the underlying framework? After all it affects the bot's behaviour. I feel this is going the wrong way. Миша13 19:17, 23 September 2008 (UTC)

Yes I would definitely not think that every regex change should have it's own approval process, but like you said maybe some consultation with another person familiar with regexes should help some. As to the periodic review, once every month wouldn't seem to be to hard, but like you said we won't know till the full workload is seen. I don't know much about pywikipedia and such but I guess they should review changes that will affect the bot, but we don't need to add too much process into this whole thing, just enough to get it working. --Coffee // have a cup // ark // 20:57, 23 September 2008 (UTC)

It has a database of regular expressions applied to edits to detect vandalism. For obvious reasons, I will never make them public, but I'm willing to show them to interested parties. Why not have some sort of service like OTRS where people can submit certain configs of their bots like expressions so that certain people can view them but not the general public?. Peachey88 ^{(Talk Page | Contribs)} 03:39, 24 September 2008 (UTC)

Because no one has spent the time to do something like that? It would need to be set up, maintained, and bot operators would have to remember to update the pages. And there would also have to be some sort of access control system with manual approval. Its a lot of work. Mr.Z-man 05:51, 25 September 2008 (UTC)

Also may be worth having a small tight panel/list rather than a mailing list do this - after all it's config (mainly regex) changes only. Doesn't need a big mailing list to review these, not that complex, and more people facilitates dedicated code-capable vandals getting into the loop. "Please email your regex updates to any of the following who will check and endorse them". FT2 ^{(Talk | email)} 00:52, 29 September 2008 (UTC)

These rules are the one part of a bot with a legitimate reason not to be open. I think that, when a bot is going through the approval process, it should be sufficient to make public a few representative examples of rules. rspeer / ɹəədsɹ 05:12, 24 September 2008 (UTC)

That's useful for seeing what the bot will do (and making sure the author isn't a total incompetent), but it won't let people check for bugs. --Carnildo (talk) 07:30, 25 September 2008 (UTC)

Bots with administrative rights - now agreed?

There seems to be an emerging consensus above in favour of the current "Bots with administrative rights" section. Are there any objections to the "proposed" template now being removed from that section so I can go ahead with approving such bots? WJBscribe (talk) 00:37, 29 September 2008 (UTC)

I have no objections, it looks fine to me. Anyone else see anything they don't like? --Coffee // have a cup // ark // 00:52, 29 September 2008 (UTC)

No objections from me --Chris 05:18, 29 September 2008 (UTC)

I still don't see a clear consensus on the "Rules files" section above. There seem to be agreement that there should be some oversight over them but not quite how would such governance look like (wide OTRS-like approval vs. Cabal review). Other than that, I agree we have an agreed policy. Миша13 07:23, 29 September 2008 (UTC)

I feel there is sufficient community for admin bots with BAG and crat approval, ie, without an RFA. However, I think these bots should run under their own account, not under the operator’s admin account. I also think that these bots should not be coded to unblock themselves—that I simply can not support. This weekend Maxim said he wanted to approve Cyde bot but I said I felt we weren’t quite ready to approve admin bots-I think FA bot needs to be settled first-and that I think these bots should run under separate accounts. I also think all existing admin bots that are not approved need to go through the BAG/crat approval process and be separated from their owner’s accounts. — Rlevse • Talk • 12:22, 29 September 2008 (UTC)

I'm fine with this version, modulo some copyediting. — Carl (CBM · talk) 13:58, 29 September 2008 (UTC)

Current adminbots

Are we any nearer to establishing consensus about if, when and how current ("unauthorised") bots running on administrator accounts are going to be approved? MSGJ 13:14, 11 November 2008 (UTC)