User:SeventyThree/Current

From Wikipedia, the free encyclopedia

 This page is a user's work in progress page, not an article, and may be incomplete and/or unreliable. The current version of this article is, or will be located at Wikipedia:Semi-bots.

[edit] Wikipedia:Serialized edits

This page 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. References or links to this page should not describe it as "policy".
Shortcut:
WP:SERIAL
Proposed template/categorisation: {{Guideline}} (includes categorisation in Category:Wikipedia guidelines)
Proposed guideline in a nutshell: Only serialize edits which are covered by a broad consensus

Wikipedians are encouraged to be bold in their edits, or even to ignore all rules. For serialized edits, however, extra precaution is advised, and a broad consensus, for the type of edits you want to serialize is desirable.

This guideline gives a description of what is intended by the phrase "serialized edits", and explains which types of possibly contentious edits should not serialized.

Contents


[edit] Definitions

Serialized editing is defined as performing repetitive tasks on different articles.

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

  • Moving a single 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 inter-wiki links;
  • Reverting vandalism or removing obvious errors.

Apart from that, repetitive is defined very broadly: two consecutive edits only inserting redundant whitespace could be considered a pattern of repetitive editorial behaviour, and fall under this guideline.

[edit] General principle

Being bold in updating pages and ignore all rules are great principles which help to make Wikipedia what it is. If you wish to change something in a single article and you guess that a significant number of wikipedians may find the change objectionable or redundant (in the sense of taking server time without inherent benefit) you can do it; that would be covered by the boldness principle, even if a fellow-wikipedian has the boldness to revert it. However, serializing this edit over several articles would not be a good idea.

  • When in doubt whether it would be a good idea to serialize a particular type of edit, you may want to consult your fellow-wikipedians before proceeding with the serialized edit. The proposal can be raised on an appropriate talk page, a village pump page, Wikipedia:Current surveys, etc.
  • One way to find out if an edit should be serialized is to request approval for that type of edit as a bot job at Wikipedia:Bots/Requests for approvals.

Even simple tasks that need individual interpretation or assessment of context and content of a page can easily lead to errors when performed repetitively.

Users who serialize a set of edits should be prepared to undo edits diverging from the principles of this guideline. These reversions should not destroy intermediate changes by other editors.

[edit] Software and Bots

Users of any software which enhances the speed with which edits can be made (that is: faster than exclusively editing with a standard webbrowser installation), should be particularly careful.

Botflagged accounts are excluded from this guideline. Accounts that are in a trial run for bot status are also excluded - however, remember that only tasks which are properly described in the bot's job description and trial run description should be done.

[edit] Examples

This section lists some tasks and whether they should be performed in a serialized manner. This is not a comprehensive list limiting the scope of this guideline; rather this list should be treated as a set of examples.

[edit] Policies and Guidelines

Since official policies are covered by a broad consensus, bringing articles in line with these policies in a serialized manner would generally be perceived as uncontentious.

Guidelines are also covered by consensus, but they are more likely to have exceptions. As such, more care needs to be taked when applying guidelines in a serialized manner.

  • When a guideline or policy implies that the appropriateness of certain edits is dependent on context or interpretation, it is wise to consider that different people might choose to make different edits. For example, an ArbCom case decided against serialised reformatting of Harvard references to footnotes. The arbitrators justified this because whatever encouragements were inscribed in guidelines, there was no uniform format imposed by wikipedia policies and guidelines.

[edit] Style Guidelines

Style guidelines (the Manual of Style and other pages in Category:Wikipedia style guidelines) often hold recommendations that are not suitable to be serialized indiscriminately.

For example Wikipedia:Lead section#Be appropriate length currently recommends that articles with less than 15000 characters have a lead section of less than three paragraphs. Systematically lumping together the lead section paragraphs of such articles would probably not be a good idea: depending on context it might be better to create subsection headers or otherwise reorganise the content of such articles.

Another example is linking/delinking words. 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. Because of this, serializing linking or delinking is often contentous.

[edit] Adding/removing whitespace

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

Examples:

  • Changing section headers from == Headline text == to ==Headline text== (or vice versa). There is no visual effect on the output, and there is no consensus as to which is prefered. Serializing these edits alone is largely redundant, may spamming Recent Changes, and may hide vandalism from user's watchlists.
  • Adding spaces around pipes. While generally there is no visual effect (as above), in specific cases the visual result may inadvertedly be affected. For example, changing ([[:category:wikipedia essays|essay]]) to ([[:category:wikipedia essays | essay]]) changes the appearance from (essay) to ( essay).

[edit] Fixing redirects that aren't broken

See Wikipedia:Redirect#Don't fix links to redirects that aren't broken. The consensus not to fix these is narrow, and may change. Until a broad consensus emerges, serializing these edits is not recommended.

[edit] Re-ordering category sequences alphabetically

Wikipedians have spent quite some time to find the "ideal" order of categories listed at the bottom of an article. No consensus has resulted thus far. See Wikipedia talk:Categorization of people#Order of the categories for a summary of the discussions.