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 · Archive 21 · Archive 22 · Archive 23 · Archive 24 · Archive 25 Control proposals Archive policy Archive interwiki (also some approvals for interwiki bots)

I am currently applying to be a member of BAG and input is greatly appreciated.—cyberpower _Offline^{Happy 2013} 13:31, 2 January 2013 (UTC)[reply]

I am currently (self) nominated to become a member of BAG (Bot Approvals group). Any questions and input you have is invited with open arms. ·Add§hore· ^{Talk To Me!} 21:38, 16 January 2013 (UTC)[reply]

Per WP:BRD I've undone a recent addition to the bot policy: "Except for very trivial cases, an Administrator should refrain from unblocking their own bot."

I disagree with that addition (there's a related discussion on the Administrators' Noticeboard) and would actually prefer the opposite language to be included: something that explicitly allows a bot operator to unblock their own bot with the caveat that by doing so they are taking responsibility for the bot's activities. 99 times out of 100, a bot operator is responsible enough to do this, and I wouldn't want to see policy geared towards the 1% who aren't. 28bytes (talk) 19:51, 21 January 2013 (UTC)[reply]

If the bot operator is so responsible, why'd their bot get blocked in the first place? NE Ent 19:56, 21 January 2013 (UTC)[reply]

Well, there's a difference between responsible and infallible. Bugs do happen, and if the bot op is asleep or away when their bot starts breaking something, blocking it is an appropriate action. Once fixed, unblocking it is appropriate, whether by the bot op or another administrator. 28bytes (talk) 20:02, 21 January 2013 (UTC)[reply]

I would have to agree with 28bytes, There are times where users change something on wiki without notifying the Operator, who has had working stable bug free code for an extended period of time so that they really don't monitor it any longer. Unexpected changes can cause issues that require minor adjustments in the software if the operator is not notified that the change was made, the bot will continue to break things until the operator is notified. (Policy changes, wikiproject guidelines, ect) Werieth (talk) 20:08, 21 January 2013 (UTC)[reply]

I agree with 28bytes however part of the Arbcom restriction against Rich Farmbrough was due to his unblocking of his bot so the Arbcom has already set the precadent that a botop cannot or should not at the very least, unblock their bot. So if it is the case that a bot op is allowed to unblock their bot then that should be relayed to Arbcom as well. Kumioko (talk) 20:24, 21 January 2013 (UTC)[reply]

We don't let admins use their admin privilege for pages they're manually editing per involved, we shouldn't let them use them for bot operations. What bot task is so urgent it can't wait for review by another admin before proceeding? NE Ent 20:34, 21 January 2013 (UTC)[reply]

I don't think it's a question of rushing, I think it's a question of who's most knowledgeable about whether the bot will operate correctly if unblocked. 28bytes (talk) 20:42, 21 January 2013 (UTC)[reply]

(edit conflict)Too much time thinking about a corner case -- hopefully any editor that's survived an Rfa will have enough sense to know whether or not they should restart their bot without getting additional community or BAG input. NE Ent 20:43, 21 January 2013 (UTC)[reply]

Again its really a non issue since Arbcom has already ruled than an Admin/Bot op cannot unblock their own bot. I/we don't have to agree with it, but the decision was made. Kumioko (talk) 21:31, 21 January 2013 (UTC)[reply]

ArbCom doesn't get to make policy (although it may seem like they do at times.) Part of the reason they ruled on this issue in the way that they did is the lack of clarity in the bot policy. If we clarify the bot policy, ArbCom won't have to "read between the lines" and interpret the policy in a way that's (in my view) counter to common sense and general practice. 28bytes (talk) 02:31, 22 January 2013 (UTC)[reply]

Consensus here tells Arbcom what to do, not the other way around. To be sure, though, there are a lot of people who think unblocking your own bot for any reason whatsoever is a grotesque violation of INVOLVED, so I think that was what arbcom was appealing to. To me, that feels like missing the point of INVOLVED, at least in cases where the block is due to a bug and not to some dispute about what the bot ought to be doing. If the bot operator agrees with the blocker and has fully addressed all of the concerns of the blocker I think unblocking by the operator is fine, and should be fine even without express permission. HaugenErik (talk) 19:12, 23 January 2013 (UTC)[reply]

See also Wikipedia talk:Blocking policy/Archive 18#Unblocking bot accounts. Anomie⚔ 22:58, 21 January 2013 (UTC)[reply]

I also disagree with the change. As I said on AN/ANI. The bot operator has the best, if not the only idea of how that particular bot works, they are the only people to know if an issue has been fixed and therefore an admin botop should be allowed to unblock their own bot. If you were to make an admin botop ask at AN before their bot were unblocked the basic conversation would be the botop asking for unblock, the admin asking if the issue was fixed, the botop saying yes, the admin unblocking but 100% relying on the word of the botop. I could write an entire section for the policy page and on this talk page about this 'issue' but I hope I don't have to.

Kumioko Where can I find this? "Arbcom has already set the precadent that a botop cannot or should not at the very least, unblock their bot."

Ne Ent you say "If the bot operator is so responsible, why'd their bot get blocked in the first place?". My bot has been blocked 6 times (twice by me), this does not at all reflect on me as an editor or administrator, it is simply the easiest way to instantly turn off the bot. I have also performed every unblock of my bot.

Just for reference the two other places there has recently been discussion about this issue or events leading up to it can be found >>> Wikipedia:Administrators'_noticeboard/IncidentArchive782#User:CrimsonBot_is_malfunctioning and Wikipedia:An#Blocking_misbehaving_bots

·Add§hore· ^{Talk To Me!} 23:41, 21 January 2013 (UTC)[reply]

Here you go:

• Wikipedia:Arbitration/Requests/Case/Rich Farmbrough#Misuse of administrative tools
• Wikipedia:Arbitration/Requests/Case/Rich Farmbrough#Unblocking of SmackBot - This was recently vactated however I believe the original intent and purpose still stand. Kumioko (talk) 00:20, 22 January 2013 (UTC)[reply]

• My "two" cents as a bot operator who can't unblock his bot:
  • I would rather have someone block my bot if it is potentially making mistakes rather than just pointing it out to me and making me rollback hundreds of edits.
  • For some of my long-running scripts, I wrote in a /Stop page that disables the task, so all the tasks don't have to be stopped. This is something that most bots should probably do.
  • Nearly all my scripts run on a crontab, so if you block the bot for an hour it won't stop the same broken task from running tomorrow.
  • There's no way for someone to actually tell if I fixed my bot or not unless they look into my toolserver/labs directory and look at the code.
  • My bot does a lot of different things, so once I've disabled that task (on my crontab as well), I'll try and get the blocking admin to unblock, but if they're not around I'll flag down an admin on IRC.
• tl;dr: There's nothing wrong with an admin unblocking his own bot as long as the underlying problem is fixed or disabled. Legoktm (talk) 00:44, 22 January 2013 (UTC)[reply]

How about this?

Oppose per instruction creep, but if we must, suggest tightening it to:

If a bot is blocked, the bot operator may unblock the bot once the problem has been fixed, or request an administrator to unblock the bot. Unblocking one's bot without fixing the underlying problem may lead to sanctions, including revocation of bot operator privileges.

Also changing likely to may -- cause I think may is a more flexible word. NE Ent 03:56, 22 January 2013 (UTC)[reply]

I'm fine with those changes. (Fixed a typo in your version, hope you don't mind.) 28bytes (talk) 03:58, 22 January 2013 (UTC)[reply]

Nooooooo! Editing other editor's comments in violation of tpg??? Block! Desysop! To AN! To ArbCom! ... No, wait, gotta walk the dog, maybe next time NE Ent 04:05, 22 January 2013 (UTC)[reply]

Also fine here ·Add§hore· ^{Talk To Me!} 03:59, 22 January 2013 (UTC)[reply]

Either works for me. Legoktm (talk) 04:00, 22 January 2013 (UTC)[reply]

I propose changing "Unblocking one's bot" to "Unblocking one's bot or requesting an unblock" ·Add§hore· ^{Talk To Me!} 04:06, 22 January 2013 (UTC)[reply]

Ugh, no. That wording is too long and cumbersome. I think the intent is clear enough in the original wording without it. If we must have it, use brackets -- Unblocking one's bot (or requesting an unblock) --Chris 04:23, 22 January 2013 (UTC)[reply]

Yeah, I think I'm with Chris on that one... Has anyone ever been sanctioned for requesting an unblock? Not saying they shouldn't be, of course, just that policy should describe reality, not dictate it. 28bytes (talk) 04:26, 22 January 2013 (UTC)[reply]

My point was, as it has always been, that the admin is trusting the botop to have resolved the problem, there is no guarantee, therefore if the bot were to be unblocked via a request but then were to start doing the same bad edits again that could result in "sanctions, including revocation of bot operator privileges." I agree it could stay as it is, I just feeling adding this tiny bit would include the example case I just mentioned. ·Add§hore· ^{Talk To Me!} 04:35, 22 January 2013 (UTC)[reply]

The one concern I have is what happens where the block is not for a simple technical malfunction, but for a case where it turns out there is not necessarily consensus for the bot's task (or some portion of it) after all? It's reasonably likely that an "overly-enthuiastic" bot operator might declare consensus or might make changes that in his mind address the complaints (but don't address them in the minds of others) and unblock his own bot rather than wait for someone uninvolved to close the discussion. This sort of thing is implicitly addressed here, but should we make it more explicit? At least a caution that if the unblock is at all likely to be at all controversial (for reasons other than "OMG!! He unblocked his own bot!!"), it would be better done by an uninvolved admin? Anomie⚔ 12:48, 22 January 2013 (UTC)[reply]

Yeah, to me that is a key distinction. If the reason for the block is not a simple bug/malfunction, but a dispute about what is ok for the bot to be doing, then the operator should not unblock unless there's a discussion/agreement or the operator configures the bot to operate as suggested by the blocker; that is, after removing the cause for dispute. This all seems pretty straightforward if we can get past the feeling that unblocking a bot isn't really a violation of the spirit of INVOLVED—if you're doing anything en masse with or without bots and someone asks you to stop then you should discuss it. That's all that's happening in this kind of scenario, really. HaugenErik (talk) 19:21, 23 January 2013 (UTC)[reply]

Also, I'd suggest advertising this discussion at WT:BLOCK and WP:VPP, maybe WP:BON, maybe WP:AN more explicitly (I know it was mentioned in the recent discussion, but that was easy to miss), and since this relates to recent arbcom junk it may be worth poking WP:AC/N too. We don't want people coming by later and claiming this discussion wasn't advertised widely enough.

And whatever gets decided here should also be mentioned in the bot section of WP:BLOCK. Anomie⚔ 12:48, 22 January 2013 (UTC)[reply]

I think the policy should say that, by default, unblocking of an approved bot is at the discretion of the bot operator. For an admin botop, this means they may unblock the bot themselves. For a non-admin botop, this means that an unblock request will be uncontroversial. I'm opposed to the policy according any unnecessary privilege to admin botops. When I say "by default", I acknowledge that there are cases when this is inappropriate, but this would place the onus on the blocking administrator to state that explicitly (and subsequently be prepared to justify it). For the same reason, I would also encourage any administrator seeking to stop a bot to use any operator-provided stop mechanism in preference to a block. Cheers, Bovlb (talk) 20:28, 22 January 2013 (UTC)[reply]

In general, I think bot operators who are also admins should be able to unblock their own bots, it's an efficient and reasonable use of the tools. I'm okay with the explicit wording being put in policy, but, really, if your bot is blocked, it's generally because something went wrong and needs addressed. I don't think it's a problem that non-admin operators have to request an unblock for their bot. At some point you have to say, use the tools you've been granted by the community. If you're an admin, you've been granted unblock privileges. If you can't use them properly, the community should sanction you.

There is a case where a bot operator unblocked his own bot when the community consensus for the task was being discussed (Anybot). It was a bad unblock on the operator/admin's part (Smith/Martin), and he was told that he should not have done so, and another admin blocked the bot permanently. Martin ran for adminship based on his desire to be able to unblock his bots at will, and the community granted him adminship. I think this establishes some community input on the matter, although the RFA is probably very old. Having had this happen, does not, in my opinion, detract from the fact that if the bot is blocked, obviously the operator should check for why it was blocked and fix it, and, if the operator has admin privileges, there should be no need to formally request an unblock, that's just added bureaucracy, so is deciding the policy should be the same for admins versus non admins as bot operators, it's almost like taking away a community-granted higher vetted level of trust. -64.134.221.141 (talk) 01:13, 23 January 2013 (UTC)[reply]

• Wouldn't a lot of this be unnecessary if most bots were required to have kill switch pages that would allow them to be disabled without resorting to a block, or even kill specific tasks that are causing a problem? Is there a good reason for bots not to have one? Monty₈₄₅ 06:59, 24 January 2013 (UTC)[reply]

This could make blocking bots almost unneeded, but killswitch pages generally don't stop a bot editing immediately as blocking does. ·Add§hore· ^{Talk To Me!} 19:21, 24 January 2013 (UTC)[reply]

There's also the circumstance when the bot is misbehaving so badly that the killswitch doesn't work. Legoktm (talk) 19:55, 24 January 2013 (UTC)[reply]

I had a few questions regarding the section "Cosmetic changes." Would WP:CHECKWIKI things fall under this category? It's a Fox! (Talk to me?) 15:02, 10 February 2013 (UTC)[reply]

Could I propose that in general, bots should not be editing pages that have un-reviewed edits under pending changes protection. The exception should of course be bots like cluebot. This edit shows why. The vandal removed part of the content including a tag, a bot then replaced the tag leaving the rest of the vandalism in place.Martin451 (talk) 23:04, 13 March 2013 (UTC)[reply]

I don't see what the issue is. The bot's edit isn't automatically-accepted, so you can revert it like you normally would, and eventually the bot will come by and make the edit again. Legoktm (talk) 23:22, 13 March 2013 (UTC)[reply]