Wikipedia:Wikipedia Signpost/2011-02-14/WikiProject report
WikiProject report
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!
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)
- 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.
Discuss this story