Wikipedia:Semi-bots: Difference between revisions

The following is a proposed Wikipedia policy, guideline, or process. The proposal may still be in development, under discussion, or in the process of gathering consensus for adoption.

Shortcut [[:|WP:SBOTS]]

Proposed template/categorisation: {{Guideline}} (includes categorisation in Category:Wikipedia guidelines)

Proposed guideline in a nutshell: Only serialize edits that are covered by a broad consensus

Wikipedians are encouraged to be bold in their edits, or even to ignore all rules. For serialized or "semi-bot" edits, however, extra precaution is advised, and a broad consensus (as for example in official policy) for the type of edits you want to serialize is usually required.

This guideline gives a description of what is understood by serialized edits in this sense, explains which types of possibly contentious edits are better not serialized, and gives some general recommendations for operators of semi-bot auxiliary software.

A wikipedia semi-bot is defined as a non-botflagged account that performs repetitive tasks on different articles, at a pace slower than bot rate (30-60 seconds between edits).

Not considered "repetitive tasks on different articles" in the context of this definition:

• Moving a page together with its talk page (this creates four edits in one go);
• Cleanup after a page move or the creation of a disambiguation page (e.g. double redirect or disambiguation repair);
• Stub sorting;
• Updating categorisation and inter-wiki links;
• Reverting vandalism or removing obvious errors.

Apart from that, repetitive is defined very broad in this context: two consecutive edits only inserting redundant whitespace, with or without an appropriate edit summary, can be considered a pattern of repetitive editorial behaviour in the sense of this guideline.

For the practicability of this guideline, any user account using software which enhances the speed with which edits can be made (that is: faster than editing exclusively with a standard webbrowser installation), and that is not listed at WP:BOTS, can be labelled a semi-bot.

Whether the tasks are fully automated, or humanly-supervised for every edit makes no difference for the semi-bot definition, only a repetitive pattern of edits as defined above.

Semi-bot tools include (see also Wikipedia:Types of bots):

• Anti-vandalism plug-ins and other software (see also Wikipedia:Counter-Vandalism Unit#Detection and reversion):
  • VandalProof: AmiDaniel's VandalProof
  • Vandal Fighter: CryptoDerk's "original" (historical); Henna's continuation
  • Anti-vandal tool: Lupin's "original"; Radiokirk's implementation
• AutoWikiBrowser
• Popups and other JavaScript tools
• Conversion of citations/footnotes:
  • By SEWilco: Wikipedia:Footnote3/numlink2note.pl and Wikipedia:Footnote3/order-footnote.pl (note that use of these scripts has been restrained by ArbCom decision)
  • Cyde Weys' Ref converter (some of the implementations of this semi-bot ignore the ArbCom case mentioned above; converts all types of footnote3 templates, including Harvard references, to Cite.php footnotes)
  • User:Lulu of the Lotus-Eaters/citation tool (under construction, converts Cite.php footnotes to Footnote3 footnotes; tries to avoid the "conversion of footnotes" restraints by making conversions subject to the per-article choice of the semi-bot operator)
• Certain uses of the Pywiki bot, such as disambiguating

For non-botflagged bots that are in a trial run for bot status, or that are permanently listed as non-botflagged at WP:BOTS, the following applies: Don't do the type of tasks that are mentioned in this guideline as likely to be contentious, unless these tasks are properly described in the bot's job description.

Don't serialize edits that have a reasonable chance of being perceived as contentious.

In other words, being bold in updating pages and ignoring all rules are great principles that made Wikipedia to what it is. But don't push your luck: if you've found something about which you might guess that a significant batch of wikipedians would find it objectionable (or simply redundant in the sense of taking server time without inherent benefit), you can do it, and that would be covered by the boldness principle, even if a fellow-wikipedian has the boldness to revert it instantaneously - serializing over several articles something that is likely to be perceived contentious is not covered by the boldness principle.

• Since official policies are covered by a broad consensus, bringing articles in line with these policies in a serialized manner would generally not be perceived as contentious, so this usually can be performed by a semi-bot (but also see next point).
• When a guideline or policy implies that the appropriateness of certain edits is dependent from context or interpretation, it might be good to consider that "context" and "interpretation" are not mathematical concepts, and might be perceived differently by different people. Serializing an identical edit over several articles with "applying NPOV" as edit summary, for example, would not be a good idea in most cases.

See also the "Specific tasks" section below.

• Regarding performed tasks need a broad consensus: other wikipedians might have another view on page layout issues, which templates are used on which pages, etc... it's no fun to compete with a semi-bot in such case.
• Tasks that need individual interpretation or assessment of context and content of a page may easily lead to errors when performed on a repetitive scale, so if performed repetitively, such tasks can only be performed by accounts that have a proper bot task description.

This section lists some tasks that are specifically seen as not to be performed by semi-bots. This is not a comprehensive list limiting the "general principle" above; rather this list should be treated as a set of representative examples.

"Whitespace" consists of spaces, empty lines, etc.

Examples:

• Changing section headers from == Headline text == to ==Headline text== (or vice versa). The effect is not visible, and there is no consensus as to which is prefered. Performing such edits by semi-bot also creates redundant edit history.
• Adding spaces around pipes: while generally the visual effect would be nil, and some editors prefer it one way, while others prefer it another way, in specific cases the visual result may inadvertedly be affected, e.g. changing ([[:category:wikipedia essays|essay]]) to ([[:category:wikipedia essays | essay]]) leads to ( essay).

Wikipedia:Only make links that are relevant to the context mentions that context (which is always subject to interpretation) is important when deciding whether or not to apply a wiki-link.

An ArbCom case decided against serialised reformatting of Harvard references to footnotes^ref. The arbitrators justified this because whatever encouragements were inscribed in guidelines, there was no uniform format imposed by wikipedia policies and guidelines.

Regarding serialized reformatting of footnote3 footnotes-by-templates to Cite.php footnotes (current standard according to wikipedia:footnotes): a discussion to find consensus is currently going on at Wikipedia talk:WikiProject Fact and Reference Check#References formatting.

See Wikipedia:Redirect#Don't fix links to redirects that aren't broken. The consensus not to do this is narrow, and maybe could change over time to a permission to do this kind of linkfix. But even in that case it is not to be expected that the consensus would be very broad, so, until a broad consensus emerges: not recommended to be serialized.

If you're not sure whether a particular serialized edit would be perceived as contentious, a generic way for finding that out, is to request approval for that type of edit as a bot job at Wikipedia:Bots/Requests for approvals.

Edit summaries of changes performed by semi-bots should be clear as well about the performed changes as about the auxiliary software used, when such software is used.

Operators of semi-bots (whether separate account or not) should be reachable and responsive on an en:wikipedia talk page. Removing remarks given about the semi-bot's behaviour before ascertaining that the poster of the remark considers the remark properly handled is considered the same as "not being responsive". Following on the posting of a remark on the appropriate user talk page, a response is expected within minutes of the next edit by the semi-bot. Not being responsive may lead to the blocking of the semi-bot account, for which the blocking admin will leave a note on the contact page for the semi-bot. Alternatively, and this is preferred for semi-bot software that has this functionality, in case of lack of response the semi-bot software is temporarily disabled for that account, equally with an appropriate note to the semi-bot operator. For example AWB has such functionality at Wikipedia:AutoWikiBrowser/CheckPage#Enabled users.

Operators of semi-bots should be prepared to undo edits diverging from the principles of this guideline. These reversions should not destroy intermediate changes by other editors. Improving the semi-bot's settings without properly undoing previous problematic edits does not suffice.

Unlike bots, semi-bot operators are not required nor even specifically encouraged to take a separate user account for semi-bot operations. Nor does the wikipedia:sock puppet guideline discourage to take a separate account for serialized operations (which is a type of 'role' account), if it is made clear which semi-bot account relates to which semi-bot operator account, and what the precise 'role' of the separate account is.

So, the decision is up to the semi-bot operator. The reason for this section is to list pro's and con's for both approaches, in order to help a semi-bot operator to make his/her choice:

• A separate account might be perceived as some kind of bot, with its disadvantages, e.g. bot accounts are sooner blocked than bot operator accounts if a bot starts to behave strangely. If a semi-bot and its operator share the same account, this would usually make sysops hold back from pre-emptive blocking (which is not a big issue when applied to a separate account).
• If, on the long run, a semi-bot operator might want to request approval for bot status, it might be a good idea to start with a separate account, so that the behaviour of the account performing serialized operations is already known by the time of the bot account application (which would usually speed up the process of receiving approval as a bot for that account).
• Reachability: think for yourself what would be the easiest way for wikipedians to contact you with regard to issues on the semi-bot operations: if separate accounts would make it take longer before you notice a message has been sent to you (e.g. while you're logged in with the bot account, and you don't receive notification of messages left on your operator account's talk page), this might be a contra-indication for having separate accounts.
• Risk of being perceived as sockpuppeteering, e.g. forgetting to change login when expressing your opinion in a straw-poll may be ill-received.
• Cleaner separation of tasks: glitches performed by a semi-bot that are properly handled don't reflect back as much on the operator: if the two accounts are not separated the "glitch" is more identified with the operator.
• Starting as a semi-bot under your own account is certainly the less red tape solution.
• Sometimes the auxiliary software (if any is used) gives an indication: most of the typical semi-bot software (e.g. anti-vandalism tools) is designed to be used on a single account. Typical bot software (e.g. py framework) is rather designed for a separate account (even when used as semi-bot).

If a semi-bot operator decides to use a separate account it is recommended not to use "bot" in the semi-bot's account name (in order not to confuse with bots that have a listed and agreed upon job description). Instead it is recommended to use an account name in the vein of:

(derivative of) user's account name + "Task"

Where "Task" can be either just the word task, or a word that indicates a task. For example linkcheck could be a "Task" name for a semi-bot that checks whether external links are still live.