User:Ironholds
A look at the problems surrounding our attraction of new users, how they are treated at Special:NewPages, why they are treated that way, and what can be done to fix the issue. The problems surrounding New Page Patrol can be traced to two things – communications issues, and the mentality which taggers bring to the field. The first one can be directly addressed through improving our interface and through opening up wider fields in which new users can get help. While the second problem is hard to tackle as an underlying problem, its symptoms can be dealt with, and the “disease” itself at least reduced in prevalence as a side-effect of our efforts to improve things.
It should be noted that none of this is meant to disparage the editors who participate in New Page Patrol. The work is difficult and under appreciated and the answers never easy. The idea is rather to show that there are places where we can improve and that this is quite possibly a high value spot to make some of those changes.
Background edit
Problems with New Users edit
The Wikimedia Foundation, and the community of the English-language Wikipedia (“Wikipedia”), have been aware for some time that there are problems attracting new contributors and new contributions. Despite being ranked #8 on the net in terms of Alexa rankings, which covers viewers in total, the number of new editors (over 10 edits) has begun slowly waning over the past year. Statistics going up to December 2010 show that the number of new user accounts in that month was 6,675 compared to 8,143 at the same time in the previous year and 9,012 the year before that.
The size of Wikipedia has also begun stabilising, while the growth of the project in terms of newly created articles has plummeted since reaching its peak in late 2006. Aware of these problems and the need to attract new contributors (something reflected in the five-year strategic plan, which makes increased editing a priority) the Foundation has done several studies on the motives of new users, and the reasons behind their disinclination to continue editing. The largest publicly released study, done by Howie Fung, looked at 1,223 respondents, and found that 618 left due to the complexity of editing, or the attitude of the community. These are things which, to a degree, can be remedied.
Special:NewPages and New Page Patrol edit
Newly created articles are logged at Special:NewPages, a MediaWiki record of new content. Special:NewPages has a thirty-day “buffer”, meaning that it records all new articles in the last 30 days. Those that drop off the end of the buffer are lost from the log, which (as I will explain) creates problems.
Newly created articles can be “patrolled”, removing them from the list. This allows users to examine and scrutinise new content for issues without having their work overlap. The contributions of existing editors with good records are automatically patrolled (through various user-rights which allow for this) meaning that the users engaging in New Page Patrol tend to almost exclusively scrutinize articles made by new editors and those who have not historically written many from scratch.
Articles may be tagged for improvement, with a wide variety of tags for different situations (“unreferenced”, “referenced, but without footnotes”, “footnotes, but in a confusing style”, so on) or tagged for deletion, through the Speedy Deletion (CSD), Proposed Deletion (PROD) or Articles for Deletion (AfD) processes. Both categories of action can be carried out manually, but are normally done with semi-automated javascript tools, the most prominent of which is Twinkle.
Twinkle allows for articles to be tagged, either for improvement or maintenance, for the notification of users that their articles have been tagged (in cases of deletion), or for the semi-automated deletion of the articles if the editor using the tool has administrator privileges.
One of the things a new user is most likely to do, after correcting perceived errors in existing articles, is to create new content. As such, Special:NewPages is where their contributions appear, and with the contributions of new articles serving as the mainstay of the page, it is imperative that they are presented with a pleasant response and a simple way to correct issues with their content.
Confronting the Problem edit
Noting the importance of avoiding problems with new users creating content, the community and foundation have attempted to confront the issue. This has mainly taken the form of new avenues through which users can create articles, such as Articles for Creation and the Article Wizard. Each tool is targeted at different groups of contributors, and produces different results. Articles for Creation is aimed at non-”users”; IP editors, who are not able to create articles directly. Instead, articles can be created in the Wikipedia namespace, where an experienced editor reviews them. Those articles considered good enough are turned into an article, those that need further work are put on hold, and those that are inappropriate to the point of being unfixable are denied and scrapped. Although this may seem like an excellent way to induct new editors into creating pages, it suffers from several of the same issues as New Page Patrol itself (which I'll explain later).
The Article Wizard, on the other hand, is for those contributors with accounts (who are therefore technically permitted to create articles) who do not feel comfortable doing so right off the bat. It is a template-based tool with five steps designed to create a notable, referenced, and properly structured article, which is ported directly to the articlespace.
Issues edit
Despite our awareness, the problems have got worse. The newest data shows that, since the last publicly-released survey, the proportion of new editors (known as 1-99 editors, i.e., editors with 1 to 99 edits) has actually decreased, despite the introduction of the Article Wizard and Articles for Creation. Based on my experience at New Page Patrol and some raw data, I have concluded that the issues are mainly related to the way we interface with new users. These can be roughly divided (with some overlap) into three categories; the mentality with which they are approached, the structure in which they are approached, and technical issues behind the approach.
Mentality edit
One of the biggest problems is the mentality with which new users are approached. This problem was highlighted by the NEWT breaching experiment, in which various experienced users masqueraded as newbies, creating flawed-yet-valid articles, in an attempt to judge the response they got. The results were not good, particularly Atama's experience (as an example) – newbies were met with irritability, a misunderstanding of procedure and policy, lax and inappropriate tagging, and generally a mentality which would drive off most people.
The irritability can be linked to the workload. Special:NewPages works on the principle that, after pages get to a certain age, they are dropped from the logs – they cannot be reviewed, and this means that if the backlog is not constantly and unremittingly tackled, the potential exists for inappropriate pages to slip through. This creates a “siege mentality”, rather like that which Special:RecentChanges suffers from, in which users contributing to the area feel constantly under pressure to tag – and tag quickly, efficiently, and without brooking dispute (which would slow them down). As a result, users are unlikely to respond well to queries and complaints from the creators of articles they have tagged for deletion – they feel pressure to keep clearing the backlog as fast as possible, putting them under stress, making them defensive, and making them loathe to deal with long-running or potentially long-running disputes or discussions which distract them from what they see as the real priority. Instead they respond with biting newbies, treating them badly, and generally giving them short shrift. This is a problem which also effects Articles for Creation.
Lax and inappropriate tagging can also, partly, be traced to this. Due to the mentality present at Special:NewPages, users do not fully review articles – at least, not all the time. The pressure is not to review articles correctly, but review them quickly; Special:NewPages is treated as a firing range in which the biggest prize goes to the person who fires the most shots, not the one who gets the most shots on target.
Technical Issues edit
The NEWT experiments, and my own experiences, highlight flaws which can be traced back to technical issues. The majority of tagging is done with Twinkle, the semi-automated tool mentioned above. This contains various flaws with the potential to frustrate and confuse new editors.
Firstly, a user tagging an article for deletion can option not to notify the creator. It can therefore be deleted without the creator immediately realising it, only to come back and find a single-line rationale in tiny type in the deletion log; one which provides no information, no content, and no obvious place of recourse. Secondly, if an administrator uses the interface, the options currently only allow for tagging-and-warning, deleting-and-not-warning, and tagging-and-not-warning. The second option is the problematic one, because it means that, again, a user's creation can be removed without any warning, any knowledge, or any opportunities to fix the problem.
Tagging an article, while choosing to notify the creator, leaves two messages on the talkpage; a welcome template, and a CSD notification. This is confusing to the new user, who is both welcomed to Wikipedia and thanked for their contributions, and then told that their contributions are inappropriate and to be deleted. Not only is this confusing, it also highlights that the welcome template is a standardised, faceless and semi-automated creation – and the recipients realise that, further enhancing their view that Wikipedia is a faceless and confusing place with awkward contributors and contribution policies, as Howie's survey showed.
Structure edit
The third category of problems are structural ones – issues with the underlying way we approach deletion. They overlap with the other issues, and can mainly be tackled as a secondary impact of proposed solutions for problems relating to the mentality and technical interface, but are worth mentioning separately.
Users whose articles are tagged are told that their only method of recourse is to put a “hang on” tag on the article, and then discuss the problems on the talkpage. The problem here is that talkpages are obscure – the talkpage of a newly created article has no watchers, no followers, and nobody who will pay attention other than the creator and the tagger (if the tagger bothers to turn up at all). This means, firstly, that the only attention the creator gets is from the tagger, who as mentioned, is commonly stressed, frustrated and has far more of an incentive to provide rebuttals to the creator's arguments than he does to help the creator fix the problems with the articles.
Not only that, but if the article is deleted by the administrator, the talkpage also goes. All evidence of the creator's contributions and conversations vanish, increasing frustration, and if the tagger has been acting in an inappropriate or bitey manner, all evidence is now lost. A deleted discussion on a relatively obscure page does not allow for problematic behaviour to be effectively corrected, because there's almost no evidence that it happened.
Proposals edit
Deletion Noticeboard edit
One of the most effective methods of fixing the issues would be to create a noticeboard, specifically for deletion, where questions and queries could be brought. CSD templates would be altered to invite new users to take up the issue on the noticeboard, rather than on talkpages. This would have several positive impacts. Firstly, the problematic mentality of New Page Patrollers would be tackled, if only through treating the symptoms rather than the underlying disease. In their interactions relating to the tagged article, the creator would be dealing with people from all over the wiki, rather than people specifically dedicated to New Page Patrol. This means they would generally experience smaller amounts of biting, and be given greater leeway to fix the problems, because they aren't exclusively dealing with stressed, pressured individuals who consider themselves to be under siege.
Not only this, but problematic behaviour from New Page Patrollers could be dealt with. A noticeboard is far more visible than an obscure and in many cases temporary talkpage; if there is inappropriate behaviour on the part of the tagger of an article, uninvolved Wikipedians will be able to see this more easily, and attempt to address the problem through talking to the tagger. This could also have the impact of reducing the tagger's stress – part of it, although not the largest part, comes from having to deal with inexperienced users who may have “stupid” or “useless” questions; the tagger can consider this a distraction from what's “really important” (reducing the backlog). While I don't think this will make a massive difference, it will make a small one, and is a positive side-effect of the proposal.
The only real problem would relate to the idea that Wikipedia has become too bureaucratic, and that yet another noticeboard is taking things too far. This could hinder adoption of the idea. However, in many respects a single noticeboard is actually less bureaucratic than the alternative (a thousand tiny talkpages which live and die in a second), and given the positive impact of the idea on new users (who, it is felt, are those overly affected by bureaucracy) it should be possible to convince the community to adopt it.
Twinkle Alterations edit
As mentioned, a problem is the confusing and two-faced appearance we have to new users through the mix of welcome templates and deletion templates. One solution would be to merge the two; alter CSD templates to include a cautionary welcoming message, noting the contributions and the problems with them, and providing a more detailed rationale as to how they can be fixed, and dispensing of welcome templates for Twinkle-based tags entirely.
Another alteration would be to fix the problems surrounding tagging-and-not-warning and deleting-and-not warning, by simply removing these features. Deleting-and-not-warning would be replaced by the option to delete, and leave a newly created talkpage template informing them that their article has been deleted, why it has been, and where to go with questions – customised for each CSD category.
These would be relatively uncontroversial changes, without a real possibility of community rejection – it's simply a matter of proposing them.
Limiting article creation? edit
One suggestion I was given was limiting article creations so that non-autoconfirmed editors can only create articles in their user-space, or through Articles for Creation. I consider this a non-starter; ignoring, for a second, that many of the same problems infect Articles for Creation, and that the userspace is poorly patrolled and looked at, directly discouraging new editors from contributing is the root of this problem, not the solution.
New Data edit
One of the limitations of proposing new changes is that it is difficult to assess their potential efficacy. We know that most tagging is done through Twinkle, but only through personal experience, and we do not know how much. We know that some tagging is done through Twinkle without user warnings, but not how often this occurs.
A suggestion would be to conduct a survey. Twinkle leaves a specific tag in edit-notices when it is used; by comparing the log of deleted pages to the summaries of each page's deleted edits, we could identify the proportion of deletions undertaken with the aid of twinkle. Similarly, by comparing that resulting list to the user talkpages of the creators of each article, we could assess what proportion of twinkle-based deletions do not include notifying the creators. This would ideally be done by an automated bot, preferably one with admin privileges to review deleted diffs – although a semi-automated process would reduce the number of statistical errors and anomalies.
The inherent problems are technical and statistical. On the technical front, it may burden the servers to run such a bot, and there may also be technical objections to creating the bot in the first place. On the statistical front, there will inherently be errors and anomalies – Twinkle can be used for many things, and unless the data is reviewed after being gathered, it may produce a large number of false positives. Nevertheless, assuming that there are no technical objections, somewhat inaccurate data is better than no data at all.