Articles for Creation

WikiProject news

News in brief

• In light of current events in Egypt, Tunisia, Yemen, and Algeria, new contributors could be used at the semi-active WikiProject Egypt, WikiProject Tunisia, WikiProject Yemen, and WikiProject Algeria to update information, create new content, patrol contentious articles, debate inclusion/exclusion of material, and otherwise help rebuild the projects.
• The new WikiProject Women's History is looking for contributors.
• The February Wikification Drive has knocked out 600 articles from the project's backlog, but they could still use your help. Join today and earn barnstars for your efforts!

Submit your project's news and announcements for next week's WikiProject Report at the Signpost's WikiProject Desk.

This week, we interviewed WikiProject Articles for Creation which offers unregistered users an opportunity to create new articles with help from the Wikipedia community. Unregistered users have not been able to create new articles since the Seigenthaler incident in 2005. The Articles for Creation page was created to allow unregistered users an opportunity to contribute new articles after being reviewed by a registered user. WikiProject Articles for Creation was initiated in 2007 to deal with the growing backlog of unreviewed articles. The project maintains a showcase of featured, good, and DYK content that began as submissions by anonymous users.

We interviewed project "participants" Someguy1221, Sven Manguard, Chzz, and Graeme Bartlett. Someguy1221 came across AFC by accident in December 2007 after spending time patroling recent changes with VandalProof. He primarily reviews AFC submissions and helps with formatting, sourcing, and neutrality. Sven Manguard has "no clue" how he ended up at AFC, but he says "I know why I stayed... I was welcomed by a great group of people." He gives kudos to Chzz and Fetchcomms for being warm and friendly. He says AFC serves as a great niche for people who are not "prolific content generators," because he can feel "a certain level of vindication from being able to serve as an intermediary, helping people who are content generators get their content onto Wikipedia." Chzz doesn't think of AFC as a WikiProject, thus he never bothered to "join" it despite being one of the project's central figures. He considers AFC "part of a fundamental Wikipedia process" and has been answering {{helpme}} requests and giving feedback since June 2009. He tends to push a lot of submissions through Did You Know. Graeme Bartlett is an admin who also works on Files for upload, the multimedia version of AFC. He likes to start near the end of the alphabet when burning through backlogs.

How many submissions does the project receive in an average day? Are most submissions accepted or declined? What are some ways an unregistered user can improve an article's chance of being accepted? What are the fastest ways to get a suggestion declined?

Someguy1221: The statistics are easiest to keep track of only after September 2008, whereafter each submission was given its own page. There have been 25,807 submissions in that time, of which 7864 have been accepted (or roughly 30%). There are on average 30 submissions each day. These statistics can be found at Wikipedia:WikiProject_Articles_for_creation/Submissions. There is actually some undercounting of the number of declined submissions, as many have been deleted entirely (although those are often ones made in bad faith, which should not be counted anyway), and sometimes multiple declined submissions are made under the same title. The best way for an any user to give his submission a high chance of being accepted is to provide reliable sources for the article, and write it in the same tone as those sources. In fact, the fastest way to get one's article declined (beyond the trivial stuff like making a blank submission, or not writing it in English) is to not include any sources. Sometimes the reviewer will find sources himself, but more often we simply won't. This is why we remind the submitter at multiple points in the submission process to cite their sources. A less common, but very quick way to get an article declined is to assert the non-notability of the subject. I've seen multiple submissions contain something along the lines of "This band hasn't gone on tour or released any albums, but they are working very hard in Dave's garage on their first single." Particularly relevant to this question is the "quick fail criteria" section of Wikipedia:WikiProject_Articles_for_creation/Reviewing_instructions.

Chzz: I believe others have given you stats; my guess would be 50 a day, but it does vary greatly. The vast majority are declined - at least, the first draft, and that can be quite demoralizing for us reviewers. But if we work carefully with the users, helping them add references, then they not only improve the submission, but also they learn more editing skills, and thus get more interested and involved in Wikipedia.

Fastest decline would be copyright violations, or blank, offensive or other silly submissions. Beyond that, it'd be writing about something that doesn't have significant coverage in reliable sources - and very often, the subject is autobiographical, corporate, or about the author's band, book, website, etc.

But the three most important things are references, references and references. If I had a penny for every time I've had to explain the basic need for verifiability, I'd need very big pockets.

What are some common issues with image submissions? How do they differ from article submissions?

Sven Manguard: Understandably, a large number of people that come to FFU to submit images do not have an understanding of copyright law, of what constitutes fair use, or of the licenses that Wikipedia does and does not accept. As a result, users often submit images that they do not own under the {{PD-self}} public domain tag for own work, or provide links to images on Flickr or Picassa accounts that are licensed as "all rights reserved" on or one of the "non-commercial" creative commons licenses. I consider this to be a problem for two reasons. First of all, it is rather disheartening for a user to submit for upload a file and have it rejected out of copyright concerns. If Wikipedia can use an image under fair use, I will upload it and fill out the fair use rationales myself, but in many cases, I am forced to decline. I try to explain the reasoning behind these declines, but I doubt that dampens the blow to the submitter, and I often wonder how many potential repeat contributors we lose because of this. The second way this knowledge and communication barrier causes issues occurs when contributors submit their own work through a photo sharing service, but license their work "all rights reserved" or with a "non-commercial" license. The contributor is indicating that he or she wants to contribute the image, however Wikipedia is legally bound to decline the request unless the release license is changed to a Wikipedia compatible free-use license. When we ask the contributor to change the license, and they are watching the requests, they do so almost every time. What makes this frustrating, however, is that only a very small number of contributors watch their submissions and respond to our requests. While the struggle for clear communication with new users and concern over copyright are issues across AfC and Wikipedia as a whole, they seem especially concentrated and prevalent at files for upload.

Graeme Bartlett: The problems with images are as Sven Manguard states, almost all due to copyright, either the wrong license or license unknown. The rules to include images are much stricter than the average blog or facebook page, so new people have a bit of trouble understanding.

Chzz: Invalid, or incomplete, declaration of copyright. People freely (and yes, illegally) copy images from the net all the time, so they find it hard to understand the need to get clear, unequivocal permission to use images. And the intricacies of nonfree content confuses the bejesus out of all of us, of course.

The project had a sizable backlog until a drive in 2008 eliminated the backlog. What strategies did the project use to accomplish this? How has the project prevented a new backlog from forming in the past three years? Do you have any tips for other projects attempting their own backlog elimination drives?

Someguy1221: Under the original AFC system (pre-September 2008), all submissions in a day were made to the same page, which was archived every 24 hours. This made it very easy to forget or ignore old submissions, which would simply be shoved away in an archive, never to be seen again. And indeed, that is what happened for over two years. In 2008, a barnstar was offered to anyone who assisted in clearing the backlog (I actually helped, but never asked for one). Lists were assembled of all the archives by year and month, and very gratifying checkmarks applied whenever a day or month was cleared. The new system of a new page for each submission has greatly assisted us in keeping the backlog to only a few days at most. With this system, a single page, CAT:AFC, shows us every outstanding submission, and they don't leave that page until they are reviewed. Martin created a date parameter for the AFC templates that causes the oldest submissions to be listed first, or the exact opposite of what we had before. Someguy1221 (talk) 05:16, 1 February 2011 (UTC)[reply]

Graeme Bartlett: Tips would include a barnstar, discussing the project in places outside the normal project pages to attract new interest, and adding the backlog to the list of backlogs. Naturally the backlog should look to be attractive to work on, and some may attract only those with the most gnomish personality. When we meet new people here we can suggest projects to join.

Chzz: I was not there in 2008. Since 2009, it has frequently backed-up, and when it does, new users become disillusioned with the lack of responses. I've often had my own mini-elimination-drive, enlisting help from other users I know, but mostly I just clear it down myself. For example, on 20 Jan with help from Bsherr (talk · contribs), we cleared it from over 100 to less than 10 (pending). Two days later, it was back over 100, and I processed all of them, in a manic 5-hour session of reviewing. Since then, I've had several similar sessions, clearing 50 or so. It's like painting the forth bridge.

This is a significant and increasing problem for Wikipedia as a whole; that a large portion new users simply want to write their article, and few people want to help others write articles; thus, the ratio of helpers to helpees is not good, and getting worse. The helpees can get pretty disillusioned with the dearth of COI and spam, too.

The project funnels submissions through the Article Wizard. How intuitive is the wizard for new editors? Are there any features you wish were added or changed?

Someguy1221: I always had the impression the Article Wizard was too much, too many rules, too many instructions. The problem is that... well, that's the nature of Wikipedia. I thought about pruning the Wizard once, but I came to agree that users need to be told everything that's in there. We have a page for submitters to provide feedback. Some say it's too much, while others liked it just fine. Regardless, I can't think of a better way to do it.

Chzz: I have a strong aversion to wizard-style submissions of any kind, ever since the horrors of clippy. I believe the basic wiki interface should be vastly simplified, instead. The Wizard, if we need one, should probably just ask the title of the subject, a short summary of what it is about, and then just have a series of lines with box to put a sentence, then a compulsory box to say where that sentence comes from (the reference). It'd add appropriate info to the references, collate named references, and format things neatly. And make the tea for us, while we wait.

I don't think a wizard, or indeed AFC, is the answer to simplifying things for new users editing Wikipedia; I think we need more fundamental simplification of the entire process.

How difficult is it to bring a new article proposed by an unregistered user all the way up to Featured or Good Article status? Does the unregistered user or a member of the project typically do most of the legwork in getting the article up to higher assessments?

Graeme Bartlett: Very few articles from AFC make it to the higher levels of assessment, that is because we are mostly dealing with people's first steps in Wikipedia. However there are a few anonymous experienced users around using the system too. These people create pages at the C or B class, whereas most are stubs or start class.

Chzz: So rare, that in processing well over 9000 submissions, I've never seen it happen. I don't often keep in touch with submissions I've accepted, beyond basic formatting when live and maybe a few follow-up questions on my talk page. The vast majority don't bother to continue editing after getting their one article live; the few who do are usually clueful enough by that time to work out Wikipedia for themselves.

As, sadly, only about 0.1% of articles are FA and 0.3% are GA, it is unsurprising that few AFCs rise to those exalted classifications.

What are the project's most pressing needs? How can a new member help today?

Sven Manguard: I've been helping out at files for uploading, the image uploading component of Articles for Creation, for about three months. In that time, I can't recall seeing more than a half dozen people in total helping to review the submissions there. While FFU does not see the same volume of submissions that the other sections of AfC do, I do believe that it is a tad understaffed at the moment. Helping out at FFU is relatively easy and does not require a large time commitment. I would be more than willing to show any interested users the ropes, and would encourage them to contact me if they're interested.

Chzz: Please help out! - you'll have my everlasting gratitude. Anyone can help; it is very simple. Unfortunately, I think the instructions are a bit complex, so I'll try to simplify;

• Go to CAT:AFC
• Look at the ones under 'P' for pending
• If it is 'acceptable' - that is, if you think it'd be likely to survive deletion (CSD, PROD and AfD) then 'accept' it by moving it live, and tidying it up. (It would be nice to add it to categories, tell the user it was live, and all those other trimmings)
• If it is not 'acceptable', decide if it can be fixed up - ie, is the subject notable? (Do a bit of googling)

If so, either fix it, or explain to the author what needs fixing. (On the page itself, and/or on their talk page)

If not, 'decline' it. Edit the page, and you'll see a template at the top, something like...

{{AFC submission|||ts=20110206020642|u=Example|ns=5}}

You need to add a letter D for 'decline', the parameter 'reason', and some reason;

{{AFC submission|D|reason|This fails to meet our [[WP:GNG|notability requirements]], because it lacks [[WP:RS|reliable sources]]; please see [[WP:BAND]].|ts=20110206020642|u=Example|ns=5}}

A note to people not afraid of .js:

If you add importScript('User:Timotheus Canens/afchelper4.js'); to your your js page; it makes it very easy to 'accept' and 'decline' giving standard rationales, using a drop-down thingy.

Anything else you'd like to add?

Graeme Bartlett: A related page is the WP:Drawing board that gets a few proposals per month.

Chzz: Yes, please - a short-as-I-can, opinionated, bit of a rant;

As Wikipedia matures, we shift focus from "quantity" to "quality". This makes it harder for new users to join in. It is no longer a reasonable expectation for any truly new user to write a new article, from scratch, and for it to conform to basic policy and guidelines without help. I'm sure that less than 1 in 250^* first articles are - without considerable help to develop them - really, genuinely meaningful additions to the project. It is no longer a matter of mere competence; learning to edit takes effort.    ^*The figure is a very rough estimate; we desperately need to analyse this information.

A few people will learn things for themselves, but largely these are from the type we already have in abundance. The system lends itself to attracting the younger, more technical adept, mostly male, mostly American editors. To widen the demographic, it is essential we make the whole system more friendly and accessible.

There is a disparity with the way new users are treated if they make a live article, as opposed to if they use AFC. Most (truly) new editors creating a live article get a CSD-tag, and/or other template warnings. In AFC, they (mostly) get informed help. I think that creation of new articles needs general reform - and I'm sure it will happen, one day. The system is nasty, to new users - and really, that is why we don't get retention of new editors, and why the editorial mass becomes more and more of an entrenched community.

However, it is not a mere volume of new blood we need, it is quality editors. AFC is most frequently used for Conflict of Interest, so we may be focusing resources on the wrong people. Most new editors are not here to edit an encyclopaedia, they are here to have their article up.

We're approaching the stage where anything with good coverage in RS is already on Wikipedia, particularly for Western culture. We're not lacking in articles on e.g. (ex-) Kings, a (non-trivial) USA town, or some invention (that is known to a few thousand). So naturally, most new articles are either junk, (few) genuine new discoveries or - and this is the big one increasing - conflict of interest cases. At least, this applies to Western culture topics; the drive for new editors from other places can shift that, but raises other issues, as they often need considerable help with the language itself, and there are the difficulties in sourcing information in other languages.

The ratio of helpees to helpers is shrinking.

I think we will require a 'quarantine' for all new articles, similar to AFC, changing auto-confirmed requirements to e.g. 100 edits / 1 month, and thus force all new users to create articles in a 'holding pen', with a checking process. This would inevitably create AFC-type backlogs, but would considerably reduce new page patrol, speedy deletions, proposed deletions, requests to userfy, and annoyed new users, shouts for help, people blocked, and so forth. So instead of productive new users getting horrible nasty CSD template warnings, they'd get helpful advice - "Sorry, can't accept that because of x, y, z - if you can address those concerns though, sure, it'll be fine - ask again".

New users are the lifeblood of the project; we need to treat them much better.

Next week, we'll search for the equation that determines a WikiProject's success. Until then, calculate how many interviews you've read in the archive.

Reader comments

2011-02-14

RFAs and active admins—concerns expressed over the continuing drought

Contribute  —  

Share this

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

By Tony1 and Dabomb87

Jim Devlin, c. 1873, from the new featured list Philadelphia Phillies all-time roster (D), which lists all players with surnames starting with the letter D. The Phillies are the oldest continuous, one-name, one-city franchise in all of professional American sports, dating to 1883.

Red Dooin was the Phillies' catcher for 13 seasons (1902–14). This baseball card showing his portrait is held in the Library of Congress. The age of the team and its history of adversity have earned it the distinction of having lost the most games of any US sports team.

This week's "Features and admins" includes Saturday 5 – Friday 11 February. Our regular coverage of new featured content appears under the special story.

RfAs and the decline in active administrators

The number of successful RFAs has continued to fall over the past year, despite a temporary spike last August after The Signpost's story on the RFA drought, and a sudden (but not statistically significant) upswing at the start of this month. Over the past four years, the fall in numbers is significant: 408, 201, 119, and last year just 75 promotions. The author of that Signpost report, WereSpielChequers, maintains a page of information on RFAs. We asked him to comment on the trends over the past six months: "RFA is perhaps not as gloomy a story as the raw figures might suggest. A good trend is that self-nomination, once seen as a bit of a negative, is emerging as almost the norm at RFA; and I'm happy to see the drop in unsuccessful RFAs, as I hope it's largely the consequence of changes such as semi-protecting WP:RFA and other measures to dissuade the WP:Notnow candidates with only a few hundred edits from running."

Possible reasons

However, WereSpielChequers is concerned about the declining number of successful RFAs, and his experience has led him to an original view. "RFA has been in a deepening drought since the unbundling of Rollback in early 2008. Having spoken to editors on a few other projects, I think we could operate with far fewer active English Wikipedia admins than now, but only if we are prepared to make adminship a much bigger deal than it once was, shifting from the model of admins as ordinary editors who mostly do non-admin stuff, to the more full-on model that one of my Spanish Wikipedia contacts described as 'appoint a new admin, lose a good editor'. I think this future would work, though we wouldn't be the sort of community that I'd like us to be."

WereSpielChequers asks what he sees are six critical questions: "(1) With total edits broadly stable at 200,000 a day, how long can we afford to have our number of "active admins" dwindle by 1% a month? (2) What would the trend be and how much of a safety margin would we have by defining active admins rather more strictly than one edit in the past 90 days? (3) Active, uncontentious editors with more than a year's experience can usually get through RFA without difficulty, so why are so many editors waiting three years or more? Should we do more to persuade editors with between one and three years' experience to become admins? (4) WP:Admin coaching seems to be moribund; would it be worth reviving? (5) Does the community want adminship to become the big deal that the RFA crowd are making it, or would people be happier with adminship being a less exclusive club? (6) Would people prefer a large number of active editors who also happen to be admins and occasionally use the mop, or a small number of admins who have little or no wikitime for non-admin activity?"

Bureaucrats respond

Our bureaucrats are primarily responsible for managing the RFA process. The Signpost asked their opinions on the issues raised here. For Dweller, the relevant issue is not the definition of active admins, but "workload and queues; the stats are just one way of measuring problems, [and anyway,] bots do a lot of work previously done by admins." He thinks "a lot of people have been scared off RfA, with good reason. Others are simply waiting to be asked, because they're too modest to self-nom." On WSC's last point [6], he says that obviously everyone would prefer a mix between those two extremes, "which is the status we currently have". How much of a big deal should adminship be? Dweller believes the current balance is about right. "The problem lies with the small number of RFA participants." He emphasises that above all, "RfA's biggest problem is that too few long-standing editors frequent it."

Anonymous Dissident says: "The promotion rates over the past few years are concerning, and the issue merits immediate attention by the community. If the number of active admins continues to diminish while Wikipedia continues to grow, we'll have major problems on our hands. What strategies might be considered? I don't think a reformatting of the system or a paradigm shift are in order; the RfA process is not "broken", as has frequently been asserted. Instead, we need to look for ways to adapt the culture to these dire conditions. We need to be more open when evaluating candidates, especially on matters of time served and experience in particular areas. We need to dispel the notion that adminship is for a privileged and powerful few, so that more editors will have the courage and inclination to lodge candidacies. In short, we need to revive the attitude that adminship is not a big deal, clichéd though its mention may appear."

WJBscribe says RFA is currently failing in its role of creating new admins. "Either attitudes at RFA need to change or we as a project need to consider other ways of appointing new administrators. The cost to the community in terms of too few active admins doing too many tasks is hard to see but I believe it is there. In particular, I worry that there is now too little capacity for admins to double-check the work of others and ensure that 'routine' blocks/deletion/protections are being done correctly."

New administrators

The Signpost welcomes two editors as our newest admins.

• 5 albert square (nom), from the UK, works in the field of technical support. She has been a Wikipedian for almost two years, with nearly 34,000 edits, half of them in article namespace. She is a member of the Guild of Copy Editors and has participated in the backlog elimination drives. 5 albert square has been active at Administrator intervention against vandalism and Requests for page protection
• ErikHaugen (nom), a programmer from California, has been a Wikipedian since 2005, although until a year ago edited only occasionally. Erik works at History merges to fix the large numbers of cut-and-paste moves on Wikipedia, a seriously backlogged area, and intends to contribute to article deletion processes and the backlogs on CAT:AB, such as Requested moves. He will also contribute to New-page patrolling.

At the time of publication there is one live RfA, for ErrantX, due to finish 18 February.

Featured articles

Fourteen articles were promoted to featured status:

• Frederick Delius (nom) (1862–1934), an English composer in the Romantic tradition. (Nominated by Brianboulton and Tim riley; picture at right)
• Battle of Towton (nom), fought on Palm Sunday 29 March 1471, has been called the "largest and bloodiest battle ever fought on English soil", in which King Edward IV "chased his opponents out of England or killed them", according to nominator Jappalang.
• Adelaide leak (nom), the revelation of a dressing-room incident that occurred during the third Test match of the 1932–33 Ashes series between Australia and England, more commonly known as the Bodyline series. As nominator Sarastro1 puts it, it's the story of "the people involved, and how much they hated each other".
• Tales of Monkey Island (nom), a 2009 graphic adventure video game. (S@bre)
• 1950 Atlantic hurricane season (nom), the first year in which hurricanes received names. The season saw many very strong hurricanes. (Hurricanehink)
• Rhodocene (nom), a molecule containing an atom of rhodium – a transition metal – bound between two planar "ring" systems of five carbon atoms. The hydrogen atoms are omitted for clarity. (EdChem; picture of a derivative at right)
• Adenanthos cuneatus (nom), a shrub native to the south coast of Western Australia and originally described by French naturalist Jacques Labillardière in 1805. It is grown in gardens in Australia and the western United States, and a dwarf and prostrate form are commercially available. (Casliber and Hesperian)
• Stark Raving Dad (nom), the premiere of the third season of American animated television series The Simpsons, originally aired in 1991. (Scorpion0422)
• Startling Stories (nom), an American pulp science fiction magazine published from 1939 to 1955, with characteristic cover art by E.K. Bergey. (Mike Christie)
• Thomcord (nom), a seedless table grape variety developed in 1983 by Californian grape breeders working for the US Department of Agriculture. The article has received an expert review by one of the men who created the variety, Dr Ramming. (Visionholder)
• U.S. Route 30 in Iowa (nom), a major east–west US highway that spans 330 miles (530 km) across Iowa, from the Mississippi River to the Missouri River. (Fredddie)
• Allegro (musical) (nom), one of the most eagerly awaited Broadway musicals ever. Nominator Wehwalt says "it just could not live up to expectations and closed after exhausting its advance sale and a bit more. Perhaps ahead of its time, perhaps fatally flawed because of a poor plot?"
• Entoloma sinuatum (nom), a poisonous mushroom found across Europe and North America that causes primarily gastrointestinal problems that have been described as highly unpleasant. (Casliber).
• Monticolomys (nom). Nominator Ucucha says, "In 1929, someone caught a nondescript little brown mouse on Madagascar, which landed in a museum full of nondescript little rodents. However, this particular little brown mouse turned out to be unknown to science."

Featured lists

Eight lists were promoted:

• Philadelphia Phillies all-time roster (D) (nom) (Nominated by Killervogel5; pictures at the top.)
• List of Knight's Cross of the Iron Cross with Oak Leaves recipients (1943) (nom) (MisterBee1966.)
• List of demolished places of worship in Brighton and Hove (nom) (Hassocks5489.)
• List of Manchester United F.C. players (fewer than 25 appearances) (nom) (03md.)
• List of international cricket centuries by Jacques Kallis (nom) (Harrias.)
• Hugo Award for Best Professional Artist (nom) (PresN.)
• Latin Recording Academy Person of the Year (nom) (Another Believer.)
• Grammy Award for Best Rock Song (nom) (Another Believer.)

Featured pictures

Six images were promoted. Medium-sized images can be viewed by clicking on "nom":

• The ugly duchess (nom; related article), a satirical portrait painted by the Flemish artist Quentin Matsys around 1513. It is thought to be a caricature of Margaret, Countess of Tyrol, and served as inspiration for the Duchess in Alice's Adventures in Wonderland. The work is held by the National Gallery of Art, London. (Created by Quentin Matsys.)
• Écorché by Honoré Fragonard (nom; related article), the flayed figure of a horseman and his horse, prepared by anatomist Honoré Fragonard. Fragonard was the first professor of anatomy at the National Veterinary School of Alfort and prepared thousands of anatomical pieces. In 1771, after six years of teaching, he was dismissed from the school as a "madman". (Created by Commons user:Jebulon.)
• Hagia Sophia Church, Sofia (interior) (nom; related article), the nave of the church, dating to the 6th century CE, located at the centre of the Bulgarian capital. (Created by User:MrPanyGoff.)
• Pedro II of Brazil (nom; related article), the second and last emperor of Brazil (Created by Mathew Brady and Levin Corbin Handy.)
• Jammed phases of the Biham-Middleton-Levine traffic model and Free-flowing phase of the Biham-Middleton-Levine traffic model (nom; related article), two more animations of a self-organising cellular automaton traffic flow model in addition to the two that were promoted two weeks ago; they now make a set of four. (Created by User:Purpy Pupple.)
• Making of a Death Mask 2 (nom; related article). A death mask is a wax or plaster replica of a person's face made after their death. Here, two workers, circa 1908, use plaster to create a mould of the deceased person's face; this mould will then be used make the death mask. (Created by Bain News Service, originally uploaded by User:Howcheng, restoration by User:AutoGyro; picture below.)

Information about new admins at the top is drawn from their user pages and RfA texts, and occasionally from what they tell us directly.

Reader comments

2011-02-14

Proposed decisions in Shakespeare and Longevity; two new cases; motions passed, and more

Contribute  —  

Share this

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

By Ncmvocalist and Lord Roem

The Committee opened two new cases during the week. Four cases are currently open; two of which have posted proposed decisions.

Open cases

Monty Hall problem (Week 1)

Opened on 12 February 2011, this case involves allegations of problematic behavior relating to the Monty Hall problem article. During the week, one editor submitted under 2 kilobytes of content as on-wiki evidence. A deadline for evidence submissions has not yet been set.

Kehrli 2 (Week 1)

Opened on 11 February 2011, this case involves allegations of disruptive editing to the Kendrick (unit) and Kendrick mass articles. The case is following on from the 2006 case concerning Kehrli (talk · contribs). During the week, two editors submitted over 10 kilobytes of content as on-wiki evidence. A deadline for evidence submissions has not yet been set.

Shakespeare authorship question (Week 4)

On 10 February 2011, drafters Newyorkbrad and SirFozzie posted a proposed decision for arbitrators to vote on. Proposals which are being voted on include "standard discretionary sanctions"(see Signpost coverage: 20 September 2010) and rulings concerning two editors. Yesterday, arbitrators Cool Hand Luke and Elen of the Roads added a new principle to the proposed decision; the principle builds on the proposals made in the workshop. A motion to close was then adopted on 14 February, ending the case.

Longevity (Week 12)

On 7 February 2011, drafter Kirill Lokshin posted a proposed decision in the workshop; the proposals, consisting of 14 kilobytes, attracted comments from arbitrators, parties, and others. During the week, more than 50 kilobytes of content was added to the workshop, of which more than 15 kilobytes was contributed by a single party. On 12 February 2011, the drafter submitted a proposed decision‎ for arbitrators to vote on. Proposals being considered include "standard discretionary sanctions", an evidence subpage remedy, rulings concerning two editors, a specific ruling that affiliation with the Gerontology Research Group does not in itself constitute a conflict of interest when editing longevity articles, as well as a proposal that urges WikiProject World's Oldest People to seek experienced editors as mentors to the WikiProject.

Motions

Date delinking

As reported last week, arbitrator Newyorkbrad proposed two motions to amend this case. The motions were passed this week with two recusals:

• Lightmouse (talk · contribs) is permitted to use a separate bot account for any bot task(s) approved by the bot approvals group.
• Ohconfucius (talk · contribs) is permitted to use a separate bot account for any bot task(s) approved by the bot approvals group.

Other matters

The Committee conditionally suspended the indefinite ban of Lyncs (talk · contribs) (formerly Justanother (talk · contribs) or Justallofthem (talk · contribs)). The conditions are such that Lyncs is subject to a single account limitation, an interaction ban, and a Scientology topic ban.

Reader comments

2011-02-14

Bugs, Repairs, and Internal Operational News

Contribute  —  

Share this

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

By Theo10011 and Waldir

MediaWiki 1.17 deployment failed, postponed

The planned update of MediaWiki as the underlying software which forms the basis of WMF wikis to version 1.17 failed last week (Wikimedia Techblog). The original deployment was expected to begin 07:00 UTC on February 8 (see previous Signpost coverage), but preparations took longer than anticipated and actual deployment began at around 13:00 UTC.

Several issues became apparent almost immediately. The parser cache miss rate almost doubled with the new deployment, at which point the Apache servers, which are responsible for delivering content to users, became overloaded and started behaving unpredictably. The increased load culminated with multiple issues across the project from increased lag to even outage for some users. At this point, the deployment was rolled back to the previous 1.16 release. The tech team investigated and prepared for another attempt after resolving some technical issues. A second attempt was made at 16:27 UTC, but this ran into similar performance issues and had to be called off 90 minutes later. Further attempts were put on hold.

Danese Cooper, Wikimedia's Chief Technical Officer, blogged about the failed deployment and explained what the Foundation had attempted to deploy:

“

The 1.17 release process has been longer than we would have liked, which has meant more code to review, and more likelihood for accumulating a critical mass of problems that would cause us to abort a deployment.... [it] was an omnibus collection of fixes, including a large number of patches which had been waiting for review for a long time. The Foundation’s big contribution to the release was the ResourceLoader, a piece of MediaWiki infrastructure that allows for on-demand loading of JavaScript. Many other incremental improvements were made in how MediaWiki parses and caches pages and page fragments.

”

After further investigation and several fixes to the release, Rob Lanphier, a developer with the WMF, added that "some of the unsolved issues are complicated enough that the only timely and reasonable way to investigate them is to deploy and react". As a result of this, he said, a new plan had been drawn up in which 1.17 will be deployed on "just a few wikis at a time". The tech team believes the problem was located in the configuration of the $wgCacheEpoch variable, which caused a more aggressive culling of the cache than the servers could handle (Wikimedia Techblog).

The team decided on a two-stage deployment for their next attempt (reviving some old code for project-wise upgrading). The first phase took place 6:00–12:00 UTC on Friday, February 11. This was limited to the Simple English Wikipedia and Wiktionary; the Usability and Strategy Wikis; Meta; the Hebrew Wikisource; the English Wikiquote, Wikinews and Wikibooks; the Beta Wikiversity; and the Esperanto and Dutch Wikipedias.

At the time of writing, the deployment had been completed on all but the last two projects. The Hebrew Wikisource, included after a request from a community member, gave a chance to observe the deployment on a right-to-left language wiki. The team also reported some localization issues which triggered ParserFunction bugs on both nl.wikipedia.org and eo.wikipedia.org. The traffic from nl.wikipedia.org was enough at the time to cause a noticeable spike in CPU usage on the web servers, including some time-out errors; thus, deployment onto nl.wikipedia.org had to be delayed. After these issues are resolved , the second wave of deployment is expected to start on Wednesday, February 16 (see the current list of WMF wikis that are already running 1.17).

An IRC office hour Q&A was held on matters related to the ResourceLoader, which is expected to cause compatibility issues with some existing Javascript code. Trevor Parscal and Roan Kattouw, the main developers of the ResourceLoader, were available on IRC on February 14 at 18:00 (UTC) to answer queries related to the new feature.

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.

• RefTools default: Through a poll at the Village Pump, it was decided by near unanimous consensus to make the refTools gadget a default feature on the English Wikipedia. Implementation discussion is proceeding at MediaWiki talk:Common.js, and the switch is currently on hold until MediaWiki 1.17 is deployed (see also last September's Signpost dispatch on RefTools/RefToolbar and other references-related tools).
• New wikitext parser? After the last attempt at creating a wikitext parser generated excitement and lengthy discussion on the wikitext-l mailing list, a new attempt, by AboutUs.org developer Karl Matthias, has been brought to light under the name of "Kiwi". Discussion is ongoing in the post's comments and on wikitext-l.
• Distributed wikis: One of the applications of a defined parser grammar would be the ability to have alternative, non-MediaWiki interfaces to interact with the content. The full video was released of "Distributed wikis", a talk at linux.conf.au by Brianna Laugher (User:pfctdayelise; abstract) that touched on the subject. She proposes the use of the write function of the API and custom interfaces to create WikiProject-sized "forks" as the key to the long-term survival of the project, arguing that community decentralization would create smaller, more manageable and more welcoming groups of editors. Laugher compares these to the editing groups that existed at the beginning of Wikipedia, and those that can still be found in various specialized wikis (most notably wikias). Similar ideas have been floating around for a while; see meta:Versioning and distributed data.
  The talk also examined the possible application of the concept of distributed revision control to wikis, to allow easy forking and merging (a concept explored in various earlier proposals), and compared Flagged revisions to release versions in software development.
• Call for skins: A call for skins was made on the wikitech-l mailing list.
• Public status-monitoring page: The WMF announced that a public status monitoring page has been set up at http://status.wikimedia.org to allow staff, community members and the general public to keep an eye on the servers' uptime and status (Wikimedia blog). The service, powered by Watchmouse, has been in the works for a while, having been mentioned in the last three WMF Engineering Updates. Its relationship with previous monitoring tools Nagios and Ganglia is still unclear.
• Bug fixes: Several long-standing bugs have been fixed:
  • The successful close of bug #17160 (opened January 2009) allows for the display of namespace aliases in userpages to be gender-specific (revision #82029). As The Signpost reported last week ("Widespread discussions about the low participation of women in Wikipedia"), the blanket use of masculine namespace forms—such as Benutzer (male user) rather than Benutzerin (female user) on the German Wikipedia—had come up in the recent discussions about Wikipedia's "gender gap", where it was criticized as "hardcoded discrimination" and Sue Gardner had called it "awful".
  • Bug #16013 (opened October 2008) was resolved in revision 81573, allowing the direct linking to sections (tabs) of the preferences page.
  • Bug #8680 (opened January 2007) was closed successfully, after the introduction of $wgFooterIcons allowed easy customisation of MediaWiki sites' footers.
    
    Reader comments
    

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

It's your Signpost. You can help us.

Home

About

Archives

Newsroom

Subscribe

Suggestions