Jump to content

Wikipedia talk:Bot policy/Archive 26

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 20←Archive 24Archive 25Archive 26Archive 27Archive 28→Archive 30

Defining cosmetic changes

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

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

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

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

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

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

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

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

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

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

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

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

I think the above sections may be missing the point

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

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

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

Anomie

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

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

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

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

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

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

A draft rewrite

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

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

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

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

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

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

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

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

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

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

Policy on edit rate

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

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

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

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

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

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

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

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

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

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

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

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

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

Bot wars on Wikipedia

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

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

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

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

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

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 identifies 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 if 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. ~ Rob13Talk 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. ~ Rob13Talk 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)

Cosmetic changes to the wikitext are sometimes the most controversial, either in themselves or because they clutter page histories, watchlists, and/or the recent changes feed with edits that are not worth the reviewing time spent. Such changes should not usually be done on their own, but may be allowed in an edit that also includes a substantive change.

Changes that are typically considered substantive affect something visible to readers and consumers of Wikipedia, such as

  • the output text or HTML in ways that make a difference to the audio or visual rendering of a page in web browsers, screen readers, when printed, in PDFs, or when accessed through other forms of assistive technology (e.g. removing a deleted category, updating a template parameter, changing whitespace in bulleted vertical lists);
  • the "user-facing interfaces" of Wikipedia, such as category listing or on-wiki and external search engine results (e.g. changing category sort keys, noindexing, search engine summaries/snippets, or page images);
  • the "administration of the encyclopedia", such as the maintenance of hidden categories used to track maintenance backlogs (e.g. changing {{citation needed}} to {{citation needed|date=September 2016}}); or
  • egregiously invalid HTML such as unclosed tags, even if it doesn't affect browsers' display or is fixed before output by HTML Tidy (e.g. changing <sup>...</sub> to <sup>...</sup>)

while changes that do not are typically considered cosmetic. Minor edits are not usually considered cosmetic but still need consensus to be done by bots.

Consensus can, as always, create exceptions for particular cosmetic edits. For example, the community frequently determines that a particular template should be substituted so it can be deleted, even though the substitution does not change the output of the page. Consensus for a bot to make any particular cosmetic change must be formalized in an approved request for approval.

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. Keep in mind that reverting a cosmetic edit is also a cosmetic edit. 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. Report the issue to the bot operator instead.

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 [6]. 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 [7] or even 1000 of these edits [8] 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. ~ Rob13Talk 07:04, 28 March 2017 (UTC)
    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)
    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 (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.--JohnBlackburnewordsdeeds 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.

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)

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

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)

Obvious mistake

The meaning of "visible to readers and consumers of Wikipedia" is clearly explained in the policy. Stop, Magioladitis, before things get to WP:POINT. Anomie⚔ 12:36, 12 June 2017 (UTC) Endorse closure. If you need clarifications, the way to go about this is not to unilaterally change the substance of a widely advertised and supported policy that was subject to an RFC less than a month ago. Headbomb {t · c · p · b} 14:39, 15 June 2017 (UTC)

The following discussion 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.

I just fixed an obvious mistake in COSMETICBOT. "Visible" can't be right. We have bots that add date parameters, etc. -- Magioladitis (talk) 00:00, 12 June 2017 (UTC)

I've undone that edit. Those bots have explicit approval to do these activities. Primefac (talk) 00:02, 12 June 2017 (UTC)
Primefac Exactly. So in general these edits are not considered "cosmetic". This policy applies to bots. -- Magioladitis (talk) 00:03, 12 June 2017 (UTC)

Primefac You should know that all bots need explicit approval. -- Magioladitis (talk) 00:04, 12 June 2017 (UTC)

Anomie why don't you let more editors to comment on this? Right now the trick some people use to jump in every discussion, claim the matter is "obvious" and do not let more members of the community to participate. Right now, we have a policy what changes by consensus instead of a policy that reflects consensus. -- Magioladitis (talk) 14:17, 15 June 2017 (UTC)

Because there's nothing that needs to be commented on here except for your misjudgement in making such a poor edit. I don't really want to have to have a discussion about topic-banning you from bot-related discussions for continuing to make disruptive edits, comments, and proposals, but for that you'll need to stop doing so. Anomie⚔ 14:34, 15 June 2017 (UTC)
Seconded. This is becoming very WP:IDIDNTHEARTHAT. Headbomb {t · c · p · b} 14:36, 15 June 2017 (UTC)
Anomie I try to understand why my opinion on bot editing should be banned. Especially, when the policy recently changed exactly due to my comments and editing. I have contributed heavily in forming today's policy. -- Magioladitis (talk) 14:37, 15 June 2017 (UTC)

Headbomb Wikipedia works by consensus (See Wikipedia:BOLD, revert, discuss cycle). I do not plan to stop until consensus is achieved. Wikipedia has hundreds of editors. I want to inform about a consensus that changed to disallow working bots and kicked editors out of Wikipedia. -- Magioladitis (talk) 14:39, 15 June 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. –xenotalk 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. ~ Rob13Talk 22:39, 12 April 2017 (UTC)
I've updated the page to say WP:BOTN. Headbomb {t · c · p · b} 02:22, 16 June 2017 (UTC)

Replace cosmetic with a less misleading name

Moved from User talk:Anomie/Sandbox2. Anomie⚔ 12:37, 12 June 2017 (UTC)

One of the problems of the cosmetic bot policy is that we use the word cosmetic to mean the opposite of its real world meaning. In the real world a change that didn't alter the meaning of anything but subtly changed its visual appearance would be considered a cosmetic change. The equivalent of refreshing lipstick or dabbing on some rouge. In wiki speak it is almost the opposite, a change that doesn't have any visible effect is described as cosmetic. I suspect some of the conflict about what is and is not a cosmetic edit is from editors who have taken a commonsense real world view as to what cosmetic means rather than read the policy. So if we are going to review and redefine cosmetic now would be a good time to replace it with a word such as trivial or invisible. Since a change to alt text or a subtle change of hue so that a table made sense to people with colour blindness might be invisible to most of us but nonetheless a useful edit, invisible wouldn't always be the right word, so I suggest we define and deprecate "trivial" edits. ϢereSpielChequers 20:32, 11 June 2017 (UTC)

This draft has been RFC'd and adopted. The live version is at WP:COSMETICBOT. If you have issues and suggestions with the adopted wording, the place to raise it is at WT:BOTPOL. But I don't see how cosmetic changes to the wikitext makes things unclear. Headbomb {t · c · p · b} 23:43, 11 June 2017 (UTC)
I'd say these changes are often cosmetic from the point of view of the person viewing the wiki source. I'm not saying we should be using words in a policy that are defined in terms of how the wiki source looks, rather than how the rendered article looks; I'm just guessing that might be why the word was chosen originally. Jc3s5h (talk) 13:29, 12 June 2017 (UTC)
"Non-rendered edits" would be clearer and more verbally precise. ~ Rob13Talk 13:43, 12 June 2017 (UTC)
True, but WP:NONRENDEREDBOT is a bit wordier (and a bit harder to read). At the very least, COSMETICBOT gives some indication of the type of edit. Primefac (talk) 13:46, 12 June 2017 (UTC)
How about visual changes? The shortcut would be WP:VISUALBOT. TheMagikCow (T) (C) 15:12, 12 June 2017 (UTC)
Straightforward and clear. I like it. Primefac (talk) 15:13, 12 June 2017 (UTC)
It could work, but it suffers from a similar problem: what we are trying to proscribe is "non-visual" (i.e. invisible) changes. All of the "not" statements would have to be reversed, since what we want is visual changes, and the current language is about prohibiting "cosmetic" changes. Not a big deal, but someone would have to propose a rewrite. It's not just a drop-in change of wording.
There may be a single word that can replace "cosmetic" that means what we want: "changes that do not affect the rendered output." I can't think of that word right now, but I think it exists. – Jonesey95 (talk) 16:18, 12 June 2017 (UTC)
At one point we have to recognize that Wikipedia has terms of art, and I'd surmise that if you don't understand the concept of cosmetic edits as used by the Wikipedian community, you probably shouldn't be operating a bot on Wikipedia. A "cosmetic edit", as far as the Wikipedia community is concerned, is an edit that makes the edit window prettier, but which otherwise doesn't substantially change the rendered page. We also give a list of changes typically considered substantial. If there is still confusion about what is or is not considered cosmetic, it's not inverting the explanation from what cosmetic edits are not and define them explicitly (which can't be done) rather than by contrast that will solve the issue. If there is a specific question about specific edits, the policy is to ask for clarification and BAG will give their opinion, and if needed, serve an an mediators between bot operators and editors with concerns of violations. If something is controversial, we'll ask for an RFC. Headbomb {t · c · p · b} 19:05, 12 June 2017 (UTC)
I don't doubt the bot operators understand what we mean by cosmetic edits. I'm not convinced that their critics do, and I think a name that means the same in the real world as on wiki would reduce tensions ϢereSpielChequers 19:36, 12 June 2017 (UTC)
If they don't know what it is, then they can be pointed to WP:COSMETICBOT which explains it. Headbomb {t · c · p · b} 21:44, 12 June 2017 (UTC)
Just to respond to Primefac, the shortcut could be anything. WP:NRBOT is shorter than WP:COSMETICBOT and no less intuitive than WP:AIV, WP:RFPP, WP:RFA, etc. ~ Rob13Talk 13:43, 15 June 2017 (UTC)

I agree that COSMETICBOT should change. As I have written before. The term "cosmetic" is misleading and was inherited by a pybot script. I am satisfied to see that people that claimed in the task that the term was crystal clear now understand the need for a better term. -- Magioladitis (talk) 08:27, 20 June 2017 (UTC)

I agree with WP:NRBOT. -- Magioladitis (talk) 17:40, 22 June 2017 (UTC)

Maybe try a different approach?

I think the community is ready to completely remove the entire section. We already have many bots working on maintenance without any further prerequisites. I am glad to read that the word "cosmetic" is not clear. -- Magioladitis (talk) 14:13, 15 June 2017 (UTC)

We had an RFC that closed with "a clear consensus exists to adopt the proposed language" not even a month ago. Headbomb {t · c · p · b} 14:16, 15 June 2017 (UTC)
Headbomb True. It was a big step forward to make clearer that some edits may not change the "Visual output" but they may still be useful and at the same time disconnect the policy form an old python script. Stepping o this I suggest that we should not move to the other direction and instead reject bots byt a policy that changes by consensus to allow bot proposals and judge afterwards if they are worth to be done as tasks or not. The idea of requiring "another more important edit" before an edit is done is not working in practice. Who is actually doing it? -- Magioladitis (talk) 14:21, 15 June 2017 (UTC)
"Not working in practice" - Then fix your bots. Pretty much everyone else is doing it without issues. Headbomb {t · c · p · b} 14:22, 15 June 2017 (UTC)
Headbomb The only way to achieve this is to demand an AWB to run with general fixes on which is not actually happening with very few exceptions. I am not even aware of bot combining tasks at the moment. Are you sure that the other AWB bot owners actually use general fixes in addition to a different task? -- Magioladitis (talk) 14:23, 15 June 2017 (UTC)
I am, for one. See MinusBot (talk · contribs), or CitationCleanerBot (talk · contribs) for instance. Headbomb {t · c · p · b} 14:24, 15 June 2017 (UTC)
Thanks for letting me know. I am still not satisfied by the number of "minor errors" fixed per day. -- Magioladitis (talk) 14:29, 15 June 2017 (UTC)

The previous RfC was a good start against all those that completely disagree with edits that do not change the visual output. Now it's time for a more decisive action i order to reflect the real consensus. -- Magioladitis (talk) 14:41, 15 June 2017 (UTC)

Because, after this period there should an aftermath. 35,000 unfixed pages maybe have thought us a lesson. -- Magioladitis (talk) 14:47, 15 June 2017 (UTC)

Magio, WP:DROP it. 1) The RFC reflects the 'real consensus'. 2) Several of those 35,000 fixes are extremely-low priority fixes that do not change anything in how the actual page is rendered, and does not concern anything that is actually broken. 3) I have spent months trying to get you to fix those things that everyone agree are actually broken and needs fixing, and even updated the WP:CWERRORS table to make which fixes are considered cosmetic and which are not crystal clear to you and others. You can even sort them by priority, and by whether or not they are cosmetic. If 35,000 unfixes pages somehow offends you, you have a path to reduce that number by a significant amount. Bitching about you being unable to fix [Error 2], of which there is currently only 1 instance, on your own, will do nothing to reduce that 35000 number. Headbomb {t · c · p · b} 14:54, 15 June 2017 (UTC)
Headbomb how did we end up having a backlong in high priority errors too? Who is responsible for that? I recently came across another discussion of an admin complaining to an editor because the editor was fixing pages in maintenance categories. Or recently I was advised that when a bot clogs I should use the nobots tag by the very same people who without reporting bugs played key role against bot editing. -- Magioladitis (talk) 17:14, 15 June 2017 (UTC)
I'm not sure I understand the question? I have a backlog? If you mean the checkwiki stuff, I suspect that has to do with either a lack of participation, the loss of bgwhite, or refinements to CW logic that now catches more instance of issues. One thing it doesn't have a thing to do with is WP:COSMETICBOT, since those fixes aren't cosmetic. For the rest, you're asking me to comment on things I know nothing about. I don't know what conversations you're referring to, concerning what edits, or what the nobots thing has to do with anything. Headbomb {t · c · p · b} 17:18, 15 June 2017 (UTC)
I still would like an investigation to what led to Bgwhite's loss. I did not get satisfying answers of how certain people may haave led to that. Anyway. this is offtopic but at some the commuity has to inestigate that. -- Magioladitis (talk) 11:35, 16 June 2017 (UTC)
If you want to know why bgwhite is gone, send them an email. From my recollection, they simply lost their patience with the ARBCOM case. Headbomb {t · c · p · b} 11:43, 16 June 2017 (UTC)
Which could be summarised as "hostile editing environment", I think. All the best: Rich Farmbrough, 10:28, 17 June 2017 (UTC).

Headbomb I already sent several emails to them and I also contacted WMF in person in Berlin for that case. I think that certain actions from certain people led to this situation. Losing Bgwhite, on eof the most active editors and programmers is not that simple as lost patience to a single case. -- Magioladitis (talk) 11:33, 20 June 2017 (UTC)

Please comment there. Headbomb {t · c · p · b} 17:55, 22 June 2017 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Bot_policy/Archive_26&oldid=1137404130"