Wikipedia talk:Bot policy

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 · 26 Control proposals Archive policy Archive interwiki (also some approvals for interwiki bots)

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)

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)

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)

Are/should IPs be allowed to run bots?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

While some support IP-operated bots under some certain conditions, the consensus is generally against IP-operated bots. Concerns are IPs are not generally static, which compromises WP:BOTCOMM. Even in the case of a static IP, the IP could change after (moving from town to another), edits from different temporary locations, or similar. There's also the fact that if you can be bothered to login/register an account for a bot, you can login/register an account for yourself.

Consensus is also in favour of considering an IP's edit history for the purpose of establishing "good standing" and "experience" in the sense required by WP:BOTAPPROVAL. Headbomb {talk / contribs / physics / books} 01:29, 25 March 2017 (UTC)

---

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)

Discussion

• Note: After discussions that took place here and on the request-for-approval page I've decided to create a bot-operator account and updated the request, so it doesn't fully match the subject anymore. For the initial version see the history of commits. Thank You TrustMeImAIRobot (talk) 10:41, 2 March 2017 (UTC)

You should post from that account, not from the bot account. See WP:BOTACC, which has been pointed out before. Headbomb {talk / contribs / physics / books} 11:02, 2 March 2017 (UTC)

I understand, but taking in consideration the fact that the topic was started from my bot account, it was logic to add notes from it as well. Should I start a new request-for-approval from this account, or that topic with some discussions already made is OK? 5-HT (talk) 13:26, 2 March 2017 (UTC)

You should never use your bot account for anything but limited testing or approved tasks. This means no messages that might lead others to believe the account is a human. This is part of WP:BOTPOL, which you are expected to read and understand before you can get approved for a full bot account. —  HELLKNOWZ  ▎TALK 14:03, 2 March 2017 (UTC)

Yes, but as an IP-user I wasn't able to add my request-for-approve, and having only robo-account I thought that it's not a big problem to make the request from it, WP:IAR. Also, i've added 2 notes, to mention, that account-operator was created, and I consider that making them from robo-account was a good deal, because it was the topic starter. All other commits are made as IP-user or from this newly created account. 5-HT (talk) 15:11, 2 March 2017 (UTC)

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

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)

• I'd say no no this - in that the bot's edits need to be accountable to a specific person who will be accountable for it. — xaosflux ^Talk 16:14, 1 March 2017 (UTC)

  The bot policy states that bot accounts fall under the Username_policy and Sock puppetry policy requiring Bots should be clearly linked to their owner's account - and an IP address is not "clear". — xaosflux ^Talk 16:17, 1 March 2017 (UTC)

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

Expensive? Creating an account on Wikipedia is free. Headbomb {talk / contribs / physics / books} 17:51, 1 March 2017 (UTC)

Creating account and making commits to fit experience requirements is very time consuming (expensive throw time spent on it). 89.28.5.39 (talk) 18:16, 1 March 2017 (UTC)

Creating the account takes less time than developing a bot; you would be better off with a completely new account, pointing to your IP edits, than staying unregistered. עוד מישהו Od Mishehu 14:26, 2 March 2017 (UTC)

I've tried to create an account-operator some time ago, which was banned a day after for 'meaningless' nickname. Reading in depth nickname policies and requesting nickname change isn't as fast as writing an assistance bot for the task I'm solving, moreover it's a way less interesting. 5-HT (talk) 15:22, 2 March 2017 (UTC)

You've mentioned this a few times now, I'm curious what the name was that was blocked as "meaningless". Anomie⚔ 15:42, 2 March 2017 (UTC)

Also, not having an account does not remove the requirement to have some experience and familiarity with English Wikipedia, its policies, guidelines, processes and community expectations. It's not about edit count -- making commits just to make commits wouldn't count anyway. And commits made as an IP before are just as fine. —  HELLKNOWZ  ▎TALK 18:03, 1 March 2017 (UTC)

I've tried before for two times to create an account, and was two times banned few days after for the reason that my nickname was 'meaningless' (which is quite abstract reason), and I'm dropped the idea to change it, because nickname changing policy was stating that this process can take 3+ months, and having an account wasn't giving any reasonable option for me or outweighing necessity to read nickname policies in details, to understand what the real reason for ban was. Before applying for approve, the idea to create an empty account for bot-operator was looking more senseless than applying as an IP-user. 89.28.5.39 (talk) 18:28, 1 March 2017 (UTC)

Only developers and checkusers can see user-agent information, it is not useful as a contact for editors. — xaosflux ^Talk 18:16, 1 March 2017 (UTC)

If my bot makes some significant load on the servers administrators can contact me about this. If my bot makes any harmful commit, which would be reverted by any other user after me, I would know about this, and would come here to see what's happening, what my bot did wrong, and if there were any messages on my IP-talk-page, or bot's-talk-page about the issue. 89.28.5.39 (talk) 18:45, 1 March 2017 (UTC)

• In general, I would say this is not a great idea. But I think in this case, there's a solution. If the IP editor is concerned about the time it would take to bring an account up to par, allow them to create an account, and allow their IP contribution history to count toward any edit count or tenure requirements. That addresses the concern in this case which is seemingly an exceptional one, without making a wider policy change that I think would normally be quite unwise. Seraphimblade ^{Talk to me} 03:31, 2 March 2017 (UTC)
• Bot operators need to have registered accounts in order to respond to questions and issues about the bot. This page isn't the location to re-argue whether accounts should exist in the first place. An editor who has not yet developed a good track record on their own account is not ready to begin doing so with a bot account. Moreover, a bot operator cannot guarantee they will always edit from the same location: bot operation is different from normal editing, and may require responding to questions from other locations. — Carl (CBM · talk) 12:09, 2 March 2017 (UTC)
• Not only an account but an experienced account with at least some substantial history should be required to operate a bot. I submitted my first BRFA two months after joining, and that was with a good 10k edits under my belt. That's the lower end of the spectrum on what I would consider acceptable for tenure; I would probably think twice before approving my past self, now that I have more experience and understand the risks of a bot. ~ Rob₁₃^Talk 12:40, 2 March 2017 (UTC)
• The current applicant has created an account, so the immediate situation appears to be resolved. But Oppose any expectation that IP's should be running bots. I find it implausible to conceive any situation where it would be necessary, and it has too many downsides. An operator who can't even get around a casually placed semiprotect is a problem-waiting-to-happen. An IP operator would require an incredibly good reason, and that would be handled as an extraordinary exception-by-consensus. Alsee (talk) 20:48, 2 March 2017 (UTC)
• Support with condition that the user provides a permanent point of contact. Because IPs cannot be considered permanent (even if nominally static), a user wishing to operate a bot must provide a reliable point of contact. For Wikipedia editors with accounts, their talk page is sufficient. For editors without accounts, another permanent point of contact must be provided (e-mail, twitter, github, etc.), at the very least privately to the BAG team, but ideally in a non-private location. ☺ · Salvidrim! · ✉ 22:47, 2 March 2017 (UTC)
• Require an account, but allow the history as an IP to count towards tenure and edit count. I myself first edited Wikipedia as an IP on 01 January 2006, but my first edit under this username was on 09 June 2006. I use the January date when calculating how long I have been editing Wikipedia. --Guy Macon (talk) 03:03, 3 March 2017 (UTC)
• Nominal oppose per Guy Macon. Bots are disturbing enough without allowing people to set up creative routes to the complaints department. For example, if a bot operator requires an email address for complaints, that is a step toward "outing" editors who want to be heard about it. A web-based interface might even expose the complainer's computer to a hacking attempt. By far the better solution is to allow an account-holder to claim credit - here and throughout Wikipedia - for their IP editing history. (Provided they have posted that they control that account from the IP address after its creation, for purposes of verification - we don't want just anybody taking credit for any IP's contribution history they can find) Wnt (talk) 16:45, 3 March 2017 (UTC)
• Oppose, but count history Seems like the best way to handle it. This is a fairly rare case, and I think that requiring standard procedure (i.e. accounts) makes things simpler for everyone. Obviously, we'd need a checkuser (or other verification) to prove identity, but beyond that, I don't see any problems counting IP history. Tamwin (talk) 21:34, 3 March 2017 (UTC)
  • @Tamwin: Our CheckUser policy forbids CUs from connecting an IP to an account, so that route is impossible. ~ Rob₁₃^Talk 21:53, 3 March 2017 (UTC)
    • To the best of my memmory, if the user requests that a very specific question, personally about him/her, be answered in public, a checkuser may do so. Specificly, if this anon registers an account, (s)he should be able to have the following question answered publicly: "Am I doing this edit from IP address 89.28.5.39?" עוד מישהו Od Mishehu 19:15, 4 March 2017 (UTC)
      • Self-requests are not admissible exemptions to the Privacy Policy which binds CUs not to divulge private information about accounts, such as the IP they are editing from. ☺ · Salvidrim! · ✉ 16:58, 10 March 2017 (UTC)
• Strong Oppose. There must be a way to hold a bot op accountable for their bot. A misbehaving bot has the potential to wreak chaos in a very brief amount of time, and we need to know that owner will take responsibility for cleaning up after it. -FASTILY 00:13, 6 March 2017 (UTC)
• Limited support. I'd be OK with this only in the following limited circumstances: (i) the IP is static and sufficiently established to demonstrate the sort of experience required of bot operators with accounts; and (ii) an email address at which the operator can be contacted is prominently displayed on the userpage of the bot account. WJBscribe (talk) 18:04, 10 March 2017 (UTC)
• Oppose. If the IP address changes, then the bot operator's IP changes as well. It can be hard to keep track of a bot operated by an IP, especially if that person's IP address changes a lot. —MRD2014 📞 What I've done 20:19, 12 March 2017 (UTC)
• Support I.P's are people as well. If the IP wants to run a bot, we sh ould have history from this IP, just like we would for anyone else. (He or she did point out that their IP is static and thus is them and them only ).

  So we have that. As long as the IP maintains that page and is responsive to request, I see no reason to deny. К Ф Ƽ Ħ 17:31, 16 March 2017 (UTC)

  • They can only "maintain that page" as long as their direct connection remains from that IP. Otherwise, they just become a different number claiming to be the previous IP. They can't control if their ISP changes the IP, updates to IPv6, shares or routes it, implements a VPN, etc. Or the editor themselves simply move, change ISPs, or allow someone else to connect on their network (they wouldn't even need to login to appear as them). —  HELLKNOWZ  ▎TALK 17:16, 20 March 2017 (UTC)
• Oppose also Absolutely not. Damotclese (talk) 15:21, 20 March 2017 (UTC)
• Oppose. If someone wants to be as involved as running a bot on Wikipedia, they really should have an account at that point for contact purposes, etc. An established IP making a new account for this purpose is a bit of a special case though, so that IP's history should be linked to the new account in the request for approval when the editor themself specifically requests it. Kingofaces43 (talk) 15:55, 24 March 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WP:COSMETICBOT update

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

A clear consensus exists to adopt the proposed language. bd2412 T 16:43, 18 May 2017 (UTC)

---

The current policy of WP:COSMETICBOT, while relatively clear in its intent, is currently fairly vague in practice, and short on examples. Several of us (both BAG and non-BAG members) have drafted User:Anomie/Sandbox2 (talk, see also a prior discussion) to 1) the motivation for this policy 2) clarify what the terms cosmetic, substantial/non-cosmetic, and minor edit typically refer to, 3) to clarify under what conditions bots may or may not make such changes 4) how to deal with undesired cosmetic edits.

This RFC is to see if the proposed update/wording has consensus. Refinements can be made during the RFC if issues are found with it. Headbomb {talk / contribs / physics / books} 11:46, 26 March 2017 (UTC)

Current vs proposed versions

Current

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

Scripts that apply cosmetic changes, such as cosmetic_changes.py, should be used with caution. The pywiki functions standardizeCategories, validXhtml, translateAndCapitalizeNamespaces, removeNonBreakingSpaceBeforePercent, or equivalent functionality, should not be used (as of May 2009), as they do not function correctly or there is no consensus for such changes. The functions removeUselessSpaces and cleanUpSectionHeaders are also not recommended, as they mainly move around whitespace.

Proposed (changes since start of RFC)

The draft that was here for some time has been incorporated into policy in Special:Diff/781024503/prev. I'll eventually repurpose this sandbox for other tests. Thanks, everyone.

Cosmetic bot section update discussion

The overall clarification is good. The final paragraph, however, goes too far. What we have seen in several cases of abuse - with Betacommand, as one example, and more recently with others - was an attempt to gain a first-mover advantage by making cosmetic edits on their own on a large scale, based on the opinion of the bot operator rather than on any site-wide consensus. This is related to WP:FAITACCOMPLI. The best way to handle these is to restore the status quo from before the inappropriate bot edits. While there are some cosmetic edits that do objectively improve the article, others only change from one optional style to another. — Carl (CBM · talk) 13:06, 26 March 2017 (UTC)

I also believe that the final paragraph should, at a minimum, not be given the same weight as the rest of the text. If adopted, this new text could be used to clarify WP:AWBRULES, #4. I support the rest of the changes. (Full disclosure: I have applied minor copy edits to the proposal to change "substantial" to "substantive" per the original text and the meaning of English words.) – Jonesey95 (talk) 13:41, 26 March 2017 (UTC)

This last paragraph is specifically to prevent/minimize knee-jerk reverts like [1]. If the changes would otherwise have been fine (e.g. as part of a non-cosmetic change), then there is by definition no reason to revert the edit. It is not because no substantive changes have been done in an edit that the previous version was better, especially if those changes would eventually be done as part of a substantive edit. These reverts are utterly pointless, and clutter edit histories just as much as the original edits. This is in contrast to reverting a cosmetic change because neither version are considered preferable, and both version are on equal footing.

For example, changing {{WP Astronomy}} to {{WikiProject Astronomy}} shouldn't be done on its own. But if a bot did that by mistake/malfunction, there's no reason to revert this. However, if a bot changed {{citation |last=Smith |first=John |...}} to {{citation |first=John |last=Smith |...}}, breaking an already established convention, or trying to create a convention no one supports (e.g. WP:FAITACCOMPLI), then there is a reason to revert. That's the distinction drawn in that last paragraph. Headbomb {talk / contribs / physics / books} 14:40, 26 March 2017 (UTC)

Refining my objection: I can live with bits about reverting, but the first sentence really serves as a restatement of, or addendum to, MEATBOT. If you want to refine MEATBOT, do it in that section, not in a section ostensibly describing cosmetic edits. I recommend removal of this sentence: "While this policy applies only to bots, human editors may also wish to follow this guidance for the reasons given here, especially if making such changes on large scales." Incorporating that sentiment, in some form, into MEATBOT might make sense. – Jonesey95 (talk) 15:41, 26 March 2017 (UTC)

I could live with putting that first sentence in WP:MEATBOT. However it makes more sense to me here, given that this is more or less where the only guidance on cosmetic edits exist on Wikipedia is. Having it here also makes it clear that the policy applies to bots only, unless there are issues of WP:MEATBOT. Thoughts? Headbomb {talk / contribs / physics / books} 15:50, 26 March 2017 (UTC)

Re Headbomb: The problematic bot operators who cause problems are not making these edits "accidentally" - they intentionally allow the bot to make them because of a personal desire to see their preferences implemented site-wide. In some cases they go out of their way to make the cosmetic edits in a misguided attempt to "clean" pages or "check" the wiki. Your proposal gives these operators a first-mover advantage, which is inappropriate. In general there is no reason to remove "Template:" or to change "WP Astronomy" to "WikiProject Astronomy". These are just personal preferences of a relatively small number of bot operators, and do not need to be changed even if another edit is made. We tolerate the change, to some extent, if a more significant change is made, but that does not mean the change is actually an improvement. — Carl (CBM · talk) 15:57, 26 March 2017 (UTC)

I see you were right, Headbomb. True, there's no reason to remove "Template:" or to change "WP Astronomy" to "WikiProject Astronomy". The point you're missing is that there's even less point to knee-jerk revert the edit. Stop/block the (meat)bot, take it to WP:ANI or other appropriate forum, and it can be reverted if consensus there determines that reverts should be done. Anomie⚔ 16:07, 26 March 2017 (UTC)

That doesn't really deal with the first-mover advantage, though. It also doesn't deal well with issues like this IP editor. For an IP address which is making MEATBOT COSMETICBOT edits, the right solution is the same as handling vandalism: if they know their edits won't stick, they have less reason to make them. I'll also point out that for some problematic bot editors - such as one who was recently the subject of an arbcom decision - it can be clear from experience that discussion is unlikely to be fruitful. I think it is likely that the collection of bot operators and MEATBOT operators I have in mind, and the collection you have in mind, may not be the same. The policy needs to cover all of them. — Carl (CBM · talk) 16:35, 26 March 2017 (UTC)

If discussion doesn't help, then blocking would be the next step. That's why blocking exists after all, stopping editors who don't listen to requests and warnings. Jo-Jo Eumerus (talk, contributions) 16:46, 26 March 2017 (UTC)

First mover advantage on invoking templates with {{TemplateName}} instead of {{Template:TemplateName}}? I'm afraid you're looking at 10+ years of a pretty standard convention. As of the last dump, this was done on a total of 17 articles (and those were mostly in comments telling people were to look for the documentation of a template), out of 5.3 million articles (or 0.00032% of all articles). If you dispute that CW Error #01 is contentious, take it to WP:CHECKWIKI. But to revert simply because nothing else was done to "prevent" an already achieved WP:FAITACCOMPLI on a matter everyone agrees is best practice is a waste of everyone's time. Headbomb {talk / contribs / physics / books} 17:19, 26 March 2017 (UTC)

Yes, that one is relatively well established. However, experience shows that very often, once one problem is "fixed", another problem is invented to take its place. Reference re-ordering was an example of one of these non-rules that someone made up - it took years to get that removed from AWB, despite it never having consensus in any guideline or style guide. Occasionally I have to remind editors that HTML entities are perfectly acceptable. I have seen bot operators intentionally orphan a template via cosmetic edits, then claim the template is unused and should be deleted. It's these new issues where being aware of the the first mover advantage is particularly important. There are many "minority" styles that are perfectly acceptable. — Carl (CBM · talk) 17:28, 26 March 2017 (UTC)

Then use a scalpel, not a hammer. "... despite it never having consensus in any guideline or style guide". That is covered by the "if" clause in the last paragraph. If the edit shouldn't have been made as part of a substantive edit, there is a reason to revert. If the edit would have been fine as part of a substantive edit, there is no reason to revert.Headbomb {talk / contribs / physics / books} 18:02, 26 March 2017 (UTC)

Not sure if we want to encourage the pounding of the revert button over cosmetic edits. Maybe talk first revert later if ever is a better tactic. Jo-Jo Eumerus (talk, contributions) 13:20, 26 March 2017 (UTC)

The goal should be prevent cosmetic edits in the first place, of course. — Carl (CBM · talk) 13:32, 26 March 2017 (UTC)

Mostly a personal feeling, the bickering over them is more harmful than the cosmetic edits themselves. Jo-Jo Eumerus (talk, contributions) 13:57, 26 March 2017 (UTC)

I think I'm in agreement with Carl on this one. We have an ongoing problem with a small minority of bot operators, as the recent arb-case has demonstrated. Non bot-operators can't apply BRD to large scale changes carried out by these editors, for the obvious practical reasons. As has been demonstrated in recent months, their response to challenge has simply been to say "I've made the change, against policy, put up with it". Routinely reverting such changes would certainly remove the "first-mover" advantage, dis-encouraging their behaviour, and it would reduce tensions with non-bot operators, who would see BRD being applied. I take Jo-Jo's comment on blocking being a good option, but as the recent arb-case shows, this simply doesn't work/happen in practice. Hchc2009 (talk) 17:30, 26 March 2017 (UTC)

@Hchc2009: say a bot made, because of a malfunction, 20 of these edits [2] or even 1000 of these edits [3] before it got blocked. What is gained by reverting? Especially since those have consensus to be been done as part of substantive edits? The Magioliditis/Yobot situation was caused by a big case of WP:IDIDNTHEARTHAT, not because people weren't allowed to revert (or not revert) his bot's pointless edit. Headbomb {talk / contribs / physics / books} 18:10, 26 March 2017 (UTC)

For me, the problem with that argument is that normal editors can't revert the likes of Magioliditis, as they don't have bots with which do so. For what it's worth, I think that if editors operating bots were held responsible for fixing the malfunctioning behaviour of their bots - including the potential 1,000 article mistake example you've given here - they might be more motivated to prevent their bots malfunctioning in the first place... Hchc2009 (talk) 18:18, 26 March 2017 (UTC)

Everyone has the ability to revert anyone. The question the paragraph attempts to address is should you? If a bot has been favouring one cosmetic style over another equally valid cosmetic style ({{citation |last=Smith |first=John |...}} to {{citation |first=John |last=Smith |...}}), then clearly reverts are warranted. But if a bot cleaned up

[[Category:Animals]][[Category:Cats]][[Category:Pets]]

to

[[Category:Animals]]
[[Category:Cats]]
[[Category:Pets]]

There really is no reason to revert just because this was a cosmetic edit. Headbomb {talk / contribs / physics / books} 18:30, 26 March 2017 (UTC)

If I understand the distinction you are making, you are suggesting that changing from one valid cosmetic style to another such as the order of parameters in a template can be reverted, but changing {{WP Astronomy}} to {{WikiProject Astronomy}} shouldn't, nor adding spaces between categorization links, because while both styles are also permissible, the second is preferred to the first? If this is your intent, the proposed text should clarify this; as it stands, removing the spaces between category links or changing to {{WP Astronomy}} would also be considered cosmetic edits that shouldn't be reverted. To be honest, though, if the desire to avoid a cosmetic revert on top of the original cosmetic change is considered higher priority than combating fait accompli editing, I'm not clear on why the first scenario of reverting from one equally valid style to another should be considered OK. isaacl (talk) 06:50, 28 March 2017 (UTC)

Re:"If this is your intent, the proposed text should clarify this". I'm not sure how "If the changes made in a cosmetic edit would otherwise be acceptable as part of a substantive edit, there is no reason to revert them." is unclear. No bot would be approved to change the parameter order of last/first in citations. That's not a change that would otherwise be acceptable. Putting categories on their own lines/using the full WP Astronomy templates are not otherwise contentious. Headbomb {t · c · p · b} 09:50, 28 March 2017 (UTC)

That's a helpful clarification: If the changes made in a cosmetic edit would otherwise be approved as a bot edit when made as part of a substantive edit, then there is no reason to revert the change. Acceptable is in the eye of the beholder: with a manual edit, personally I don't believe a change to the order of parameters in a template would be considered unacceptable. Thus it would be helpful to clarify that "acceptable" is in context of bot approval. isaacl (talk) 01:47, 29 March 2017 (UTC)

• Support new version, as one of the drafters of the above text, for the record. Headbomb {t · c · p · b} 19:13, 26 March 2017 (UTC)

  This is a major improvement, but I still disagree with the invalid HTML example. The example has been repeatedly controversial, and the term "invalid HTML tag" is not well-defined. See, for instance, this AN thread. I'd wholeheartedly support this if that example was struck. That isn't to say it always isn't a substantive change, but I don't think it is a substantive change so obvious that it should be enshrined in policy, especially when some tags can be "minorly invalid" without being "egregiously" so. ~ Rob₁₃^Talk 07:04, 28 March 2017 (UTC)

  When is it acceptable to have something like 10² be declared as 10<sup>2</sub>. How is that controversial? Headbomb {t · c · p · b} 09:52, 28 March 2017 (UTC)

  Agreed with Headbomb to start. In addition, repeatedly controversial deserves a {{citation needed}}. (The specific discussion you cite is an example with its own, unfortunate, history that I think is quite clearly an outlier.) Fixing the HTML is always a substantive change and has impacts on accessibility to boot (review the rationale for existence of WP:Accessibility). --Izno (talk) 11:55, 28 March 2017 (UTC)

• Support new version it's a big effort to make things clearer. -- Magioladitis (talk) 07:33, 28 March 2017 (UTC)
• Support new version - I have always wondered whether bots should just have a check whether the parsed wikitext of the old version differs from the parsed wikitext of the to-be-saved version (as parsed by the api, using an off-the-shelve-library diff-function of the programming language used). If that is the same, the edit is by definition cosmetic, and should not be saved in any form (especially not in bot-mode, and maybe also not in manual-mode). The override for this should be rather difficult, and only be activated for specific tasks (template substitution, where I would suggest BAG approves specific template-substitution tasks, and not 'general cleanup tasks that may encounter templates to be substed). One could then argue about the 'regular-space' to '&nbsp;-space', but maybe that could be extracted out of a diff as well (though I would argue that that is not cosmetic). --Dirk Beetstra ^{T C} 09:06, 28 March 2017 (UTC)
• Support new version: Clarifying really needed to happen. Seems to be based of the old interpretation of the policy and formalising it. TheMagikCow (T) (C) 11:54, 1 April 2017 (UTC)
• Support update. This is a good clarification and essentially matches the common practice or at least BAG's expectations. I don't think this solves any of the WP:MEATBOT cosmetic edit issues, nor does it necessarily prevent undesirable editing patterns. But it's a step in the right direction to at least remove some ambiguity as to what "cosmetic" means, broadly constructed. There's still a lot of questions as to which changes are or aren't cosmetic, like many of the CheckWiki or AWB genfixes, but the policy isn't trying to address each one (for now, anyway). The only real addition here is "reverting a cosmetic edit is also a cosmetic edit", and I support this inclusion. Unless the community decides for specific case that problematic edits were undesirable and should be reverted (to avoid fait acompli or some such), there's no real point reverting them every time. —  HELLKNOWZ  ▎TALK 12:45, 1 April 2017 (UTC)
• Oppose – the text is longer, but not helpful (afaics even far less helpful than the current shorter one). A cosmetic edit is a non-substantial edit (e.g. rearranging categories in a different order). The definition needs to be broad enough in order to avoid bots performing such cosmetic edits (see example in parentheses in previous sentence: some years ago there was a big problem about this kind of edits – ultimately it could only be stopped by defining them as non-substantial, i.e. cosmetic, and keep bots away from performing such edits). Because the order of categories is visible at the bottom of a page rearranging the order of categories would fall outside the proposed new definition of COSMETICBOT, while "visible" = "substantive" according to the proposed definition. Whether a particular (series of) edit(s) is cosmetic is part of the assessment when a new bot task is proposed for approval. If in doubt, the task should be presumed "cosmetic", unless the proposer of the task can demonstrate (e.g. by "consensus" reached in a previous discussion) that it can be regarded as substantive. The onus of "proving" that a series of annoying edits which have never been demonstrated to be substantive should not be left to the non-bot editor: it should be up to the bot-assisted-editor to "prove" that the tasks they are proposing for approval have a consensus of not being perceived as cosmetic. In other words, the current proposal is too much written from the perspective of the bot-editor, who is still not recognising the annoyance they can cause by non-substantive edits. --Francis Schonken (talk) 09:09, 3 April 2017 (UTC)

  Bots still need approval for their tasks. That re-arranging categories is a minor, rather than a cosmetic edit, doesn't mean a bot would be approved for such changes, or that such changes would have consensus to be done by bots. The bot requirements still apply. I'm not sure where you get the idea that such bots would be approved. Headbomb {t · c · p · b} 10:41, 3 April 2017 (UTC)

  Re. "...[[WP:BOTREQUIRE|bot requirements]]..." – argh, just circular reasoning: WP:BOTREQUIRE is a redirect to a (section of) Wikipedia:Bot policy. We're deciding here what these "requirements" are, for (fully automated) bots as well as semi-automated (some way bot-assisted or not) edits: these "requirements" for bots belong to the "policies and guidelines", mentioned in the 5th bullet of the list of these requirements, which includes, of course, the entire "bot policy" page. Referring to the same policy page as a "solution" to what is proposed for rewrite (on the same page) doesn't help a bit. So I continue my opposition to the proposed rewrite as it is apparently a bit clueless regarding the ground of the matter. Some points for consideration:

  1. I'd take "non-substantive" and "cosmetic" as synonyms for this policy (while that is closest to how this would be generally understood – I'm not opposed, in general, to some concepts having specific meanings in Wikipedia's guidance, but for this one I see no need to initiate a specific non-intuitive concept while all of it can be explained with concepts as they are usually understood in natural language);
  2. "cosmetic" has little to do with whether it is "visible" or not: if anything, "cosmetic" always refers to something that is "visible", whether only in edit mode or also in reading mode (if there's no "difference" in edit mode then one can't show a "diff", so in that case there isn't even an edit).
  3. "cosmetic", a.k.a. "non-substantive", covers a wide range of things, including e.g. changing "autumn" to "fall" for no obvious reason or slightly modifying the background colour for a column in a table, while "substantive" edits can be invisible (e.g. setting an appropriate "DEFAULTSORT" parameter for an article that has a diacritic in its article title).
  4. I think the policy can give some well-chosen examples of "cosmetic" vs. "substantive", but a definition that can be applied mechanically is not possible (that should be left to approval procedures, particular guidance, RfC's if necessary etc.)
  5. for human "one edit at a time" editing WP:BOLD would generally cover (or at least: excuse) cosmetic edits that aren't contradicted by guidance or some particular consensus; WP:BOLD does however not cover for automatons: they need permission prior to making automatic/repeated edits, including cosmetic edits.
  6. there should be no automatic granting of cosmetic edits: either the type of edit is precisely described as part of the approved bot task, or it is deemed "not granted".
  7. semi-automatic edits (such as assisted by AWB) need the same permissions regarding cosmetic edits: either the cosmetic edit is allowed or it isn't, to be determined before dozens of editors start applying the same type of edit multiple times.
  8. cosmetic edits can be:
     • generally allowed, e.g. setting the background colours of a series of navboxes to the same pre-approved colour scheme (a "generally allowed" cosmetic change is, to all extents and purposes, treated in the same way as a substantive change)
     • generally disallowed, e.g. adding whitespace after paragraphs is generally useless, and thus disallowed (except where covered by specific guidance such as Help:Dummy edit)
     • allowed, but within certain limits when performed (semi-)automatically, e.g. some cosmetic edits when accompanied by generally approved substantive edits: the performed cosmetic edits, and the conditions under which they can be performed, need to be specified in the approval procedure (see point 7 above).

  --Francis Schonken (talk) 14:25, 3 April 2017 (UTC)

  There is no circular reasoning. The bot requirements are that they are a) harmless, b) useful, c) don't consume resources unnecessarily, d) performs only tasks for which there is consensus, e) adheres to relevant policies and guidelines, f) uses informative messages. Category re-shuffling fails d, and arguably b as well. Nothing in the proposed update to WP:COSMETICBOT changes that. Cosmetic changes are changes that only affect the edit-window text, but not the output of the page. If a change creates a visible difference, it is by definition non-cosmetic. Changing "Autumn" to "Fall" or vice-versa is most definitely not cosmetic, because clearly that is an entirely different word used. Headbomb {t · c · p · b} 14:53, 3 April 2017 (UTC)

  The proposal proposes to modify d (i.e. tasks having consensus), so, really, no, the more you entangle yourself in circular reasoning, the more I oppose the current proposal, for its apparent cluelessness, a cluelessness that is, for clarity, further highlighted by your latest replies. --Francis Schonken (talk) 15:10, 3 April 2017 (UTC)

  It doesn't modify d. It clarifies what the current situation is with d and cosmetic edits in general. Call me and the rest of BAG clueless all you want, but the fact remains that the proposed update reflect current practices. Headbomb {t · c · p · b} 15:31, 3 April 2017 (UTC)

  ? Afaik, problems with current practices prompted the idea of a rewrite. Seems there is too little guarantee that the proposed rewrite would lead to improved practices. --Francis Schonken (talk) 16:10, 3 April 2017 (UTC)

  What led to the current rewrite is that the existing policy is unclear as to what does or does not constitutes a cosmetic edit. Problems arose because of this unclarity, combined with a big case of WP:IDIDN'THEARTHAT, not because the community's expectations with regards to cosmetic changes were off. Headbomb {t · c · p · b} 16:24, 3 April 2017 (UTC)

• Oppose. TL;DR – I don't have time to get bogged down with reading about Parkinson's law of triviality, the bike-shed effect and opportunity cost in microeconomic theory, and try to figure out what the heck that has got to do with bots. Isn't the problem with watchlists? Where's the RFC to make fixing the damn watchlists the top priority? wbm1058 (talk) 21:09, 3 April 2017 (UTC)

  Even if the watchlist issue was fixed (T11790), that wouldn't make the issues with cosmetic edits go away, nor is refusal to read the policy a reason to oppose it. Headbomb {t · c · p · b} 21:24, 3 April 2017 (UTC)

  Do you have any comments on the actual revision, rather than not wanting to read articles that explain certain terms and complaining that some other tangentially-related bug hasn't been fixed? Anomie⚔ 22:04, 3 April 2017 (UTC)

  Where's the Reader's Digest / {{nutshell}} definition of "cosmetic edit", or is it still "I know one when I see one"?

  And tell me, what is inherently bad about "cosmetic edits", other than that they clog watchlists and there's no means of filtering them out of watchlists? wbm1058 (talk) 23:52, 3 April 2017 (UTC)

  The nutshell version is above; it's the bullets. If it helps, try reading the bullets preceded by "Changes that are typically considered cosmetic do not modify any of:" – Jonesey95 (talk) 00:03, 4 April 2017 (UTC)

  The bullets list edits that are typically considered substantive. Can you make a bullet-list of edits that are typically considered cosmetic? wbm1058 (talk) 00:48, 4 April 2017 (UTC)

  There's very little point in doing that. If it doesn't do one of the things listed in the bullets, it's likely cosmetic. When in doubt, ask. That's pretty clear. Headbomb {t · c · p · b} 00:56, 4 April 2017 (UTC)

  I reread that, and it is hard for me to think of any types of edits that are not listed in the bullets. From what I gather there are two or three types of cosmetic edits. (1) substituting a template, (2) bypassing a template redirect, and though not mentioned here, I suppose a null edit is also cosmetic. Though I don't see how anybody but maybe server operations would see those. So as long as my bot doesn't subst templates or bypass template redirects, without special approval to do that, I'm good to go, right? wbm1058 (talk) 19:07, 4 April 2017 (UTC)

  See a user's request of me at User talk:wbm1058#Please update the source code of RMCD bot. They are asking me to change the format of the way my bot writes section headings. Is this a cosmetic edit? That's a "user-facing interface" of Wikipedia, and a user has asked me to change it, so I guess it's not cosmetic. wbm1058 (talk) 19:25, 4 April 2017 (UTC)

  That is indeed a cosmetic edit. Nothing rendered changes. People might prefer that headings are spaced (I have no idea what is the majority use here), and that's fine to update the behaviour of a bot to fall in line with expectations, but the bot wouldn't be allowed to start doing header spacing on its own, if that's the only thing it did. Headbomb {t · c · p · b} 19:45, 4 April 2017 (UTC)

  There are plenty of types of cosmetic edits. For instance

  • Changing parameter order {{cite journal |last=Smith |first=J. ...}} → {{cite journal |first=J. |last=Smith ...}}
  • Bypassing redirects {{WP Astronomy}} → {{WikiProject Astronomy}}
  • Trivial whitespace edits Lorem ipsum.__Lorem ipsum → Lorem ipsum._Lorem ipsum <code><nowiki> (where _ is a space)
  • "Single line" refs {{cite journal |last=Smith |first=J. ...}} → multiline refs {{cite journal \n|first=J. \n|last=Smith \n...}}
  • Templatifying measurements 10 m to {{val|10|u=m}}

  Your bot would be good to go if it actual produces changes that readers can see. Or if it obtained consensus that such even though nothing changes for readers/consumers of Wikipedia, that the edit provides some kind of benefit that warrants the annoyance. Null edits aren't cosmetic, since they show up nowhere except in server logs. Headbomb {t · c · p · b} 19:40, 4 April 2017 (UTC)

  • Suggest change the "user-facing interfaces" of Wikipedia to the "reader-facing interfaces" of Wikipedia to make it clear this does not include the Wikitext user-facing interface.
  • It's OK to add a newline to a ref. if a reader sees it, right? The parser strips those newlines just like spaces, so those newlines are only seen when editing the Wikitext? So it seems the rules boil down to three broad classes of cosmetic edits... (1) changes that are inside templates, i.e. what happens between {{ and }} which aren't included in the bullet-list of exceptions (2) replacing plain-text with a template that produces the same output, or vice-versa (3) adding or removing newlines or spaces in the Wikitext, anywhere that the parser "eats" them. Does that cover everything? wbm1058 (talk) 20:39, 4 April 2017 (UTC)

  If you want a broader rule of thumb, focus on bullet 1. If a reader can see a rendered difference online, in print, with a screen reader, or via any other means of consuming Wikipedia, it's not cosmetic. If you can't tell two versions them apart, it's cosmetic. Bullets 2-4 are more technical in nature, but all comes down to the same idea. Did the edit affect something tangible, or did it just make the edit window prettier? If yes, it's not cosmetic. If no, it's cosmetic. Headbomb {t · c · p · b} 20:48, 4 April 2017 (UTC)

• OK, though I'd still prefer that this lose the WP:OVERLINKs to the "bike-sheds" at the top. I'd encourage you to supplement the official guideline with the supplemental information that I've teased out of you just above, as that will be much more clear to editors with just a passing interest in this. I'm having trouble understanding why anyone would want to make "cosmetic" edits a priority. There are so many more things of substance needing to be changed that I could never in a hundred years (or at least before the "singularity"), imagine having cleared all the higher-priority work lists such that these types of changes might bubble to the top. Is this all because of some bug(s) in AWB that these happen where AWB should have just skipped a page? wbm1058 (talk) 21:23, 4 April 2017 (UTC)

  Some people are quite OCD about how things 'ought' to be, and these edit will annoy the hell out of people, especially if they are done on large scales. Very few people do them on purpose, but it can happen. Someone might decide infoboxes look nicer with all the = signs aligned, code an AWB routine for it, then go on an editing spree to "cleanup" articles of ugly code. In practice, most of the time, it's caused by bad skip conditions, or a bad find/replace logic. When complaints arise, having a better-defined guideline on what is or isn't a cosmetic edit will help both complainers and bot coders to resolve the dispute on whether it was fine for the bot to do the edit it did, or if the bot needs to be tweaked to prevent trivial edits. Headbomb {t · c · p · b} 22:24, 4 April 2017 (UTC)

  They also clog page histories, have a slight chance of making vandalism harder to revert, and even if they fix the 'watchlist issue', they would still clog the watchlists of people who want to review bot edits to catch malfunctions with pointless clutter. Headbomb {t · c · p · b} 00:07, 4 April 2017 (UTC)

• Good — the previous version was much vaguer. Might want to include some text that would encourage wider community input in suspected COSMETICBOT situations, but that's also probably something BAG could do on its own. I don't see how opposing based on shortcomings in the interface is going to help us here, as bots on Wikipedia, from a philosophical standpoint, are there to balance the wishes of the community with the technical shortcomings of the software as a whole. I think it's a good idea to point out examples of what frequently is considered a substantial edit, as policies are usually descriptive, not prescriptive. --slakr^\ talk / 21:48, 3 April 2017 (UTC)
• Support As a BAGger and as one of the original drafters of the text. The rewrite is needed because many, including ArbCom, have expressed dissatisfaction with the current policy's lack of definition for what is and is not cosmetic. Anomie⚔ 22:04, 3 April 2017 (UTC)
• Oppose the added exceptions (e.g. changing x, e.g. changing y, etc) just make more and more loopholes to get around doint pointless edits. Every single one of the exceptions need to be listed (on a standalone list, if needed), so people who've been dragged to ANI time and time again (e.g. Magioladitis) or people who simply don't listen (e.g. @Bgwhite:) finally fully understand what they're doing. Then they're not exceptions, right? Lugnuts ^{Fire Walk with Me} 17:37, 7 April 2017 (UTC)

  I can drive a(n automated) bus through the giant loophole that is the current policy. Even if anyone agreed that this creates loopholes (doubtful--please name a potential one that you see otherwise you're just crystal balling), they are surely smaller in sum than the current policy is now. --Izno (talk) 17:46, 7 April 2017 (UTC)

  Lugnuts, you appear to be opposing this proposed policy, which is clearly an improvement, because it is not perfect. How do you propose to fix the definition of cosmetic edits? Fixing the definition was a clear recommendation of the recent Arbcom case. – Jonesey95 (talk) 13:43, 8 April 2017 (UTC)

  Simple - to have a full list of edits that would come under the scope of whatever the bot was doing. Maybe the experts at Arbcom have such a list. Lugnuts ^{Fire Walk with Me} 13:50, 8 April 2017 (UTC)

  That's neither 'simple', nor is it within ARBCOM's mandate to come up with such a list. Headbomb {t · c · p · b} 13:52, 8 April 2017 (UTC)

• Support with positive examples 22:52, 5 May 2017 (UTC) This proposal does a good job of explaining what a substantive edit is, but still only defines a cosmetic edit negatively as a non-substantive edit, without giving any examples. Would strongly support inclusion of User:Headbomb's examples above, either as-is or prosified. Apart from that, I have two questions: Is changing whitespace in bulleted vertical lists unique as a substantive whitespace change? Does removal of an unused template parameter affect its rendering to any screen reader or is this edit type cosmetic? I remeber that having come up. Snuge purveyor (talk) 01:00, 10 April 2017 (UTC) Also change second sentence from may be allowed in an edit that also includes a substantive change to are allowed..., unless that is no longer the intent. 01:02, 10 April 2017 (UTC):

  It's not unique. There are other whitespace changes that would affect rendering. E.g. having 2 line breaks between paragraphs instead of 1, having a linebreak in a link or wikilink (e.g. [[Bob<br>Marley]]), changing two non-breaking spaces in a row to one non-breaking space, etc. For the second part, the intent is may be allowed, because cosmetic edits are still subject to consensus and BRFAs. Removing underscores in wikilinks is fine as part of a substantive edit, converting templated citations from multiline to single line is not, even though both are cosmetic. Removing unused/unsupported template parameters is cosmetic since they don't affect rendering, but might be allowed depending on the specifics of the situation. Headbomb {t · c · p · b} 10:50, 10 April 2017 (UTC)

• Support without reservations as the new version is clearly superior to the old. However, it's always possible a loophole will be found, so I hope that this will be revisited as deemed necessary. Stevie is the man! ^{Talk • Work} 17:52, 11 April 2017 (UTC)
• oppose. That just muddies things up by spending far too long avoiding clarifying anything in the current version. The current text already links to examples at WP:GENFIXES, examples which are missing in the new version. The last two paragraphs make no sense. Fixing up templates before deletion is not a cosmetic edit, but necessary housekeeping. And this policy is not a [human] editing guideline, so that guidance is misplaced.--JohnBlackburne^words_deeds 13:47, 12 April 2017 (UTC)

  "Far too long avoiding clarifying anything"? That's literally the first thing it does after a two-sentence preamble. Linking to WP:GENFIXES clarifies nothing, since GENFIXES gives no criteria for what is a cosmetic edit or not. There are dozens of cosmetic genfixes, and dozens of non-cosmetic genfixes. Headbomb {t · c · p · b} 13:53, 12 April 2017 (UTC)

• mild oppose Withdrawn. See my post below. (invited by the bot) Appears to just open up a loophole. "Mild" because I'm no expert here. North8000 (talk) 19:10, 24 April 2017 (UTC)

  North8000 What loophole does it open? Especially compared to the previous version? Headbomb {t · c · p · b} 19:25, 24 April 2017 (UTC)

  Again, as I said before with "weak" and "I'm no expert here" I don't have expertise here, but here's how I read the proposed change in that respect. They both say that you can only have bots do cosmetic changes when they are doing substantive changes at the same time. Then the change defines "substantive changes" very very broadly, to include many things that people might call very minor changes. Sincerely North8000 (talk) 20:00, 24 April 2017 (UTC)

  Yes, they can be minor changes, but visible ones, which require BRFAs for them. That hasn't changed from before, but it is now much clearer what exactly cosmetic vs non-cosmetic refer to broadly speaking. If this proposal isn't acceptable, what then, would be? To keep the current one? While this may not be 'perfect', it's certainly an improvement over what is the current policy. If issues are found with the new version, we can always refine things later. Headbomb {t · c · p · b} 20:34, 24 April 2017 (UTC)

  I'll withdraw mine. This is a complex proposal (including on how it interacts with other policies, practices and guidleines) in an area where I don't have sufficient expertise and experience. North8000 (talk) 20:52, 24 April 2017 (UTC)

• Unqualified support, per the above. Other users above seem to be shooting for the perfect rather than the better. This change does improve the otherwise undefined section, and will allow better communication between bot ops and others when there is a question about cosmetic edits. --Izno (talk) 12:15, 25 April 2017 (UTC)

Proposal for a different approach

In the approach I would like to propose the update to the policy would be in two parts:

1. define Cosmetic edit in Wikipedia:Bot policy#Definitions
2. write the rules regarding cosmetic edits in Wikipedia:Bot policy#Cosmetic changes (a.k.a. WP:COSMETICBOT)

The definition (#1 above) could be something in this vein:

---

• A Cosmetic edit is an edit that doesn't really change the substance of the content of a page, but only how the material on the page is presented. The presentation change may be only visible in edit mode (e.g. changing a section title from ==Title== to == Title ==), or also in the saved page (e.g. changing Aug 15 to 15 August). Some cosmetic edits are forbidden or discouraged (see e.g. MOS:TIES), while others are encouraged, and are sometimes even mandatory (see e.g. MOS:ARTCON). Many cosmetic changes are however neither mandatory nor discouraged, but reflect an editor's preference on the way material is presented (e.g. table syntax allows to separate cells in a row by a double pipe, or by a single pipe on a new line)

---

And the update to the COSMETICBOT section something in this vein:

---

Any bot may generate false positives (i.e. the bot changes something that shouldn't be changed, or, at least, the change falls outside the intended task). The "acceptable" amount of false positives relates to the importance of the task at hand: e.g. a bot removing images that are copyvio would be given more slack when it accidentally removes an image that isn't actually copyvio but was wrongly tagged as such, while on the other hand a bot removing underscores before a pipe in a wikilink should be stopped when turning bluelinks into redlinks. Thus a first prerequisite for a bot performing cosmetic changes is that under no condition it should generate false positives: a potential presentation improvement is no advantage over a questionable malfunction or content issue.

For fully automated bot edits cosmetic changes are generally discouraged: the cosmetic change should at least be mandatory according to applicable stable guidance (preferably policy-level) or have a very broad consensus (e.g. a few supporters for a task that affects thousands of pages would not be enough). When a bot task is submitted for approval potential cosmetic aspects should be explicitly discussed during the approval procedure (failure to do so may lead to the task being put on hold until the bot would no longer performs cosmetic edits, or is granted permission for them), and the avoidance of false positive cosmetic edits should equally be discussed during the approval procedure. Cosmetic edits would generally be low-priority, so bots performing them should be put on hold, i.e. should be put on hold more easily than bots performing high-priority edits, when producing false positives, until issues are resolved. A bot performing an edit that is entirely cosmetic should always leave an operational link in the edit summary to the place where the cosmetic edits are granted, which should also contain a human-readable explicit description of the cosmetic task (e.g. "see WP:MOS" would be too vague as an edit summary for a cosmetic task, and a link to a page with unexplained python code would be too technical for most editors wondering about the sense of a series of cosmetic edits).

Cosmetic edits performed in an assisted or semi-automated setting should be approved bot tasks (in which case the same conditions as for fully automated edits apply) or should at least generally be experienced as beneficial to the encyclopedia. When performing cosmetic edits without general bot task approval, at least all of the following applies:

• The type of edit should be encouraged or mandatory according to applicable guidance, or at least have consensus.
• The edit summary should provide a link to the applicable guidance and/or the talk page section that establishes consensus about the task.
• Optional cosmetic edits (i.e. cosmetic edits that reflect the presentation preferences of a group of editors without established firm consensus) should not be performed in an assisted or semi-automatic setting without a substantial change, or without an edit with an established consensus, being performed on the same page in the same edit. Stand-alone optional cosmetic edits should not be performed in an assisted or semi-automatic setting.
• Cosmetic edits that are discouraged or forbidden by applicable guidance should be avoided altogether: even a local consensus to override general guidance can not be accepted as a reason to perform such cosmetic edits in an assisted or semi-automatic setting.

---

Advantages of this approach (imho!)

1. gives a rationale why bots and cosmetic edits are often (but certainly not always) at odds
2. better distinction between desirable and undesirable cosmetic edits
3. more intuitive (i.e. less an artificial in-Wikipedia construct) w.r.t. concepts such as "cosmetic", "substantive", etc.
4. less technical linguo, for better understandability by the average editor
5. integrates better with current provisions of the bot policy

--Francis Schonken (talk) 11:24, 5 April 2017 (UTC)

Oppose I don't like your version. Instead of clearly defining cosmetic edits, which is the problem that's being tried to solve here, it continues the situation of having a vague semi-definition. And your vague semi-definition does not fit with current practice as I understand it. Your wall of text trying to set policy is far too rambling. Addressing your claimed advantages, IMO you have failed at actually doing #1, #2, and #5; #3 is debatable; and #4 you succeeded in "less technical lingo" but IMO failed at "better understandability". Anomie⚔ 12:13, 5 April 2017 (UTC)

Oppose, per Anomie pretty much. It also spectacularly fails at defining a cosmetic edit (Aug 15 → August 15 is not cosmetic at all).Headbomb {t · c · p · b} 13:57, 5 April 2017 (UTC)

Oppose as both insufficiently specific and insufficiently correct. If Aug 15 to 15 August is cosmetic, so too is every minor wording change copyeditors frequently make. Snuge purveyor (talk) 01:06, 10 April 2017 (UTC)

• Opppose. This does not improve either the current version, nor the one proposed one above. This does not describe the current practice, introduces a lot of ambiguity, and prescribes a lot of new restrictions. I don't think this correctly grasps what a "cosmetic" edit is versus something like "substantive". Almost all of this is already covered by typical BRFA process and this won't help with WP:MEATBOT violations anyway. I concur with Anomie that this doesn't fit its own the criteria listed. —  HELLKNOWZ  ▎TALK 11:41, 10 April 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Venue change for bot appeals and reexaminations

The current policy (Wikipedia:Bot_policy#Appeals_and_reexamination_of_approvals) requires bot approval appeals to take place at Wikipedia talk:Bots/Requests for approval. I would like to change this venue to the Wikipedia:Bot owners' noticeboard to keep in in line with other issues that are discussed there, and to ensure a larger audience. I'm fine with leaving a requirement to send "notice" to WT:BRFA of such discussions. Any thoughts on this proposed change? — xaosflux ^Talk 18:56, 12 April 2017 (UTC)

Sensible. –xeno^talk 21:16, 12 April 2017 (UTC)

It's something I've been meaning to tackle for a while. To me it doesn't​ make sense to have this in the BRFA page, but i never could decide between creating a de-BRFA process, or something else. Having the discussion at BOTN makes perfect sense though. I'd be for that. Headbomb {t · c · p · b} 23:27, 12 April 2017 (UTC)

Support. It should be specified whether existing discussions should be moved or not (if this is enacted). I support moving ongoing discussions while leaving a notice of the move behind. Larger audiences are always good. ~ Rob₁₃^Talk 22:39, 12 April 2017 (UTC)