Wikipedia talk:Bot policy

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:BOTS)
Jump to: navigation, search
Archive
Archives

1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27


Control proposals


Archive policy


Archive interwiki (also some approvals for interwiki bots)

TIDY[edit]

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? ~ Rob13Talk 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). ~ Rob13Talk 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/[edit]

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

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

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

@Jonesey95: I think this is the opposite of the edit that should be made. The page on Meta says self-closing tags will no longer be valid, meaning (I think?) <br/> would no longer work. ~ Rob13Talk 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. ~ Rob13Talk 10:18, 11 July 2017 (UTC)
Personally, if tidy fixes it, and the tidy replacement fixes it, I'd have to say this is cosmetic yes. This wouldn't be egregiously invalid html, but rather an acceptable wikicode variant. Headbomb {t · c · p · b} 12:00, 11 July 2017 (UTC)
Certain self-closing elements are no longer valid. However, void elements may optionally contain a slash, and <br> is a void element. --Izno (talk) 12:13, 11 July 2017 (UTC)
Before Andy's bold edit, this edit would have been considered cosmetic. Re-read the policy, it is the other way around, before Andy's change such things were specifically exempt, he removed that exemption. - Kingpin13 (talk) 18:00, 12 July 2017 (UTC)
Any changes to br should be to make it <br> (no slash). Tim Starling wrote RemexHtml to replace Tidy, and he recommended <br> without a slash because it is simpler and is valid wikitext. Johnuniq (talk) 01:33, 13 July 2017 (UTC)
Unfortunately, the current syntax highlighter gadget doesn't handle <br> gracefully. Perhaps when the new syntax highlighter is available, there will be no functional difference between the unclosed and self-closed version of the br tag. – Jonesey95 (talk) 01:59, 13 July 2017 (UTC)
Until Html 5 specifies otherwise (whatever Tim thinks about the value of slashes), a slash is valid, so wikitext will no-doubt support it forever also. --Izno (talk) 02:32, 13 July 2017 (UTC)

Specific edit #2: b/ changed to /b[edit]

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

If we know a software change is going to break pages, it seems useful to be proactive in fix the errors ahead of time, before such a change is deployed. Of course, after the change is deployed, the rendering will change, making the edit no longer cosmetic. Anyways, these kinds of edits seem fine and necessary to me. Legoktm (talk) 06:23, 11 July 2017 (UTC)
I totally agree. Having a good quality code (i.e. no broken tags) and not depending on how wicicode is converted to HTML is a good proactive action. -- Magioladitis (talk) 06:39, 11 July 2017 (UTC)
This one is completely fine. ~ Rob13Talk 10:18, 11 July 2017 (UTC)
I've had a bot working on the "invalid self-closing tag" issue across many projects (c.f. meta:User:Fluxbot/BADHTML. — xaosflux Talk 11:24, 11 July 2017 (UTC)
To @Jonesey95:'s question: these are primarily cosmetic today - but this has been a planned change for a long time, so community authorizations were sought in advance for the specific task. — xaosflux Talk 11:30, 11 July 2017 (UTC)
Personally, if tidy fixes it, and the tidy replacement doesn't fix it, it's not cosmetic in the sense of the policy. I wish whoever maintains CW Error #02 would update the logic to remove self-closing line breaks from it (or split 02 into 02a and 02b) though. Headbomb {t · c · p · b} 12:04, 11 July 2017 (UTC)
I've made this change and I've found it can be contextual--sometimes, <b/> is meant to be <br/>. A bot or semi-automatic change for this needs to include the leading <b> in the regex. I presume everyone here realizes that problem. --Izno (talk) 12:10, 11 July 2017 (UTC)
Yes, this is one extra reason why b tags should also be fixed. -- Magioladitis (talk)
Please be careful, Magioladitis. – Jonesey95 (talk) 13:07, 11 July 2017 (UTC)
Jonesey95 Why did you add this here? Did I do something? -- Magioladitis (talk) 12:02, 12 July 2017 (UTC)
This is a discussion about cosmetic edits. – Jonesey95 (talk) 14:11, 12 July 2017 (UTC)
Jonesey95 and potentially these edits will change the visual output. Moreover, if there is consensus we can fix those. Here, I am referring to the case a b tas was added instead of a br tag. -- Magioladitis (talk) 14:53, 12 July 2017 (UTC)
Agree @Izno: - <b> tags are not so easily replaced - they often need manual attention to address what is really trying to be done, fortunately (and I was somewhat surprised) enwiki isn't plagued by 'br' and 'b' errors anywhere as much as some of the other language projects - and when it comes down to throwing the kitchen sink at making visual layouts wikisource is the toughest! — xaosflux Talk 13:24, 11 July 2017 (UTC)
Probably due to the checkwiki and AWB efforts by certain editors. --Izno (talk) 15:08, 11 July 2017 (UTC)
Izno Exactly. I 've been fixing this for 6 years daily with the help og Bgwhite and others. AWB and WPCleaner provide functions for these. -- Magioladitis (talk) 12:04, 12 July 2017 (UTC)
Back to @Jonesey95: original question - yes its cosmetic today, but it isn't expect to be in the future - and cosmeticbot doesn't apply to casual cleanups made by editors anyway - if you were to start flooding recent changes (by not using a flagged bot and making a large number of highspeed edits) I'd expect you would get called out for disruptive editing. — xaosflux Talk 01:54, 13 July 2017 (UTC)

WP:COSMETICEDIT[edit]

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

@Headbomb: as an outsider here, and with no position on the behaviour of Magioladitis, I do think that a definition of "cosmetic editing" that is clearly independent of the operation of bots is desirable. When I need to draw the attention of editors, particularly new editors, to the undesirability of making edits like removing double spaces in the wikitext or inserting/removing spaces after and before = in section headings when not accompanied by any substantive edits, it's not helpful to have to refer to a WP page about bots. Peter coxhead (talk) 17:10, 3 August 2017 (UTC)
@Peter coxhead: You're welcome to write an essay on minor non-significant edits; I would avoid calling them cosmetic edits if possible because that confuses things. There is no policy or guideline that prevents editors from making cosmetic-only edits manually, although it's not a good use of time. ~ Rob13Talk 17:14, 3 August 2017 (UTC)
@Peter coxhead: We have WP:ME which could probably host a bit about such edits, where it could be defined in a noob-friendly way "As a rule of thumb, if an article is rendered the same way before and after an edit, you've likely made a useless edit" (with have WP:USELESSEDIT as a shortcut).Headbomb {t · c · p · b} 17:23, 3 August 2017 (UTC)
It seems to me that WP:ME at present is carefully written to exclude "cosmetic edits"; see e.g. the list under "When to mark", so it could be confusing to add such material there. It needs some thought. I certainly wouldn't use "USELESSEDIT" as a short cut; this is too aggressive for new editors. Peter coxhead (talk) 06:20, 4 August 2017 (UTC)

ADMINBOT simplification[edit]

Please review [2].

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. ~ Rob13Talk 23:03, 1 August 2017 (UTC)
Some thoughts:
  1. I'm not sure holding a consensus discussion at AN is appropriate given the number of people who may be interested in an adminbot whom are not admins. I think the better text was the former, or something like it (maybe "be held at a 'public' [insert good word there] location and advertised widely, at a minimum at WP:AN, WP:VPPRO, WP:VPT, and WP:RFC [if you want to get specific]").
  2. "Without a demonstrated need" (or even a demonstrated "want"), a bot will be denied regardless of its admin flag, won't it (the spirit, if not wording, of WP:BOTREQUIRE)? This seems like fluff and should be removed.
  3. The licensing and publicity of the code is and should be discussed elsewhere, presently at WP:BOTPOL#Configuration tips for generic bots (the last paragraph). That is also a sub-optimal location I think, since the licensing and publicity of the source is irrelevant to the bot's configuration (unless someone wants to change it). Perhaps both statements should be moved to WP:BOTREQUIRE, since one might expect this to be a requirement, even if it is not?
  4. The whole paragraph at Administrators running a bot should babysit their bot during development and trial and terminate it at the first sign of incorrect behavior. Administrators are responsible for the behavior of robots that are allowed to run wild. Like for any bot, adminbot operators must exercise their best judgment when making alterations to their adminbot's logic, especially if they can significantly alter the bot's behavior. Administrators are allowed to run semi-automated tools (assisted use of administrative tools) on their own accounts but will be held responsible if those tools go awry. doesn't tell us anything new regarding who is responsible for an adminbot vice the entire rest of the policy (especially WP:BOTISSUE). Consequently, I think that paragraph should be removed.
  5. What goes unsaid in the paragraph highlighted in item 4, and which should be stressed there instead of all that fluff, is WP:ADMINCOND (and/or WP:TOOLMISUSE), since that may be an additional significant issue affecting an administrator bot (which may require a consensus process a bit stronger than the simple updates you've done, but since we're looking at the section anyway...).
In other words to items 2-5, an adminbot is just a bot with the admin toolset (and not an admin with a bot toolset, IMO), and so the qualities of the admin toolset are what should be highlighted in this section. --Izno (talk) 03:18, 2 August 2017 (UTC)
Re:1/2 The idea was "do your homework" before you file it. Demonstrate a need/want for it, and do at before you get to BRFA. WP:AN seems like a natural place for this, but really any place is fine.
Re: 3 I think the point was that since adminbots have the potential to much more damage, code needs to be available for review. The concern is likely mostly theoretical, given that I can't recall one time this provision was invoked/needed. I didn't feel comfortable removing this part without an RFC, however.
Re: 4/5 Yes, it's kinda said elsewhere. It's not really critical to include in the current form, but a reminder that 'if you fuck up, it's on you' is good. WP:ADMINCOND (and/or WP:TOOLMISUSE) are good, but those often required intent.
I'll further trim/edit it. Headbomb {t · c · p · b} 03:56, 2 August 2017 (UTC)
@Izno: How about now? [3] Headbomb {t · c · p · b} 04:20, 2 August 2017 (UTC)
@Izno:? Headbomb {t · c · p · b} 11:37, 11 August 2017 (UTC)
I was waiting for other feedback before commenting again. I still think the changes are insufficient, but I don't care enough to push. --Izno (talk) 12:44, 11 August 2017 (UTC)

RfC on admin bot trials[edit]

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

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

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

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

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