As reported by Steven Ma, the Wikimedia Foundation's Community Associate, "more than one hundred Wikipedia editors, donors, and readers" attended an event titled Inside the Globe in New York on 7 October. The evening was both a fundraiser and an opportunity to introduce major donors to the people and culture of the projects. Roughly a dozen editors were present, including Wikimedia New York City board members and other local Wikimedians. Hosted by the Harnisch Foundation (a patron of Wikimedia) in the Metropolitan Tower, the evening saw presentations by Jimmy Wales and Wikimedia fellow Steven Walling. Steven spoke about "the identity and culture of the most involved editors, highlighting the motivations and methods behind their amazing accomplishments within the project". After the event, Ruth Ann Harnisch, the president of the Harnisch Foundation, expressed her pleasure to have introduced "so many people to the workings of their favorite online resource." In an August blog post, she had invited donors to attend the Wikimedia fundraising event, noting that she had added the WMF to her list of grantees several years ago (as a "tiny part of the support system for Wikipedia"); in the posting, she also expressed her support for the Wikimedia Foundation in its then ongoing conflict with the FBI over the reproduction of the Bureau's seal (see Signpost coverage).
The copyright situation in Argentina is considered particularly restrictive. In a 2010 Consumers International study of 34 countries, it came out sixth-worst for consumer rights. Argentina provides no fair use or library exceptions, and does not even permit the free use of public domain works in all cases (for some uses, a fee has to be paid to a fund supporting artists). The book argues that this is detrimental for education and culture. Wikimedia Argentina has engaged in various lobbying efforts regarding the copyright situation, such as signing a letter to parliament protesting last year's extension of copyright in phonograms (sound recordings) from 50 to 70 years after creation, and opposing ongoing lobbying by photographers to extend the monopoly on photographs from 25 to 50 years after creation, which would affect commons:Template:PD-AR-Photo.
Edited by Busaniche, the book collects contributions by various authors to the copyright debate in Argentina. One chapter, by Wikipedian and founding member of Wikimedia Argentina Roberto Fiadone, presents Wikipedia and other Wikimedia projects as examples of communities that generate free knowledge. Another chapter, on ebooks, was reprinted by the German weekly newspaper Die Zeit. The Heinrich Böll Foundation funded a translation into German and organized a presentation of the book in Berlin, in addition to the panel at the Frankfurt event. The book is available as a PDF under a CC-BY-SA license. The Spanish version was downloaded more than 20,000 times during the first week. Busaniche also gave a podcast interview (in English) about the book to German blog Netzpolitik.
.png)
This week, we took a look at WikiProject Numismatics, a project dedicated to money and its history. Included within the project's scope are articles about coins, banknotes, cheques, credit cards, stock certificates, medals, medallions, and token coins. The project started in 2004 and has grown to include 9 featured articles and lists, 7 good and A-class articles, and over 1,000 images. WikiProject Numismatics maintains a portal, to-do list (Numitasks), and a list of helpful sources. We interviewed Searchme (Joe) and Enlil Ninlil.
What motivated you to join WikiProject Numismatics? Do you collect coins, medals, or other items covered by the project?
Do you prefer working on articles pertaining to coins (etc.) from recent history or ancient history?
Have you contributed to any of the project's featured or good articles? Are you currently working on bringing an article up to FA or GA status?
How difficult has it been to find images of rare coins?
The project maintains a portal that receives around 60 views per day. How much effort goes into maintaining the portal? Is it a worthwhile component of the project?
Does WikiProject Numismatics maintain close connections with any other projects? Have there been any inter-project collaborations on articles?
How can a new contributor help today?
Anything else you'd like to add?
Next week, we'll visit a scary project just in time for Halloween. Until then, look for thrills and chills in the haunted archive.
Reader comments
_edit.jpg)
The Signpost welcomes Looie496 (nom) as our newest admin. Looie496 is a neuroscientist who specialises in learning and memory, with a focus on the hippocampus; many of his publications have involved theta rhythm. He has been contributing since April 2008, and since then has co-maintained WikiProject Neuroscience. More recently, Looie496 has been involved in an effort sponsored by the American Society for Neuroscience to encourage more scientists to contribute to Wikipedia. He is interested in dispute resolution, and has participated at ANI, WQA, and various other noticeboards, with an eye to contributing to AIV, UAA, and RPP.
Four featured articles were delisted:
Choice of the week. We asked FL nominator PresN for his/her choice of the best. The choice is from both last week plus the three new FLs from the week before:
One featured list was delisted:
Choice of the week. DerHexer is a regular reviewer and nominator at Common’s featured picture candidates. He told The Signpost:
| “ | This was not an easy decision, because there were very interesting subjects to choose from. In particular, three more of Alchemist-hp's fine pictures of chemical elements were promoted: Nickel and Zinc. But all in all, I preferred what is a beautiful underwater shot of a white-spotted jellyfish (phyllorhiza punctata). Although not entirely sharp, the photo still shows many details and amazing colours of a world not often visited by humans. That photo may have convinced me to join that hidden world and possibly even to take pictures there for Wikimedia projects! | ” |
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?
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.
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.
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.
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 ( ) 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").
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!
The Arbitration Committee opened no cases this week, but closed one, leaving one open.
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.
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.
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.
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.
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.
.png){kind=link}
