Wikipedia talk:Bot policy/Archive 27

Should bots perform multiple edits in a page?
In continuation to this discussion Village pump (proposals)/Archive 137 it's a good question whether we should work in a direction of where a bot should perform secondary valuable tasks or not. Right now some bot owners that use AWB deny to enable general fixes which causes many issues to remain unfixed while they could be fixedin a single run making bot editing really optimal and concrete. -- Magioladitis (talk) 21:39, 15 June 2017 (UTC)
 * To be very clear, are you proposing that bot operators may enable secondary tasks without approval, may enable secondary tasks with specific approval, or are required to enable secondary tasks? These are three very different things and it isn't clear from your question which you're advocating for. ~ Rob 13 Talk 22:07, 15 June 2017 (UTC)
 * To your third point: I don't think we require operators to do any "extra" (non-required by their approved task) editing they don't want to do. — xaosflux  Talk 23:11, 15 June 2017 (UTC)
 * I'll repeat what I said last time, because nothing changed since then.
 * "But to answer the question directly, WP:COSMETICBOT is clear that bots can perform cosmetic fix alongside more substantial edits, that bots can be approved to do genfixes following a proper BRFA, and that some but not all of the checkwiki/genfixes are considered non-cosmetic and can be done own their own. As for asking bots to do AWB genfixes, I suppose you can ask, but no bot operator can be compelled to do them. And of course any bot op that chooses to do AWB genfixes alongside their main task is required to go through a BRFA for approval."
 * Now you say "some bot owners that use AWB deny to enable general fixes". This is not a problem related to WP:BOTPOL, that's bot operator choice. Feel free to ask bot operators to enable WP:AWB genfixes, either directly or at WP:BOTN, but whether or not to do so will remain a bot operator choice, subject to BRFA approval, and nothing that will ever be enshrined in policy. Headbomb {t · c · p · b} 02:18, 16 June 2017 (UTC)

Headbomb That's the problem. It's not about choice otherwise some errors will never be fixed. -- Magioladitis (talk) 09:46, 16 June 2017 (UTC)

exactly we don't require them to do anything and in the contrary to bot owners that want to do the general fixes we require them to do something else. This is unbalance that leads to unfixed errors. -- Magioladitis (talk) 09:48, 16 June 2017 (UTC)
 * Most bot frameworks don't even have "general fixes" as a concept, so requiring all bots to do it would never fly. — xaosflux  Talk 11:04, 16 June 2017 (UTC)
 * true and that is reason of an inbalance. The way I see it is that we either stop complaining for bots maintance tasks or we find a way to combine actions. Right now we still have questioning whther adding/remving a pages from a cleanp cateory is a valid bot bot or not. -- Magioladitis (talk) 11:33, 16 June 2017 (UTC)
 * If some "errors" like Italics don't get fixed to Italics, it's really not the end of the world since the visual output is completely unaffected. "In the contrary to bot owners that want to do the general fixes we require them to do something else." is patently false. People are certainly free to make bots that address specific errors like or  (provided they go through BRFAs). What they can't do is bots that solely fixes  or  for instance. Headbomb {t · c · p · b} 11:52, 16 June 2017 (UTC)
 * The only point I'm stressing is that it should continue to be fine for a bot to not make every possibly improvement to a page when they edit, for an extreme example I don't want to see ClueBot NG being stopped because it won't also go "fix" things unrelated to its task - especially "cosmetic" things like changing article --> article when it is making an edit. — xaosflux  Talk 13:09, 16 June 2017 (UTC)
 * ClueBot NG doesn't even submit edits, so it wouldn't even be able to do so. ClueBot NG submits rollbacks, and just sends a revision ID and edit summary.  And incorporating miscellaneous fixes in the User Talk page edits seems like a lot of work for very little return.  Furthermore, in general, bot edits that do lots of things make for very confusing diffs, and more difficult to understand edit summaries (to the point that many simply give up on producing a decent edit summary and instead simply mention their BRFA or user page for a detailed explanation of what all they do).  Software, including bots, should do one thing, and do it well[1][2]  -- Cobi(t&#124;c&#124;b) 23:53, 16 June 2017 (UTC)

In general, I would argue that bot tasks should be limited to the changes specifically approved in the BRFA. The purpose of a BRFA is to document exactly what the bot task will do, and in principle it should be possible for someone to verify that each bot edit for a particular task matches the BRFA. So any "secondary" edits should be explicitly listed in the BRFA. One system that would not work would be for bot operators to be able to add any additional "secondary" task that they like to existing approved bot tasks. The way to avoid that is for the operators to include the desired edits in the BRFA, or submit a revised BRFA if the edits associated with a particular task should be revised. &mdash; Carl (CBM · talk) 12:30, 16 June 2017 (UTC)

I completely agree that we should not mandate bot owners into putting general fixes into their bot. This is an extra layer of complexity that could stop important tasks, as has mentioned above. We don't want to put off important tasks for trivial ones. If bot owners would like to do cosmetic tasks as the same time as a major task, I have no problem with that, in particular, as long as it has been approved in the BRFA. The BRFA is there to show what the bot is approved to do. Anything outside that scope is breaking the BRFA and therefore an unauthorised task. The BRFA holds owners accountable for their actions, and without mentioning the tasks we lead down a slippery slope of so-called secondary tasks that don't need approval. Also, not all bots with be appropriate for these genfixes at the same time. Bots with already complex tasks that produce complex edit diffs should probably not be further complicated. As long as the approval goes the normal way, I don't have a problem with asking owners to do it. Should we mandate it? No. TheMagikCow (T) (C) 13:41, 16 June 2017 (UTC)

This discussion seems like a complete misunderstanding of the question posed by Magioladitis. Let me rephrase and see if we can gain traction. Given that:


 * 1) There are many small fixes  which have consensus.
 * 2) Some bot frameworks have support for such things, the best known being AWB and Pywikibot.

should we force, encourage, allow, discourage or disallow the use of such extensions?

It seems to me that no-one has suggested that we should force their use - this is a straw man proposal we can dispose of immediately.

Certainly the attitude many Wiki-gnomes have taken in the past is that there are tasks we can, at least for the first 80%, delegate to AWB users (both bots and humans) to reduce the number of gnoming edits required.

And again the general feeling in the bot community and BAG was certainly, for some years, to allow the inclusion of AWB "general fixes" as performing an en passant improvement to pages while another edit was taking place.

So far so good. However as a bot-runner it is much easier to turn off General Fixes, especially when one is faced with argumentative and disruptive editors. Stating our support for the idea of making as much improvement per-edit as conveniently possible is a good idea.

All the best: Rich Farmbrough, 10:23, 17 June 2017 (UTC).


 * It doesn't seem quite that clear-cut to me. When Magioladitis uses languages like "deny to enable", "It's not about choice", and "exactly we don't require them to do anything", that sounds very much like advocating what you claim is a strawman. BU Rob13 asked for specific clarification as to what exactly was being proposed, but unfortunately has not received a reply as of yet. Anomie⚔ 13:47, 17 June 2017 (UTC)
 * It turns out that Magioladitis is indeed advocating the position you describe as a straw man. Anomie⚔ 00:21, 18 June 2017 (UTC)

My view is that we should still allow these edits, on a case-by-case basis. The BRFA must include the edits in the request, and it is not always suitable for every bot (see above comments). As long as the BRFA has approved it, that's fine, and if the owner refuses, that's fine too. What I don't want to see is unapproved edits being made, even if they are genfixes, as this leads to a situation where it gets hard to define what is and is not ok to run as a secondary task. TheMagikCow (T) (C) 12:14, 17 June 2017 (UTC)


 * "Stating our support for the idea of making as much improvement per-edit as conveniently possible is a good idea."
 * This very much depends on the bot. I don't support ClueBot making such improvements, for instance. I'm not aware of anyone that thinks genfixes in addition to the bot's main task isn't allowed, provided of course it's part of the task as described in the the BRFA, and if those editors exist, you can send them at WP:BOTN, or point them to the bot's BRFA. But that's a bit of a misrepresentation of the issues that normally arises with genfixes, and that is to not make cosmetic edits with bots. There are a handful of genfixes which are miscategorized as non-cosmetic/non-minor. That's on the AWB team to fix, of which Magioladitis is part of. Whether or not those are problem for bots depend on the bot. Most issues can be avoided by simply enabling the skip conditions and an intelligent selection of articles on which to run the bot on. Headbomb {t · c · p · b} 15:30, 17 June 2017 (UTC)

Anomie I ask to require bot owners to do more in a signle edit the same way it is required(?) for some valid edits to be done only in addition to other edits. -- Magioladitis (talk) 22:58, 17 June 2017 (UTC)
 * That will never fly. There is zero reason to ask User:ClueBot to perform AWB genfixes. Headbomb {t · c · p · b} 23:02, 17 June 2017 (UTC)


 * I'd sooner shut IABot and Cyberbot down than install an additional chunky piece of software that consumes precious time to make changes completely unrelated to its task.— CYBERPOWER  ( Message ) 23:35, 17 June 2017 (UTC)
 * Yeah, I doubt there will ever be consensus for forcing bots to make cleanup edits. Thanks for clarifying your request though. Anomie⚔ 00:23, 18 June 2017 (UTC)
 * There is no way that we would be able to recruit and retain some of our best bot operators if you required general fixes. I know a few bot operators who simply refuse to run other people's code that they do not control and which is subject to change without the operator's knowledge or consent. Bot operators, like all of us, are responsible for their edits, and those operators do not want to be responsible for erroneous edits.


 * That said, there are some bot operators who want to run AWB's general fixes along with substantive edits, and they should be allowed to do so. In other words, the status quo is acceptable to most operators. – Jonesey95 (talk) 00:24, 18 June 2017 (UTC)

We don't have to require everyone to do it. But since now we are about to initite 4 AWB bots to fix ISBNs we coould ask all of them to perform AWB genfixes. -- Magioladitis (talk) 15:30, 18 June 2017 (UTC)
 * Feel free to ask the operators to update their BRFAs (if necessary). But it's not going to be required that they do so. Anomie⚔ 15:53, 18 June 2017 (UTC)

Anomie If we can't manage this up to a descent level then we shoould abandon the ther diretion that created the inbalance too. I am refering to the prequisity to do certain edits only when another edit is made. -- Magioladitis (talk) 15:33, 18 June 2017 (UTC)
 * So just trying to understand the true motive of your question/proposal. You are saying not all bot ops have to do it, just those running AWB, since they are already integrated with AWB?  I don't mind that.  AWB bot's simply just need to call the genfixes.— CYBERPOWER  ( Chat ) 15:51, 18 June 2017 (UTC)
 * Did you mean to reply to the comment above, rather than this one about dropping WP:COSMETICBOT? Anomie⚔ 15:53, 18 June 2017 (UTC)
 * Also not going to happen. You may want to review WP:STICK. Anomie⚔ 15:53, 18 June 2017 (UTC)


 * I've been mostly absent the past few days so haven't followed this discussion, but the answer to my question is exactly what I thought it was. No, we're not going to require bot operators to do anything. If we did, we'd not only fail to get these minor/zero-impact tasks done, but we'd also start losing out on actual high-impact tasks as bot operators just decide not to develop tasks for enwiki. Bot operators can run general fixes or other minor fixes with their bots, provided they get approval to do so and enable the settings that ensure compliance with WP:COSMETICBOT. Moreover, I think everyone knows this proposal is never going to happen, and I don't see this as a serious proposal. It looks, smells, and feels like an extreme "no chance" proposal intended so that, when it's shot down, the proposal can be rolled back to the more reasonable (relatively-speaking) idea of getting rid of WP:COSMETICBOT. That's been debated repeatedly. The outcome is always the same. The latest attempt is in the section immediately above this one. Can we move on already? ~ Rob 13 Talk 16:45, 18 June 2017 (UTC)

The goal of the bot system is to allow for specific tasks with clear consensus. In general, bots that focus on one task, and do it well, tend to cause little drama. For example, the current Magic Links Bot does not seem to have caused any. This is because it has a clearly defined task, a clear edit summary, and editors who see its changes can tell what was done and why. In contrast, a bot that does some changing combination of 20 different things, with a vague edit summary, can only cause confusion. That situation should be avoided. &mdash; Carl (CBM · talk) 16:00, 19 June 2017 (UTC)
 * If you go this direction, which I also fine with, this would mean that we are OK with a bot revisiting the same page multiple times to perform various tasks. I would agree that the "watchlist" argument should go off the table then. -- Magioladitis (talk) 08:25, 20 June 2017 (UTC)

Anomie You may want to reviewWP:BRD. Saying that "it's not going..." how do you conclude that? Do you mean that you reject the discussion? Does that ma that you disagree? How do you know? I made a proposal here. -- Magioladitis (talk) 07:51, 20 June 2017 (UTC)
 * WP:BRD has nothing to do with anything here. You, however, may want to review WP:INDENT. "it's not going" is my assessment of the existing consensus, both broadly and in this discussion section. Anomie⚔ 11:39, 20 June 2017 (UTC)
 * Anomie Consensus may change. Especially, when there is inconsistency and when the community may be in need of forming a strategy on the matter. I am OK if you kep this part of the bot policy the same but then we would need to change some other part. The one I mentioned before. So BRD applies here. -- Magioladitis (talk) 11:43, 20 June 2017 (UTC)
 * No, BRD has nothing to do with what you're saying. WP:CCC seems more like what you're trying to say, but at the same time "consensus can change" does not mean "keep asking every few weeks until you get your way". Anomie⚔ 11:54, 20 June 2017 (UTC)
 * Anomie Where is my previous attempt on that direction? I even changed direction here. -- 12:05, 20 June 2017 (UTC)

I gave the impression that require bot owners in order to make some edits to make some other "more important". I may be wrong but I recall discussions whether a task is important as "sole task". I understand that you are new in the bot area. -- Magioladitis (talk) 07:53, 20 June 2017 (UTC)

Anomie This is a about policy. My proposal addresses to the community. -- Magioladitis (talk) 08:00, 20 June 2017 (UTC)
 * Since you've advertised this at VPT, I'll give an opinion; I have occasionally made some AWB edits using my bot account. When working manually I always review the changes that the general fixes want to make. I don't always agree with them, and sometimes they make the diff too complicated to check easily. Personally I would never make bot edits from my bot account with general fixes turned on. -- John of Reading (talk) 08:36, 20 June 2017 (UTC)
 * John of Reading I understand that. Would you then be OK with bot visiting a page multiple times per day in favour of clear diffs? -- Magioladitis (talk) 09:05, 20 June 2017 (UTC)

I advertised this to the Village Pump because this has to do with Wikipedia Strategy on Bots. I am trying a slow pproavh before we go to a Request for Comment and then to more general discussion for the future of bots on Wikipedia. -- Magioladitis (talk) 09:09, 20 June 2017 (UTC)
 * Magioladitis, really, if you continue in this vein, I don't think there will be a more general discussion for the future of bots on Wikipedia, but a more general discussion for the future of Magioladitis on Wikipedia. Your constant flogging of the same dead horse, like this discussion which was doomed from the start, will not help your cause at all. Fram (talk) 10:08, 20 June 2017 (UTC)
 * Fram Was this already discussed somewhere already? I say that the community has two roads to choose: Multiple bot edits or single edit. Depending on this choice we have to make some rearrangements in the policy. Please link me to previous discussion because I want to promote this to an RfC. -- Magioladitis (talk) 11:31, 20 June 2017 (UTC)
 * This argument is precluding that the edit that "wouldn't be made" will necessarily be made in the future by a bot. Future edits should not be assumed. —  xaosflux  Talk 13:51, 20 June 2017 (UTC)
 * Fram This discussion is mainly to help form a more conrete proposal to the community. I already had similar discussion in the Wikimedia Conference in Berlin about th Stragey of Wikipedia for the next 15 years. -- Magioladitis (talk) 11:35, 20 June 2017 (UTC)
 * Your general preoccupation with bot policy and cosmeticbot since your arbcom case is what I was referring to (although this very discussion is a good example of not knowing when to stop either). You seem to be getting more and more out of sync with the general opinion of the community (here and in other recent discussions), and my recent notes at your talk page about your editing of pages with the AfD template on them also gives me very little confidence. In any case, first get some people to agree that a) there is a problem as you describe it (I don't see why we have to choose between these two roads, they can exist perfectly next to each other) and b) the option(s) you want to propose at the RfC have any support. As far as I can tell, no one will support an option that people have to enable genfixes or other AWB settings if they run an AWB-based bot. But no one will support an option where bots are only allowed to do one tiny task at a time instead of multiple (approved) tasks. For most bot operators, this has worked quite adequately for years now, and most editors seem heppy with the frequency of bot edits to articles in general. Basically, you are having this discussion and planning an RfC not to solve a general problem, but to solve your problem. And that is the kind of thing that, if you keep it up for long enough, eventually will boomerang. Fram (talk) 11:46, 20 June 2017 (UTC)
 * Fram The ArbCom said that the issue has to be disccused openly and the community is encouraged to discuss about it. After the ArbCom, a discussionon the COSMETICBOT policy started which resukted in the policy to change. This is a good start. Moreover, as you can see all the tasks that were done before the ArbCom have started to be re-approved which means the tasks will be done but in many cases the bot will revisit the same page over and over again. -- Magioladitis (talk) 07:42, 21 June 2017 (UTC)
 * I have no problem with discussion. I have a problem with how you approach this, and I don't seem to be the only one. Things like speaking about "low-volume" edits out of the blue because you don't like "cosmetic", even though no one understands what you are talking about and low-volume is something completely different than what "cosmetic" tries to convey. If you want to replace "cosmetic", use "no-impact edits" or soemthing similar, but not "low volume". I really don't think you are the right person to be spearheading this discussion and to make proposals or an RfC about it, as can be seen by this very discussion. You are presenting a false dichotomy and then an unsupported "solution" for it. Simply acknowledge that this idea doesn't have any chance at all of getting accepted and take a step back, take your time to digest "why" this idea gets shot down so resoundingly and why few people seem to share your concerns or to recognise the problem you present. Fram (talk) 07:54, 21 June 2017 (UTC)
 * Fram I am opne to better solution. And I use the term "low-volume" becaue it may be the combnation of two tasks taht both hange the visual outcome. I have started another discussion for the "no-impact edits". There are two different discussions. -- Magioladitis (talk) 08:00, 21 June 2017 (UTC)
 * FYI, The term "cosmeticbot" is already subject to change with most people arguing in favour of this change. -- Magioladitis (talk) 08:02, 21 June 2017 (UTC)
 * No, most people argue in favour of "a" change (if something better can be found at least), not the one you are using (feel free to propose "low volume edits" there if you want to have another proposal shot down by everyone though). Fram (talk) 08:18, 21 June 2017 (UTC)
 * Yes, I meant "a" change which means that the current statu is not satisfying. -- Magioladitis (talk) 10:52, 21 June 2017 (UTC)
 * "most people argue in favour of 'a' change", I'm going to have to ask for on that one. I've followed the cosmetic bot kerfuffle from the start, and I have seen no one advocate for any change since the WP:COSMETICBOT RFC save for Magioladitis. Headbomb {t · c · p · b} 14:02, 21 June 2017 (UTC)
 * Wikipedia_talk:Bot_policy Name is about to change to a less misleading one. -- Magioladitis (talk) 14:40, 21 June 2017 (UTC)
 * I highly doubt it will. Headbomb {t · c · p · b} 23:51, 21 June 2017 (UTC)

Reworded proposal
I think I'm starting to understand Magioladitis' intentions here. In an effort to give this proposal a fair chance, I have reworded into my interpretation below.


 * All bots approved to operate should make an effort to make general fixes to articles along with the edit it intends to make in the same edit. These efforts are not required, with the following exceptions:
 * Any bot running AWB are required to make gen fixes along with the intended edit in the same edit.
 * Any bot running Pywikibot are required to make gen fixes along with the intended edit in the same edit.
 * Any bot running a library capable of carrying out gen fixes are required to make gen fixes along with the intended edit in the same edit.


 * To clarify, any bot not using a library that can make these fixes are NOT required to make gen fixes when making edits.

If I interpreted this wrong, sorry, but this proposal also stands to have a greater chance of passing. Please discuss opinions below.


 * I for one wouldn't mind my wording of the proposal since it's not putting additional demands on those bot operators.— CYBERPOWER  (Around ) 19:56, 21 June 2017 (UTC)
 * Strong oppose to the rewrite. As an AWB bot operator who may run jobs in automatic mode, I am not willing to accept responsibility for these type of edits and don't think any other editor should be required to either. Also, allowing me to make the same edits by rewriting my job under another library to avoid this would be completely pointless - but allowed. — xaosflux  Talk 21:04, 21 June 2017 (UTC)

Cyberpower678 Nice job! -- Magioladitis (talk) 21:25, 21 June 2017 (UTC)

in AWB not much needs to be rewritten. For instance, we now have 4 bots to fix ISBNs. 2 or use AWB. Why only now will do general fixes? -- Magioladitis (talk) 21:38, 21 June 2017 (UTC)
 * I didn't say AWB needs a rewrite, it is pretty good. I'm saying that when I run my bot (currently under AWB) I don't want to take responsibility for blindly applying "gen fix" edits - especially when running in automatic mode and hitting pages like user_talk's.  My opposition has nothing to do with people that want to apply genfixes in addition to another task - just against it being mandatory.  And then making it framework specific - are we going to make policy that we won't approve bots that COULD run under a genfix framework, even if their operators don't want to?  I guess I could always fork AWB and remove genfixes - then I'd being running under NotAWB and be exempt for example?  This blanket requirement is too strict. —  xaosflux  Talk 22:22, 21 June 2017 (UTC)
 * Well I suggested since these are well known frameworks. I never said one needed to run it.  If they really don't want to run it, they don't need to use gen fix capable frameworks.  But this isn't my proposal ultimately.  I just reworded it to make the original intention clearer and give it a fair chance.— CYBERPOWER  ( Message ) 23:33, 21 June 2017 (UTC)
 * so you suggest that if I run my NotAWB fork that doesn't have genfixes as opposed to AWB core an exemption would be OK, so why require these edits if I don't fork? — xaosflux  Talk 23:40, 21 June 2017 (UTC)
 * Well the general idea was that if the framework can do it, it should, and if it can't the botop shouldn't have to go out of the way to implement it. Anyways, I'm fine with it, but am neutral on the proposal itself.— CYBERPOWER  ( Message ) 00:49, 22 June 2017 (UTC)

If we're !voting on this, strongest possible oppose on requirements. By all means, bot ops who feel genfixes would nicely complement their task can implement them, subject to WP:BRFAs, but this amounts to operator discretion. Some tasks are well suited for genfixes, others not so much. Headbomb {t · c · p · b} 23:54, 21 June 2017 (UTC)
 * Reworded oppose: no. ~ Rob 13 Talk 01:23, 22 June 2017 (UTC)
 * Reason for oppose other than WP:IDONTLIKEIT? -- Magioladitis (talk) 07:35, 22 June 2017 (UTC)
 * You're welcome to see my detailed oppose above. If the same proposal is advanced repeatedly, I will give the redundant proposals the time they deserve, which is no time at all. ~ Rob 13 Talk 17:30, 22 June 2017 (UTC)


 * — CYBERPOWER  ( Message ) 02:35, 22 June 2017 (UTC)

I keep hearing that some tasks shuld be done as "Secondary tasks to others". What is the plan to achieve this? Rob just approved a bot that does the same thing Yobot does but with no general fixes. Nice trick to avoid "secondary tasks" completelly. -- Magioladitis (talk) 07:35, 22 June 2017 (UTC)
 * The attempt to ascribe some hidden agenda to that is ludicrous. The bot operator never mentioned genfixes. I handled their BRFA and not yours because I'm recused from handling your BRFAs. I approved theirs without general fixes because they never brought them up. If they had, I would have approved that as well, if they demonstrated they could avoid cosmetic-only editing. ~ Rob 13 Talk 17:33, 22 June 2017 (UTC)

No. WP:NOT states that volunteers aren't required to give more time and effort than they wish. If someone wants to run a useful bot, but does not want to have the trouble of being responsible for "genfixes", why should we tell them no? Anomie⚔ 12:36, 22 June 2017 (UTC)
 * Anomie Exactly! This was the right comment here :) So if someone want to fix a single issue describe in the Manual of Style there should no restriction to it. Right? -- Magioladitis (talk) 15:08, 22 June 2017 (UTC)
 * No, that does not follow at all. By that logic, if someone wants to vandalize there should be no restriction on that either. Anomie⚔ 17:28, 22 June 2017 (UTC)
 * Anomie I ask ask again: Should all pages follow the Manual of Style or not? -- Magioladitis (talk) 17:38, 22 June 2017 (UTC)
 * You're assuming that "all pages should follow the MoS" means "Magioladitis should be allowed to run a bot to enforce the MoS, even if that results in cosmetic edits". That is not the case. Anomie⚔ 17:41, 22 June 2017 (UTC)
 * Anomie Does the Manual of Style allow edits that do not change the rendered output? Moreover, these edits are allowed. "all pages should follow the MoS" means that everyone can edit Wikpedia articles to fix inconsistencies against ownrship issues. -- Magioladitis (talk) 17:50, 22 June 2017 (UTC)
 * Anomie so the reason you oppose this is personal? -- Magioladitis (talk) 17:53, 22 June 2017 (UTC)
 * No. And I'm not going to bother to reply to your continued loaded questions, you're wasting my (and everyone else's) time. Anomie⚔ 17:54, 22 June 2017 (UTC)
 * Anomie I only ask to let the community read my comments and decide. I am no trying to convience you. -- Magioladitis (talk) 17:57, 22 June 2017 (UTC)

Reworded proposal 2
-- Magioladitis (talk) 07:46, 22 June 2017 (UTC)
 * All bots approved to operate should make an effort to make general fixes to articles along with the edit it intends to make in the same edit. More specifically:
 * Any bot running AWB is encouraged to make gen fixes along with the intended edit in the same edit.
 * Any bot running Pywikibot is encouraged to make gen fixes along with the intended edit in the same edit.
 * Any bot running a library capable of carrying out gen fixes are encouraged to make gen fixes along with the intended edit in the same edit.
 * This proposal makes no sense as written. "These efforts are not required, with the following exceptions" and then no requirements follow. Either you simply propose


 * All bots approved to operate are encouraged to make general fixes to articles along with the edit it intends to make in the same edit.

with nothing further needed to be add, or you propose that some of them (AWB, pywiki, ...) are required to do so, which will not get consensus at all and just result in many bots stopping completely or at best stop running under AWB and so on.

Proposals like this one are just a waste of time. Fram (talk) 08:46, 22 June 2017 (UTC)

Fram Maybe it's better now? I rephrased. After an ArbCom and many cases of conflicts these proposals are here to save community from further conflicts and restore community health in a peacful co-existence. There are also here to help WMF an its programmers. Happy editing! - Magioladitis (talk) 09:24, 22 June 2017 (UTC)


 * As far as I can tell, this is not about the community, this is just about you and your bots. I don't think anyone else is actually waiting for these proposals. All it will do is give you a tool to use in your BRFAs to say "but look, policy says that we are encouraged to do genfixes, so you must allow me to make these as well while running a bot task". As far as I can tell, bot owners are free to include genfixes or not, and should just indicate this at their bot request. For most bots, this creates no problems. You are the only one (?) with an arbcom case about your problematic bot (and regular account) edits, and thus the only one to get significant opposition when you want to do genfixes and the like with your bots. You also seem to be one of the few people really worried that some genfixes may take a while before they are performed. Most people don't care, partially because they don't know about or understand all genfixes, partially because a fair number of the genfixes are hardly necessary or urgent at all. Taking all of this together, all your proposals seem to be tailored to allow you to make edits which are in your case controversial, so you can fix some problems very few people care about somewhat faster than they are fixed now. I don't think changing policies or guidelines to help you get rid of the problems you encounter due to your earlier editing issues is something which should be encouraged, and while the reworded version of the 2nd reworded proposal is better than the previous ones, it is in general a totally unnecessary change. Fram (talk) 09:36, 22 June 2017 (UTC)

Fram I recall cases of people who left Wikipedia or got restrictions like Rich. I recall threats for further restrictions to people and bots. -- Magioladitis (talk) 09:58, 22 June 2017 (UTC)
 * Your proposals have nothing to do with what happened to Rich Farmbrough though. His edits (bots and/or mass edits on his own account) contained way too many serious errors. New policy on requiring, encouraging or allowing genfixes wouldn't have changed his case at all. Fram (talk) 10:03, 22 June 2017 (UTC)
 * The new policy will solve strategic problems for bots. It's your right to believe otherwise. -- Magioladitis (talk) 10:09, 22 June 2017 (UTC)
 * His bot edits (Helpful Pixie Bot mainly) generally fall under a), both authorized and correct. That is the trouble with folk-memory, it so often contradicts the documentary evidence.  All the best: Rich Farmbrough, 19:34, 23 June 2017 (UTC).


 * 4) Rich Farmbrough has repeatedly violated the letter and the spirit of the bot policy. Examples include running high-speed tasks without sufficient approval ([11]), running high-volume tasks without sufficient approval ([12]), running bot tasks from a non-bot account ([13]), and running unapproved bot tasks ([14]). Your text comes from the workshop (and was made before I became aware that you had made hundreds of serious errors with an unauthorized bot task on your main account, and then countless more with the same task on your bot account), mine from the actual, accepted findings of fact at the Arbitration/Requests/Case/Rich Farmbrough/Proposed decision. People can read the complete proposed decisions to get the full picture instead of relying on memory, if anyone is interested in it here. Fram (talk) 16:58, 26 June 2017 (UTC)
 * If you don't know the answer to a question, the correct behaviour is to admit your ignorance, not make something up.
 * Something may have been a "proposed decision" that doesn't make it correct - indeed even the adopted decision was shown to be incorrect in many ways, as you are doubtless aware.
 * To the point, I have made it clear that the environment on Wikipedia in some quarters is hostile. Specifically I have included the behaviour of treating rules as more important than people, and more important than the end goal - this is the behaviour that Magioladitis refers to.
 * I do not hesitate to also include casting aspersions on other editors as also part of this hostile environment. I think it is a shame that you did it in the past, and I think it is a shame that you do it now.
 * All the best: Rich Farmbrough, 17:40, 27 June 2017 (UTC).


 * I invite everyone to read Rich's reply, and to then see whather it applies to my responses or to his own. You got restrictions based on the accepted "proposed decision" from ArbCom, no matter if you believe those findings of facts and those decisions to be correct or not. What this has to do with "not knowing the answer", "ignorance" and "making things up" is not clear, unless you refer to Magioladitis original inclusion of your case in his response. In your case, the restrictions were not for putting the rules above the people, but for putting the encyclopedic content above the people. It takes a long time before prolific good faith editors get serious restrictions, but at some point the damage done time and again through reckless or thoughtless editing of articles (made worse by the high speed of the edits) just becomes unacceptable to too many people. You may continue to blame your restrictions to whatever and whoever you want, but in the end it were your own actions that led to them. If that means that the environment here has become too hostile for you, so be it. It is at least less hostile than accusing people of making things up when they post accepted findings of facts of arbcom cases. Fram (talk) 13:43, 28 June 2017 (UTC)
 * Either you were making it up when you said my bot edits were good, or you were making it up when you said they were bad. You cannot have "known" two opposite facts.
 * Charitably I assumed that you were mis-remembering what happened five or six years ago. Instead you claim that you were writing out of ignorance.  So be it.
 * All the best: Rich Farmbrough, 19:38, 28 June 2017 (UTC).


 * I'm not in the "strong oppose" camp on this - and I think a good talking point is for bots that run in automatic mode: what are the accountability expectations for operators that make "gen fix" edits via their bots? — xaosflux  Talk 11:15, 22 June 2017 (UTC)
 * That's what you were referring to? A comment made 5 years ago which I afterwards learned was too optimistic? Oh well, if it makes you happy to harp about that, be my guest, it doesn't change anything about what I said here, in this discussion. Fram (talk) 04:41, 29 June 2017 (UTC)
 * If we're down to All bots approved to operate are encouraged to make general fixes to articles along with the edit it intends to make in the same edit. ... meh. I don't see a problem with encouraging people to do it. But it seems like a random wishy-washy statement to be putting in what's already a TL;DR policy. And it hasn't been proposed where exactly it would be inserted, and it would need to be clear that approval via BRFA is still required. Without those details, I'd oppose for now. People who care are free to suggest it on likely BRFAs. Anomie⚔ 12:36, 22 June 2017 (UTC)
 * Encourage is too strong a word, as it may actually discourage people from creating small bots that are perfectly on their own if they feel they'll get badgered into expanding the bot's task beyond what they want it to be. May is the right balance. Headbomb {t · c · p · b} 13:07, 22 June 2017 (UTC)
 * Unnecessary addition. It is completely up to the bot operator whether to request approval and enable genfixes (or whatever variation their software might provide). We will not require or forbid this in the near future. And it is 100% on bot operator to show and ensure that such genfixes are correct and follow consensus and we should not imply otherwise by "encouraging" toggling some magic checkbox. — HELL KNOWZ  ▎TALK 14:24, 22 June 2017 (UTC)

Will in favour for bot tasks that will implement part of the Manual of Style without any futher conditions? -- Magioladitis (talk) 14:49, 22 June 2017 (UTC)

I think it is best for bot tasks to focus on doing one thing well; we have seen many examples of bot tasks that try to do many things and do them poorly. At the same time, the BRFA process is the right time for any additional tasks to be approved, if there is consensus for the task and operator to do more than one thing at a time. One problem with an open ended "general fixes" requirement is that there is no community or BAG review of what those "fixes" entail - the developer of the bot framework could include anything they like and call it a general fix. This is not completely hypothetical, as the example of previous AWB versions rearranging references or adding named references to pages that did not use them shows. Another problem is that AWB is buggy with regards to skipping edits where the main task was not carried out. &mdash; Carl (CBM · talk) 15:02, 22 June 2017 (UTC)

I'm also confused by this. Is there currently something in the guideline/policy that discourages or disallows genfixes? The words "required" and "encouraged" imply a wide consensus for something. I personally have no strong feelings one way or another. I wouldn't "encourage" it be done; but I wouldn't "discourage" either. There are pros and cons either way and it's dependent on the bot owner, software and core task. If something must be said about genfixs, maybe they are allowed but then list reasons to be cautious like they can generate errors, don't have access to source code etc.. -- Green  C  17:14, 22 June 2017 (UTC)
 * Reworded oppose take 2: Nope. This is process spam to keep advocating the same thing with epsilon deviations. This is unnecessary as instruction creep, and further, I don't think it's policy-level consensus to suggest bot operators take on additional tasks that make trials harder to review, bugs harder to chase down, and diffs less informative. ~ Rob 13 Talk 17:33, 22 June 2017 (UTC)
 * The trails can be done without that part. Should all pages follow the Manual of Style or not? -- Magioladitis (talk) 17:39, 22 June 2017 (UTC)
 * the way you reply to me is way to harrass me again as you did some months ago? I try to find a middle ground following the instructions. You seem not to care but still participating in this process. Amazing that after the problems caused during and after the ArbCom you keep the same tactic. -- Magioladitis (talk) 17:41, 22 June 2017 (UTC)
 * One, we don't approve tasks (or parts of tasks) we haven't trialed. That's important to ensure the bot operator isn't going to make edits that violate WP:COSMETICBOT. Two, opposing your proposals is not harassment. I've purposefully avoided you because you seem unable to work with me productively, but I'm not going to avoid the repeated attempts to sneak through changes to the bot policy that have already been opposed several times at this point. If you detect a hint of annoyance, it's because I am annoyed that you're repeatedly forum-shopping, trying to use various processes to harass me, and twisting everyone's words or actions to try to suit your ends or fit your black-and-white view of some overarching conflict regarding cosmetic editing (e.g. accusing me of trying to prevent genfixes by approving a bot task that doesn't include them). ~ Rob 13 Talk 17:53, 22 June 2017 (UTC)
 * edits that change the visual output are not cosmetic. -- Magioladitis (talk) 17:56, 22 June 2017 (UTC)
 * And many of the genfixes do not affect visual output. Not to mention WP:COSMETICBOT reads "Minor edits are not usually considered cosmetic but still need consensus to be done by bots." Non-cosmetic minor edits also need consensus. Actually, all bot edits need consensus, though sometimes consensus is implied by silence. See WP:BOTREQUIRE. ~ Rob 13 Talk 18:04, 22 June 2017 (UTC)
 * exactly. The question is that do we want edits that are dscribed to the MoS to evetually happen or not? Is yes, how? Solely? In addition to other edits? -- Magioladitis (talk) 18:29, 22 June 2017 (UTC)
 * The MoS and CHECKWIKI/genfixes are very different, so this isn't a particularly well-formed question if you're trying to relate it to the current topic of discussion. Many "fixes" to the wikicode aren't mandated by the MoS (bypassing template redirects, reformulating piped links as regular links with text after them, etc). For low-priority MoS fixes, I'm happy to see them done as part of other bot tasks if the operator wants to take them on, but I don't think we should necessarily encourage it. It's ultimately a decision for the bot operator; do they want to be responsible for running someone else's code and have to deal with the bugs that comes with? They should not be the sole task. ~ Rob 13 Talk 18:36, 22 June 2017 (UTC)
 * I did not say anythong about CHECKWIKI tasks. I did not say that all general fixes should be done. This is a general policy page and I am discussing the policy the bots should have as guideline. -- Magioladitis (talk) 18:43, 22 June 2017 (UTC)
 * Your proposed text says "general fixes" once and "gen fixes" four times. It encourages bot operators to do them. How exactly do you "not say that all general fixes should be done" in those statements? ~ Rob 13 Talk 18:55, 22 June 2017 (UTC)
 * Doing some general fixes depending on skills or willingness does not imply "all general fixes". Bgwhite for instance was not tagging pages but only doing some of the general fixes. -- Magioladitis (talk) 19:02, 22 June 2017 (UTC)
 * There is currently no functionality in AWB to enable just some genfixes without using outside code. We already allow bot operators to enable genfixes if they request as much in their approval. ~ Rob 13 Talk 14:46, 23 June 2017 (UTC)


 * Support As the person who proposed it. -- Magioladitis (talk) 17:48, 22 June 2017 (UTC)
 * Oppose: My comments above still stand - GenFixes is not suitable for all bot tasks. Further the specific proposal seems to contradict itself, or at least it is too ambiguous. It first asserts that all bots... should, but then talks about bots being encouraged to make fixes. Are they compulsory or not? TheMagikCow (T) (C) 13:55, 23 June 2017 (UTC)
 * TheMagikCow this case only means that we encourage the bot editors nor force them. -- Magioladitis (talk) 14:09, 23 June 2017 (UTC)
 * Oppose - I wouldn't encourage or discourage it in the bot policy. If bot policy says anything about genfix: the option exists for certain frameworks, links to info, and potential problems to be aware of. --  Green  C  14:24, 23 June 2017 (UTC)
 * Oppose - This is simply not something that's needed at the policy level. Some bots have tasks that are clearly better suited to have genfixes off. Let's say ClueBot made used of the pywikipedia framework, rather than its own custom frameowork, it would still be a bad idea to have it both revert vandalism and do genfixes at the same time. Encouraging ClueBot to do such fixes would be detrimental. At the same time, it would also be detrimental to discourage from doing genfixes. IMO, the policy should be neutral on whether or not bots should do genfixes/cosmetic fixes. Headbomb {t · c · p · b} 14:37, 23 June 2017 (UTC)
 * Headbomb I get this point but we could for example check if this applies fir the bots that do simple find and replace activities. Recall that this was the standard norm for the pybots till their cosmetic.py script got outdated. Many bot operators had no problem activiating the script when encouraged too. -- Magioladitis (talk) 14:47, 23 June 2017 (UTC)
 * 1) That was years ago. 2) I have no idea what "activiating the sctit" means. 3) Any bot operator that wants to do genfixes or cosmetic fixes, or whatever fixes, is free to apply for them when they do a BRFA. To me, mentioning that bot ops running AWB may want to consider doing (not are encouraged to do) genfixes is something that should be mentioned at WP:AWB (or one of its subpage), rather than here. Likewise for pywkiki and other frameworks. Headbomb {t · c · p · b} 14:56, 23 June 2017 (UTC)
 * Headbomb sctit = script. On the other part, we could for example add something to the BRFA process: Would you like to run more fixes with the task or attach this task to another to save bot runs? -- Magioladitis (talk) 15:02, 23 June 2017 (UTC)
 * How about a compromise wording "are encouraged to consider"? All the best: Rich Farmbrough, 19:35, 23 June 2017 (UTC).


 * Agree. -- Magioladitis (talk) 19:58, 23 June 2017 (UTC)
 * The more the statement is watered down, the less sense it makes as a potential policy. I don't oppose the content of such a statement, but it isn't appropriate for a policy-level page. ~ Rob 13 Talk 21:09, 23 June 2017 (UTC)
 * It makes sense because it shows the direction the community wants to follow. Rephrasing COSMETICBOT was a first step to make things clearer for which edits have total support of the community. This is a step forward on the bot policy because the other step only described edits but did not describe how these edits will be done.-- Magioladitis (talk) 22:45, 23 June 2017 (UTC)

It's a step forward if you think these edits are high-priority and should be done by bots. There has been no community consensus supporting either of those, though. ~ Rob 13 Talk 22:50, 23 June 2017 (UTC)
 * BU Rob13 which edits do you mean? The Manual of Style is a proof of support to certain edits. Moreover, I discuss here various aspects. Which edits you mean exactly? You have to answer this. -- Magioladitis (talk) 22:52, 23 June 2017 (UTC)
 * I don't have to answer anything, and I actually can't here, as your entire premise is flawed. "Support certain edits" is not the same as "Support certain edits as high-priority and to be done by bots as rapidly as possible". It doesn't make sense to actually write into policy an encouragement to do a certain edit if they aren't high-priority. MoS edits are generally regarded as rather low-priority. Going forward, you can safely assume "edits" refer broadly to edits done by AWB genfixes, since genfixes are how this entire discussion has been framed. ~ Rob 13 Talk 23:08, 23 June 2017 (UTC)
 * "MoS edits are generally regarded as rather low-priority" Now we start to find the flaw in your logic. That's why I wrote that you have to explain your position because now all can see the source of the reaction here. MoS says nothing about priorities. MoS only states which rules apply to Wikipedia articles. -- Magioladitis (talk) 16:03, 24 June 2017 (UTC)
 * Consensus says something about priorities, and WP:CONSENSUS is a policy. We have policies preventing bots from doing these edits stand-alone (COSMETICBOT) and rules of use on AWB preventing it from being used solely for these edits (AWB Rules of Use #3). Those reflect a relatively low-priority. No-one (but you and a couple others) are clambering for these wikitext fixes as essential fixes for the encyclopedia. That's where the assessed low priority comes from. Having said that, I'm done talking to you about this, because you twist every single word I say. You either don't understand how consensus works, don't understand plainly-written English, or are purposefully misinterpreting what everyone tells you to push your agenda. Either way, continued dialogue is pointless. The community is sorting this out. ~ Rob 13 Talk 16:34, 24 June 2017 (UTC)
 * You became aggressive. I suggest that you calm down. The rest about your behaviour and your impolite replies may need to be discussed in a separate thread. Thanks for your time to explain your position. -- Magioladitis (talk) 16:49, 24 June 2017 (UTC)
 * This is simply wrong - and I think one of the points Magioladitis has been trying to make. There is nothing in MoS which is forbidden in COSMETICBOT.  By definition MoS refers to the rendered page, and by definition COSMETICBOT refers to things which don't affect that.
 * At the risk of muddying the waters, the position which espouses "general fixes" is not a "do things quickly" solution, it is rather an eventualist position. Some of these changes have taken years to achieve, and some are still ongoing and will take years more.  It is a shame when these changes, are derailed by obstructionism, as has happened not a few times, especially as they are taking the most low-impact method of implementation.
 * All the best: Rich Farmbrough, 17:57, 24 June 2017 (UTC).


 * Actually, no. First, to correct the obstructionist point, I support bot operators being able to choose to implement (or not) these fixes. That gives you the eventualist outcome you desire. To correct the rest of what you stated, WP:COSMETICBOT and WP:BOTREQUIRE both note that all changes bots make must have consensus to be done by a bot, specifically including minor changes. It is not the main point of COSMETICBOT, but it is in the text and clearly intended to be there. To quote specifically, "Minor edits are not usually considered cosmetic but still need consensus to be done by bots." (emphasis mine) I often wonder why editors wanting to make those small fixes don't just go the community at the village pump and say "Hey, here's a fix, should I do this?". Those discussions would be simple and completely support your outcome if the underlying consensus is actually what certain people claim it is. Is it really obstructionism to say you need consensus to make changes with a bot? That's a rather moderate position. ~ Rob 13 <sup style="margin-left:-1.0ex;">Talk 18:06, 24 June 2017 (UTC)
 * All tasks need consensus to be done by bots. This is redundant. -- Magioladitis (talk) 18:14, 24 June 2017 (UTC)
 * Glad you see my point. I'll point to this post in the future when you quote the MoS generally as supporting a task, as the MoS doesn't say a word about bots anywhere that I'm aware of. ~ Rob 13 <sup style="margin-left:-1.0ex;">Talk 21:18, 24 June 2017 (UTC)
 * You are in confusion I think. You mix MoS with bot policy. -- Magioladitis (talk) 06:26, 26 June 2017 (UTC)


 * The MOS supports certain changes, COSMETICBOT has nothing to say about those changes. It may make a reference to something outside its scope, in the usual WP:BLOAT manner.  No one is suggesting that that consensus isn't needed, though there is more than one way of demonstrating it.
 * As for obstructionism, it is, sadly, common. Lightmouse spent over a year trying to get people to agree that there was consensus for fairly uncontroversial fixes, but was opposed by a few (possibly even just one, I can't remember) editors at Talk:MoS.  We even had someone say that there was "more semantic information" in "otheruses" than in "other uses".
 * And I think that explains why people do not want to get into drama fests on VP.
 * All the best: Rich Farmbrough, 16:09, 25 June 2017 (UTC).

Nice example. Lightmouse spent a lot of time for conversions and unit fixes that were useful and yet the community failed to protect this work. -- Magioladitis (talk) 06:29, 26 June 2017 (UTC)

Another nice exxample where more on https could happen like remiving duplicated prefixes. -- Magioladitis (talk) 11:44, 30 June 2017 (UTC)

Interwiki bots
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 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 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. Please explain your reversion. --Izno (talk) 03:51, 25 June 2017 (UTC)
 * 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 13 <sup style="margin-left:-1.0ex;">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 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)
 * 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 13 <sup style="margin-left:-1.0ex;">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: HTH. Anomie⚔ 12:22, 26 June 2017 (UTC)
 * 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.
 * , 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.
 * 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====

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,, but there's got to be another better guideline or policy for that. This policy is related to bots only. ~ Rob 13 <sup style="margin-left:-1.0ex;">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:
 * There isn't a need for the date (I see you snuck that in, ). We document how it is now, not since when something changed.
 * 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).


 * 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 13 <sup style="margin-left:-1.0ex;">Talk 23:32, 28 June 2017 (UTC)
 * Do the thing! --Izno (talk) 11:52, 29 June 2017 (UTC)
 * ✅ Been a week and no-one else has gotten to it (and no-one vehemently disagreed). --Izno (talk) 15:43, 8 July 2017 (UTC)

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

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

WP:COSMETICEDIT
I've redirected this to WP:COSMETICBOT. The old version was, 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)
 * as an outsider here, and with no position on the behaviour of, 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)
 * 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 13 <sup style="margin-left:-1.0ex;">Talk 17:14, 3 August 2017 (UTC)
 * 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)

TIDY
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 13 <sup style="margin-left:-1.0ex;">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 13 <sup style="margin-left:-1.0ex;">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? - Kingpin13 (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 is changed to. 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 CHECKWIKI/WPC 002 dump and similar lists. – Jonesey95 (talk) 05:06, 11 July 2017 (UTC)
 * 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?)  would no longer work. ~ Rob 13 <sup style="margin-left:-1.0ex;">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 13 <sup style="margin-left:-1.0ex;">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 &lt;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. - Kingpin13 (talk) 18:00, 12 July 2017 (UTC)
 * Any changes to  should be to make it   (no slash). Tim Starling wrote RemexHtml to replace Tidy, and he recommended   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  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 . --Izno (talk) 02:32, 13 July 2017 (UTC)

Specific edit #2: b/ changed to /b
This edit changed an invalid self-closed to a correct. See, 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 13 <sup style="margin-left:-1.0ex;">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 '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 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, &lt;b/> is meant to be &lt;br/>. A bot or semi-automatic change for this needs to include the leading &lt;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 -   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 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)

ADMINBOT simplification
Please review.

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 13 <sup style="margin-left:-1.0ex;">Talk 23:03, 1 August 2017 (UTC)
 * Some thoughts:
 * 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]").
 * "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.
 * The licensing and publicity of the code is and should be discussed elsewhere, presently at WP:BOTPOL 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?
 * 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.
 * What goes unsaid in the paragraph highlighted in item 4, and which should be stressed there 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)
 * How about now? Headbomb {t · c · p · b} 04:20, 2 August 2017 (UTC)
 * ? 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
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 13 <sup style="margin-left:-1.0ex;">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 Bots/Requests_for_approval/RonBot to provide visibility and allow community comment. There were no issues. ~ Rob 13 <sup style="margin-left:-1.0ex;">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, ? ~ Rob 13 <sup style="margin-left:-1.0ex;">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)
 * 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 13 <sup style="margin-left:-1.0ex;">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)

WP:MEATBOT blocks by newbie User:Oshwah
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, nice to see you found more after I blocked the first one. Primefac (talk) 00:41, 17 November 2017 (UTC)

Bots that consume user time, and request for comment
Please see Village_pump_(proposals)/Archive_145. 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)
 * 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)
 * 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.
 * We know how many messages the bot in this case posted - 500,000+
 * We know how many views the talk pages where the bot posted were viewed - 10s of millions, probably 100s of millions over 2 years
 * We know that this particular bot solicited humans to read its messages and react
 * In response to the bot's solicitation, we have counts of how many times humans responded
 * We can measure how much time it takes for human to engage with the bot
 * 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
 * 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'. 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 or  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 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)
 * 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:
 * 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.
 * 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.
 * 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.
 * 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.
 * 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.
 * 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.
 * 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.  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)
 * 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)
 * 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)

Mass page moves
I've made a bold edit. If it is controversial, it can be discussed below. E to the Pi times i ( talk  &#124;  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)
 * 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 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  &#124;  contribs ) 03:54, 8 April 2018 (UTC)
 * 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
 * Do you have examples of problematic mass page moves, especially problematic script-assisted page moves?
 * Does preventing mass moves at a policy level solve more problems than it creates?
 * 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  &#124;  contribs ) 15:04, 8 April 2018 (UTC)

Creation of redirects
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 ·&#32; t ·&#32; 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. - Kingpin13 (talk) 00:24, 17 April 2018 (UTC)
 * Thanks, – much appreciated. Kevin ( aka L235 ·&#32; t ·&#32; 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)

RFC to ease introduction of citation templates to articles not presently using them
Please see Wikipedia talk:Citing sources

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)

Bot adoption
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)
 * 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)

New BAG nomination
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)