Reworded proposal

Reworded proposal 2

I was reverted by Rob today (without receiving a notification, oddly...), and I have to say, I'm really confused: 1. What is that edit summary attempting to say? and 2. Why is the entirety of that edit so problematic that it was straight-reverted?

I know how Wikidata works (perhaps Rob does not--I have 30k-ish edits to that esteemed project and have been one-of-the-few Wikidata ambassadors to en.WP): Links for new pages are not added automatically to Wikidata by MediaWiki nor any of its extensions except through the CX extension. (Links are updated automatically when client pages are moved; perhaps that is what Rob is referencing?) But that is beside the point. My text attempts to make clear that, regardless of bot activity, one shouldn't add interwiki links to, change, or modify interwiki links on, the English Wikipedia. Perhaps that is not in-scope for this policy (I don't think I disagree with that idea), but the former text is, on the point, seriously confused about the current state of things; it appears to have been written during the initial bot runs to export the interwiki links from Wikipedia to Wikidata, a process which mostly-ended literal years ago. The text is also stated in a mostly negative sense of "don't do that" rather than "do do this; and also, don't do that", which is generally bad PAG (specification)-writing practice where avoidable (and perhaps concise).

The rest of the change I made: Regarding "running the most recent copy of pywiki", that seems like a "duh" or "no-brainer", and again sounds out-of-date. Ditto for the last sentence removed. (And, anyway, I see it as bad PAG-writing practice to call out specific frameworks.) There is at least one word redundancy in the current text which I also removed. Lastly, I moved the word "only" because of the above changes w.r.t. cleaning up Wikidata references. @BU Rob13: Please explain your reversion. --Izno (talk) 03:51, 25 June 2017 (UTC)

@Izno: This was my bad on not starting a discussion. I had intended to, but I got pinged on IRC about an OTRS matter and then got seriously side-tracked with that. Completely forgot. My issue with your edit was that I think it (unintentionally) changed the meaning of the section significantly, and I think it warranted further discussion on the clearest writing before pushing something live. Keep in mind this policy is about editing the English Wikipedia. When you changed "Operators of interwiki bots should no longer add interwiki links on the project" to "Interwiki bots should add interwiki links to Wikidata", that means start adding wikidata:PAGE IDENTIFIER HERE to articles. That is obviously not needed. I think you intended to write "Interwiki bots should not edit directly on the English Wikipedia but rather add interwiki links on Wikidata". That would be accurate, although I share your uncertainty on scope; is telling bots how to edit Wikidata in scope for the English Wikipedia policy page when the edits to Wikidata would support the English Wikipedia? That doesn't have an easy answer. I reverted because I thought the reword was unintentionally very misleading with the intent of hammering out something better on the talk page. Apologies for leaving you confused when I got side-tracked. ~ Rob₁₃^Talk 04:33, 25 June 2017 (UTC)

that means start adding wikidata:PAGE IDENTIFIER HERE to articles "to you", I think is an operative phrase, and adds intent that is not in my rephrasing (to articles). When I read it, it means "add interwiki links on Wikidata", because the links stored on Wikidata are the interwiki links. I think the word "to" is messing up your read of my intent and agree "on" is better. As for the scope question, there's no really good way around discussing what to do here, otherwise we leave a bot operator in the lurch (and the next sentence feels confusing without the proper grounding). I've reverted to my version and added some supporting text, as well as introduced a link to the Wikidata bot policy. --Izno (talk) 12:55, 25 June 2017 (UTC)

@Izno: My point is that this is an enwiki policy. If you're saying to make those edits on Wikidata, it doesn't belong in enwiki policy, likely. Can we not just delete the whole section at this point or replace it with the one-liner "Wikidata has replaced interwiki links. Bots should no longer add interwiki links to articles." ~ Rob₁₃^Talk 00:36, 26 June 2017 (UTC)

I am well-aware that this is EN.WP policy, not Wikidata policy (or any other wiki's policy)--as you might see below in my comment regarding "migrate". I'm not sure we need the section now in the form it is, but let's improve from your draft below. --Izno (talk) 12:57, 28 June 2017 (UTC)

A few comments:

• Yes, there was a difference of understanding in that should add interwiki links to Wikidata could be taken as meaning "should add interwiki links by entering them into Wikidata" or "should add local interwiki links pointing to Wikidata". IMO the latter interpretations is unlikely, especially since such links can't show up in the "languages" sidebar, but better wording is possible.
• Regarding removing the section, something is probably needed here since it's referred to from WP:GLOBALBOTS, especially since I don't see anywhere in Meta's bot policy specifying what exactly interwiki bots should do. Also, while new interwiki links shouldn't be added locally and the backlog has probably long since been taken care of, there may still be a potential for some bot work in removing interwiki links that out-of-touch humans add (and potentially adding them into Wikidata).
• The parenthetical about Wikidata's bot policy is probably not necessary here.
• The details on pywikibot probably aren't needed here anymore, since any interwiki bots should probably be global bots at this point. Perhaps that ("any interwiki bots should be global bots") is worth adding though.
• @Izno:, it's generally a bad idea to re-edit the page while discussing it. In the future, it'd be best if you didn't do so.

HTH. Anomie⚔ 12:22, 26 June 2017 (UTC)

Be careful when you cite BRD--there is a fourth element in the lead at Cycle that identifies how I was editing, since a) no one disputed the changes later in the paragraph and b) the changes earlier in the paragraph were quite open to revision, not-least because I expected them to be improved upon (and since the previous policy was categorically bad, as was borne out quite shortly after I started the talk section here). The rest of what you say is not particularly objectionable, per the below draft comments I made. --Izno (talk) 12:52, 28 June 2017 (UTC)

FWIW, I support the new wording generally speaking. Details could be a bit different, but the core idea of "put the interwiki stuff on Wikidata rather than on enwiki" is fine. Headbomb {t · c · p · b} 12:38, 26 June 2017 (UTC)

I totally support any wording that will in fact give instructions to editors to add interwikis directly to Wikidata instead of adding randomly in the text and waiting for a bot to do the cleanup. I would support any wording that would encourga eto move interwiki data from English Wikipedia to Wikidata too. -- Magioladitis (talk) 13:20, 26 June 2017 (UTC)

• Here's a proposed re-write of the section. Thoughts are welcome:

====Interwiki links====

Shortcut

• WP:INTERWIKIBOT

See also: Help:Interlanguage links, Wikipedia:Wikidata, and m:Interwiki bot

Interwiki bots should add interwiki links on Wikidata, rather than on the English Wikipedia, unless the task cannot be performed on Wikidata (such as linking to a section). Interwiki bots may remove interwiki links from English Wikipedia articles only if already present on Wikidata. Globally-approved interwiki bots are permitted to operate on English Wikipedia, subject to local requirements. Interwiki bots running in the Template namespace must ensure links are not transcluded on all pages using the template by placing them in the appropriate documentation subpage section, or non-included portion of the template if no documentation subpage exists.

This tightens up some of the wording, removes some extraneous information, and gets specific about what interwiki bots should currently be doing. As far as encouraging editors to add to Wikidata, I fully agree with that, Magioladitis, but there's got to be another better guideline or policy for that. This policy is related to bots only. ~ Rob₁₃^Talk 15:28, 26 June 2017 (UTC)

For encouraging editors, that place is WP:INTERWIKI. Headbomb {t · c · p · b} 17:36, 26 June 2017 (UTC)

Some comments on the draft:

1. There isn't a need for the date (I see you snuck that in, Headbomb). We document how it is now, not since when something changed.
2. migrate carries the wrong intent, as it implies a bot authorized here can edit there. remove alone would be better. Mostly what we need regarding a migrate like statement needs to be posed in the expository sense rather than the persuading or action sense, i.e., "this is how it works" and not "you may do this".

The rest appears not to bring a change to the policy from where it is now, so no comment there. --Izno (talk) 12:52, 28 June 2017 (UTC)

On the date, I'd thought I'd mirror WP:INTERWIKI, and figured it would be a bit less jarring with a date to explain when things changed, but it's pretty damn old, so I don't feel strongly about this. Headbomb {t · c · p · b} 13:35, 28 June 2017 (UTC)

You should probably be aware that here has been fairly recent discussion on Wikidata relating to the section-link types of issue. All the best: Rich Farmbrough, 17:45, 27 June 2017 (UTC).

• @Headbomb and Izno: I agree with the lack of date, though it's not a big deal either way. WP:INTERWIKI probably should have a date since it's an information page, so it documents more history than a policy page would. As for the more substantive migrate issue, I agree with you Izno. I propose just striking that whole bit from my proposed section (done above, so you can see what I mean to strike). "Migrating" is a subset of "removing" which involves simultaneously making an edit on Wikidata, so we cover both bases by just talking about "removing" in the general sense. Any objections to going live with this? It's more of a reword for clarity than any substantive change. ~ Rob₁₃^Talk 23:32, 28 June 2017 (UTC)

  Do the thing! --Izno (talk) 11:52, 29 June 2017 (UTC)

   Done Been a week and no-one else has gotten to it (and no-one vehemently disagreed). --Izno (talk) 15:43, 8 July 2017 (UTC)

Hello everyone!!! I just nominated myself for BAG membership. Your participation would be appreciated.

Wikipedia:Bot Approvals Group/nominations/Cyberpower678 3—CYBERPOWER (Message) 23:51, 9 July 2017 (UTC)

I've redirected this to WP:COSMETICBOT. The old version was [2], created by Magioladitis in violation of his topic ban. Whatever 'WP:COSMETICEDIT' would be as its own page in a final version, it would simply be restating the part defining cosmetic/non-cosmetic edits from WP:BOTPOL, making it completely redundant. Headbomb {t · c · p · b} 01:40, 13 July 2017 (UTC)

@Headbomb: as an outsider here, and with no position on the behaviour of Magioladitis, I do think that a definition of "cosmetic editing" that is clearly independent of the operation of bots is desirable. When I need to draw the attention of editors, particularly new editors, to the undesirability of making edits like removing double spaces in the wikitext or inserting/removing spaces after and before = in section headings when not accompanied by any substantive edits, it's not helpful to have to refer to a WP page about bots. Peter coxhead (talk) 17:10, 3 August 2017 (UTC)

@Peter coxhead: You're welcome to write an essay on minor non-significant edits; I would avoid calling them cosmetic edits if possible because that confuses things. There is no policy or guideline that prevents editors from making cosmetic-only edits manually, although it's not a good use of time. ~ Rob₁₃^Talk 17:14, 3 August 2017 (UTC)

@Peter coxhead: We have WP:ME which could probably host a bit about such edits, where it could be defined in a noob-friendly way "As a rule of thumb, if an article is rendered the same way before and after an edit, you've likely made a useless edit" (with have WP:USELESSEDIT as a shortcut).Headbomb {t · c · p · b} 17:23, 3 August 2017 (UTC)

It seems to me that WP:ME at present is carefully written to exclude "cosmetic edits"; see e.g. the list under "When to mark", so it could be confusing to add such material there. It needs some thought. I certainly wouldn't use "USELESSEDIT" as a short cut; this is too aggressive for new editors. Peter coxhead (talk) 06:20, 4 August 2017 (UTC)

The latest tech news says:

We will not use Tidy on Wikimedia wikis in the future. It will be replaced by June 2018. It could be earlier. Editors will need to fix pages that could break. You can read the simplified instructions for editors.

so there may need to be related bot edits, before then. Accordingly, I've removed the reference to TIDY from this policy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:42, 10 July 2017 (UTC)

This comes in a period that the main syntax fixing bot, Yobot, is a process of pre-approving all its tasks and that process is really slow. -- Magioladitis (talk) 15:46, 10 July 2017 (UTC)

Mag, you're not the only one with a bot. Primefac (talk) 16:19, 10 July 2017 (UTC)

Primefac ofcourse. I hope now this development motivates bot owners and editors to replace HTML tags with wikisyntax and/or other valid tags. -- Magioladitis (talk) 16:32, 10 July 2017 (UTC)

Obviously, if the functionality for the software to handle malformed HTML tags goes away, then we need to fix the tags. Having said that, I don't really understand what's going on. If we're developing an in-house tool, why can't most of these fixes be included in that tool? ~ Rob₁₃^Talk 18:39, 10 July 2017 (UTC)

Note that many of the fixes that editors need to make are context-dependent, and we need to be very careful about what actually needs to be fixed. Tidy is being replaced, not removed. Some of its functionality will remain. The BAG will need to scrutinize carefully each related BRFA to ensure the change is required by the upcoming update (or supported by the community as a cosmetic-only non-essential edit that deserves to be made anyway). ~ Rob₁₃^Talk 18:43, 10 July 2017 (UTC)

Most of the problem are already detected by CHECKWIKI and are fixed by willing editors. Still lattely we have huge backlogs. -- Magioladitis (talk) 06:40, 11 July 2017 (UTC)

I've reverted your edit to the policy page Andy. This policy was recently updated and the specific wording was agreed on, you should avoid making unilateral edits to such things. Prior to your edit fixes to HTML errors (including those which were handled by TIDY) were considered substantial (i.e. exempt from COSEMETICBOT) - why would you remove this exemption? - Kingpin¹³ (talk) 18:00, 12 July 2017 (UTC)

I removed no exemption, I removed an explanatory note which was already redundant, and which is now superseded. My reason for doing so is in my OP. You may disagree with it, but please don't pretend I was anything other than open about it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:19, 13 July 2017 (UTC)

Unilateral edits are a good thing. All the best: Rich Farmbrough, 13:12, 5 August 2017 (UTC).

Specific edit #1: /br tag changed to br/

Oh boy, a can of worms! Thanks for opening it, Andy.

Before Andy's bold edit, this edit would have been considered cosmetic, not to be made with AWB or by a bot without specific approval.

To be clear, there is currently no change to the rendered page when </br> is changed to <br />. Is there consensus that this edit, since it fixes an HTML coding problem that might result in broken pages after Tidy goes away, is no longer cosmetic? I'm OK with either outcome, I just want to make sure that we know what we are getting with this change. People might complain about watchlist-flooding when a helpful AWB gnome gets to work on Wikipedia:CHECKWIKI/WPC 002 dump and similar lists. – Jonesey95 (talk) 05:06, 11 July 2017 (UTC)

@Jonesey95: I think this is the opposite of the edit that should be made. The page on Meta says self-closing tags will no longer be valid, meaning (I think?) <br/> would no longer work. ~ Rob₁₃^Talk 10:16, 11 July 2017 (UTC)

Nevermind, FAQ states self-closing line breaks are fine. I don't see anything indicating that the other version (/br) is going away, so until we hear something to that effect, I would probably oppose this change. We need clarity on exactly what fixes are needed so we don't go out there changing a lot of stuff unnecessarily. ~ Rob₁₃^Talk 10:18, 11 July 2017 (UTC)

Personally, if tidy fixes it, and the tidy replacement fixes it, I'd have to say this is cosmetic yes. This wouldn't be egregiously invalid html, but rather an acceptable wikicode variant. Headbomb {t · c · p · b} 12:00, 11 July 2017 (UTC)

Certain self-closing elements are no longer valid. However, void elements may optionally contain a slash, and <br> is a void element. --Izno (talk) 12:13, 11 July 2017 (UTC)

Before Andy's bold edit, this edit would have been considered cosmetic. Re-read the policy, it is the other way around, before Andy's change such things were specifically exempt, he removed that exemption. - Kingpin¹³ (talk) 18:00, 12 July 2017 (UTC)

Any changes to br should be to make it <br> (no slash). Tim Starling wrote RemexHtml to replace Tidy, and he recommended <br> without a slash because it is simpler and is valid wikitext. Johnuniq (talk) 01:33, 13 July 2017 (UTC)

Unfortunately, the current syntax highlighter gadget doesn't handle <br> gracefully. Perhaps when the new syntax highlighter is available, there will be no functional difference between the unclosed and self-closed version of the br tag. – Jonesey95 (talk) 01:59, 13 July 2017 (UTC)

Until Html 5 specifies otherwise (whatever Tim thinks about the value of slashes), a slash is valid, so wikitext will no-doubt support it forever also. --Izno (talk) 02:32, 13 July 2017 (UTC)

Specific edit #2: b/ changed to /b

This edit changed an invalid self-closed <b /> to a correct </b>. See Category:Pages using invalid self-closed HTML tags, which contains pages that may break when Tidy goes away. There was no change to the rendered output. Is this change cosmetic? – Jonesey95 (talk) 05:10, 11 July 2017 (UTC)

If we know a software change is going to break pages, it seems useful to be proactive in fix the errors ahead of time, before such a change is deployed. Of course, after the change is deployed, the rendering will change, making the edit no longer cosmetic. Anyways, these kinds of edits seem fine and necessary to me. Legoktm (talk) 06:23, 11 July 2017 (UTC)

I totally agree. Having a good quality code (i.e. no broken tags) and not depending on how wicicode is converted to HTML is a good proactive action. -- Magioladitis (talk) 06:39, 11 July 2017 (UTC)

This one is completely fine. ~ Rob₁₃^Talk 10:18, 11 July 2017 (UTC)

I've had a bot working on the "invalid self-closing tag" issue across many projects (c.f. meta:User:Fluxbot/BADHTML. — xaosflux ^Talk 11:24, 11 July 2017 (UTC)

To @Jonesey95:'s question: these are primarily cosmetic today - but this has been a planned change for a long time, so community authorizations were sought in advance for the specific task. — xaosflux ^Talk 11:30, 11 July 2017 (UTC)

Personally, if tidy fixes it, and the tidy replacement doesn't fix it, it's not cosmetic in the sense of the policy. I wish whoever maintains CW Error #02 would update the logic to remove self-closing line breaks from it (or split 02 into 02a and 02b) though. Headbomb {t · c · p · b} 12:04, 11 July 2017 (UTC)

I've made this change and I've found it can be contextual--sometimes, <b/> is meant to be <br/>. A bot or semi-automatic change for this needs to include the leading <b> in the regex. I presume everyone here realizes that problem. --Izno (talk) 12:10, 11 July 2017 (UTC)

Yes, this is one extra reason why b tags should also be fixed. -- Magioladitis (talk)

Please be careful, Magioladitis. – Jonesey95 (talk) 13:07, 11 July 2017 (UTC)

Jonesey95 Why did you add this here? Did I do something? -- Magioladitis (talk) 12:02, 12 July 2017 (UTC)

This is a discussion about cosmetic edits. – Jonesey95 (talk) 14:11, 12 July 2017 (UTC)

Jonesey95 and potentially these edits will change the visual output. Moreover, if there is consensus we can fix those. Here, I am referring to the case a b tas was added instead of a br tag. -- Magioladitis (talk) 14:53, 12 July 2017 (UTC)

Agree @Izno: - <b> tags are not so easily replaced - they often need manual attention to address what is really trying to be done, fortunately (and I was somewhat surprised) enwiki isn't plagued by 'br' and 'b' errors anywhere as much as some of the other language projects - and when it comes down to throwing the kitchen sink at making visual layouts wikisource is the toughest! — xaosflux ^Talk 13:24, 11 July 2017 (UTC)

Probably due to the checkwiki and AWB efforts by certain editors. --Izno (talk) 15:08, 11 July 2017 (UTC)

Izno Exactly. I 've been fixing this for 6 years daily with the help og Bgwhite and others. AWB and WPCleaner provide functions for these. -- Magioladitis (talk) 12:04, 12 July 2017 (UTC)

Back to @Jonesey95: original question - yes its cosmetic today, but it isn't expect to be in the future - and cosmeticbot doesn't apply to casual cleanups made by editors anyway - if you were to start flooding recent changes (by not using a flagged bot and making a large number of highspeed edits) I'd expect you would get called out for disruptive editing. — xaosflux ^Talk 01:54, 13 July 2017 (UTC)

Please review [3].

While I don't think I've significantly changed the substance of ADMINBOTS, that section was rather long-winded and a bit out of date with how we actually do things. Highlights are

• I've clarified we need community approval for the task before going to BRFA, rather than show such approval at BRFA.
• Removed the "unapproved trial on your own account" bit. No one ever did this, or should do this.
• Removed the "users must/should/are expected to have technical expertise to comment" bit.
• Trim things that are already said elsewhere

The first two are the biggest changes. Revert if you feel this is controversial/needs more discussion.Headbomb {t · c · p · b} 22:51, 1 August 2017 (UTC)

I proposed a more substantive change below. This is something I've been thinking about for a bit; the section was quite outdated. ~ Rob₁₃^Talk 23:03, 1 August 2017 (UTC)

Some thoughts:

1. I'm not sure holding a consensus discussion at AN is appropriate given the number of people who may be interested in an adminbot whom are not admins. I think the better text was the former, or something like it (maybe "be held at a 'public' [insert good word there] location and advertised widely, at a minimum at WP:AN, WP:VPPRO, WP:VPT, and WP:RFC [if you want to get specific]").
2. "Without a demonstrated need" (or even a demonstrated "want"), a bot will be denied regardless of its admin flag, won't it (the spirit, if not wording, of WP:BOTREQUIRE)? This seems like fluff and should be removed.
3. The licensing and publicity of the code is and should be discussed elsewhere, presently at WP:BOTPOL#Configuration tips for generic bots (the last paragraph). That is also a sub-optimal location I think, since the licensing and publicity of the source is irrelevant to the bot's configuration (unless someone wants to change it). Perhaps both statements should be moved to WP:BOTREQUIRE, since one might expect this to be a requirement, even if it is not?
4. The whole paragraph at Administrators running a bot should babysit their bot during development and trial and terminate it at the first sign of incorrect behavior. Administrators are responsible for the behavior of robots that are allowed to run wild. Like for any bot, adminbot operators must exercise their best judgment when making alterations to their adminbot's logic, especially if they can significantly alter the bot's behavior. Administrators are allowed to run semi-automated tools (assisted use of administrative tools) on their own accounts but will be held responsible if those tools go awry. doesn't tell us anything new regarding who is responsible for an adminbot vice the entire rest of the policy (especially WP:BOTISSUE). Consequently, I think that paragraph should be removed.
5. What goes unsaid in the paragraph highlighted in item 4, and which should be stressed there instead of all that fluff, is WP:ADMINCOND (and/or WP:TOOLMISUSE), since that may be an additional significant issue affecting an administrator bot (which may require a consensus process a bit stronger than the simple updates you've done, but since we're looking at the section anyway...).

In other words to items 2-5, an adminbot is just a bot with the admin toolset (and not an admin with a bot toolset, IMO), and so the qualities of the admin toolset are what should be highlighted in this section. --Izno (talk) 03:18, 2 August 2017 (UTC)

Re:1/2 The idea was "do your homework" before you file it. Demonstrate a need/want for it, and do at before you get to BRFA. WP:AN seems like a natural place for this, but really any place is fine.

Re: 3 I think the point was that since adminbots have the potential to much more damage, code needs to be available for review. The concern is likely mostly theoretical, given that I can't recall one time this provision was invoked/needed. I didn't feel comfortable removing this part without an RFC, however.

Re: 4/5 Yes, it's kinda said elsewhere. It's not really critical to include in the current form, but a reminder that 'if you fuck up, it's on you' is good. WP:ADMINCOND (and/or WP:TOOLMISUSE) are good, but those often required intent.

I'll further trim/edit it. Headbomb {t · c · p · b} 03:56, 2 August 2017 (UTC)

@Izno: How about now? [4] Headbomb {t · c · p · b} 04:20, 2 August 2017 (UTC)

@Izno:? Headbomb {t · c · p · b} 11:37, 11 August 2017 (UTC)

I was waiting for other feedback before commenting again. I still think the changes are insufficient, but I don't care enough to push. --Izno (talk) 12:44, 11 August 2017 (UTC)

RfC on admin bot trials

Resolved

 – The proposal has been (in-general) unanimously supported with the proviso that a case-by-case evaluation is preferable.Winged Blades of Godric^{On leave} 16:54, 30 August 2017 (UTC)

A recent(ish) update to the MediaWiki software allows us to set temporary sysop flags (or any other flags) on accounts. This makes it much easier to trial adminbot tasks on a bot account without having to ensure the flag is removed afterwards. Should we change our procedures on adminbot trials to hold them on bot accounts instead of the operator's main account (when it is technically infeasible to trial without admin actions)? ~ Rob₁₃^Talk 23:03, 1 August 2017 (UTC)

• Support. Adminbot trials are currently the only instance in which we allow a fully-automated process to run from a main account. It's unexpected and unusual behavior when it happens. Now that we have the technical capability to provide the sysop flag for a set period of time, we can easily use this to trial adminbots like any other bot. I've already approved one trial using this method at Wikipedia:Bots/Requests_for_approval/RonBot to provide visibility and allow community comment. There were no issues. ~ Rob₁₃^Talk 23:03, 1 August 2017 (UTC)
• Depends - really depends on the situation, the same way we have certain bot trials that require the bot flag to be placed to actually conduct the trial. These should be evaluated case by case. — xaosflux ^Talk 23:29, 1 August 2017 (UTC)
  • That also works for me. Would you support adding it as an option in the policy while also leaving the existing options in place, Xaosflux? ~ Rob₁₃^Talk 23:43, 1 August 2017 (UTC)
    • I'm OK with this on an as-needed basis. It really depends on the task. And this has nothing to do with the "expiration" value existing - if it makes the most sense then I'm fine with it. All of the parts about ensuring there is well advertised community support should remain. — xaosflux ^Talk 00:04, 2 August 2017 (UTC)
• Support it generally. When to test what on what should be evaluated on a case by case basis.—CYBERPOWER (Message) 00:58, 2 August 2017 (UTC)
• Support Don't see why we shouldn't use the option when it makes sense to do so. Personally, I'd much prefer bot-testing to be done on the bot account. It would make it much easier to review, and probably make it easier for admin bot operators to not accidentally fuck up. Headbomb {t · c · p · b} 16:00, 4 August 2017 (UTC)
• Support: Not every admin bot will need this, but this will be a boon to others. The expiration time is a good safeguard and a case by case evaluation seems sensible. TheMagikCow (T) (C) 17:06, 4 August 2017 (UTC)
• Support the use of temporary flags (bot and admin if necessary) for trials. Using a different account for trials more closely duplicates production (since expiry is invisible to the user) and reduces confusion for users looking at the admin's contributions. – Train2104 (t • c) 23:11, 14 August 2017 (UTC)
  • @Train2104: I think bot flags are quite different and warrant their own discussion. During a trial, we often want community members to see edits and comment if they have an issue with them. We want to give people a chance to break silence if they wish to. For this reason, we may not want the edits of a trial to be bot-flagged and hidden from many watchlists. I'm not necessarily against it, but it's worth the full discussion and consideration of the pros and cons. ~ Rob₁₃^Talk 21:08, 24 August 2017 (UTC)
• Support: makes more sense. Dan Koehl (talk) 07:44, 15 August 2017 (UTC)
• Support. Perfectly reasonable update considering the new feature, a separate account with its own contribution history is the way it should be. Bright☀ 18:31, 24 August 2017 (UTC)

FYI https://en.wikipedia.org/w/index.php?title=Special:Log/Oshwah&offset=20171116210907&limit=17&type=&user=Oshwah 78.50.143.155 (talk) 21:12, 16 November 2017 (UTC)

Good job Oshwah, nice to see you found more after I blocked the first one. Primefac (talk) 00:41, 17 November 2017 (UTC)

Please see Wikipedia:Village_pump_(proposals)/Archive_145#Disable_messages_left_by_InternetArchiveBot. I would appreciate comments from anyone who reviews the suitability of bots for Wikipedia would be welcome.

Also, I would like to ask if anyone here can point at or describe any previous discussion about a goal that bots avoid consuming user time. In the current text of the bot policy there is a statement that bots editing wiki text might "they clutter page histories, watchlists, and/or the recent changes feed with edits that are not worth the time spent reviewing them". I wish to advocate more strongly that bots not do anything which consumes human time in a way that is not predicted in advance and discussed to get the consent of the community.

The Internet Archive Bot has posted 500,000 messages to talk page. At the discussion linked above, I estimate that each of these messages lives for several years and consumes 30 seconds average from multiple users who scroll past it or get exposed to it on the talk page. Almost no one has a meaningful interaction with this messaging and I feel this is time wasted. I do not mind a few messages, but anything scaled into the hundreds of thousands becomes a community wellness issue. 500,000 messages times 30 seconds is 4100 hours. I do not think my number is wrong, but even if it is, I would rather advocate for setting norms in how much time anyone's bot can ask of Wikipedia's editors. I feel that unless there is community consensus, the base expectation should be that wiki users should interact with other humans and have minimal exposure to obvious bot solicitation for their time.

To this point I think all of this is innocent and well meaning and without precedent but I wanted to develop the conversation on this topic. Please comment on the village pump discussion above to see a practical case of this. Blue Rasberry (talk) 22:10, 16 February 2018 (UTC)

At the time, IABot had consensus to do so, the BRFA was open for over two months. The bot was also much more prone to errors then. So I don't think this was a mistake back then, but improvements to IABot is making this talk page stuff much less needed in general. As for a discussion, I don't think anything like that exist specifically, at least nothing recent, but see WP:BOTREQUIRE. I'd argue that #3 is being questioned right now. Headbomb {t · c · p · b} 00:07, 17 February 2018 (UTC)

Headbomb Yes, thanks, correct. I am not saying that any mistake happened in the past. In retrospect and for the future, yes, I am advocating for #3 "does not consume resources unnecessarily" take into greater consideration the amount of human time which any bot by design will solicit. I do not know where to draw the line, but perhaps any bot creator should give an estimate of how much wiki community human user time a bot will consume. As an arbitrary starting point, maybe a bot which consumes more than 100 hours over its life from humans who have not consented or opted into interaction with the bot gets mention and consideration. Perhaps anything over 500 hours of non-opt-in human time is a red flag for broader discussion. I am not particular about details here but just wanted to shout out here for future policy consideration. Blue Rasberry (talk) 00:16, 19 February 2018 (UTC)

Frankly, whatever estimate you have there relies on so many assumption that you could easily be off by 2 order of magnitudes either way. How much time a bot takes from humans is unmeasurable, and at this point Newton's Flaming Laser Sword kicks in. But even assuming it would somehow be measurable, there's a half a million issues with using 'time' as a metric. The real question here is is BOTPOL lacking in some way? I don't see that the answer is yes, given WP:BOTREQUIRE makes it clear bot tasks need consensus, be harmless, and not waste resources. A second question might be is BOTPOL unclear in some way?, and I can't offer a better answer than 'Maybe?'. If your answer to that is yes, then we'd have to know what, specifically, you consider unclear. Headbomb {t · c · p · b} 04:55, 19 February 2018 (UTC)

@Headbomb: We have lots of measurements of this situation. I agree that I can be underestimating. I would like to hear any calculation which you or anyone else could do that makes a case for this being an overestimate, with my base guess being "500,000 messages each consume 1 second". Yes, I agree that the most complete answer could use research but we do have a lot of data. Also, whether we have data or not, all sides make assumptions. What is happening here is new, unusual, and merits discussion.

1. We know how many messages the bot in this case posted - 500,000+
2. We know how many views the talk pages where the bot posted were viewed - 10s of millions, probably 100s of millions over 2 years
3. We know that this particular bot solicited humans to read its messages and react
4. In response to the bot's solicitation, we have counts of how many times humans responded
5. We can measure how much time it takes for human to engage with the bot
6. We can measure how much time it takes for a human who sees the message for the first time can understand they should ignore it
7. We can measure how much time it takes for a human who recognizes the message to ignore it by scrolling past

I feel justified in cornering anyone to talk through how much time a project like this consumes. Does anyone doubt Wikipedia's audience report metrics? Does anyone doubt that people expect text on Wikipedia to be intended for humans to read it?

Is there anyone who is willing to state their disbelief that if we know that a talk page has 50 views over a period of 2 years, then those 50 views constitute the expenditure least 1 second of human time? To me this seems obvious and I wonder how anyone could doubt this.

Yes, the bot policy is unclear, because lots of people seem to have the idea that if designers make bots which seek out human time, then somehow, the human time which bots seek is not a resource worth protecting as valuable. I advocate that it is. Bots should not have unregulated access to human user attention, and bots which seek a lot of human time need special consideration, and in general the presumption and norm should be that Wikipedia human users interact with other humans and do not experience calls to engage with bots. Blue Rasberry (talk) 14:30, 20 February 2018 (UTC)

Re 'time' stuff. This can neither be precisely measured, nor compared from bot to bot. So whatever threshold would be decided can neither be enforced nor verified. Going up this venue is a waste of time, quite literally.

First scenario. Let's say we decide 50000 seconds of human review time per year is 'the limit'. Bibcode bot for instance edits at an average rate of 5000/year. If every edit takes 3 seconds to review, it would be in the clear. If every edit takes 10 second to review, then it's at the limit. Whatever limit you come up with yields zero insight on whether or not the task should be carried out, or whether it has consensus to operate, of unnecessarily waste resources, human or otherwise.

Second scenario, let's say that whatever 'human time' IABot costs is 'the limit'. What happens if we find Cluebot or Citation bot takes more time. Do we disable those bots? Block them? That seems ridiculous. Do we decide they're OK, despite exceeding the acceptable limit? Then why bother having a limit in the first place?

That's why a "human time cost" is neither desirable as a metric, nor is such a limit desirable as policy. And it wouldn't even be enforcable, assuming this would somehow get adopted in policy.

Re the second part.

"Yes, the bot policy is unclear, a) because lots of people seem to have the idea that if designers make bots which seek out human time, then somehow, the human time which bots seek is not a resource worth protecting as valuable. I advocate that it is. b) Bots should not have unregulated access to human user attention, c) and bots which seek a lot of human time need special consideration, d) and in general the presumption and norm should be that Wikipedia human users interact with other humans and do not experience calls to engage with bots."

Concerning a), I have yet to see one editor, bot operator or otherwise, who thinks that. Concerning b) such bots are regulated c) every bot undergoing a BRFA gets special considerations commensurate to the bot's task. See WP:BOTAPPROVAL/WP:BAGG#Guide to BRFAs for how approvals work and how the BAG operates. If you have proposed revisions to that process or BAG procedures, feel free to bring them up. However, you yourself admit that IABot had consensus to operate in the manner it was approved of at the time. This consensus was called into question, and now IABot must operate differently. What exactly is wrong with this picture? You mostly seem to be venting your frustration with IABot in general, rather than make specific policy proposals. d) That depends on the bot. Human-bot interaction is quite desirable at times, and unrequired at other times. Headbomb {t · c · p · b} 15:08, 20 February 2018 (UTC)

@Headbomb: I am not complaining about IABot. I am happy with how it got approval, operated, and then recently changed after discussion. However, in retrospect, it operated in an inappropriate which which bot policy should prohibit in the future. IABot did awesome things and also made a big mess, but the bigger issue is preventing the bad activity in general rather than criticizing IABot in any particular way. IABot is awesome and only deserves praise. The criticism I have is for bot policy in general and not about IABot even though I use it for an example. IABot followed policy and community consensus but following policy led to an unexpected negative outcome which I want to raise, address, and prohibit by policy.

There is a difference between the bots you demonstrate and IABot. My complaint is about bots which communicate and seek engagement in places where previously we have expected human conversation. You are showing bots which communicate in the edit history log, where we already have some precedent of bot editing, and where there is already noise in the log entries, and where there are already regulations in place like a character limit and an inability to create an ongoing conversation.

If I were to make a rule or regulation about norms, I would say that bot communication in the edit history log is fine, but the talk page is for humans and should have a higher bar of entry for bots, and maybe other places where currently there are humans also should be preserved for humans and have a bias against letting bots become routine conversation participants. There are also already regulations which seek to minimize bot edits to articles, like for example, no one wants to see more bot edits in an article history when there could be fewer. People might have a goal to have fewer bot edits in articles, or to achieve a goal, but there is no one who seeks to design bots which do article editing while maximizing the bot edit count.

Check out your examples, which I think are fine bot activity:

• typical Bibcode edit
• typical Citation bot edit

Each of these bots post to the edit log, where we already have norms for certain kinds of bot posting with human posting. I am not overly worried about this kind of posting right now because it is short, I find it comfortable for me as a human reader, and because it is easy enough to ignore.

Here is the kind of bot activity which I find problematic:

• typical InternetArchiveBot edit

Here are the differences between this bad kind of bot activity versus the better activity which you present:

1. The bad activity is communication in a space were there was a norm for human to human conversation. This bot changed the norm from ~95% of messages on talk pages being human to maybe something like 85% of talk messages in the past 2 years being from humans. This is a massive change to user experience and creates an environment where engaging with Wikipedia means humans being directed to engage with bots rather than humans being engaged with humans.
2. This bot makes active appeals for human responses. It says, "Please take a moment to review my edit" and "When you have finished reviewing my changes, you may follow the instructions". By design the bot is seeking peership with human editors and asking for their time, attention, and labor.
3. This bot posts a lot of text. Whereas the bots you show have a text posting limit of 250 characters and actually use about half that, this bot routinely posts messages of 2000 characters. New users will read this; regular users have to learn the new skill of ignoring these long, ubiquitous bot posts. Even avoiding the messages takes time.
4. Because of the time this bot solicits and the scale of its operation, tens of thousands of English Wikipedia editors have had the shared cultural experience of spending time reading these bot posts and thousands of experienced editors now have the shared experience of training themselves to ignore these posts. There probably are not more than 20 people whose Wikipedia activity prioritizes having communication exchanges with this bot. Perhaps there is not even 1 editor who does this among the tens of thousands whom the bot asked. Interaction with this bot has become a part of the Wikipedia experience in terms of its familiarity. We should be cautious about what kinds of experiences we scale up to 10s of 1000s of editors and which have the design to solicit lots of time from each. This is unusual in Wikipedia.
5. These messages are unlikely to provide a high quality user experience. Maybe many people will have no strong opinions about them, but as compared to a talk page post from a human, these automated messages are much lower value on the talk page.
6. Inherent in the design of talk page messages versus the edit history log there is an appeal for human attention and time. There should be some thoughtfulness about whether the design of a bot interaction seeks to recruit volunteer labor versus being more discrete, opt-in, or providing information briefly then allowing interested users to click through to get more details.
7. IABot posts to talk pages where those messages persist for years. The messages have a design to seek and consume human attention until they are archived, and probably 95% of messages do not get archived within 2 years. Each of these messages will consume time from every talk page visitor to whom the messages get published. If 30 people go to a talk page in a year, then I think it is reasonable to assume that the messages will consume a second from each of them even if the users only seek to ignore the message. If I am very wrong, then maybe for 30 viewers somehow the message in total will only consume 1 second. Even 1 second is a lot of time scaled up to 500,000 messages which get published to an average of 30 people each.

I am ready to say that the bot activity you present has a design and intent to consume less human time and the IABot has a design and intent to seek more human time. Yes, as you say, human time is not an absolute cut off for approving or rejecting bots, and we have to balance human time consumed with the value of the bot activity. In the case of IABot the ratio of human time consumed to value is orders of magnitude more than what has been normal in Wikipedia. I am not advocating for a hard cutoff for a certain amount of human time, but if a bot designer makes a choice about whether by design the bot should seek 1000s of hours of human engagement versus a few hours, then the bot review policy should favor bots which consume less human time. When bot designers present a bot for review they should first reflect on how much human time they expect their bot to solicit and consume and they should self-report that estimate as part of the application process. They should show their calculation, and say something like "This bot will post 100,000 messages of 150 characters to Wikipedia edit history logs, and maybe humans will read or ignore these messages 100,000 times consuming at least 50,000 seconds and probably not more than 300,000 seconds." If a bot has a design to seek human attention, then the bot operator should say "This bot will post 2000 character messages to 500,000 talk pages and each message will ask for 3-5 minutes of human labor. By design this bot seeks 5000 hours of human interaction but I expect that most people will ignore the messaging and I only expect it to consume 1000 hours of human volunteer labor." Self reporting by bot proposers is a great place to start, just to demonstrate that human time has a value and minimizing human labor costs is a good thing to do all things being equal. Blue Rasberry (talk) 15:45, 21 February 2018 (UTC)

• I signaled the existence of this conversation at Wikipedia_talk:Bot_Approvals_Group/Guide#Require_bot_operators_to_self-report_expected_bot_cost_in_human_time. Blue Rasberry (talk) 15:55, 21 February 2018 (UTC)

Again, I re-iterate, what changes specifically, are you seeking to the WP:BOTPOL and/orWP:BAGG? You say talk page messages should have a 'higher bar for entry', but are happy with how things with IABot went. So if IABot is not an example of something that needs to be address by WP:BOTPOL, what would be an example of it? Newsletter delivery bots? DPL bot? Because right now it really seems you're seeking a solution to a problem either doesn't exist or can't be defined, or are contradicting yourself because you say you're happy with how IABot was handled, but seek a change to BOTPOL to prevent things like IABot from happening, even though it had consensus. Headbomb {t · c · p · b} 16:33, 21 February 2018 (UTC)

@Headbomb: I do not want to criticize IABot in retrospect or find fault with anything done in the past. However, knowing what we know now, if anyone proposed anything like IABot then I would criticize it heavily and recommend that it have a prohibition against talk page messages. The outcome was not something we could have predicted but now that we know, yes, the design is a big problem. I do not wish to attack IABot because I like it and I like that it recently quit posting these messages, which means that it has always operated with the best available guidance. Now we have better information about what it means to post a huge amount of content and now I would not want that to happen again so casually.

I say the same about newsletter bots - they should post to hundreds of places typically and thousands of places sometimes. I hope that no newsletter operates at the level of 100s of 1000s without a human opt-in. No newsletter should go to the talk pages of any category of 100,000+ wiki articles. Consent matters more when a process becomes more interventional.

I might communicate poorly and I might continue to fail to communicate effectively. You say that the problem cannot be defined, but everyone imagines a default. I could start this way - can you at least say how much human time you think is consumed if IAbot or anything else posts 500,000 messages to talk pages? You say this is hard to measure, but is your best guess that this consumes 0 human time, some positive amount of time (I suggested 1 second per message), or some negative amount of time (like maybe posting messages somehow gives more time to people)? You say that this cannot be measured, so you must have in your mind some default time measurement. Probably that is 0: you imagine that since there is no number, then go forward with evaluations imagining that the messaging neither takes time nor consumes time.

The value of the activity is another issue, and of course in the end a bot evaluation compares the value of the bot to the cost of operating it. I am not considering all aspects of bots at this time, and not considering the activity benefits. Right now I am only raising the issue of measuring and reporting bot costs. My argument is that a bot posting 500,000 messages to talk pages has a cost in human time consumed. If I understand you correctly, you are taking the position that posting 500,000 messages will have no cost in human time.

I have trouble understanding you but that fault is mine, and also I take the blame for failing to make my own position understandable. I neither expect you to understand me nor do I expect you to agree, but I am trying here and I appreciate the talk. Thanks. Blue Rasberry (talk) 17:32, 22 February 2018 (UTC)

I find costs on Wikipedia to always be interesting discussions, but really hard to practically quantify. One thing to measure is what the cost of a reader clicking on a replaced link that doesn't lead to the intended target due to an IABot false positive is. Is that cost worth leaving a talk page message for further review? Now what's the cost of not leaving those messages? What's the cost of having Cyberpower participate in these discussions when they could be working on other things? And so on. I can see where you're coming from, but I'm not really sure how this could be integrated into the bot policy.

PS: I'd suggest investing in a better keyboard and mouse if it takes you 30 seconds to scroll past messages. Legoktm (talk) 20:34, 21 February 2018 (UTC)

@Legoktm: Suppose that that there is a 2000 character talk page message posted and persisting on a talk page for 2 years, and in that time the wiki pageview metrics report that 100 people have come to this message. May I ask if you would be willing to challenge my time estimate that such a message will consume at least 30 seconds over that time period, imagining that some people will scroll past it, some people will read it, and maybe some people will follow its instructions requesting human attention? The 30 seconds is not for me - it is average time consumed over the life of the advertising message. I am not contesting the value of what IABot does as its primary activity, but only saying that its posting 500,000 long messages should have been a cost consideration in its design and should be a cost consideration for future, similar bots which might post to a talk page.

I do not wish to press you into an argument, but I do wish that I could improve my own failure in communication and prevent you from misunderstanding that I am complaining about the inconvenience of scrolling for the sake of myself. Any message multiplied by 500,000 is new to wiki culture and is on a scale which we have no culture of understanding or discussing. Any process which has a design to consume time 500,000 times adds up to a major time sink. I do not object to the activity; I only object to the inherent design to consume much more time than the activity required, and that when there was a choice to consume more time or less time, the choice made was to consume more on the presumption that human time is not a cost worth considering. Blue Rasberry (talk) 17:32, 22 February 2018 (UTC)

I've made a bold edit. If it is controversial, it can be discussed below. E to the Pi times i (talk | contribs) 19:45, 7 April 2018 (UTC)

Reverted, while mass page moves are covered by WP:BOTPOL, WP:MASSCREATION does not apply to that. Headbomb {t · c · p · b} 23:53, 7 April 2018 (UTC)

@Headbomb: Um, WP:BOTPOL doesn't currently say anything about mass page moves, so I don't see how "mass page moves are covered by WP:BOTPOL".

Unless you mean implicitly, but policy should be explicit, and anyway, mass page moves technically count as mass article creation if the new pages are being created with the page moves (which is all page moves for non-admin accounts).

I note in your edit summary you said "while mass page moves need a BRFA, this is not the policy section to cover that". Where would you suggest covering it? Mass page creation seems like the most appropriate section to cover it to me, since it's not covered anywhere else in the page, and it's not content heavy enough for its own section. E to the Pi times i (talk | contribs) 03:54, 8 April 2018 (UTC)

@E to the Pi times i: It's implicitly covered by WP:BOTREQUIRE and WP:BOTAPPROVAL. Bot policy doesn't need to be explicit about every specific type of edits made. For example, we don't specifically list adding/removing/updating WikiProject banners as something needing approval, even though it's one of the most common type of bots out there. The WP:MASSCREATION restriction exists because it creates massive cleanup backlogs when things are done sloppily, including dozens if not hundreds of PRODs/AfDs if created on non-notable entries. Bad page moves are very easy to undo, without the need for admin intervention in most cases.

But more to the point, before additions should be made to the bot policy (a WP:MASSMOVE section), there has to be a need for those additions. So the following things need to be addressed (IMO) before an addition is made to the bot policy

1. Do you have examples of problematic mass page moves, especially problematic script-assisted page moves?
2. Does preventing mass moves at a policy level solve more problems than it creates?
3. Is there consensus for such additional restrictions (e.g. need for a WP:VP discussion before moving pages)?

Headbomb {t · c · p · b} 12:17, 8 April 2018 (UTC)

My concern comes more from a desire for personal clarity in reading the policy than from an overarching policy perspective, so my changes may be in error. I would suggest a revised version: "The restriction also applies to mass page moves when the moves create pages.", but I think your concerns may be correct when it comes to not having a consensus or need for explicitly regulating these changes in this way.

Also, I moved the anchor because it causes problems with edit summary links, as can be seen in my most recent edit summary on this page. E to the Pi times i (talk | contribs) 15:04, 8 April 2018 (UTC)

Moved from Wikipedia talk:Bots/Requests for approval

I recently used AWB to create about 50 uncontroversial redirects – see here. Each one was manually approved. Out of a nagging sense of paranoia, I just checked the bot policy and saw WP:MASSCREATION. Are uncontroversial redirects covered by that policy? If so, mea culpa – my apologies, and I will not do this again. Best, Kevin (aka L235 · t · c) 00:06, 17 April 2018 (UTC)

Redirects are not technically considered "articles" (although they are in the "article namespace"), so you're in the clear from a literal interpretation of the policy standpoint. And more importantly that is not the kind of thing the policy was created with in mind, so I wouldn't worry about it if I were you. - Kingpin¹³ (talk) 00:24, 17 April 2018 (UTC)

Thanks, Kingpin13 – much appreciated. Kevin (aka L235 · t · c) 01:53, 17 April 2018 (UTC)

Gonna say the letter of WP:MASSCREATION is perhaps not super clear here, but I agree with Kingpin13 here about the intent of WP:MASSCREATION: it's about articles. Sufficiently large redirect creation might still fall under WP:BOTPOL, and certainly fall under WP:CONSENSUS, but that'd be like any other sort of editing out there. Headbomb {t · c · p · b} 20:14, 26 May 2018 (UTC)

Please see Wikipedia talk:Citing sources#RfC: Remove the bullet point that starts "adding citation templates..."

The discussion is relevant to this policy because even though the RFC has been around for less than a day, there have been several mentions of mass changes. Naturally mass changes are a phenomenon associated with bots. Jc3s5h (talk) 17:12, 4 July 2018 (UTC)

In the case of tools that are being used for various purposes in wiki,the policy of adoption is acceptable. Can a bot be adopted if it is inactive?Adithyak1997 (talk) 18:09, 18 November 2018 (UTC)

@Adithyak1997: if the old and new operators are in agreement, it may be OK to pass control of a bot account to another operator - start a discussion at WP:BOTN. If the old operator is gone, most any bot task can be forked, just file a WP:BRFA and start a new bot account to run the tasks. — xaosflux ^Talk 18:27, 18 November 2018 (UTC)

I have put in my name for consideration of the Bot Approvals Group. Those interested in discussing the matter are invited to do so here. Thank you for your input. Primefac (talk) 00:42, 4 December 2018 (UTC)