Jump to content

Wikipedia talk:Bot policy

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 89.28.5.39 (talk) at 17:21, 1 March 2017. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive
Archives

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25

Control proposals

Archive policy

Archive interwiki (also some approvals for interwiki bots)

Defining cosmetic changes

"Cosmetic changes do not include adding or removing hidden maintenance categories."

I propose we add this phrase. -- Magioladitis (talk) 08:07, 30 December 2016 (UTC)[reply]

  • Oppose. I don't think this is good as a blanket statement. It allows any bot operator to create a hidden maintenance category populated by a template to justify any cosmetic-only edit they wish to justify. That clearly goes beyond what the community sees as appropriate bot edits, in my opinion. ~ Rob13Talk 08:11, 30 December 2016 (UTC)[reply]
BU Rob13 What is a cosmetic-only edit? -- Magioladitis (talk) 08:14, 30 December 2016 (UTC)[reply]
An edit which doesn't change the visual output of the page, with a footnote that the community can allow a certain cosmetic-only edit by consensus, of course. ~ Rob13Talk 08:45, 30 December 2016 (UTC)[reply]
BU Rob13 Perfect I agree with that! -- Magioladitis (talk) 08:56, 30 December 2016 (UTC)[reply]
  • Oppose as written, this type of edit offers no immediate benefit to readers and I think it opens a slippery slope route (e.g. I forged template a to b because b has a parameter for this hidden category but otherwise looks the same-and while I'm here, here's a pile of whitespace fixes). — xaosflux Talk 12:46, 30 December 2016 (UTC)[reply]
xaosflux So no bots are allowed to remove parameters from templates? -- Magioladitis (talk) 13:46, 15 January 2017 (UTC)[reply]
The statement above is rather absolute - I'd give that this activity "could" be cosmetic, and your counter above is another absolute - removing parameters from templates absolutely "could" impact the cosmetic and informational information presented on an article. — xaosflux Talk 16:31, 15 January 2017 (UTC)[reply]
  • Support in theory, but I don't think it should be included in the policy itself. Anything that isn't a cosmetic edit is a non-cosmetic edit -- we don't need to list all such edits or cherry-pick examples. Even with inclusion, I don't see what would change. Approval is still needed anyway for any category changes, so it's not like this would bypass that. —  HELLKNOWZ  ▎TALK 14:14, 30 December 2016 (UTC)[reply]

"Cosmetic changes do not include file renaming after file move"

I propose we add this. -- Magioladitis (talk)

Oppose an addition to the policy as instruction creep, but support in practice because it's supported by WP:FMV/W, which states "After moving the file, please replace all uses of the old file link with the new one." Since there's community consensus for this task directly in a policy-level page, it's appropriate despite being technically cosmetic. ~ Rob13Talk 09:11, 30 December 2016 (UTC)[reply]
BU Rob13 OK. We can add to the footnote "by consensus or as instructed by other stronger policies". Since COSMETICBOT is a policy we have to explain that this policy does not override other policies. Very good. -- Magioladitis (talk) 09:20, 30 December 2016 (UTC)[reply]
I'm hesitant to ever put "stronger policies" in a policy, since it creates another tier. "By consensus" would be sufficient, since policies represent consensus. ~ Rob13Talk 09:36, 30 December 2016 (UTC)[reply]
Somehow we should indicate that the one policy adds to the other and they are not in conflict. -- Magioladitis (talk) 09:38, 30 December 2016 (UTC)[reply]
Let's continue in the below thread to keep this all together, but something like this for a footnote might be good: "The prohibition on cosmetic-only edits is based on strong community consensus that such edits unnecessarily use server resources, make article histories more difficult to review, and usually have little to no positive effect on the encyclopedia. Cosmetic-only bot tasks may be approved at the discretion of the BAG if there is strong community consensus that the positive effects of the edits outweigh the issues noted above." ~ Rob13Talk 10:11, 30 December 2016 (UTC)[reply]

Add a footnote that the community can allow a certain cosmetic-only edit by consensus in COSMECTICBOT section

I propose we add this. -- Magioladitis (talk) 08:56, 30 December 2016 (UTC)[reply]

@BU Rob13: who suggested the brilliant idea. -- Magioladitis (talk) 08:57, 30 December 2016 (UTC)[reply]

This is already common practice. Pinging Xaosflux to verify, but consensus is always the "great decider". It can override just about anything. Note that consensus here means general community consensus, not a small local consensus - often, a village pump thread is necessary for large-scale changes. For a couple thousand changes, a more local WikiProject-level consensus may make sense. Depends on the task, really. I have no objections to spelling this out in a footnote so long as it's obvious that "consensus" doesn't mean an obscure discussion at bot requests or something. ~ Rob13Talk 09:07, 30 December 2016 (UTC)[reply]

Perfect. This is common practice but still not written. Time to make it explicit. -- Magioladitis (talk) 09:19, 30 December 2016 (UTC)[reply]

No problem with making it explicit after giving sufficient time for community input. ~ Rob13Talk 10:07, 30 December 2016 (UTC)[reply]
  • Not sure if this is a needed addition. The same practice is true for every policy, guideline, convention and whatnot. Consensus can change and we can always adjust things with new consensus. Explicitly saying that something can be changed smacks of some underlying problem that's not being solved correctly. A BRFA supported by prior discussion/consensus can always override the normal practice. —  HELLKNOWZ  ▎TALK 17:41, 30 December 2016 (UTC)[reply]
  • "Let's continue in the below thread to keep this all together", so I'm responding down here. Filename changes following a rename aren't necessarily cosmetic anyway: following a Commons file rename, I've sometimes seen an article here display the file as broken when it still links the old filename, even though the old name is a working redirect at Commons. It's actually rather important to fix filenames following renames in many cases; that's one reason that the Commons filerename script includes an option to replace all uses globally. Nyttend (talk) 13:26, 3 January 2017 (UTC)[reply]
  • Small cosmetic changes applied to very large numbers of pages on my watchlist, I find that disruptive. Please minimise cosmetic-only editing. --SmokeyJoe (talk) 23:50, 3 January 2017 (UTC)[reply]

I think the above sections may be missing the point

"Add a note about X specific case" doesn't seem hugely helpful when we don't have a definition to start from. If we want to define cosmetic edits, we should look at it more generally. I see two questions here that we should answer:

  1. Should cosmetic edits be defined here in policy, or in a guideline or essay?
  2. What can we agree are and are not cosmetic edits?
    1. I think everyone agrees that edits that make a visible change to a reader generally aren't cosmetic. We might be able to argue about nearly-invisible changes like “” to "" or adding of non-breaking spaces.
    2. What about changes that aren't visible in the article itself but are elsewhere? For example, changing hidden categories, changing category sort keys, or perhaps in the future overriding the auto-detected page image.
    3. What about changes that make no visible difference now, but make things easier to fix later? For example, converting external links to an external link template, particularly when it's a database site that occasionally changes its URL structure.
    4. How about changes that are invisible in normal browsers, but affect the output HTML in a way that's detectable to screen readers or the like?
    5. How about embedded metadata, like back when we had {{Persondata}}?

As for consensus, IMO both "an approved BRFA can override COSMETICBOT" and "bots still need approval even if it's not cosmetic" are obvious and I don't think they've ever been a point of dispute. Disputes around bot cosmetic edits seem to have been either malfunctioning bots that aren't making their non-cosmetic change or attempts to see if consensus has changed so something should no longer be done. Anomie⚔ 14:21, 3 January 2017 (UTC)[reply]

Anomie

    • We also need something for this case: [1] where an editor / or bot may change something based on another text (policy?) In that particular case it's Wikipedia:File_mover#What_files_should_be_renamed.3F.
    • If we clarify that changes that do not affect the rendered output can be done by consensus is also OK.
    • There are also people who would argue that doing these changes is OK but only in addition to other changes and not as sole edits.

These are some of the complaints I get from time to time. -- Magioladitis (talk) 14:31, 3 January 2017 (UTC)[reply]

Re your first bullet, WP:COSMETICBOT doesn't affect individual edits. For large-scale assisted edits such as cleaning up renames of many files or files with many uses it would want consensus, but I'm not convinced we need to waste our time enumerating every instance where such consensus already exists as seems to be the case here. For bots, the bot already needs a BRFA to do anything at all outside of its own or its owners userspace, which would include consensus to override WP:COSMETICBOT if necessary.
I'm not sure what your second bullet is referring to, unless it's not really a separate bullet from the first one.
Re your third bullet, "doing these changes is OK but only in addition to other changes and not as sole edits" is exactly what WP:COSMETICBOT is saying. Unless again this isn't supposed to be a separate point from the first bullet.
I'll admit I haven't looked into what complaints you get beyond seeing what's been raised at notice boards I happen to watch and at the arbitration request, but aside from a very few people complaining that no bot should ever make any cosmetic changes (even combined with non-cosmetic changes) it looks like most of the complaints about your bot with respect to cosmetic edits are due to the bot making cosmetic changes without the intended non-cosmetic change, where you've fixed the immediate issues over the years without being able to fix whatever is the underlying cause that makes it keep recurring, combined with a high edit rate so even a low percentage of errors is still a large number. The complaints about assisted edits on your own account with respect to WP:COSMETICBOT (as oppose to the complaints about other things) seem to be similar. Anomie⚔ 15:11, 3 January 2017 (UTC)[reply]

Anomie Re my first bullet: There are also bots doing the same. We need some protection for these bots against complaints. An easy reference for them wehn someone mentions COSMETICBOT. -- Magioladitis (talk) 15:19, 3 January 2017 (UTC)[reply]

That would be their BRFA. As I already said. Anomie⚔ 03:31, 4 January 2017 (UTC)[reply]

I don't think anyone is arguing that a BRFA cannot override COSMETICBOT. The issue that has come up occasionally is when the BRFA is for one task, but the bot operator insists on making other changes at the same time. One solution would be for the bots that have trouble to simply limit themselves to clearly-articulated tasks in their BRFA, which can be backed up with consensus-determining discussions. Edits with that kind of documentation are not likely to sustain much criticism. — Carl (CBM · talk) 01:23, 16 January 2017 (UTC)[reply]

A draft rewrite

I drafted a potential rewrite at User:Anomie/Sandbox2 (permalink). Your input would be appreciated, please comment here. If we can come up with a version that seems good to us here, the next step would be a full-blown RFC. Anomie⚔ 19:57, 21 January 2017 (UTC)[reply]

May we edit the draft?Headbomb {talk / contribs / physics / books} 00:08, 22 January 2017 (UTC)[reply]
It might make it a little hard to discuss if it changes too much, but otherwise I don't see why not. Anomie⚔ 00:36, 22 January 2017 (UTC)[reply]
Gave it a shot (permalink). The biggest difference (content wise) is the removal of mention of automated/semiautomated means of editing. I don't believe this is important to mention, especially since someone using scripts, or just doing a bunch of cosmetic things manual would be just as wrong (WP:MEATBOT). I also didn't like the original structure, which made it hard to follow if sub-bullets were meant as examples or counterexamples, so I switch it to a clearer 'these are cosmetic, usually' and 'there are non-cosmetic, usually' list. Headbomb {talk / contribs / physics / books} 01:10, 22 January 2017 (UTC)[reply]
Also added examples (Special:PermaLink/761274974), but we'll need one for the 'egregiously bad HTML', since I'm not really familiar with those errors. Headbomb {talk / contribs / physics / books} 01:28, 22 January 2017 (UTC)[reply]

I like the tone of the expansion to the policy I'm seeing at the draft—I think those are broadly the categories of the constitution of a cosmetic edit.

It does offend my sensibility that we jump from "cosmetic changes are problematic" to "here's what these are/aren't". A user reviewing the section will be somewhat disoriented. (I don't see a good way to fix this issue myself else I would have been bold.)

A good idea IMO would be to suggest examples at the first mention of each classification, rather than in the context of the "substantial edit" list. I would scratch my head at "administration of the encyclopedia" in the context of the cosmetic if I weren't to read to the next section.

As a curiosity, if I throw "WikiProject talk page maintenance" at these definitions, what would you assess that as? (And you can take "WikiProject talk page maintenance" to mean what you want.) --Izno (talk) 14:05, 3 February 2017 (UTC)[reply]

@Izno: I had put examples before, but Anomie felt they were unhelpful [2]. Would those help? As for "WikiProject talk page maintenance" it mostly depends on what you have in mind. Automatic assessment? Clearly not cosmetic. Archival of discussion? Not cosmetic. Bypassing a template redirect (e.g. {{WP Journals}} → {{WikiProject Academic Journals}}? Clearly cosmetic. Headbomb {talk / contribs / physics / books} 15:12, 3 February 2017 (UTC)[reply]
Ah, yes, that rationale makes sense. I think the section should definitely be refactored to show us the substantial edits rather than the cosmetic. --Izno (talk) 15:44, 3 February 2017 (UTC)[reply]

The draft is in a good way. Nice work. -- Magioladitis (talk) 14:37, 3 February 2017 (UTC)[reply]

Strong Support of the new draft. This discussion that I have been having highlight the issues with the current ambiguity of the policy and its failings to define what cosmetic actually is. I would like to add: Consensus for a bot to make any particular cosmetic change must be formalized in an approved request for approval, which will require an established consensus for that task. I don't feel that enough outside-BRFA people contribute to the discussions there. Consensus discussions should be actively advertised for participation, as RfCs are. TheMagikCow (talk) 12:55, 13 February 2017 (UTC)[reply]

We're not at the RFC stage yet, but it's coming. The point of the draft is to hash out ideas before proposing it to the wider community. The draft seems to have stabilized to something I think most or all of the BAG is behind. I suspect we're just waiting for the ARBCOM stuff to settle before going to RFC. But who knows, maybe it'll help with the ARBCOM stuff to submit it for RFC now? Headbomb {talk / contribs / physics / books} 13:23, 13 February 2017 (UTC)[reply]
The ArbCom seems to move in the direction to encourage discussion within the community. So, in fact we are moving to the direction that everybody seems to agree. -- Magioladitis (talk) 13:38, 13 February 2017 (UTC)[reply]
  • Generally, support. I disagree with the unclosed HTML tags; what exactly is "egregious" about them if they affect output for no users? I also dislike the reference to TfD; since consensus has determined that the template will be deleted in those cases, substitution does affect output ... only it affects output after the time of the edit when the template is deleted. Perhaps we should remove that example and update bullet point one to note that edits that change the rendered output now or in the imminent future are not cosmetic-only? That would also cover, for instance, deprecated HTML tags that are about to become non-functional or other similar changes. Further, I should note that bullet point 3 is easily gamed. Create a maintenance list or category and you're inside this policy? That's a bit eh. ~ Rob13Talk 14:30, 13 February 2017 (UTC)[reply]
    I don't much care about removing the TFD example, but you're missing the point that it's trying to illustrate: consensus can override the general rule. That should be obvious, but it seems the obvious may need stating on this point. Anomie⚔ 03:35, 14 February 2017 (UTC)[reply]
    Bullet point 3 is perhaps not so easily gamed as you think. Create a maintenance category and you can add articles to or remove them from that category when appropriate for the purpose of the category without that falling under WP:COSMETICBOT, yes, at until people get annoyed and your category gets deleted at CFD. But you still can't do so with a bot unless you get an approved BRFA for the task, and if you do it at a large scale in a manual or semi-automated manner it's not going to protect you from objections on any other grounds. And nothing here allows cosmetic edits to "fix" things just because you put it on a list or in a category. Anomie⚔ 03:35, 14 February 2017 (UTC)[reply]
  • Like Anomie said, bots still require approval. Someone creating a maintenance category for the purpose of getting ever with cosmetic edits via bots would get that bot blocked on sight and bot-privileges revoked for massively failing to get the point. The policy needs to outline the general idea, and the draft those that very well. This isn't a legal document that needs to cover all cornercases and malicious behaviours, otherwise we run the chance of causing an economic collapse here. We have WP:COMMON/WP:WIKILAWYER to deal with atypical situations if they ever arise, and people who try to lawyer their way around consensus. Headbomb {talk / contribs / physics / books} 04:20, 14 February 2017 (UTC)[reply]

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. Headbomb {talk / contribs / physics / books} 16:10, 20 January 2017 (UTC)[reply]

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)[reply]
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:BURO. Hence the and/or. I know personally, I would very comfortable approving a mushroom-stub creating bot, with only input of 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.
Headbomb {talk / contribs / physics / books} 22:52, 20 January 2017 (UTC)[reply]

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)[reply]

How was [3] against current consensus on the issue? Or is your objection purely procedural?Headbomb {talk / contribs / physics / books} 12:33, 21 January 2017 (UTC)[reply]
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)[reply]
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. Headbomb {talk / contribs / physics / books} 13:00, 21 January 2017 (UTC)[reply]
IMO the original addition accurately described the prevailing consensus here: Usually a bad idea, but 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)[reply]

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 unblocking one's own bot (which can only happen if a bot operator is also an administrator) is usually frowned upon, especially in cases where the block originated from a dispute over the bot's intended behavior rather than from a technical glitch. While WP:IAR exceptions may exist, it is good idea to check with the blocking admin first before unblocking your own bot. If the bot is blocked again for the same or similar issues, further self-unblocks are extremely unlikely to be well-received.

Headbomb {talk / contribs / physics / books} 14:45, 22 January 2017 (UTC)[reply]

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)[reply]
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. WP:BURO is a strong concern here, and I would be opposed to the alternate wording you've proposed. Headbomb {talk / contribs / physics / books} 15:30, 22 January 2017 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

I agree with the general ideas from Thryduulf, though it might be possible to simplify/generalize in some way as basically being 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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 unblocking one's own bot (which can only happen if a bot operator is also an administrator) is usually frowned upon, especially in cases where the block originated from a dispute over the bot's intended behavior rather than from a technical glitch. While WP:IAR exceptions may exist, it is good idea to check with the blocking admin first before unblocking your own bot. If the bot is blocked again for the same or similar issues, further self-unblocks are 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 WP:WHEELWAR", then surely that's all we need at the BOTPOL level, no? Headbomb {talk / contribs / physics / books} 14:31, 10 February 2017 (UTC)[reply]
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 unblock their own bot (which can only happen if a bot operator is also an administrator) unless the block was due to a technical glitch, software bug, or other technical reasons. While 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)[reply]
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. Headbomb {talk / contribs / physics / books} 17:34, 10 February 2017 (UTC)[reply]

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)[reply]

I believe that's been in WP:BOTISSUE for about 3 weeks now. Headbomb {talk / contribs / physics / books} 20:50, 10 February 2017 (UTC)[reply]
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)[reply]
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. Headbomb {talk / contribs / physics / books} 22:31, 10 February 2017 (UTC)[reply]

Exclusion compliant

Would someone please add a section here (or at WP:B if that's more relevant) explaining the exclusion-compliant process? This comes out of the WP:Exclusion compliant RFD (the current target is {{Bots}}), which was started because there's no page other than that template's documentation that explains the process at all. I'm not comfortable writing up an explanation, because I'm not a bot operator and don't hugely understand the process; I think the idea is that an exclusion-compliant bot is one that is instructed to refrain from its normal actions in specific situations (e.g. {{bots|deny=your bot's name}}), but I'm not familiar enough that I should be trusted in writing an informative piece on the topic. Nyttend (talk) 04:31, 6 February 2017 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Policy on edit rate

I am led to believe some of the information at WP:BOTREQUIRE is a bit outdated, or is at least unclear. Specifically:

Bots' editing speed should be regulated in some way; subject to approval, bots doing non-urgent tasks may edit approximately once every ten seconds, while bots doing more urgent tasks may edit approximately once every five seconds.

This 10-second rule was added no later than 2006, presumably before the introduction of the maxlag parameter. I think we're at the point that we really shouldn't worry about performance, so instead of a hard N-second rule, we should ask that bots use the standard 5-second maxlag and respect it, making all API requests synchronous. The same goes for the next bullet point about slowing things down during peak hours. The last bullet down in this section of the policy mentions maxlag, but it's unclear if it is an alternative to the 10-second rule. Finally, if the concern is flooding recent changes, then I must argue against it, as this is why we have the option to hide bot edits from recent changes and watchlists. Right?

Let's assume the clauses are all in regards to performance. I'm then proposing we change these three bullets to something like:

  • Bots' editing speed should be adjusted based on slave database server lag; this allows bots to edit more quickly during quiet periods while slowing down considerably when server load is high. This can be achieved by appending an extra parameter to the query string of each requested URL. The standard 5-second maxlag is recommended; see mw:Manual:Maxlag parameter for more details. In addition, bots should make synchronous requests, having only one API query in-flight at any time.
  • If the bot is unable to use maxlag, its' editing speed should be regulated in some way; subject to approval, bots doing non-urgent tasks may edit approximately once every ten seconds, while bots doing more urgent tasks may edit approximately once every five seconds. Bots editing at a high speed should also operate more slowly during peak hours (1200–0400 UTC), and days (middle of the week, especially Wednesdays and Thursdays) than during the quietest times (weekends).

This gives more weight to the maxlag solution, which I believe is preferred. The 10 second rule can still stay as an alternative, because indeed sometimes the maxlag climbs to at least that high, if not much much more. In that case your 6 EPM bot is going too fast. I just don't think we should impose arbitrary EPM limitations when the server can do it for us. During BRFA trials I do ask that the edit rate be limited to some degree, since we don't know the bot to be stable, etc. Beyond that I think it's OK to go reasonably fast, even for non-critical tasks. If I am wrong and we should give concern to performance in the case of bots, please correct me :)

Thoughts? — MusikAnimal talk 21:13, 16 February 2017 (UTC)[reply]

The 10 second rule (or whatever limit there is) is also there to provide limits on malfunctioning bots. If it takes 10 minutes to notice an issue, then that's 60 edits. If you go down to 5 second, then you've doubled that. Headbomb {talk / contribs / physics / books} 22:11, 16 February 2017 (UTC)[reply]
As far as codifying this policy goes, using "averages" and "approximates" may be preferred. I got hit on another language project for doing manually supervised bot edits (flagged) over their "6 edits per min" rule - even though it was <3epm over my 30 editing run (during 3 of the specific mins I hit 10epm). — xaosflux Talk 23:11, 16 February 2017 (UTC)[reply]
Re: malfunctioning bots – This is why I ask to slow things down during a trial. After being approved, any concern regarding a malfunctioning bot could also be said about the "urgent" bots that edit much faster. For instance ClueBot NG, which is deemed "urgent", reportedly can ran at over 9,000 EPM, though I don't think it's come anywhere close to that. Many other non-urgent bots run well beyond 6 EPM ([4][5][6]). Either way, the policy seems to imply this is about performance, not malfunctioning bots or flooding recent changes, so it should at the very least be clarified. We should also encourage usage of maxlag, and not list at the bottom as an apparent alternative. Again, authors who code it to edit at 10-second intervals may actually be doing more harm than good when things are backed up. Maxlag can grow well beyond 10 seconds, so you should listen to the server — MusikAnimal talk 20:58, 17 February 2017 (UTC)[reply]
I think the exact numbers are outdated. I think exact numbers are also fairly pointless, especially since it's very subjective as to what constitutes urgent tasks exactly. Respecting maxlag (or sane latency) is really the only real requirement from performance standpoint. Perhaps limiting concurrent connections. Slower editing may be advised if the task is likely to screw something up. I agree that this focuses too much on performance (10 years ago), which really isn't a major issue. —  HELLKNOWZ  ▎TALK 21:35, 17 February 2017 (UTC)[reply]
As an aside, I've tested this, and AWB in bot mode doesn't appear to obey maxlag as far as I can tell. If I tell it to edit with no pause between edits, it will do that. It only seems to slow when the wiki is actually in read-only mode (in which case I get a pop-up saying it's in read-only; that happens every rare once-in-a-while no matter what speed it's running at). ~ Rob13Talk 00:16, 18 February 2017 (UTC)[reply]

I agree that the 10 epm is outdated and it should change to maxlag. -- Magioladitis (talk) 01:38, 18 February 2017 (UTC)[reply]

I think we should be finding ways to make the subject-space page half as long. So many words. Regarding edit rates, I believe MediaWiki already sets rate limits for bots and admins, regular logged-in users, and logged-out users. Why not just rely on those settings? --MZMcBride (talk) 05:34, 18 February 2017 (UTC)[reply]

While rate limits can be set in MediaWiki, no editing rate limits are set here for autoconfirmed users. Anomie⚔ 12:19, 18 February 2017 (UTC)[reply]

Side note: AWB in bot mode respects maxlag. -- Magioladitis (talk) 12:27, 18 February 2017 (UTC)[reply]

  • The original speeds were based on "not putting too much strain on the server" (singular).
  • For trials slower could be a good thing, but most trials are pretty small, e.g. 30 edits or 100 edits at max. Reverting these is a few moments work, even manually.
All the best: Rich Farmbrough, 16:39, 18 February 2017 (UTC).[reply]

Bot wars on Wikipedia

  • Ian Sample (2017-02-23). "Study reveals bot-on-bot editing wars raging on Wikipedia's pages". The Guardian.

-- GreenC 01:46, 25 February 2017 (UTC)[reply]

Some "research". All old news, and they didn't even mention bots warring with themselves, which is much more fun. All they had to do was come here and ask, and someone would have pointed them to this page. – Jonesey95 (talk) 02:09, 25 February 2017 (UTC)[reply]
Bot warring is not "news". They looked beyond anecdotal stories like the Lamest list, and did data analysis and statistics with every edit by every bot (within a sample article group) and reported what the results actually are - something that beforehand was unknown. They also did it across wiki languages to see what patterns arose (Germany had the least problems for example). They did it not to inform Wikipedia of its bot problems, but to show how automated bots in a complex system can create unintended consequences with an eye on things like self-driving cars and other types of networks where many well-intentioned and vetted bots can create havoc unintentionally. For the purpose of Wikipedia and policy, I think the results show how widespread the problem really is - it's systemic, subtle, not a random lulz list of a dozen incidents - and maybe think about what we can do about it. I know my bot WaybackMedic over 75% of its edits are fixing problems created by other bots and tools. There doesn't seem to be much inter-bot coordination other than what bot operators do on their own. -- GreenC 15:22, 25 February 2017 (UTC)[reply]
Hmm. The Guardian article seems fairly useless as far as any real coverage of bots on Wikipedia. Tracking down the actual paper reveals that the majority of the reverts they found came from interwiki bots and they analyzed data from 2001–2010, i.e. it's already rather dated. Anomie⚔ 14:30, 26 February 2017 (UTC)[reply]
I don't see why any of those facts makes the study useless for real coverage of bots on Wikipedia. Has something changed since 2001-1010? Are interwiki bots not bots? My bot is not interwiki, it's 2017, and the majority of its fixes are other bots and tools. I have no recourse other than appeal to the bot/tool owners to coordinate and sometimes they do, and sometimes they don't. The wars continue. -- GreenC 15:32, 26 February 2017 (UTC)[reply]
Unless there is a bov v bot revert cycle going on, this isn't really much of a war. — xaosflux Talk 16:06, 26 February 2017 (UTC)[reply]
The traditional sense of a revert cycle is a curious though rare phenomenon, and generally easy to fix once made known. The bigger issue of well meaning bots with slightly different rules that lead to unintended consequences; and bots which spend much of their time changing edits made by other bots for lack of common rules and coordination. -- GreenC 16:18, 26 February 2017 (UTC)[reply]
Err, yes, a lot has changed since 2001–1010. Wikidata completely eliminating interwiki link bots, for one thing. Anomie⚔ 16:59, 26 February 2017 (UTC)[reply]

It was a problem with the interwiki scripts back in 2010. Now it's resolved. Wikidata improved this situation. I don't there are any bot wars anymore. A thing that we have is one bot improving other bots edit. We have a phenomenon of multiple bots visiting the same page one after the other. -- Magioladitis (talk) 16:11, 26 February 2017 (UTC)[reply]

If each edit is incrementally making the page better, then everyone wins. If a bot edit makes the page worse, and another bot has to clean it up - that is undesirable - and we should discuss shutting stopping the first task. These are very case by case and are always open for re-review. An important caveats that often gets overlooked: we should never depend that any bot will make a future edit; so if one bots makes a page better than it was before their edit it will generally be justified. — xaosflux Talk 16:30, 26 February 2017 (UTC)[reply]

RfC to add general fixes to existing bots

Wikipedia:Village_pump_(proposals)#Should_bots_perform_secondary_.22cosmetic.22_tasks_while_making_a_primary_task.3F. -- Magioladitis (talk) 07:48, 28 February 2017 (UTC)[reply]

There is nothing in the RFC as posed that would "add general fixes to existing bots". Each bot would still need to be approved for all of its tasks, including general fixes. The RFC seems to be on the broader point of whether such approval is acceptable, which of course it is in some situations. — Carl (CBM · talk) 12:32, 28 February 2017 (UTC)[reply]

It's a motion that community encourages bot owners to add general fixes in their bot tasks. -- Magioladitis (talk) 12:34, 28 February 2017 (UTC)[reply]

Are/should IPs be allowed to run bots?

This issue came up at the newly-filed Wikipedia:Bots/Requests for approval/TrustMeImAIRobot, which would be a bot run by 89.28.5.39 (talk · contribs · WHOIS).

Current bot policy is that bot operators are "prominently identifiable" on the bot's user page. This is mostly to ensure that WP:BOTCOMM is followed, and to a lesser extent help the community deal with problematic issues from the bot operator should they arise (and I will note here I have no reason to suspect that IP 89.28.5.39 would be prone to such problematic issues). TrustMeImAIRobot (talk · contribs) currently identify its operator as 89.28.5.39 (talk · contribs · WHOIS), so in a strict reading of the policy, one might argue the policy's requirements are met. I'm not sure however, this is is what the community intended to require.

So, regardless of they are currently allowed by current policy, should IPs be allowed to operate bots? Headbomb {talk / contribs / physics / books} 16:07, 1 March 2017 (UTC)[reply]

Discussion

  • I'm sitting here feeling somewhat puzzled from a particular perspective (and not the general question): If the IP is willing to create a bot account, what is preventing him from creating a normal user account? --Izno (talk) 16:13, 1 March 2017 (UTC)[reply]
The IP might be willing to create an account. I'm just wondering (pre-emptively) what happens on the day that an IP wants to run a bot, but is unwilling to create an account for themselves for whatever reason. Headbomb {talk / contribs / physics / books} 16:19, 1 March 2017 (UTC)[reply]
  • I think that letting IPs run bots could create problems if the IP in question is not super stable, as you'd need to update the "botop" every time. Jo-Jo Eumerus (talk, contributions) 16:15, 1 March 2017 (UTC)[reply]
  • I see several issues with this. 1) BAG routinely denies bots (WP:BOTNOTNOW) for users with few edits. As an IP, it would be impractical to demonstrate prior experience and diligence to run a bot (even if the scope is small). 2) WP:BOTCOMM and WP:BOTISSUE requires accessible venues for communication (including, for example, via e-mail) and IP talk page is confusing at best. 3) IPs change. ISP may change it, the user may move/switch ISPs, the IP might become shared, it might switch to IPv6, someone else might access or even impersonate botop from the same IP, etc. Finally--subjectively speaking--someone willing to run a trusted process on a separate account should have no issues creating their main point-of-contact account. —  HELLKNOWZ  ▎TALK 16:30, 1 March 2017 (UTC)[reply]
  • My IP is static, and I'm the only user of it for more than 10 years. I have contact information in User-Agent header, if my bot would make any harm. Furthermore my bot makes changes only if previous editor was my bot as well, otherwise I will access wikipedia to see what's happening and can be contacted directly. I've already made a lot of commits without registering my bot (I'm sorry), and their scope is well defined. Registering a bot-operator account and making commits, just to fit requirements about experience and edit-number would be too expensive for me and the task I'm solving using this bot. Thank You 89.28.5.39 (talk) 17:20, 1 March 2017 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Bot_policy&oldid=768075674"