Wikipedia talk:Bot policy
From Wikipedia, the free encyclopedia
 |
The project page associated with this talk page is an official policy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Before editing this page, please make sure that your revision reflects consensus. When in doubt, discuss on the talk page. Always remember to keep cool when editing. Changes to this page do not immediately change policy anyway, so don't panic. |
 |
This is not the place to request a bot, request approval to run a bot, or to complain about an individual bot
|
 Archives |
|---|
|
Archive 1 · Archive 2 · Archive 3 · Archive 4 · Archive 5 · Archive 6 · Archive 7 · Archive 8 · Archive 9 · Archive 10 · Archive 11 · Archive 12 · Archive 13 · Archive 14 · Archive 15 · Archive 16 · Archive 17 · Archive 18 · Archive 19 · Archive 20 · Archive 21 Archive interwiki (also some approvals for interwiki bots) |
Contents |
[edit] Clarifying where some kinds of tool fit
There are certain kinds of tool that aren't clearly defined under the present policy wording. At present, bots are basically automated tools, and tools whose edits require some element of interaction come under "assisted editing".
There are some tools that are presumably assisted editing but not clearly defined as such, where the user doesn't "interact" for each edit, because the task is very well defined for each run, requires no element of machine judgement, and all interactional data is specified in advance of the run.
What these have in common is the use of an automated tool, to perform at high speed a repetitious and non-controversial "housekeeping" task on multiple "targets". They don't really come under "fully automated bots" since there is user interaction - it's just front loaded at the point the run is executed, by the user individually checking each action will be okay.
I'd like to see under assisted editing, something to the effect: "It also covers tools that perform well-defined non-controversial actions requiring no further judgement, on a previously checked list of targets."
The fact the user has checked the proposed targets individually beforehand, is the key. Can the wording be made more watertight to prevent its abuse for mass actions though?
Hopefully this aim is sensible and not controversial. FT2 (Talk | email) 02:50, 20 April 2009 (UTC)
- My understanding of the current policy is that the user has to approve each edit before the script commits it. Tasks that process a large number of simple edits at high speed, even if they are working off a user-generated list, must go through BRFA. I think the distinction is very clear in the existing language. Also, I reverted your change to the assisted editing definition for now. Wronkiew (talk) 04:29, 20 April 2009 (UTC)
- It seems to me that there are several reasons for the current approvals process in this case:
- To some people, "checked" means "I generated this list from known criteria", which fails if corner cases were not considered. For example, I've recently had requests to tag every page in Category:Energy and subcats and every page in Category:NATO and subcats with the corresponding WikiProject banners; in both cases, it was not hard to find a page a few levels down in the category tree that had nothing to do with the project.
- High-speed edits can mean high-speed mistakes. While we can't catch every mistake someone's bot might make, the approvals process does help detect them and the requirement to manually approve each script-assisted edit (hopefully) handles those scripts.
- Users often do not consider how their idea may be controversial, and (when we do our job right) BAG will point this out during the approvals process. Restricting unapproved actions to "human" speed gives reviewing humans a chance to object before too big of a mess is made.
- Is there something in particular this addition is aimed at? Anomie⚔ 12:07, 20 April 2009 (UTC)
-
- It's aimed at cases where a fixed well defined action is required on many pages. This arises quite regularly in checkuser or oversight work, where a vandal may post many dozens of "outing" data, all of which need the same treatment. Other examples are as a developer of the SPI process, having to change the format of the {{RFCU}} "request for checkuser" template on all SPI subpages that used that template, when it was modified to allow a second "case letter" to be added. A further case was a process update that would be of relevance to a number of users (~30 from memory), all of whom needed the same note added to their talk page so they were aware. In each case the matter may be classified as "routine", and the exact actions to be taken are listed and individually reviewed before any are processed, up front. These tend to be non-controversial types of actions that just need doing to a list of pages. What's being asked is to add that if each individual edit is checked (ie no "assumptions") and the matter is non-controversial, they may use an "assisted tool" (at "human" and not "bot" speed) to do the actual posting for them once they have reviewed all the proposed items. I think this fits into the criteria and spirit of "assisted tools", but it would be good to add it explicitly.
-
- Quick comments on the above - 1/ automated generation of "targets" isn't contemplated. Individual checking of each item is intended, before they are added. The tool acts purely as a saving on the repetitious activity, not a substitute for checking each case. 2/ See #1, 3/ Agree, this would appear to be an argument for speed restriction (as with all assisted editing) though, which is already in the policy. FT2 (Talk | email) 14:07, 20 April 2009 (UTC)
-
-
- The only example you give where having to get bot approval would be troublesome is your oversighting example, and even there I think it likely that a bot tasked to generically "revert (if necessary) and oversight a specific list of revisions determined by an authorized oversighter" has a fair chance of being approved and would be more likely to correctly handle any edge cases. As for the rest, we already have bots approved to manipulate templates without having to worry about any random user's poor regex skills, and we already have many bots approved to deliver notices to talk pages. And I doubt doing either with AWB in manual mode (or the equivalent using any other script falling under the current assisted-editing criteria) would be excessively onerous, if it came down to that.
- In general, well-defined non-controversial tasks by proven bot ops are precisely those that can easily sail through BRFA with little delay anyway, while ill-defined tasks and those by unproven bot operators are precisely those that should have more attention paid. Anomie⚔ 16:43, 20 April 2009 (UTC)
-
I used to use a tool I wrote called TINA (admins can view the page User:Ameliorate!/TINA). It worked by displaying a list of each changes it was going to make, as an example:
Somepage: {{sometemplate|someparam=foo}} --> {{sometemplate|someparam=bar}}Anotherpage: {{sometemplate|someparam=foo}} --> {{sometemplate|someparam=bar}}Someotherpage: {{sometemplate|someparam=foo}} --> {{sometemplate|someparam=bar}}
So in a list of 1000+ edits it was easy to see any corner-cases and exclude them. As far as I was concerned this was acceptable under "... but do not alter Wikipedia's content without some human interaction" as there was human interaction, just it was done en-mass at the beginning. I never received any complaints about it, so I would support any change to explicitly allow this. ~ Ameliorate! 04:52, 20 April 2009 (UTC)
- Back when you brought it up, I thought it displayed a bit more of a diff than that... Anomie⚔ 12:07, 20 April 2009 (UTC)
- I think that this should be in the bot tasks category. Even though the script is presenting all the diffs for confirmation before it makes any edits, no allowance is made for feedback by other editors. If someone disagreed with the change and it was running unattended, the only way they could stop it would be to have your account blocked. Wronkiew (talk) 17:11, 20 April 2009 (UTC)
- It stopped if anyone edited my talkpage. ~ Ameliorate! 23:24, 20 April 2009 (UTC)
- This is exactly the issue when trying to clarify the difference between a bot and a script. How/why is it different to manually approve 1000 changes in advance than to approve them all in real time as the script runs? Is there a difference between making a list of pages in userspace and using Twinkle BatchDelete on them versus making a list in a file and using a Python script to delete them? Mr.Z-man 06:36, 21 April 2009 (UTC)
- Yes, there is a difference. If you review a list of articles and then start the edits, the delay between the review and the edit may become long and intermediate edits become likely, which may change the edit from the form initially reviewed. When the edit is generated "live" and reviewed at the moment before the edit is made, the delay should be small. Deletions in particular can cause difficulties if done in large batches - I recall one case where an image was up for deletion for some deficiency in source or copyright info. An editor fixed it, then the image was deleted a few minutes later by a script run by an admin who had reviewed the pre-fix version. As I recall, the list of images was fairly lengthy, so the delay between review and actual deletion was quite long; the servers may have also been backlogged and delayed script work. Gimmetrow 01:51, 28 April 2009 (UTC)
- I've occasionally run semiautomatic scripts where I reviewed all the edits ahead of time, then the script made the edits for the next hour or so while I did something else (I was still online and available from my talk page in case of problems). The difference between what I was doing and what you describe is that the script was set up in such a way that any edit to a page between my review of that page and the script editing it would have resulted in an "edit conflict" (which would have prevented the script from editing that page at all and logged it), even if the edit happened half an hour before the script got to it, as long as it happened after my review. This is why we do not need a hard and fast rule here, otherwise you will encounter border cases that do not fall into your narrow definition of a semiautomatic script, but are in fact semiautomatic. In my opinion when the review happened should be irrelevant, so long as the reviewed version of the page to be changed is the same as the version that is in fact changed.--Dycedarg ж 02:11, 28 April 2009 (UTC)
- I could see it being semiauto if the edit is reviewed, then sometime later, immediately before the edit is actually attempted, the page is downloaded again to verify it's the same as the formerly reviewed version. Is that what you're doing, and could we count on other scripts doing that? Gimmetrow 00:22, 29 April 2009 (UTC)
- What the script I was using did was as follows: The timestamp of the revision I'd reviewed was compared to the timestamp of the latest revision of the page at the time the script was about to edit it, and if they did not match then the script didn't edit. So it accomplished the same thing. The asynchronous editing function in Pywikipedia does this automatically from what I can tell by looking at the code, so any semiautomatic script built using that would do it. As for other scripts, you can only count on this kind of checking if the person writing it was responsible enough to implement it. I would not have any problem with the bot policy specifying that this must be the case for these kinds of scripts; I would have thought that it would be a basic rule of common sense for this sort of thing anyway.--Dycedarg ж 05:09, 29 April 2009 (UTC)
- Unfortunately, common sense is far from common. Anomie⚔ 12:23, 29 April 2009 (UTC)
- Indeed it is. So how about a minor change to the policy inserting something along the lines of: "Edits to be made by semiautomatic tools may be reviewed en masse before a script makes the edits autonomously, so long as the pages are checked to ensure that no edits were made to the page in the intervening time between the review and the actual edit, and either the editor is available to stop the script or the script can be stopped by someone else (such as by editing the editor's talkpage) in case something goes wrong."--Dycedarg ж 21:05, 29 April 2009 (UTC)
- Unfortunately, common sense is far from common. Anomie⚔ 12:23, 29 April 2009 (UTC)
- What the script I was using did was as follows: The timestamp of the revision I'd reviewed was compared to the timestamp of the latest revision of the page at the time the script was about to edit it, and if they did not match then the script didn't edit. So it accomplished the same thing. The asynchronous editing function in Pywikipedia does this automatically from what I can tell by looking at the code, so any semiautomatic script built using that would do it. As for other scripts, you can only count on this kind of checking if the person writing it was responsible enough to implement it. I would not have any problem with the bot policy specifying that this must be the case for these kinds of scripts; I would have thought that it would be a basic rule of common sense for this sort of thing anyway.--Dycedarg ж 05:09, 29 April 2009 (UTC)
- I could see it being semiauto if the edit is reviewed, then sometime later, immediately before the edit is actually attempted, the page is downloaded again to verify it's the same as the formerly reviewed version. Is that what you're doing, and could we count on other scripts doing that? Gimmetrow 00:22, 29 April 2009 (UTC)
- I've occasionally run semiautomatic scripts where I reviewed all the edits ahead of time, then the script made the edits for the next hour or so while I did something else (I was still online and available from my talk page in case of problems). The difference between what I was doing and what you describe is that the script was set up in such a way that any edit to a page between my review of that page and the script editing it would have resulted in an "edit conflict" (which would have prevented the script from editing that page at all and logged it), even if the edit happened half an hour before the script got to it, as long as it happened after my review. This is why we do not need a hard and fast rule here, otherwise you will encounter border cases that do not fall into your narrow definition of a semiautomatic script, but are in fact semiautomatic. In my opinion when the review happened should be irrelevant, so long as the reviewed version of the page to be changed is the same as the version that is in fact changed.--Dycedarg ж 02:11, 28 April 2009 (UTC)
- Yes, there is a difference. If you review a list of articles and then start the edits, the delay between the review and the edit may become long and intermediate edits become likely, which may change the edit from the form initially reviewed. When the edit is generated "live" and reviewed at the moment before the edit is made, the delay should be small. Deletions in particular can cause difficulties if done in large batches - I recall one case where an image was up for deletion for some deficiency in source or copyright info. An editor fixed it, then the image was deleted a few minutes later by a script run by an admin who had reviewed the pre-fix version. As I recall, the list of images was fairly lengthy, so the delay between review and actual deletion was quite long; the servers may have also been backlogged and delayed script work. Gimmetrow 01:51, 28 April 2009 (UTC)
[edit] Change to bot account name policy
Please see the discussion here. Wronkiew (talk) 06:41, 27 April 2009 (UTC)
[edit] Wikipedia:Bot Approvals Group/nominations/Tinucherian
This is a 'mandatory' notification to all interested parties that I have accepted a nomination to join the Bot Approvals Group - the above link should take you to the discussion. Best wishes, -- Tinu Cherian - 10:58, 1 May 2009 (UTC)
[edit] BAG nomination for Nakon
Per the required "spamming" of venues, I would like to bring attention to my nomination for the Bot Approval Group, which may be found at Wikipedia:Bot Approvals Group/nominations/Nakon. Thanks, Nakon 01:23, 17 May 2009 (UTC)
[edit] "Right of first refusal"
I think it would be good to clarify long-standing practice that if source code has been released by an author and the author is able and willing to run it on a specific project, they have the right of first refusal. Any objections to clarifying this? --MZMcBride (talk) 22:39, 27 May 2009 (UTC)
- Yeah, I don't think this would be useful. It's not really a right. In some controversial cases, a task may require a particularly cautious and polite bot-runner, who may not necessarily be the person who wrote the code. Consider that in the date delinking case, we may find ourselves under the following restriction: "The Bot Approvals Group will require that the operators selected to perform any date delinking have a history of being able to handle complaints well, and willing to pause their bot when problems have been identified." This may well not be the author of the code, and I don't think giving the author "right of first refusal" would help the project. It's a good tradition, but a bad explicit guarantee. – Quadell (talk) 03:59, 28 May 2009 (UTC)
- I don't think etiquette should be encoded in policy, although IMO an essay might not be out of place. Anomie⚔ 11:09, 28 May 2009 (UTC)
- BTW, it would probably be a good idea to bring up the "Can you remain WP:CIVIL and respond promptly even if your talkpage is flooded with many repetitive uncivil complaints?" question on any "enforcement" BRFA. I'll have to try to remember that. Anomie⚔ 11:09, 28 May 2009 (UTC)
[edit] WT:Policies_and_guidelines#Subcats
Discussion about policy subcategories for several pages, including this one. As far as I know, this doesn't make any difference, except as a help to people trying to browse policy. - Dank (push to talk) 03:14, 9 July 2009 (UTC)
