Wikipedia talk:Bot policy/Archive 25

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I have contested a task of Yobot at

. I, on the other hand, believe it is a context-sensitive change because changing a single isolated Greek letter potentially makes the article hard to edit, because the editor may not be able to tell visually whether the letter is Roman or Greek. On the other hand, in a passage of text written in Greek, it will be obvious that all the letters in the passage are Greek. Bots, or at least Yobot, do not distinguish between isolated Greek letters and passages of Greek text.

I believe this is a general issue that goes beyond Yobot, and the community of bot owners should decide that changing Greek letters from HTML entities to Unicode is a context-sensitive task that should not be performed by bots. What is the correct forum to make this proposal? Jc3s5h (talk) 10:28, 8 May 2011 (UTC)

Interpret the lack of response to this matter as a refusal by the Bot Approval Group to decide, so I will move it to

WT:MOS. If a consensus forms there I will make an appropriate change to this policy. Jc3s5h (talk

) 14:07, 15 May 2011 (UTC)

BAG can't address policy issues. Bot approvals require pretty clear-cut policy support.
— V = IR (Talk • Contribs) 19:40, 15 May 2011 (UTC)

Ohms law, do you mean that the BAG isn't "in charge" of WP:Bot policy so their comments have no more weight than anyone else, and they have to follow "Bot policy" as well as other policies when approving (or withdrawing approval) from bots? Or do you mean "Bot policy" addresses something other than what kind of edits are appropriate and other policies must be consulted to discover if a type of edit is appropriate? Jc3s5h (talk) 20:02, 15 May 2011 (UTC)

My interpretation of things is that

Wikipedia:Bot owners' noticeboard.
— V = IR (Talk • Contribs

) 08:30, 22 May 2011 (UTC)

This is not really a context change though, it is a formatting one, so would not fit

TALK

19:35, 19 May 2011 (UTC)

I would say that it is a context-sensitive change, because the meaning derived from the text, viewed in edit mode, is context sensitive. An isolated "Α" could easily be interpreted as the Roman letter "A" by an editor viewing it in edit-mode, especially if the editor is cleaning up vandalism and is not a subject-matter expert. But if the same character were present in a sentence, all of which was written in Greek characters, nearly all editors would derive the meaning "Alpha" from the character. Of course, the meaning the editor attributes to the character is likely to affect the editor's editing decisions.

Also, by considering it to be a cosmetic change, it would mean that such html entities could be changed to Unicode so long as a substantive change was made at the same time, which is just wrong. Bots should not be deciding what human editors will or will not be able to understand. Jc3s5h (talk) 20:18, 19 May 2011 (UTC)

I did not say to consider it a cosmetic change, I said that the cosmetic section or some other section could fit better than the context section. Also "cosmetic" does not imply "allowed" and neither did I imply this. Obviously, bots should not do this; I thought that's already established.

I think it fits the cosmetic section better than the context section because that is how the reader would see it. I always consider reader first, then editor. To the reader, the change makes no difference. To the editor it does. For the reader this is a cosmetic change. For the editor its a formatting/markup change that might create contextually ambiguous situations. That really was the only point of my comment. But, since the policy is for the editors and not the readers, I did not elaborate. It was just a suggestion. —  

TALK

20:56, 19 May 2011 (UTC)

It would be helpful if, sometime in the first week of July, someone would add the changes to this page from April 1 to July 1 to WP:Update/1/Enforcement policy changes, 2011, which is transcluded at WP:Update. - Dank (push to talk) 19:35, 12 June 2011 (UTC)

I added the two bigger changes now. How big the edit needs to be for WP:UPDATE? Does copyediting/clarifying also need to be included or is it only contextual changes? The page could use some introduction to what is expected. —  

TALK

19:53, 12 June 2011 (UTC)

I think it would make sense to keep the convention that quote marks tell you what was added or subtracted, and brackets are used to give context ... see any page from almost 3 years of updates for examples ... but as to which changes are important enough to report, that's really up to you. If someone disagrees with you, they can always change it. - Dank (push to talk) 20:02, 12 June 2011 (UTC)

Previous related thread: Wikipedia_talk:Bot_policy/Archive_23#Quarterly update

I want to encourage volunteers to help with the quarterly policy updates, and Hellknows has offered his summary of the April-June changes to this page at the link above. Does it reflect everyone's understanding of the changes? For instance, he includes "Unsupervised bot processes should not make context-sensitive changes", but doesn't include the new text about those bots being fine if "there is community consensus to run the task without supervision". The way I've avoided these kinds of problems in my policy summaries in the past has been just to quote the text without altering it, or just giving a link to new sections so that the readers can read the text for themselves and make their own interpretations. OTOH, if people who keep up with this page like the summary, I'm not claiming any veto power. - Dank (push to talk) 14:53, 4 July 2011 (UTC)

To be honest, I am still unclear on the amount of detail the page asks for. I didn't want to copy the whole section including exceptions and examples, but I also didn't want to just leave a link without any excerpt. I did leave ellipsis implying it has more text though :) —  

TALK

15:10, 4 July 2011 (UTC)

Thanks for adding the link to the archives, I couldn't find it. There's a good argument for your approach, it's just different than my approach, and it probably requires doing what I just did, which is to ask if there are any objections to that summary. Since your approach is different from mine, if people want to keep it, I'll probably add attribution to you for that part of the quarterly update, so people will know they're getting something less detailed and less dry than usual. - Dank (push to talk) 15:18, 4 July 2011 (UTC)

Clarified it a little further so no one blames me for monopolizing BOTPOL change summaries :) —  

TALK

16:15, 4 July 2011 (UTC)

Much better I think ... it does a better job of saying what it leaves out, and the summary is good. - Dank (push to talk) 16:31, 4 July 2011 (UTC)

Where exactly is this summary available? (I'm assuming it's available to everyone?) I've been reading through the old Bot Policy Archives and this is the first I've heard of a summary/quarterly update, which would be very helpful. Thank you in advance for the information. UOJComm (talk) 19:48, 2 December 2011 (UTC)

As per

06:48, 11 October 2011 (UTC)

Another BAG nomination

Please see

communicate

23:33, 11 October 2011 (UTC)

WP:MEATBOT

pointless as unenforceable?

See [1] etc.

) 04:34, 26 October 2011 (UTC)

That hardly has to do with

books

} 07:49, 26 October 2011 (UTC)

WP:MEATBOT points out that it really doesn't matter if it's a poorly-written bot or a human failing the Turing test. The whole mess with Δ is unrelated; everyone knows what Δ is doing, and it's just enablers (and a few trolls) on the one hand arguing with the community that sanctioned Δ in the first place on the other over whether Δ should still be sanctioned. Anomie⚔

11:12, 26 October 2011 (UTC)

Unenforceable doesn't mean we should get rid of it. And I agree with Anomie, this has nothing to do with Δ specifically. One case does not determine the usefulness of a policy point (which is exactly what

TALK

11:18, 26 October 2011 (UTC)

Missing all of 2007 in the archives?!?

I am currently reading through all of the archived talk:Bot policy discussions, and between Archive 18 and Archive 19 is about a 1.5 year jump in time (including skipping completely over 2007), so I'm wondering if anyone has information on where discussions from that year were archived? Thank you in advance...UOJComm (talk) 17:54, 28 November 2011 (UTC)

There was an error in the archive numbering system. I think I just fixed it. ΔT _{^{The only constant}} 18:27, 28 November 2011 (UTC)

Cool, thanks. Can you tell me what you changed though, so I can go back and read the archive that I missed? It looks like 19 and 20 may still be out of order?!? I don't want to change anything if you (or someone else) is maintaining this page, though I'd love to talk with you more if you are the person maintaining it. Thanks again...UOJComm (talk) 18:26, 30 November 2011 (UTC)

Some things are better forgotten. Sometimes I think Wikipedia talk pages are in that set. Rich Farmbrough, 22:13, 8 December 2011 (UTC).

It should say why Editors that use bots should create more than one account. Pdiddyjr (talk) 20:35, 10 December 2011 (UTC)

It does... Wikipedia:Bot policy#Bot accounts Rock drum _Ba-dum^Crash 18:43, 11 December 2011 (UTC)

Greetings-

I am a graduate student at the University of Oregon, currently collecting data for my dissertation on Wikipedia editors who create and use bots and assisted editing tools, as well as editors involved in the initial and/or ongoing creation of bot policies on Wikipedia. I am looking for members of the bot community to interview regarding their experiences on Wikipedia and opinions of technical and governance issues on the site. The interview can be conducted in a manner convenient for you (via an IM client, email, Skype, telephone, or even in-person) and should take approximately 30-45 minutes.

Your participation will help online communication researchers like me to better understand the collaborations, challenges, and purposeful work of Wikipedia editors and programmers like you.

My dissertation project has been approved both by the Review Board (IRB) at the University of Oregon, and by the Research Committee at the Wikimedia Foundation. You can find more information on the project on my meta page.

If you would like to participate or have any questions, please contact me directly via email or by leaving a message on my talk page. Thank you in advance for your interest.

Randall Livingstone

UOJComm (talk) 04:38, 5 January 2012 )UTC)

Hello everyone. I am still looking for users from the bot community to interview regarding their experiences on the site. If you are interested, please leave a message on my talk page or email me. Thank you to those who have already participated! Randall UOJComm (talk) 23:12, 12 January 2012 (UTC)

I reorganized and expanded the "Requests for approval" section, so that is explains and reflects the BRFA process more closely. It seemed like the section is very outdated and not on par with what BAG does during the BRFAs. Besides copyediting, I added several things to it, and since this is a policy page I feel I should mention them in case I borked something up:

• "The bot operator is responsible for reviewing the edits and repairing any mistakes caused by the bot" -- this is already mentioned under #Bot accounts, but I feel like reiterating that the bot operator is expected to fix the mistakes, not the BAG is essential. In a couple recent BRFAs, no mistakes were fixed until pointed out by BAG and even then it took a while.

• Once the request has demonstrated its conformance with the community standards and correct technical implementation, the BAG may approve the task. The BAG may also decline a request which fails to demonstrate community consensus to perform the task. -- this wasn't spelled out explicitly, so I think a clear mention that BAG can a) approve b) decline based on BOTPOL should be there. It's the common sense WP:BURO stuff, but it would be easier if we can link to it from BRFAs as it occasionally comes up in one way or another.

• "The BAG may also occasionally speedily approve or decline BRFAs without having a trial period. -- basically, it had no mention of speedy approve/decline process, so I added a paragraph with a couple common examples when it happens.

The rest is just wording and organizing into paragraphs that make chronological sense (BRFA, trial, discussion, approval, speedies, testing, modification). —  

12:21, 14 February 2012 (UTC)

Just a brain fart. I have w:User:LiWa3 since some months parsing 'parsed diffs' - and based on that, I was starting to think through the problem of the often occurring problems with 'cosmetic changes' - would it be an idea to have functions which:

1. get the parsed outcome of the old revid
2. get the parsed outcome of the edit-to-be-saved

And do a (maybe smart) diff on those? If those two are the same, the edit was, by definition, cosmetic to the code, not to the displayed outcome, and hence should not be saved. It may need some tweaking, and I see some common pitfalls ('metoo' -> 'me too' is not cosmetic, though only changes whitespace), but it may be able to help. --Dirk Beetstra ^{T C} 05:47, 26 March 2012 (UTC)

That'd seem easy enough, with the functions that the API provides, but it'd be up to bot operators to choose to write that code, not for the bot policy to mandate, for the very reasons you mention. Cheers, — madman 18:22, 26 March 2012 (UTC)

Policy could at least suggest to use that trick (it is not obligatory, but so bot-owners are fully aware it exists and can be done, and when they do not use it, and do save too many of edits which do not change the parsed outcome, they would be violating this policy) and we could discuss whether policy should even state that if a diff on the two parsed revids of a page is not changed in any form except useless whitespace, that that is for sure a cosmetic change, and that such edits should certainly not be done (those for sure are cosmetic; there are other cosmetic edits which do result in slight changes in the parsed outcome, but not really in the display of the text). --Dirk Beetstra ^{T C} 05:27, 27 March 2012 (UTC)

It is a rather inefficient method though, requiring two more calls. Any decent programmer can easily keep track of what changes they are making and not even attempt to save the page. The problem is really with those using tools like AWB, where they don't have full control. But AWB and such don't have this option, and probably won't, because again -- two additional calls. —  HELLKNOWZ  ▎TALK 08:55, 27 March 2012 (UTC)

I've been pondering this, and I'm not convinced by the two additional calls argument. Sure, it's expensive, but it's not that expensive. Certainly, recent advice from Tim Starling has said as long as you're not spawning lots of threads at the same time, he's happy you're not going to affect site performance. So in AWB, for example, two calls at the same time even would be fine. Okay, so the process might take a second or two per page, but AWB bots would still be limited more by rate (8 epm or whatever) than that. - Jarry1250 ^{[Deliberation needed]} 09:57, 27 March 2012 (UTC)

So do we want this to be required of bots or optional? —  HELLKNOWZ  ▎TALK 10:26, 27 March 2012 (UTC)

Optional, but advisable if running a bot on AWB that's using genfixes, etc. I should say - Jarry1250 ^{[Deliberation needed]} 10:50, 27 March 2012 (UTC)

What if AWB refused to do it unless a) there was a link to a BRfA in the edit summary; or b) the user manually approved it? Josh Parris 11:18, 27 March 2012 (UTC)

Currently it's a checkbox, and BAG could ask for it to be kept checked at all times on specific BRFAs. - Jarry1250 ^{[Deliberation needed]} 12:51, 27 March 2012 (UTC)

So how would AWB know which BRFAs require what? Would there be a special list for this? Besides, it takes literally a couple minutes to disable/enable the checkbox in source code. —  HELLKNOWZ  ▎TALK 12:55, 27 March 2012 (UTC)

The checkbox merely removes the "not preventable" defence. Otherwise, we have to trust bot operators, we can't operate like the stasi. - Jarry1250 ^{[Deliberation needed]} 13:01, 27 March 2012 (UTC)

Oh, I see, you meant generally AWB shouldn't allow bot edits without edit summary checks? Well, I guess it's a question of trust. I don't think botops will like being patronised on a topic that hasn't really been an issue in the past. Bad edits are more the problem. - Jarry1250 ^{[Deliberation needed]} 13:01, 27 March 2012 (UTC)

(ec)I would consider to be a bit smarter than this, though. You have the start situation and the end situation in Wikicode, if both are stripped of code and whitespace and they are then not the same, it is unlikely a whitespace only edit, if it is not, it is worth to get the parsed revid of the current save, and pull your current page through the parser and check again. It is merely a thought, but maybe worth considering for some bots - we know we have bots/systems that are likely to do whitespace edits if not carefully checked, for that it might be a good thing, and it is an often returning point of contention on those who do A LOT of AWB edits or other automated edits (I've seen this come up in Rich Farmbrough discussions, Δ discussions, and it is even part of our policy that one should not do it. --Dirk Beetstra ^{T C} 12:59, 27 March 2012 (UTC)

after ec @ Hellknowz: we could make it a tickable option in AWB. If someone runs it without, and does quite some whitespace edits, they can be told to either turn it on from then, or stop the task altogether. If they continue (and it is easy to test it whether an edit with the box ticked would have tripped the whitespace-block of AWB) then that might call for .. continuation of a discussion regarding whitespace edits by said user. --Dirk Beetstra ^{T C} 12:59, 27 March 2012 (UTC)

Just to confirm, "Skip if only cosmetic changes" *is* now a

bleeding edge feature of AWB, based on action=parse as you described above. - Jarry1250 ^{[Deliberation needed}

] 13:03, 27 March 2012 (UTC)

OK (/me does not use AWB anymore - but might consider to do this on his bots where needed, and further shuts up). --Dirk Beetstra ^{T C} 13:04, 27 March 2012 (UTC)

Nah, I wasn't expecting you to know that, I only added it yesterday :) Thanks for the idea! - Jarry1250 ^{[Deliberation needed]} 13:05, 27 March 2012 (UTC)

Heh. So brilliant minds think alike .. :-). --Dirk Beetstra ^{T C} 13:11, 27 March 2012 (UTC)

I may be mistaken, but I thought that there used to be a section in the bot policy regarding bots that did not require approval. I ask because my understanding was that automated tasks which do not affect content at all (say, notifying users of things, on their talk page) did not require the approval of BAG. Has that changed, or am I simply misremembering things?
— V = IR (Talk • Contribs) 19:18, 12 April 2012 (UTC)

Neither: it still is there. But it has gotten moved from the end of the first paragraph under WP:Bot policy#Requests for approval to the sixth paragraph in that section. Anomie⚔ 20:13, 12 April 2012 (UTC)

Ah, thanks!
— V = IR (Talk • Contribs) 21:24, 12 April 2012 (UTC)

Note that per that paragraph, notifying users of things does require approval, unless the bot is ostensibly only notifying itself or its operator. — madman 23:51, 12 April 2012 (UTC)

Good catch. AnomieBOT notifies "itself" of stuff all the time, so I missed that interpretation. Anomie⚔ 10:40, 13 April 2012 (UTC)

(discussion moved from Wikipedia talk:Bot Approvals Group)

I'm floating a suggestion that we stop approving interwiki bots; no new interwiki bots. Toolserver is developing a single centrally maintained and operated interwiki bot, and we seem to be having enormous difficulties finding competent operators; if interwiki links get screwed up, the problem cascades over many languages. I propose that interwiki links ought to be added manually, or in your native wiki.

Discuss. Josh Parris 12:23, 13 April 2012 (UTC)

(This should probably be at WT:BOTPOL.) The problem of bad interwikis will cascade over many wikis anyway, but the theory is an interesting one insofar as it could help to have software-based difficulties resolved singularly rather than on many different bots separately. Note, however, that the primary driver of the TS change is resources: and if bot operators put their own resources into the mix, it's difficult to say "no" (at least, saying "no" is not really the wiki way). Hence, I'm ambivalent on this one. - Jarry1250 ^{[Deliberation needed]} 13:03, 13 April 2012 (UTC)

In the somewhat longer term, there's also m:Wikidata which has centralizing the interwiki link system as its first goal. It's not clear how they intend to handle the non-one-to-one nature of interwiki links, though. Personally I don't see much point in having hundreds of bots all doing pieces of the same task; we should also consider de-approving all the existing interwiki bots once the central interwiki bot is active. Does someone want to compile a list of existing interwiki bots and notify their operators? Anomie⚔ 17:47, 13 April 2012 (UTC)

Yeah, although I doubt that a (productive) working wikidata system is available before 2013, this can/would solve many problems... Is it worth to discuss this problem (for getting a year of quietness)? mabdul 23:05, 13 April 2012 (UTC)

Please don't end a message with the command "Discuss." If you're looking for a discussion, it should be fairly obvious, or you're doing something wrong.

I agree with Jarry.

There are a lot of stupid bots around here (I even run a few). Examples: MiszaBot is a poor replacement for LiquidThreads; Cydebot is a poor replacement for proper category maintenance and management; EdwardsBot is a poor substitute for a bulk user talk page delivery system. But until there's a better system in place, I don't think restricting users' ability to run the bots makes any sense. The Toolserver can do what it wants because it's a free resource run by Wikimedia Deutschland the Toolserver roots. But I don't see a reason to extend its policy here. If people are causing actual damage with interwiki bots, that's a separate issue that should be resolved by blocking the bots and/or having them go through a better approval process. Once there's some magical interwiki system in place that can replace the current bot horror, I'm all for not having people use interwiki bots (though you probably won't need a ban if the old system simply stops existing ;-). --MZMcBride (talk) 03:46, 14 April 2012 (UTC)

I've never understood why there was more than one interwiki bot. I'm surprised there haven't been more incidents of them interfering with each other. More toolserver capacity will supposedly come online pretty soon, so maybe more bots can centralize there when that happens. I actually think people shouldn't run important bots on their own equipment for all sorts of reasons. 67.119.3.53 (talk) 16:04, 25 April 2012 (UTC)

This part in particular

Requests for approval All bots that make any logged actions (such as editing pages, uploading files or creating accounts) must be approved for each of these tasks before they may operate.

I got the distinct impression during the approval process that this needs some improvement. Penyulap ☏ 21:39, 3 Jun 2012 (UTC)

Can a wikilink be added to the mass-creation section please? Either linking "automated or semi-automated" to MEATBOT or shifting those words forward to the end of that sentence like "This applies whether the page creation is manual, automated or semi-automated" works.

It already makes clear large-scale creation tasks must be pre-approved with community input at least strongly encouraged, and further on clarifies it's irrelevant if semi/bot-like edits are executed manually every few seconds, be it Excel use, boilerplate templates with multiple browser tabs or whatever. So no change in policy is needed.

prev discussion links
• WT:Bot policy/Archive 24#Proposed minor change -- March 2010 clarity addition re human  • WT:Bot_policy/Archive_24#Clarification regarding high-speed human editing & redux -- Oct/Dec 2010 meatbot w/anchor diff added  • WT:Bot policy/Archive 24#Applying_botpol_to_human_edits -- Dec 2010 reaffirmation manual and semi/automated mass/high-speed editing substantively identical  • WT:Bot policy/Archive_24#Wikipedia:BOTPOL#Mass_article_creation (REVIVED) -- Mar 2011 mass creation policy re-examined & extended to all namespaces inc. categories diff // ‘Mass creation of pages in any namespace may be (unintentionally) disruptive, and should be discussed with the community first.’  • WT:Bot policy/Archive 25#WP:MEATBOT pointless as unenforceable? -- Oct 2011 brief reaffirmation its genesis was users claiming they made bot-like edits manually

Technically the page doesn't yet expressly use the term "meatbot" in that exact same paragraph; a user wondered if it needs amendment so really if a wikilink'll aid clarity let's add one. Thanks, 92.6.202.54 (talk) 21:08, 4 June 2012 (UTC).^{(friendly notice left at village pump)}

I've noticed that one of the logistical problems of BRFA can be when users have a bot that already has approved tasks, runs continuously, and then wants to add more tasks onto it. From there, BAG trials the bot's additional task, but because the bot's still running approved tasks, it can make it difficult for reviewing editors, BAG or not, to figure out just how well the bot's doing in its trial period for the additional task, and whether it's staying within its trial parameters.

I'm not sure what would be ideal here, but the first thing that came to mind was encouraging users who wish to add a new task to their existing bots to create a separate bot account and run trial edits from there, leaving the main bot to continue with its approved tasks. Another idea might be to use a special edit summary that's tagged by the edit filter. Alternatively, we could ask the operator to post a complete list of the edits the bot made that are directly related to the trial.

Thoughts? More ideas?

--slakr^\ talk / 03:18, 21 June 2012 (UTC)

I think recommending that all edits of multi-task bots have some form of "task identifier" is a good idea; for example, EarwigBot includes a task number in all of its edit summaries. For trials, you can put text like "([[WP:Bots/Requests for approval/MyBot 5|Bot Trial]])" in the summary, and we have a Toolserver tool that makes it very easy to search for those specific edits. I can't foresee any problems finding trial edits assuming operators use a distinct trial "marker", and I think it is unnecessarily complicated to require operators to make an account exclusively for bot trials. — The Earwig ^(talk) 04:30, 21 June 2012 (UTC)

Personally, I always do #3: if it's something where the trial will complete in a few minutes I'll stop all other bot tasks while running the trial and post a link to Special:Contributions, while if it's something that will take time I'll make sure the edit summary is somehow unique and then use a script I wrote that works much like the Toolserver tool The Earwig linked above. The only advantage I see to #2 is avoiding the need for the Toolserver tool; more interesting would be if the bot could directly apply the tag, but that would require changes to MediaWiki. Anomie⚔ 11:03, 21 June 2012 (UTC)

Indeed, I don't see any problem as long as unique edit summaries are used (which should be the case even once the task has been approved) and we have the Toolserver tool. On the other hand, I think multiple bot accounts would be unwieldy, for approval and for operation, and I don't think spreading out advanced permissions over more and more accounts would be a very good idea. — madman 15:30, 21 June 2012 (UTC)

Setting minthreadsleft to "0" makes for a very unwelcoming talk page. Perhaps that value should be changed to something else, 4 perhaps? __

) 07:06, 19 August 2012 (UTC)

I

) 07:12, 19 August 2012 (UTC)

It depends on what the bot is doing whether a "revert" is sensible or not. For example, a bot that is removing deleted categories should absolutely repeat its edit if a misguided editor reverts.

In your particular case, you appear to be edit warring with interwiki bots. These bots propagate human-entered interwiki mappings across the various languages of Wikipedia, and generally if you see something wrong that means some human somewhere made an error and the fix is going to be more involved than just reverting the bot locally. Anomie⚔ 07:56, 19 August 2012 (UTC)

But I don't accept the responsibility of having to sort out an issue on a foreign-language Wikipedia. If the interlanguage link there is wrong, fine. Besides, there can be other reasons for not wanting a particular interlanguage link reciprocate than it being in error, see for example

talk

) 14:26, 19 August 2012 (UTC)

Just because you don't accept the responsibility doesn't mean blindly reverting the bots and then complaining when they re-propagate the link is at all correct or useful. If you can't or don't want to do it yourself, bring it to the attention of someone who will fix it (i.e. the operator of one of the bots). Anomie⚔ 15:41, 19 August 2012 (UTC)

I want to be sure that I'm not stepping on anyone's toes here, so I want to confirm this before I start up with CHECKWIKI fixes or TypoScan. Rule #2 says don't edit so fast, but it seems subjective. I've since stopped until I can get a better answer. Previously, I've been told my speed was too high. Whether it be typos, general fixes, or assessments, I've been careful not to do any damage. My only 'oops' moment is following bad advice is assessing with the 'importance tag' on bio's, which just needed to be replaced to 'priority'. It was my mistake and I won't repeat it, and the errors were fixed right away. Should I be concerned of my edit speed alone, or should I wait 3-4 seconds between loading just to review a singular change and click 'save'. Typos are typos, updating categories (with AWB) for Birth/death is semi-automatic and fulfills a clear purpose and even then I can do 6 a minute and still be sure the changes are proper and not on some building or band.

I've also been told that anything above 3-4 a minute is a problem and with Lugnuts taking Waacstats to ANI over 'edit speed'[4] I just want to make sure not to run afoul of the 'rules'. It seems silly, but I like being efficient and forcefully lagging myself down is not very fun. One typo every 20 seconds, despite AWB loading the new page within 1-2 seconds of the last 'save'? Its 4-5x slower then what is easily possible. I'm not claiming to be super human or anything, but I can tell pretty easily if 'Mississsippi' needs to be fixed. It doesn't need 20, 10 or even 5 seconds to click 'save'. I just want to make sure this unspecified 'don't edit too fast' should apply when the changes being made aren't problematic, and usually involve the meaning of a single word or a simple change. ChrisGualtieri (talk) 03:50, 17 September 2012 (UTC)

The intent of restricting edit speed is a.) so as not to overload the servers, which isn't as much of a concern now that the maxlag parameter exists and is (I believe) used by AWB, and b.) if there might be any possible problem with the task, so it can be caught in time to stop and revert before too much damage is done. 3-4 edits a minute is a restriction, in my opinion, beyond the bot policy's remit. If you're making semi-automated edits, just make sure you're checking all of them and you're fine. That being said, AWB's restrictions may be more stringent than those of the bot policy so if your question is specific to them you should ask at

WT:AWB or the like. Cheers, — madman

04:34, 17 September 2012 (UTC)

I'll take it there then. The speed is 'subjective' there is no X per minute, though I agree with your reasoning. Interesting about the maxlag bit. ChrisGualtieri (talk) 06:20, 17 September 2012 (UTC)

I'll defer to madman's more studied reading of policy, but I don't think there is an issue under either the Bot Policy or AWB practice. The reasons for the restrictions including a desire to encourage people to use the bot flag for rote edits they might perform at high speeds on AWB, a caution to performing too many identical changes quickly, if it turns out there is an error in the change, a discouragement to editors performing unmonitored changes that may turn out wrong, and a general concern with people flooding RecentChanges. Since Chris is reviewing each edit and has made many tens of thousands of hand-reviewed edits with a shockingly low error rate or even complaint rate, I don't think he should feel any need to limit himself to an arbitrary threshold. MBisanz ^talk 07:04, 17 September 2012 (UTC)

Agreed. — madman 22:34, 17 September 2012 (UTC)

Although I generally agree with the comments above I would still encourage you to be careful. There are a lot of folks who will block first and ask questions later and in my experience there are more that are going to shoot for a lower number than a higher one.

talk

) 23:49, 17 September 2012 (UTC)

I'll see about proposing a change to the wording of rule #2 or perhaps I'll just boldly update it. ChrisGualtieri (talk) 14:19, 18 September 2012 (UTC)

Fine by me. Maybe it will cut down on the most active contributors being beaten up for stupid reasons.

talk

) 16:23, 18 September 2012 (UTC)

Regarding this edit and this revert, I must be missing something. What actions of either MediaWiki developers or Wikimedia sysadmins might possibly be confused for BAG actions or might be thought to be within the scope of this policy? Anomie⚔ 18:49, 2 October 2012 (UTC)

Well, none of "us" find it confusing. Frankly, I'm not sure we even need that sentence. I always assumed this is a clarification for someone totally unfamiliar with any of the technical stuff and for someone who would bunch up all the "coding" and "developer" stuff into the same category. This sentence has been there forever, so I assume there was some sort of silent consensus for it. Sysop is different to developer, so may be mention both if we need to? Although, looking closer, I prefer to remove it altogether. —  HELLKNOWZ  ▎TALK 19:03, 2 October 2012 (UTC)

I thought that meant developers (really sysadmins) could shut down a bot outside of BAG's approval if they wanted to. But I think that's addressed better in

WP:BOTREQUIRE. LegoK^ontribsT^alk

M 20:23, 2 October 2012 (UTC)

Developers can't shutdown specific bots unless they hardcode it, much like Microsoft can't disable my Minesweeper unless they hardcode my serial number or something. That's sysadmins. —  HELLKNOWZ  ▎TALK 20:26, 2 October 2012 (UTC)

Sysadmins, on the other hand, can block the bot's IP address at the firewall or add it to the user agent blacklist. Anomie⚔ 20:33, 2 October 2012 (UTC)

(edit conflict) Did a little history searching. It appears that something reasonably close to the current sentence was added in January 2008, mutated from "This policy does not cover server-side scripts run by developers". Which makes sense, but happens so infrequently it's negligible. If we keep anything, perhaps something closer to that: "This policy does not cover office actions, edits made by installed MediaWiki extensions, or edits made by server maintenance scripts run by Wikimedia system administrators." But even that seems a bit close to stating the obvious, and IMO the user page requirements should still be followed for whatever account the extension or maintenance script uses (e.g. see User:Translation Notification Bot). Anomie⚔ 20:33, 2 October 2012 (UTC)

I am not sure that the exemption is, or should be, valid anyway. Sysadmins do not have carte-blanche. Rich Farmbrough, 22:08, 15 October 2012 (UTC).

I am currently applying to be a member of BAG and input is greatly appreciated.—

13:31, 2 January 2013 (UTC)

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)

Per

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)

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)

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)

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)

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.

talk

) 20:24, 21 January 2013 (UTC)

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)

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)

(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)

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.

talk

) 21:31, 21 January 2013 (UTC)

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)

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.

talk

) 19:12, 23 January 2013 (UTC)

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

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:An#Blocking_misbehaving_bots

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

Here you go:

• Wikipedia:Arbitration/Requests/Case/Rich Farmbrough#Misuse of administrative tools
• talk
  ) 00:20, 22 January 2013 (UTC)

• 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)

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)

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)

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)

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

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

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)

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)

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)

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)

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)

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.

talk

) 19:21, 23 January 2013 (UTC)

Also, I'd suggest advertising this discussion at

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)

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)

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)

• 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)

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)

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)

I had a few questions regarding the section "Cosmetic changes." Would

15:02, 10 February 2013 (UTC)

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)

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)

It also helps to notify the bot owner. I too don't see any issues. If someone vandalizes the page and my bot tags the page with the padlock afterwards, just revert the edits, including the bot's, and Cyberbot II will un/retag the page as necessary. I did omit it from marking edits as automatically accepted with a preceding pending edit for a reason.—

^Chat

_Offline 23:46, 13 March 2013 (UTC)

After no response to

21:58, 20 June 2013 (UTC)

And unblocked. Apparently if the user's ISP uses 10.0.0.0/8 internally and their proxy exposes this in

XFF, the block will apply based on that. Ugh. Anomie⚔

21:46, 24 June 2013 (UTC)

Module sandbox

It might be an idea to add that bots can also play in their user's 'subpages' of Module:Sandbox without a flag as well as their userspace and the regular sandbox, since you can't experiment with Lua anywhere else. I've got a tool that needs to upload a bunch of generated Lua tables and I'm going to go ahead and be bold and interpret that as the spirit of the policy. KleptomaniacViolet (talk) 16:05, 1 October 2013 (UTC)

I agree with you that is definitely the spirit of the policy. Legoktm (talk) 16:33, 1 October 2013 (UTC)

Pretty much agree as well, policy predates modules. —  HELLKNOWZ  ▎TALK 16:35, 1 October 2013 (UTC)

Now that m:MassMessage is available, having bots that deliver newsletters would seem to be unnecessary. So we should decide what to do regarding approval and usage of newsletter bots. I see a few general options:

1. Do nothing, continue to approve new newsletter bots if they're requested and let people use whichever method they prefer to deliver newsletters.
2. Deprecate newsletter bots slowly by not approving new ones and discouraging existing ones from taking on new tasks.
3. Deprecate newsletter bots quickly by setting a deadline for everyone to switch to MassMessage and then prohibiting newsletter bots, including existing ones, after it passes.

Personally, I would be in favor of option 2. Mr.Z-man 15:25, 20 November 2013 (UTC)

• #3 unless there is good reason not to or the bot does something the system can't (e.g. individually customized messages or delivery to pages the system can't). Each bot is a separate liability and a black box that cannot be centrally modified, so an extension seems preferable to individual approvals. —  HELLKNOWZ  ▎TALK 15:45, 20 November 2013 (UTC)
  • MassMessage should be able to replace all newsletter bots, and if not, bugs should be filed so that it can. Legoktm (talk) 17:31, 20 November 2013 (UTC)
• I'd go with #3. We need to tweak the userrights so that its not just limited to admins, but I'll start a thread on
  WP:VPR for that. Legoktm (talk
  ) 17:31, 20 November 2013 (UTC)
  • Wikipedia:Village_pump_(proposals)#Create_new_user_group_for_m:MassMessage. Legoktm (talk) 17:49, 20 November 2013 (UTC)
• Number 3 looks good, but I suspect there'll be weird edge cases that existing bots handle. We should encourage retirement while being mindful of whatever missing functionality there is. Josh Parris 02:42, 21 November 2013 (UTC)

Wikipedia:Bots/Requests for approval/BracketBot 2 is a request to permit the bot to use our new Thank feature; in filing the request, the operator has basically said "The rules don't require approval, but that means we need to update the rules, not run thank-bots freely". This makes me think of Wikipedia:Bots/Requests for approval/Joe's Null Bot, in which the operator got permission for something that perhaps could have been done without approval because it's not logged and wouldn't be noticed. Can we add something saying basically "Bots need approval for non-logged actions as well"? Nyttend (talk) 18:12, 31 May 2013 (UTC)

Well technically they don't, and if its not logged anywhere we really can't check either. Using the "Thanks" feature is logged, so it *does* require approval. On the other hand, Joe's Null Bot uses the apihighlimits user right, which comes with the bot flag, so he would need a request for approval to get the flag. Whether he needs to file subsequent approvals is really up for interpretation. I personally have my bot run mass-purge's over categories every so often and never bothered with filing for approval. It would really just be a waste of time for everyone involved IMO. Legoktm (talk) 19:56, 31 May 2013 (UTC)

I feel Legoktm has summed it up rather well. I was about to talk to Joe about his many requests for effectively the same thing as when they pop up I am simply speedily approving them. ·addshore· ^{talk to me!} 08:29, 1 June 2013 (UTC)

I'd say that anything causing "write activity" needs approval: that would include anything visible on-wiki, and stuff like action=emailuser, null edits, and purges. True, we can't really detect null edits or purges, but remember how someone on Commons started purging millions of pages without any sort of approval, and attracted the attention of the sysadmins, which led to action=purge being disabled on Commons for a time. Seeking approval would hopefully have told him that that was a bad idea. And we can't really detect emailuser until people complain, at which point the malefactor will be blocked. Again, approval at least would give a chance for more technically-oriented people to point out bad ideas. Anomie⚔ 23:19, 1 June 2013 (UTC)

Agree with Anomie's reasoning. Upshot?--Elvey (talk) 18:59, 11 December 2013 (UTC)

You must support your bots; you must make a reasonable attempt to respond to support requests from editors; operators who tend to ignore unanswered queries on the bot's talk page that merit a response should expect their bot to be blocked. This is already policy;

) 19:16, 11 December 2013 (UTC)

I'm not quite sure what you're asking here. Bots operators are expect to be civil to the extent that all Wikipedians expected to be civil. Answering support requests has little to do with civility, and "support" range from making behaviour tweaks to adding new features, etc... If a certain bot op doesn't want to add a feature to a bot, they certainly aren't required to. Bot ops are volunteers, and no one can ask for more time than they are willing to give. Bots need to operate under consensus, yes, but civility and consensus are two different issues.

books

} 19:30, 11 December 2013 (UTC)

See also

books

} 19:32, 11 December 2013 (UTC)

Common genfixes

I think that having a common set of approved and tested genfixes for all bots and software will leverage automation efforts; every time some specific problem is fixed on a page by a bot, all the generic fixes would also be applied. The genfixes would need thorough planning and testing, and be implemented in a way that can be accessed universally. The planning and testing I'll put to one side.

Universal access basically means an interface written in C (for example, PHP can call a C interface), but as we have no parser in C that I'm aware of (I believe one's being written in C++ for Cluebot), I suggest we go with the only wikitext parser that's available: mwparserfromhell. There are mechanisms to call Python from C. So I propose a thin C wrapper around a Python core, with genfixes implemented in Python. I'd suggest a simple interface: pass a chunk of wikitext, get a chunk of genfixed wikitext back.

Perhaps as a first goal the genfixes from AWB could be implemented. Josh Parris 10:34, 17 December 2013 (UTC)

FYI, I for one wouldn't use this C library with a Python core in my Perl bot. I also worry that, no matter how foolproof you try to make it, fools will still wind up turning what would have been a null edit into a genfixes-only edit just as they sometimes do now with AWB.

From a personal perspective, I'm not particularly fond of genfixes in general as they sometimes make it hard to see what real change the bot might have made to the page in the midst of all the "fixes". Anomie⚔ 12:04, 17 December 2013 (UTC)

Hmmmm, if the function replaces whatever library save you have (i.e. SaveWithGenfixes) and you're required to pass in the SHA-1 returned by rvprop when you got the text, the SHA-1 could be recalculated prior to applying genfixes to ensure something had happened prior to being passed to SaveWithGenfixes. Of course, that assumes that the user of the function isn't maliciously changing the SHA-1 and submitting unchanged text. Josh Parris 00:21, 18 December 2013 (UTC)

The reason I dislike genfixes is because they muddy up the actual bot edit to the page. Secondly, there is no clear line between what is a genfix okay to be done en masse by bot and what isn't. A lot of current genfixes are just style and syntax that not necessarily have consensus to be done by bot. Finally, it's a lot to assume about how a particular bot actually works and what can and cannot be passed to a black box genfix plugin. Not to mention having 2 different languages in potentially another language (personally, I wouldn't ever use a system like this). I'm not sure AWB guys would implement this, and they are the predominant bot users. This all could theoretically be solved with a lot of work and I somehow doubt that will happen. And how would updates be applied? I also really doubt the readiness of most bot operators to follow and promptly update their bots (as pywiki interwiki bots have shown). —  HELLKNOWZ  ▎TALK 13:01, 17 December 2013 (UTC)

As to what genfixes are okay and what aren't, that'd be up to the BAG.

Updates would be handled by the genfixes black-box automatically downloading updates to itself, much in the way Firefox or Chrome do. The whole thing would be owned and managed by the BAG, and presumably hosted on labs.

@Magioladitis:, @Reedy:, @Rjwilmsi: what is viability and attractiveness for AWB? Josh Parris 00:21, 18 December 2013 (UTC)

There's a common objection about meaningful changes being obscured by genfixes. I don't know what to do about that. I guess making genfixes configurable (all the way down to "none of the above") might be a way around that.

There's another common objection: mixed languages are scary. Sure, if you are responsible for the genfixes part of the bot. But all the development for that will be handled by "someone else"; as an operator, all you'd do is install the bootloader version and it'd handle the rest. From that point on, you'd code in the language of your choice and the common genfixes would look after itself; it would be a true black box.

I guess alternatively, genfixes could be implemented as a webservice, where bots send their changes to the webservice, and the webservice returns genfixed changes. Again, the functionality would need oversight by BAG. Josh Parris 00:21, 18 December 2013 (UTC)

I worked a lot on this direction by myself. There is still inconsistencies between automated tools (AWB, AutoEd, WPCleaner, etc.) which I am trying to spot, notify the programmers and get them update their code. I think that agreeing in a minimum part of changes that all bots will do in addition to a main task is possible but, I guess, it will require rewriting the same set of code in various languages to suit the various existing bots. -- Magioladitis (talk) 07:09, 18 December 2013 (UTC)

There's a fundamental decision here as to whether it is desirable for bots to carry out their change plus genfixes in the same edit or not. There are arguments for and against. This is a policy matter, personally I don't see the likelyhood of getting a clear decision either way.

As to whether there could be a standard set of genfixes available to all bots: bots work in different languages, so I can't see a single solution that would work for all bots, and I don't think it's reasonable to mandate that all bots have to be able to call a perl/C/webservice module. And as a bot operator should you be required to provide support/explanations to editors who query the genfixes part of your bot's edits? Using this standard genfixes would surely have to be optional. In terms of translating the AWB genfixes, we make heavy use of specific C# language features (nested bracket regex matching, MatchEvaluator, Dictionary, HashSet) that I think may be difficult to directly reimplement in another OO language such as Java, probably very difficult to translate into procedural langauge such as Perl. Things would have to be re-written from scratch, would a procedural language support unit tests? You're talking about re-writing about 5 years' cumulative effort there. Of course it can be done but I think the effort would be very high. Others are of course welcome to do so, AWB's code is GPL so please use it within the terms of that licence, but it's not something I would see myself working on. Rjwilmsi 09:03, 18 December 2013 (UTC)

I have been nominated for BAG membership. Input is invited. The request can be found at

14:23, 22 December 2013 (UTC)

Per

) 06:35, 8 June 2014 (UTC)

Archiving of this page

2RR is enough for me, I'll leave this to other editors to check in to now. For some reason Headbomb feels that multiple comments left here by IZAK cross-posting another discussion should be deleted rather then archived. We are obviously in conflict so I would welcome anyone else to decide if the archive should be restored or left deleted. Thanks, — xaosflux ^Talk 02:49, 13 August 2014 (UTC)

Why should comments irrelevant to bot policy be archived? See

books

} 02:54, 13 August 2014 (UTC)

@Xaosflux and Headbomb: I agree with Headbomb on this. The multiple comments left were off-topic. I would like to be able to search and read archives. This would not be possible if they were full of irrelevant topic. Thanks, Magioladitis (talk) 11:34, 13 August 2014 (UTC)

I'm currently coding a thing that you can put on your skin.js that automatically archives your talk page for a certain interval you choose using a GUI. I'm pretty sure it's a script, but just in case it's considered a bot I'm asking here. -

09:32, 5 August 2015 (UTC)

Wait- now that I re-read this, I feel really stupid for posting this. It's obviously a script since it only affects your talk page and doesn't change any pages other than that... -

usagi

09:33, 5 August 2015 (UTC)

COSMETICBOT currently says "Cosmetic changes (such as many of the AWB general fixes) should only be applied when there is a substantial change to make at the same time."

I believe that the word "substantial" should be changed to "substantive". I think the latter is was what was meant. "Substantial" means "of considerable size" or "large", while "substantive" means "meaningful" or "important" (i.e. not trivial).

I have changed the wording. Feel free to revert me if the original intent was that only "large" changes should be made with bots. – Jonesey95 (talk) 17:55, 24 October 2015 (UTC)

Seems reasonable to me. — Earwig ^talk 19:56, 24 October 2015 (UTC)

The last element of the list of example changes starts with "Changing

) 19:48, 7 December 2015 (UTC)

That's just an example, for cases like changing & to & -- a task too minor and visually indistinguishable and so afoul of superfluous edits if done by itself. Your change/example would also work the other way for other characters, but the former is way more commonly seen and proposed for bot tasks than the latter, so that's the example. —  HELLKNOWZ  ▎TALK 20:15, 7 December 2015 (UTC)

As is required by the BAG membership procedure I am placing this notification at

^{Need help? {{ping|HighInBC}}} 20:24, 2 July 2016 (UTC)

Clarification on updating approved bots

1. After a bot account is created and approved to automate a task, what is the protocol for running modified or completely new functions?
2. If one builds a suite of automated but unrelated tasks, can the bot perform all tasks at once, as long as all tasks have been approved?
3. Is it allowable to request approval for multiple unrelated tasks in one request, or should they be split into multiple requests?
4. Is there ever a reason why one user would need to create multiple bot accounts?--
   talk
   ) 04:07, 21 August 2016 (UTC)

1. Any significant modification of task, or addition of new task will require a new BRFA to be submitted.
2. It depends, using meaningful edit summaries is important - if there are multiple different kinds of changes happening in the same instantaneous edit this can get tricky.
3. It depends, mostly on how unrelated and how wide in scope. (e.g. "Replace infobox-xxx and portal link-y" in one BRFA is likely OK - "rollback vandals and convert citations to wikidata" would not be.
4. Yes, say they need different flags, or just because the operator or community thiks the edits and logs should be different. — xaosflux ^Talk 13:19, 21 August 2016 (UTC)

Thanks for responding to my questions. It seems like discretion and common sense are the driving forces here, and that's what makes Wikipedia great.--Joel Amos (talk) 16:28, 21 August 2016 (UTC)

Are there any bots running with the ability to delete an article without direct human intervention? Are there any bots running with the ability to delete an article, without placing a deletion tag or it and having it run the ordinary deletion process? In this connection, I point out that though administratorsdo havethe power to delete single=handed, they normally use this only for obvious vandalism or copyvio or straightforward technical deletions. it is very rare nowadays that any admin would themselves delte under most deletion reasons. DGG ( talk ) 01:43, 14 October 2016 (UTC)

@DGG: technically These 6 bots have deletion access. These bots are all operated by administrators. — xaosflux ^Talk 03:03, 14 October 2016 (UTC)

I have noticed that the Python code sample for bot exclusion given at Template:Bots is inaccurate: in the presence of {{bots|deny=foo}}, a robot named bar would be denied access, because of the last return False statement. I have changed this line to return True, but I would be glad to have a confirmation by a more experienced editor. (This problem had already been spotted by another editor.) − Pintoch (talk) 21:13, 26 October 2016 (UTC)

If you really want to test your code, I while back put together a series of tests at User:AnomieBOT/nobots_tests. Anomie⚔ 02:00, 27 October 2016 (UTC)

Hello! I have offered to help with the

00:55, 9 December 2016 (UTC)

(another) Request for BAG membership

Activity requirements

I purpose we change "many AWB genfixes" to "some". Unless we give specific examples of map them all. Also it's a question why to choose AWB since there are many tools that do various things in Wikipedia. -- Magioladitis (talk) 20:50, 14 January 2017 (UTC)

I suppose a good first step would be to enumerate all the AWB genfixes and identify which are "cosmetic" by the various definitions (e.g. no visible change, no change detectable in browsers or screen readers, no change to the HTML). Then we can argue over how many make "many" versus "some". Anomie⚔ 23:09, 15 January 2017 (UTC)

Anomie, when you reverted Magio's addition of a tag, you inadvertently restored the change he had made earlier—from many to some—so I've restored many. Posting here to clarify that in case my edit was confusing. SarahSV ^(talk) 02:07, 20 January 2017 (UTC)

I had intentionally reverted to "some", since neither word is really quantifiable and we don't have any analysis of which general fixes are cosmetic. What really bugged me was the burgeoning war with the addition of {{

cn}} into the policy instead of discussing things on the talk page. Anomie⚔

12:25, 20 January 2017 (UTC)

Probably it's time to open an RfC for this. -- Magioladitis (talk)

RfC about cosmetic changes

I purpose we change "many AWB genfixes" to "some" based on

) 01:45, 20 January 2017 (UTC)

• Comment.
  AWB general fixes) should be applied only when there is a substantive change to make at the same time." SarahSV ^(talk)
  02:02, 20 January 2017 (UTC)
  • SarahSV yes because only very few are related to the old python script which now is outdated. -- Magioladitis (talk) 06:56, 20 January 2017 (UTC)
• [
  which?] Neither one of these terms gives actionable information to editors to know which genfixes are or are not covered - calling it "some" vs "most" doesn't clarify anything. — xaosflux ^Talk
  05:00, 20 January 2017 (UTC)
  • Xaosflux I guess you are right. Perhaps the entire sentence in parentheses does not have a place in a policy pages then? -- Magioladitis (talk) 06:59, 20 January 2017 (UTC)
  • It does not matter which particular AWB checkboxes are used; what matters is the content of the edit. "Cosmetic changes should be applied only when there is a substantive change to make at the same time." has strong community consensus. Moreover, AWB operators who enable general fixes must ensure that edits are only saved if more substantive changes are also made. — Carl (
    CBM · talk
    ) 12:12, 20 January 2017 (UTC)
• Oppose. Looking through the AWB general fixes, a great number of them are cosmetic-only. I would support a separate proposal (after the relevant discussions elsewhere are closed, so as not to be doing 20 things at once) to specifically enumerate the following AWB general fixes as cosmetic-only: TemplateRedirects, FixSyntax*, SimplifyLinks, FixCitationTemplates*, FixSyntaxRedirects, FixCategories, SimplifyReferenceTags, FixImages, FixLinkWhitespace*, RemoveEmptyComments. This is not necessarily an exhaustive list, nor can it ever be, as AWB is in constant active development. It at least provides more flavor to what's cosmetic, though. Most of these fixes are wholly cosmetic. The fixes with *s are partially cosmetic, but do contain some non-cosmetic tasks within them (which would need to be explained at least somewhat in a note). ~ Rob₁₃^Talk 07:11, 20 January 2017 (UTC)
  • BU Rob13 RemoveEmptyComments is not a general fix. FixSyntaxRedirects fixes actual errors. Please read before commenting -- Magioladitis (talk) 07:16, 20 January 2017 (UTC)
    • RemoveEmptyComments is still listed on the general fixes page and states that it's not currently a general fix but can be called, so I listed it. The "Removes carriage inside redirects." of FixSyntaxRedirects is not clear to me, but the "Removes unnecessary namespace (e.g. Template:)." is clearly cosmetic if all it's doing is removing something that's unnecessary but not harmful. That's what led me to include it. It's not terribly clear either, though, so possibly I'm misunderstanding. ~ Rob₁₃^Talk 07:18, 20 January 2017 (UTC)
    • Still no evidence why to prefer "many" in favour of "few". -- Magioladitis (talk) 13:10, 20 January 2017 (UTC)
      • Or why 'few' would be preferred over 'many'.
        books
        } 14:14, 20 January 2017 (UTC)
      • Few means three. Please do count the sections worth of fixes that I listed, which each themselves contain many (sometimes as many as two dozen) individual fixes within them. ~ Rob₁₃^Talk 00:53, 21 January 2017 (UTC)
  • The issue is not which genfix module is used; the issue is always the content of the edit AWB operators are responsible for reviewing each edit and just not saving it if the edit is cosmetic. Of course, there are some genfixes which are purely cosmetic by nature, such as removing "Template" from template transclusions. Others may or may not be cosmetic, depending on the situation. it comes down to the AWB operators to review their edits. For bots, this means that the AWB operators need to ensure that trivial edits will not get through, which is part of the general planning and testing that goes into running a bot. The key is the actual edit made, not the software that was used to make it. — Carl (
    CBM · talk
    ) 12:07, 20 January 2017 (UTC)
• I don't see much distinction between "some" and "many"; either way, the point is that AWB operators need to be careful to avoid trivial edits. — Carl (
  CBM · talk
  ) 12:07, 20 January 2017 (UTC)
• Likewise, I don't see the distinction. If the intent is that 'some' is fewer than 'many', that still changes nothing about anything anywhere on Wikipedia.
  books
  } 12:28, 20 January 2017 (UTC)

  A more productive discussion would be identifying which AWB genfixes / Checkwiki fixes are cosmetic, and which aren't. But that's not a matter that needs to be addressed at the

  books

  } 12:37, 20 January 2017 (UTC)

• Like others have said, it doesn't matter if it says "some" or "many" when the actual issue seems to be which change in particular is or isn't cosmetic. Changing the note that was only meant to serve as an example is pointless and it should be removed if the exact number of items is such an issue. It is supposed to be the operator who verifies this and this note has never implied anything about specific fixes. —  HELLKNOWZ  ▎TALK 13:15, 20 January 2017 (UTC)

You are invited to comment at

16:03, 7 February 2017 (UTC)

Exclusion compliant

Would someone please add a section here (or at

) 04:31, 6 February 2017 (UTC)

You have the big picture - that pages, sections, even words - may be tagged by human editors in a way that asks automated editors to not edit there. This is the "exclusion request" and for the most part bots should respect this ask and be "exclusion compliant". In some cases there may be reasons to not be exclusion compliant - and if a bot wants be able to override this its task may need extra scrutiny. — xaosflux ^Talk 12:34, 6 February 2017 (UTC)

Given this is a policy page, we don't actually have any hard rules on what constitutes specific situations for exclusion compliance. {{bots}} is the most standard of them all, asking the bot to skip whatever page/section the template is on. But there aren't any hard rules on how to use it either (I've seen it added with summaries like "stop editing my article"). Depending on the task, the bots may interpret this differently (may be a category moving bot ignores it when it's on category's pages). It's not even clear if it applies to supervised or manual bot tasks. Some bots may keep their own list of pages they ignore on request. These details are generally part of the BRFA process, but mostly up to the bot operator judgement. If the bot isn't exclusion compliant, we usually ask "why?", but it's not exactly a requirement either. —  HELLKNOWZ  ▎TALK 13:29, 6 February 2017 (UTC)

Actually, I wasn't asking for a rule on when to use it or not to use it — I just want a project page to give an explanation of what exclusion compliance is. If BOTPOL isn't the best place to put such an explanation, I'd support putting it somewhere more relevant. Nyttend (talk) 23:20, 6 February 2017 (UTC)

WP:BOTS? Not sure. We don't really have any rules for exclusion compliance, more like general practice and BRFA-specific details. We could perhaps explain that. I'm not even sure how other BAGs review exclusion compliance or how much it matters for approval. —  HELLKNOWZ  ▎TALK

15:44, 10 February 2017 (UTC)

Changes to 'dealing with issues' section

I always found the guidance on dealing with issues to be deficient on this page, and the cause of some confusion in the community on exactly what should be done when dealing with problem bots. I've taken the liberty of revamping that section, mostly with common sense / common practice advice. See diff for the exact changes.

I don't believe these to be controversial changes in need of a formal RFC, but if people think it would be best, we can have one. Feedback and improved wordings are of course, welcomed.

} 16:10, 20 January 2017 (UTC)

A few comments:

• It is also strongly encouraged (and may be required by BAG) that community input be solicited at WP:Village pump (proposals) and/or the talk pages of any relevant WikiProjects. Why change it from "and" to "and/or"? In the past, people have complained that consensus for such things was only determined on some WikiProject's page without wider community input.
• For instance, a bot approved to archive discussions on a certain WikiProject's page does not need another BRFA to archive another project's page, so long as the WikiProject consents to have its discussions archived by that bot. seems like a poor example. It reminds me of a case where a bot was approved to create around 600 articles and the operator and associated WikiProject decided that meant they could create 15000 more without further approval, which turned into a big mess.
  In a case such as this, I'd advise the operator to instead file a new BRFA that could be speedily approved since it's a clear expansion of an existing task. There would also be nothing wrong with the expansion asking for approval to archive any WikiProject's page on request, instead of just adding a second explicitly-named project.
• Regarding the bit about unblocking your own bot, it's generally good IMO. I had thought "What about if there's a problem with one AnomieBOT task and someone blocks instead of using the task's shutoff page?", but then I realized it's easy enough to just use {{unblock}} to request another admin do it (if someone else doesn't beat me to it entirely).

Anomie⚔ 22:38, 20 January 2017 (UTC)

Good, comments, discussion!

• Re the first point on mass creation, I mostly felt BAG had discretion of mandating what input was needed on a case-by-case basis and reduce some
  WP:FUNGI
  and BRFA watchers. But I wouldn't in the case of biographies extracted from some database. If people aren't comfortable with this, or this is too much of a change without community input, I'm fine reverting to the previous wording.
• I didn't mean to be exhaustive with my example, just to illustrate what would be non-controversial. Feel free to add a second example, or replace mine.
• This is where
  WP:IAR
  comes into play. If it's uncontroversial, no one will care who did the unblock. It's just general advice, since self-unblocks have been controversial in the past. However, I think saying 'is often' was a bit too strong, so I've changed the wording to 'can be'. The updated page also now mentions all the other methods of stopping a bot (specific task disabling/bot page killswitch), with blocks as the hammer if nothing else worked.

books

} 22:52, 20 January 2017 (UTC)

I think the bit on admins unblocking their own bot does need an RfC - it is contentious in the community (many believe that admins should not be unblocking their own accounts for any reason) and this behaviour by some admins is currently part of the discussion of the Magio arbitration case. Hchc2009 (talk) 09:10, 21 January 2017 (UTC)

How was [5] against current consensus on the issue? Or is your objection purely procedural?

books

} 12:33, 21 January 2017 (UTC)

A bit of both. I don't think we have a clear consensus on this issue (some believe that unblocking your own account is always wrong, others don't - we haven't tested this through RfC), so the proposed wording doesn't feel right. I'd argue strongly that no admin should be unblocking their own bot account, for example - it is far more than just "frowned upon", it's an abuse of admin powers. In terms of process, attempting to change the policy halfway through an arbitration case on the issue feels like a bad decision. Hchc2009 (talk) 12:38, 21 January 2017 (UTC)

Well it wasn't an attempt at a change in policy more than it was documenting current practice, but let's wait till the dust settles and we can revisit this after. Kinda forgot about the ARBCOM case.

books

} 13:00, 21 January 2017 (UTC)

IMO the

WP:IAR can be claimed if the situation is clear enough. I think this edit weakened it a bit too much, but I also don't think Hchc2009's hardline position accurately reflects the prevailing consensus outside of overreaction to the Yobot situation. In particular, I note that Wikipedia:Blocking policy#Temporary circumstances blocks specifically mentions "Blocks of unapproved or malfunctioning bots should be undone once the bots gain approval or are repaired" without restriction against an admin-operator doing the unblocking of their own bot. Wikipedia:Blocking policy#Unblocking does say that unblocking yourself, which IMO includes your own alternative account, is "almost never" acceptable, but an unblock of your own truly repaired bot could easily be seen as falling under the "almost". The conflict over unblocks in the Yobot case largely seems to come down to repeated insufficiency of the repairs. The conflict over unblocks in Wikipedia:Arbitration/Requests/Case/Rich Farmbrough seems to have largely been due to the same thing (I note the FoF there was eventually vacated, although reading the arb discussion on the motion

I see a strong current of "Ugh, this makes no difference in the outcome so we may as well just vacate it so we can stop wasting time on it over and over"). On that basis, I'd support an addition to the proposed paragraph along the lines of "If the bot is blocked again for the same or similar issues, further self-unblocks are extremely unlikely to be well-received."

As for the ArbCom case itself, I'm confident ArbCom is aware enough to take mid-case edits into account, particularly when many in the case are calling for the community to review the policies. Anomie⚔ 18:07, 21 January 2017 (UTC)

Alright, then let's draft this on the talk page instead, and we can bundle this in the RFC for the proposed update of COSMETICBOT that'll happen eventually

Note that

extremely unlikely to be well-received

.

} 14:45, 22 January 2017 (UTC)

An alternative form of words for inclusion in the RfC, which would reflect the overarching policy language more clearly:

Note that unblocking one's own bot account (which can only happen if a bot operator is also an administrator) is almost never acceptable, unless an administrator blocked their own bot account themselves. An administrator who wishes to have their own bot account unblocked should normally contact the blocking adminstrator, or use a {{unblock}} template to request an independent administrator to do so.

Hchc2009 (talk) 15:11, 22 January 2017 (UTC)

Except this is too extreme and doesn't really reflect what the current practice/consensus is. I've seen bot ops uncontroversially unblock their own bots dozens, if not hundreds of times.

books

} 15:30, 22 January 2017 (UTC)

There are definitely differences in views, which is why an RfC is particularly valuable here, presenting both options (and potentially others) for how the policy might be clarified. Hchc2009 (talk) 16:00, 22 January 2017 (UTC)

While I agree with Headbomb here, I also agree it may be best for the RFC to offer both options for people to discuss. I hope I can get my comment above (regarding my opinion as to why the Yobot and Smackbot unblocks were so controversial) in early enough to cut down on overreactions. Anomie⚔ 20:15, 22 January 2017 (UTC)

In my (limited) experience there are six reasons why a bot is blocked, any when unblocking is acceptable depends on which it is - my opinions are below:

1. The bot owner is blocked or banned. The bot should not be unblocked unless and until the owner is. A bot owner unblocking their bot before their main account is unblocked would be grounds for desysopping in almost all circumstances.
2. The bot or task is unauthorised or not complying with its authorisation. The bot should not be unblocked without either the consent of BAG or a firm undertaking that it will not resume editing unless and until it is authorised. Except in cases of genuine misunderstanding, the owner should not normally be the one to unblock.
3. The bot has a bug that is causing disruption. The bot should not be unblocked until (a) the bug is fixed (or believed in good faith to be fixed), or (b) the buuggy task(s) have been stopped and will not be restarted before being fixed. It is normally acceptable for the owner to be the one to unblock for these reasons.

   I've included (b) to allow for bots with multiple tasks where only one is buggy, and/or where a fix needs testing.

4. The bot is, or is believed to be, tripping up on a bug or other change in MediaWiki or the API. The bot may be unblocked when the issue is resolved (task stopped, bot changed, MediaWiki bug fixed, etc). It is normally acceptable for the owner to be the one to unblock for this reason.
5. The bot is otherwise causing disruption or controversy (e.g. causing too many errors or not respecting consensus). In this case the bot must not be unblocked until the issue is resolved and the bot modified and/or task stopped.
6. The owner blocks their bot for testing or other reason not listed above. The owner may unblock the bot without restriction in this case.

In all cases, if the owner unblocks the bot before the issue has been fixed and disruption continues or reoccurrs then the bot may be blocked again. Repeated instances of a bot needing to be reblocked will lead to bot approval being withdrawn and/or desysopping. Thryduulf (talk) 14:42, 8 February 2017 (UTC)

I agree with the general ideas from

WP:WHEEL

but with +1 offset. So basically:

• A block of a bot by an admin claiming a malfunction/incorrect behavior is uncontroversial in the vast majority of cases. In fact, several templates frequently used on bot user pages basically imply "please block me if you find something wrong."
• An unblock by the bot owner (or any other admin) in response to fixing a problem (on an approved bot) is usually uncontroversial in the vast majority of cases. An unblocking admin (owner or not) shouldn't have to worry about reversing the original block unless there's a clearly superseding contra-indication (e.g., owner is themselves blocked, ARB sanction, block message saying "don't unblock without first contacting me," etc...).
• ...AND the original blocking admin (or any other admin, for that matter) also shouldn't worry about re-blocking the bot should that problem not have been fixed or other problems simultaneously arise (again, absent of any clear contra-indication, like consensus saying the block was wrong to begin with, continued blocks are POINTy, etc...).
• Essentially, the first unblock (rather than the first block) would therefore become the true "inciting" action when counting for WHEEL, so the subsequent action (i.e., reblocking) has the presumed final say as being the "revert" until either the re-blocking admin or some sort of consensus decides otherwise.
• From then on, it should be fairly straightforward as far as how WHEEL applies.

That seems like it should cover most cases. Thoughts?

--slakr^\ talk / 06:59, 10 February 2017 (UTC)

Comment Similar to Anomie's concerns of a block instead of a task shut-off. The same problem goes with AWB bots. Stopping the bot is always suffice. Blocks are unnecessary. I think the general concept of blocking a bot for malfunctioning it's outdated and only necessary for bots not allowing other options to be stopped. -- Magioladitis (talk) 07:15, 10 February 2017 (UTC)

Fundamentally, the entire reason we have bot approvals is that bots can, if malfunctioning, create a disproportionate and unnecessary burden on human editors. The longer the bot malfunctions and the more pages it hits, the greater the complexity of fixing things (it may no longer just be easy to "roll back the changes"). Thus, the most prudent thing to do is pause the bot's actions early if a problem is encountered. This gives plenty of time to investigate the problem while limiting any further damage. No admin should have to read the bot's (and/or the bot's framework's) documentation to figure out how to do that while more damage can be occurring. Bots are here to make life for humans easier—not the other way around. A block might not truly be necessary, but let's be honest, even alternate methods like shutdown pages still require a properly functioning bot to parse, and if the perception is that the bot is already broken, we shouldn't require someone to further convince themselves the bot is super broken by forcing them to test to see if and when the bot respects the shutdown page in the middle of a perceived crisis. --slakr^\ talk / 07:53, 10 February 2017 (UTC)

Slakr, I think your proposal is overly complex and would invite abuse. I think we'd be better off remaining with the current policy, namely that unblocking one's own account is almost never acceptable, unless an administrator blocked their own bot account themselves - just use an unblock tag or ask the original blocking admin, as other users do. Either way, this needs to go to a proper RfC. Hchc2009 (talk) 08:17, 10 February 2017 (UTC)

My point of view is that: If we end up to block an admin's bot and we don't trust the admin to unblock it after they claim it was fixed then we re doomed in a bureaucratic process anyway. The block for malfunctioning is not the same to a block due to bot running unapproved tasks or due to the task losing consensus. I the past, we removed approval to interwiki bots after the task became outdated. The block for malfunctioning is just a measure to prevent bot for further editing and give time to the bot owner to fix its malfunction. In a community that each one trusts each other any kind of bot stop would be suffice. If the bot provides an emergency shut off button we should be OK with that. I recall that my second bot's block was exactly because due to a malfunction the stop procedure via leaving a message in the bot's talk page was not working. So, the blocking admin correctly used the block button. In case the bot task creates more controversy the community has ways to handle this situation. PS Sorry that I have not read the entire discussion above yet. I am doing right now. -- Magioladitis (talk) 08:32, 10 February 2017 (UTC)

If an admin's bot is blocked due to undesirable behaviour, then we should trust them to unblock their bot after having fixed the problem (assuming no explicit instructions to the contrary). However if the problems haven't actually been fixed then we should be wary about letting them unblock a second time. If they reoccur yet again then I would not support allowing them to unblock themselves a third time. But common sense should be used, e.g. if the first two blocks were several years ago and the operator has been active without problems in the interim then the third should normally be treated as a first. Thryduulf (talk) 14:23, 10 February 2017 (UTC)

Thryduulf I totally agree. It should be treated similar to 3RR. Sometimes we have the impression we fixed something while we did not. Taking a step back is always useful. -- Magioladitis (talk) 14:26, 10 February 2017 (UTC)

While I general agree with Thryduulf (talk · contribs) summation of things (not everything 100% in the details, but the broad lines are there), concretely, at the policy level, wouldn't that all be covered in the proposed wording?

Note that

extremely unlikely to be well-received

.

We can make tweaks to that, but I don't feel a list of all specific cases is needed. If we capture "usually uncontroversial for glitches", "shouldn't be done when intended behaviour is in dispute", and "if the bot gets blocked again, don't unblock because

books

} 14:31, 10 February 2017 (UTC)

I think this makes it sound way too lenient. "frowned upon", "good idea", "intended", "unlikely" -- while such clarifications are fine on their own, when put together these suggest bureaucratic leeway. Depending on your approach, you could read this very differently. If I had to word it, I would say:

The bot operator should not

WP:IAR

exceptions may exist, the operator should normally check with the blocking admin first before unblocking their own bot. If the bot is blocked again for the same or similar issues, further self-unblocks should not be done.

It's a rare thing anyway, and it doesn't take long to ask for an unblock. If you're at a point where a bot is blocked for non-technical editing problems, it's time to examine things. In any case, I agree this point should have an RfC eventually. —  HELLKNOWZ  ▎TALK 16:03, 10 February 2017 (UTC)

I think I prefer your wording of "don't, unless" rather than "shouldn't, unless". It's also clearer that this (would be) part of the policy, rather than as a general addendum.

books

} 17:34, 10 February 2017 (UTC)

I wonder how we can add that if a bot had a shutdown button or provides other ways to stop it, they should be preferred over blocking. For instance, if the bot was human we would not block without a final warning etc. -- Magioladitis (talk) 20:45, 10 February 2017 (UTC)

I believe that's been in

books

} 20:50, 10 February 2017 (UTC)

Headbomb OMG. Things are moving fast nowadays. Maybe it's too technical to note that all AWB can stop with a single message in their talk page? -- Magioladitis (talk) 21:03, 10 February 2017 (UTC)

It's not too technical, but we already say "Many bots provide a stop button or means to disable the problematic task on their bot user page." If someone has a bot, then the onus is on them to mention how to disable it. The minutia of such mechanism is left to bot-ops.

books

} 22:31, 10 February 2017 (UTC)