Wikipedia talk:Bot policy

This is an old revision of this page, as edited by Lowercase sigmabot III (talk | contribs) at 00:23, 29 May 2017 (Archiving 1 discussion(s) to Wikipedia talk:Bot policy/Archive 26) (bot). 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 · 26


Control proposals


Archive policy


Archive interwiki (also some approvals for interwiki bots)

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

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

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)

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


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)Reply
The goal should be prevent cosmetic edits in the first place, of course. — Carl (CBM · talk) 13:32, 26 March 2017 (UTC)Reply
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)Reply
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)Reply
@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)Reply

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

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

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)Reply
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)Reply
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)Reply
  • 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)Reply
    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. ~ Rob13Talk 07:04, 28 March 2017 (UTC)Reply
    When is it acceptable to have something like 102 be declared as 10<sup>2</sub>. How is that controversial? Headbomb {t · c · p · b} 09:52, 28 March 2017 (UTC)Reply
    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)Reply
  • Support new version it's a big effort to make things clearer. -- Magioladitis (talk) 07:33, 28 March 2017 (UTC)Reply
  • 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)Reply
  • 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)Reply
  • 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)Reply
  • 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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    ? 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)Reply
    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)Reply
  • 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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
    • 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)Reply
    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)Reply
  • 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)Reply
    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)Reply
    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)Reply
  • 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. --slakrtalk / 21:48, 3 April 2017 (UTC)Reply
  • 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)Reply
  • 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)Reply
    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)Reply
    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)Reply
    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)Reply
    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)Reply
  • 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):Reply
    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)Reply
  • 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! TalkWork 17:52, 11 April 2017 (UTC)Reply
  • 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.--JohnBlackburnewordsdeeds 13:47, 12 April 2017 (UTC)Reply
    "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)Reply
  • 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)Reply
    North8000 What loophole does it open? Especially compared to the previous version? Headbomb {t · c · p · b} 19:25, 24 April 2017 (UTC)Reply
    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)Reply
    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)Reply
    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)Reply
  • 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)Reply

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

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)Reply
Oppose, per Anomie pretty much. It also spectacularly fails at defining a cosmetic edit (Aug 15August 15 is not cosmetic at all).Headbomb {t · c · p · b} 13:57, 5 April 2017 (UTC)Reply
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)Reply
  • 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)Reply
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)Reply

Sensible. –xenotalk 21:16, 12 April 2017 (UTC)Reply
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)Reply
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. ~ Rob13Talk 22:39, 12 April 2017 (UTC)Reply

BAG nomination

Please note a nomination for Bot Approvals Group membership is active. Feel free to comment here. ~ Rob13Talk 22:46, 26 May 2017 (UTC)Reply

History

Historically, being flagged as a bot account was distinct from the approval process; not all approved bots had that property. This stemmed from the fact that all bot edits were hidden from recent changes, and that was not universally desirable. Now that bot edits can be allowed to show up on recent changes, this is no longer necessary.

It is not my recollection that "all bot edits were hidden from recent changes". Comments?

All the best: Rich Farmbrough, 10:27, 28 May 2017 (UTC).Reply

It looks like RecentChanges had a 'hidebot' option as far back as the initial revision checked into SVN, although the watchlist didn't get such an option until August 2005 at the earliest.
But given the timing of the change to make flagging non-optional, it seems more likely that Dycedarg was mistaken in adding that text: rather than becoming non-optional due to a change in whether bot-changes are shown, it became non-optional because of the then-recent addition of the ability for a flagged bot to not flag edits. This old discussion seems to support that. Anomie 11:26, 28 May 2017 (UTC)Reply
  NODES
admin 2
COMMUNITY 4
Idea 5
idea 5
Note 2
Project 7
USERS 2