Wikipedia:Wikipedia Signpost/Single/2010-10-18

Common issues seen in Peer review

While the lead is the first section our readers see, it is usually the last section in an article to be written (or at least finalized). This is because the lead should be a summary of the whole article. A good rule of thumb is to mention every section in the lead in some way, even if only through a word or phrase.

Because it is a summary, the lead should contain no material that does not appear elsewhere in the article. For the same reason, the lead should be brief — not more than four paragraphs.

While the lead can have references, most articles do not include them there (again since it is a summary, all information in the lead should be mentioned and referenced elsewhere in the article). The main exceptions to this are direct quotations and contentious claims, which should be referenced no matter where they occur.

A good way to write the lead is to wait a few days, then reread the whole article except for the lead, then try to summarize it as a lead section. Another way is to imagine that a reader is restricted to reading only the lead: what points are essential and what can be omitted in that situation?

More information

• Wikipedia:Lead section

Citing reliable sources is critical to verifying an article's claims. A good rule of thumb is to provide at least one source for each paragraph as well as sources for all quotations, all statistics, and any claim that is challenged or likely to be challenged. Each source should clearly support the text it is used for. Blogs, personal websites, and other self-published materials are not usually reliable sources.

Wikipedia articles use what are called "inline citations", each of which is added to the main text. One option is to use parenthetical references, and another is to use clickable footnotes. For the latter, the citation details go between a pair of <ref></ref> tags. These should be placed inline directly after the end punctuation of the text that is being supported. Editors can format citations in a variety of ways, by hand or by using templates such as those of the "cite" family. A good rule of thumb for Internet sources is to include, if available, the author, title, publisher, date of publication, URL, and access date. WP:CIT includes lists of desirable data, such as ISBN numbers, for other kinds of sources.

A "References" or "Notes" section must be added to the article to make the citations fully functional. This section must contain either the <references/> tag or a small template such as {{reflist}}, which will automatically display the citation details, what is inside the <ref></ref> tags, in the "References" or "Notes" section.

Editors who use citation templates should take care not to mix the "cite" family with the "citation" family or other families. Dates in the citations of any particular article should be formatted in the same way; i.e, m-d-y or yyyy-mm-dd for US-centric articles and d-m-y or yyyy-mm-dd for most non-US-centric articles. Page ranges in the citations and elsewhere take en dashes rather than hyphens.

In addition to making Wikipedia's text verifiable, an article's citations provide readers and researchers, including other Wikipedia editors, quick access to sources that may be useful in other ways, such as when doing academic research. References add greatly to the encyclopedia's value.

More information

• Reliable sources in content review processes
• Sources in biology and medicine
• Wikipedia:Identifying reliable sources
• Tutorial: adding citations

Common image problems that are easily fixed involve size and spacing. "Thumb" is the preferred size for most images, though the lead image, maps, galleries, and panoramas are notable exceptions. It is possible to make images too small or too large, and it is possible to have too few images or too many. Judgment is required to decide how best to present an image in the larger context of the whole article. To avoid blankness on the one hand and clutter on the other, a good rule of thumb is to aim for one image per main text section and to place each image entirely within the section it illustrates. Generally, directional images such as eyes looking one way, or horses running left or right, should be placed so that "following" an image goes into the text of the page rather than away from it.

Images need captions, and it is good practice (although not explicitly required) to add alt text for readers who cannot see the images. WP:CAPTIONS has more on captions, and WP:ALT explains alt text.

Images must be properly licensed either as free-use or fair-use, and the image description and license page should include the "who, what, when, where" of the image itself, the license, the categories, and the author, original source, date, and any other information needed to verify that the license is legal and appropriate. Licensing is fairly straightforward with self-made photos but can be quite complicated in the case of images scanned from books, or obtained via Flickr, government web sites, or other sources. In these cases, great care must be taken to avoid violating copyright law.

Images used under the Fair use clause of United States copyright law must follow Wikipedia's policy on non-free content, which stipulates (in part) that fair use images must have no free equivalent, be used minimally, and must have contextual significance in the article in which they appear. So, for example, fair use images of living persons or existing buildings are almost never allowed, as they could conceivably be replaced with free images. Fair use media must be mentioned in the article in which they appear, and must add significantly to the reader's understanding of the topic.

More information

• Wikipedia:Image use policy
• Wikipedia:Picture tutorial
• Wikipedia:Non-free content criteria
• Reviewing free images
• Reviewing non-free images

Although good prose styles can vary considerably, it is helpful to keep in mind the encyclopedia's diverse audience. A good rule of thumb is to imagine a readership of ordinary adults fluent in English but unfamiliar with the material being presented. Jargon needs to be explained or linked. Abbreviations generally need to be spelled out on first use. Slang, which can be bewildering to readers living in various places around the world, should be avoided. To the extent possible, technical material should be written in plain English and technical terms either explained or linked.

Paragraphs should be neither too long nor too short. Giant paragraphs put readers to sleep, while a succession of tiny ones clutters the page and turns prose articles into lists. Do not use lists if a passage reads easily using plain paragraphs. If an article's essence is a list, it should have a title such as "List of rivers in Asia".

Good sentence structure can vary widely, but most sentences in an article should be neither extremely long nor extremely short. Exceptions can be delicious if clear; readers do enjoy variety.

Embrace the active voice. For example, instead of "Cat was chased by Mouse," write "Mouse chased Cat". Three words beats five.

Editors are often very familiar with the subjects they write about. If the article omits useful background information, this can cause problems for general readers who are less familiar with the topic. Be sure to provide context for the reader in all articles, and to write from a real-world perspective in articles about works of fiction. WP:MOSFICT has more on writing about fiction.

More information

• User:Tony1/Writing exercise box
• User:AndyZ/Suggestions
• Provide context for the reader
• The problem with in-universe perspective

While Wikipedia's Manual of Style (MOS) covers many topics, there are some MOS issues that are frequently seen at peer review.

Section and subsection headings should be uniquely named within an article, and should not contain links. These headings should avoid repeating the name of the article if at all possible (so in an article on Chicago, the section would not be "Chicago parks", but just "Parks"—the reader already knows the article is about Chicago). Only the first letter of the first word and proper nouns are capitalized. Avoid very short sections or subsections.

Measurements are generally given first in International System of Units (SI) units, except for articles on the US, where United States customary units may be given first, and with a partial exception for the UK. Except for some scientific articles, units should be converted so that they are given in both systems; the {{convert}} template is useful for doing this for almost any conversion.

Use a non-breaking space (&nbsp;) between numbers and units or symbols such as $3 million or State Route 43, or between dates and months to avoid awkward line breaks. The convert template does this automatically, and the {{nowrap}} template has the same effect.

Quotations should be within double quotes ("like this"). Single quotes ('like this') are used only for a quotation within a quotation: "John asked Mary 'Are you going too?', but she was not interested." Wikipedia uses logical quotation, so unless it is a complete sentence or thought, the punctuation goes outside the quotation marks. Block quotes are generally three or more lines long, and should use the {{quote}} or related templates. The {{cquote}} template is used only for pull quotes.

Do not use italics to show that something is being quoted. Italics are used for names of genera, court cases, vehicles, works of art, foreign words, and to show words as words as in "the word bumblebee ". Italics can be used for emphasis, though this is rare; bold face is never used in this way on Wikipedia.

One of the most useful features of Wikipedia is the ability to use internal links or wikilinks to direct readers to other articles in the encyclopedia. The usefulness of such links is reduced if there are too many links in the article. Only link to articles which would help increase the reader's understanding of the topic. Avoid links to common terms and generally avoid repeating the same link in an article, unless the second one is much further down and it seems important to link it.

Spell out abbreviations on first use; for example, "the Pennsylvania Department of Conservation and Natural Resources (DCNR)", rather than just "the DCNR", unless it is so well-known that this seems unnecessary ("BBC").

More information

• Wikipedia:Headings
• Wikipedia:Units
• Wikipedia:NBSP
• Wikipedia:MOSQUOTE
• Wikipedia:Italics
• Wikipedia:MOSBOLD
• Wikipedia:Overlink

There are almost always more peer review (PR) requests than reviewers, which has led to limits and restrictions. Editors are limited to one peer review request per day, and no more than four open peer reviews at one time. Peer review is for more developed articles, which must be free of any major cleanup banners, including, but not limited to {{cleanup}}, {{wikify}}, {{NPOV}}, {{unreferenced}}, or large numbers of {{fact}}, {{clarifyme}}, and {{huh}}. An article that has had a peer review, or gone through the substantial review process at FAC unsuccessfully, cannot be listed at PR until at least two weeks after the archive of its previous review, to allow time for the comments from the previous PR or FAC to be addressed.

Peer reviews that have received little or no feedback after four days are placed on the PR backlog, where they will still receive a review. As this can take time, editors who submitted articles are encouraged to look at the links in the Toolbox on the peer review page for their article, and then fix any problems found using the various tools. These toolbox links include automated tips, as well as checks for disambiguation links and external links in the article.

Be aware that peer review is a place to identify problems, but not necessarily to receive fixes for them. The reviewers at PR generally do not have time to do copyedits or other large scale fixes. Peer review is a good place to help out; even a single comment can be very useful. More reviewers are always needed and welcome!

More information

• Wikipedia:Peer review/guidelines
• Interview with Ruhrfisch, master of peer review
  
  Reader comments
  

2010-10-18

Climate change case closes after 4 months

Contribute  —  

Share this

•  E-mail
•  Facebook
•  Twitter
•  LinkedIn
•  Reddit
•  Digg

By Ncmvocalist

The Arbitration Committee opened no cases this week, but closed one, leaving one open.

Open case

Stevertigo 2 (Week 3)

This case concerns accusations of wiki-hounding and disruptive editing, and was filed by Stevertigo, a Wikipedia editor since 2002. He alleges that several editors deem his editing to be "disruptive" or "in need of banning" because they "still hold the grudge that previous cases did not find in their favor regarding [Stevertigo]". He also alleges that he "largely won" an argument against two editors in relation to the Time article, and that those two editors began editing the Punishment article due to an undue interest in Stevertigo's editing rather than due to an interest in the article. The case is currently in the evidence and workshop phase. Drafting arbitrators Kirill Lokshin and SirFozzie have placed proposals on the workshop page which have attracted limited input, mostly from a couple of parties and arbitrators. At the time of writing, no uninvolved users from the Community have commented on the proposals.

Closed case

Climate change (Week 19)

This case was opened after several requests for arbitration were filed on the same topic. Innovations were introduced for this case, including special rules of conduct that were put in place at the start. The case generated a number of concerns and criticisms, particularly in relation to its handling; a common concern was that arbitrators failed to sufficiently engage with participants, adversely affecting the ability of many participants to provide meaningful evidence in support of their (or in response to others) claims (see coverage by Signpost: last week, earlier).

The evidence and workshop pages were closed for an extended period; however, no proposals were posted on the proposed decision page and participants were prevented from further discussing the case on the case pages. A month after the workshop pages were closed, a proposed decision was posted; this sparked a large amount of unstructured discussion, mostly comprising concerns about the proposed decision (see earlier Signpost coverage). A number of users, including participants and arbitrators, made the discussion more structured, but the quantity of discussion continued to increase significantly. Arbitrators closed or archived discussions more frequently, particularly in the final weeks of the arbitration. The highly anticipated decision was enacted during the week; it attracted several responses.

What is the effect of the decision and what does it tell us?

• Articles related to the climate change topic (CCT) are subject to specially tailored discretionary sanctions. Editors should avoid contributing towards a battlefield mentality.
  • These specially tailored discretionary sanctions may not be applied by Lar, Stephan Schulz, and other administrators who similarly fit the case’s description of an involved administrator.
• A Quest For Knowledge, ATren, ChrisO, Cla68, FellGleaming, GregJackP, Hipocrite, JohnWBarber, Marknutley, Minor4th, Polargeo, Scjessey, Thegoodlocust, Verbal, William M. Connolley, and ZuluPapa5 are each indefinitely banned from the CCT.
  • Each user may appeal their restriction after 14 April 2011.
  • Scjessey may revert obvious vandalism and make routine cleanup-style edits to CCT (as part of Wikipedia:Recent changes patrol).
• KimDabelsteinPetersen is indefinitely limited to one revert per page per 24 hour period within the CCT, and is indefinitely banned from editing biographies of living persons.
  • KimDabelsteinPetersen is banned from the CCT until 14 April 2011.
• It is not the role of the Committee to decide the outcome of content disputes or to push for changes to any existing outcomes. The Committee’s decisions should be supplementing the standards established by the Community rather than moving towards changing or superseding them. That is, Wikipedia’s policies remain in effect; in situations where Community standards permit administrators or the Community to intervene, it remains appropriate to intervene in that way even if Committee measures like discretionary sanctions also apply.
• Experienced administrators are encouraged to assist with the enforcement of sanctions that are imposed by the Community or the Committee. Experienced administrators and checkusers are encouraged to closely monitor new accounts that edit inappropriately in the CCT area.
  
  Reader comments
  

2010-10-18

Video subtitling tool, staff vs. volunteer developers, brief news

Contribute  —  

Share this

•  E-mail
•  Facebook
•  Twitter
•  LinkedIn
•  Reddit
•  Digg

By Jarry1250

Universal Subtitles editor comes to Commons

For some time, visitors to Wikimedia Commons have been able to access "timed text" (a system of time references and accompanying text, better known by its applications as subtitles and closed captions) via the mwEmbed gadget. The subtitling effort has been hampered, however, by the lack of a useful editor for the timed text. "Universal Subtitles", a Mozilla Drumbeat project, aims to fill the void for all websites, but Wikimedia had not been able to integrate it. That changed this week, when developer Michael Dale announced that (Wikimedia Techblog):

“

Today, I am happy to share our first pass at integrating our open subtitle efforts. Please keep in mind this integration is still very early on in development, but the basic milestone of being able to use the tool on commons to create and sync up subtitle tracks is an important first step. Even without helpful tools in place, the Wikimedia community has been creating subtitles and translations. We hope this new subtitle edit tool will broaden the number of participants and enable the Wikimedia community to set a new standard for high quality multilingual accessibility in online video content.

”

An example is available, and it is also possible to leave feedback.

Staff, paid developers and volunteers: discussions continue

This week saw a revitalised drive towards reaching an understanding between WMF staff decision-makers, WMF paid developers, and the volunteer development community. For a long time the creation of the MediaWiki software, which Wikimedia, Wikia and a number of other sites rely on, had a development cycle that operated like a wiki, for better or worse. It included a large number of volunteer developers and only a handful of paid employees (for example, Brion Vibber); their contributions were checked and deployed in sequential order. With its budget expanding in recent years, the Foundation has been able to hire more developers, who are now involved in a large number of projects some would perceive as being nearly impossible for a volunteer to complete in their spare time. Likewise, the review system has been updated to allow important fixes to be deployed out-of-cycle without first reviewing other more minor edits. Staff and developers, both paid and volunteer, are now concerned that a tension is growing between the various parts of the jigsaw, an "us vs. them dynamic" (Erik Möller, Deputy Director), similar to the conflict that had flared up earlier this year between the User Experience team and volunteer developers over a seemingly minor issue (the display of interwiki links, see Signpost coverage), where Möller had likewise observed "a widening gap between staff and volunteer contributions". Paid developer Roan Kattouw put his thoughts down (Wikitech-l mailing list):

“

Since the discussion about staff collaboration with volunteers started a few weeks ago, actions and statements by staff members have undergone an increasing amount of scrutiny and criticism. That in itself is not a bad thing... in recent weeks, however, posts on this mailing list [i.e. from volunteers] have gone way beyond 'some' scrutiny and criticism, instead suggesting something closer to distrust and paranoia.

”

Volunteer Aryeh Gregor responded:

“

This is a symptom of the tension between staff and volunteers. Naturally, volunteers are more likely to express their frustration here, because they don't have to act professional and because they're the ones who feel wronged in this case.

”

More optimistically, the discussion turned to possible solutions. There was general agreement that getting back to more regular updates was the solution (Roan Kattouw):

“

I whole-heartedly agree with the analysis that deploy backlog is at the hear[t] of this. I have some gut feelings I can't word very well right now that say the "solely because they're not WMF" isn't completely fair, but what you've stated multiple times in various guises is true: what matters is perception, fair or not. If volunteers *feel* ignored, that's bad. ... We need to come up with a plan that takes us back to regular (weekly?) deployments. I think cleaning up the CR [Code Review] backlog is an uncontroversial first step.

”

This sentiment was mirrored by Aryeh Gregor:

“

To reiterate, I think most of the problem will disappear when we have regular code deployment again. At this point, it's best to focus solely on that and forget about all other complaints. If problems linger for long after everyone's code is getting deployed on a regular basis, we can talk about that then, and I think everyone will be talking on much more amicable basis.

”

There was continuing disagreement, however, about whether or not the Foundation was doing enough to achieve this goal, and how quickly it needed to be achieved. Discussion included the expansion of the code review base - including the rehiring of Brion Vibber, for example - which unfortunately coincided with the paternity leave of head code reviewer Tim Starling.

In brief

Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for many weeks.

• Google Summer of Code participant Peter Potrowl appealed for someone to take over the development of his "reasonably efficient interwiki transclusion" project (Wikitech-l mailing list). See also Signpost coverage of the project
• The Brooklyn Museum built its first open source software release, BklynFlow. BklynFlow is a MooTools class for creating Coverflow-like user interfaces for the web. It was designed for accessing Wikipedia content on iPad Kiosks placed for a recent exhibition.
• Microsoft Research has released a tool to assist people in translating Wikipedia articles. The tool makes machine translations of articles and has a simple integrated editor to make improvements upon that translation. The new product is called WikiBhasha and as Wikimedia CTO, Danese Cooper announced, it is an open-source project.
  
  Reader comments
  

If articles have been updated, you may need to refresh the single-page edition.

Want the latest Signpost delivered to your talk page each month?

Home

About

Archives

Newsroom

Subscribe

Suggestions