Talk:Article Creation Workflow/Design

Instructional text

This page looks good :-) You're absolutely right, of course, that we offer far too much instructional text. Users who are task-focused perceive the text as an impediment -- e.g., just this past weekend, I tried to test out using the Article Creation Wizard, and even though its text is relatively tight, I still found myself skipping past most of it. The trouble with our existing instructional text is that we try to accommodate all possible use cases [1], which makes the text really, really long. That backfires because users then skip all of it (like I did with the ACW). It'd be much more effective for us to keep instructional text super-succinct --covering just the most common use cases--, because that way, at least some people would get some information that could help them, rather than nobody getting any. Sue Gardner 01:59, 14 September 2011 (UTC)

[1] a laudable goal in software development, but maybe less of a laudable goal for instructional text :-)

MoodBar comments

Does anyone reading the MoodBar comments think that the articles created by these individuals would be kept on Wikipedia? I understand and appreciate the desire to make article creation less horrible, but it comes with a cost. Who's going to pay? --MZMcBride 04:11, 14 September 2011 (UTC)

Thanks for reading through the page and for the comments MZ. In my view, the two changes proposed here are:

1. Adding clear instructional material and warnings through one or two interstitial pages that appear before the edit window when you're hitting a redlink
2. Possibly providing a noindexed space outside the main namespace to create articles and strongly encouraging people to work there first

Neither of those changes seem like they will make anyone "pay". Rather, we'd like to tell newbies much more clearly upfront what the expectations are, and then ask them to start articles in a place other than the mainspace where both the article and their skills have time to develop. Even without the second step, what we want to do is reduce the costs placed on the community by making it clearer what we do and do not want in Wikipedia. Steven Walling (WMF) • talk 06:50, 14 September 2011 (UTC)

Number two seems uncannily similar to AfC. Killiondude 07:38, 14 September 2011 (UTC)

Hey Killion. You're right, it is pretty similar, but if you get a chance to read through "Future Phases" section there's more detail there about the ways it's different (as currently proposed anyway). For starters, it would not necessarily require review in order to publish, because it's aimed at registered users rather than anonymous ones. If you want to pick apart that description and leave us some feedback, it'd be a big help. Steven Walling (WMF) • talk 17:12, 14 September 2011 (UTC)

The only difference between the proposed workspace idea and AfC is that no review is required (or even encouraged, by the looks of it) by an experienced editor. This means that, while your warnings might occasionally convince a new editor to start their articles in the workspace, there is nothing stopping them from immediately moving it from the workspace to mainspace when they realize their article is not yet "live". Therefore, we're just adding a superfluous step in the article creation process which won't stop anyone from creating an inappropriate article in mainspace, and won't provide for any type of review process by an editor who is familiar with WP policies. A better process would be to require new users to go through AfC (or a similar AfC-like process) when they want to create a new article, until they have been properly educated on what is expected in a new article. Thus, en:WP:ACTRIAL. Snottywong 18:17, 14 September 2011 (UTC)

I think I might let Brandon reply about the particulars of the workspace design and how it might be adapted, but I do want to make a general point: when it comes to this or other WMF Projects, nothing has to be taken 100% as-is with an all-or-nothing decision. It's not substantially happening yet, but we'd like to live in a world where there is a lot more of this exact thing going on: experienced editors showing up very very early in the design process and giving us specific feedback about the potential process and policy implications of new features. Steven Walling (WMF) • talk 18:32, 14 September 2011 (UTC)

The description of the future phases and how they work is deliberately vague in certain areas, especially regarding how policies work out. For example, it could easily be set up that Anonymous IP editors can be allowed to create articles in the Workspace but not publish to the Mainspace - this allows us to have articles created by IP users but not allow them to pollute the Main space. That's only one policy change that could occur. Another idea could include "not automatically deleting poorly-written articles but instead unpublishing and then tagging them" so that work isn't lost.--Jorm (WMF) 18:36, 14 September 2011 (UTC)

Yeah, where they can collect dust just like everything else that needs maintenance. As evidenced by the numerous backlogs on such essential problems as copyright and fair-use issues, we can't handle all of it at the rate it's coming in. At the risk of being a dick, I'd urge you to click on the link Snottywong provided you above and give input there. The Blade of the Northern Lights (話して下さい) 22:01, 14 September 2011 (UTC)

'Specific feedback' has already been provided, but Brandon and Erik Moeler, as evidenced by gheir comments at Bugzilla, apparently do not wish to entertain it. It should not be a foregone conclusion that WMF office bods are more competent than the volunteers who do the grunt work, and if Steve wants experienced editors to show up very very early in the design process and provide you (the WMF) with specific feedback about the potential process and policy implications of new features, then a more civil and friendly approach should be considered by those who dismiss the good proposals for solutions that have already been made by groups of highly competent editors who have hands-on, first-hand experience of the problems.
All these vague suggestions above for 'new' solutions are so similar in other guises to the en:WP:ACTRIAL that was reached by an overwhelming consensus of the community at en.Wiki, that the original trial might just as well be allowed to take place - it has many safeguards that are not even being mentioned here.
A solution is required now for the en.Wiki, not in two or three years time - which is what will happen if this discussion on vague alternatives is allowed to continue. Note that the goal of Snottywong and Blade with their ACTRIAL was never to delete poorly written articles, and is not the product of a cabal of exclusionists as was suggested at Bugzilla; it was simply intended to prevent the creation of thousands of uncontroversially useless new pages, and at the same time offer three parallel avenues for fast-tracking serious articles to live mainspace - al with relatively uncomplicated and minor changes to the site software and user interface. The current decline in potentially serious new editors is due to their being driven away by the daunting text-walls of dozens of pages of policy, guidelines, and other instructions, while we are leaving the door open to a deluge of spam, copyvio, vandal, test, attack, and nonsense pages that even a squadron of mature, experienced patrollers would not be able to cope with on a daily basis. NPP is a magnet for the least experienced and least mature of users, and is therefore a broken system, and careful long-term research by en.Wiki editors (and not by WMF projects such as the Summer of Reserch), has already offered more than sufficient evidence of it. --Kudpung 20:14, 18 September 2011 (UTC)

A graph showing the number of Articles for creation submissions per day, from Jan 1, 2010 to Nov 26, 2011.

I add this comment now here, because I think that is the most fitting page right now. User:TheEarwig created this great image to show how the submissions involved in the last two years. I think this image speaks for itself... mabdul 19:34, 27 November 2011 (UTC)

Oh forgot to say: please have also a look at this comment. mabdul 21:01, 27 November 2011 (UTC)

Unfortunately, things like that happen all too often. It is one of the reasons new editors leave and never return. Hopefully, the community will recognize the harm this does to our volunteer population and do something to change it before it's too late. - Hydroxonium (T•C•V) 03:51, 6 December 2011 (UTC)

Lovely Root System - can we make it grow?

This idea has such a lot of useful ways in which it could grow. I'd personally like it if new accounts had a sandbox area automatically created for them, with links to a really good set of interactive tutorials covering the basics of what newbies need to know; screenshots with annotations for "how to do this", which newbies can read in conjunction with playing in their sandbox; a kind of "test yourself" auto-marked interactive quiz thing for each basic concept, a heap of stuff like that so that newbies can really get into practising "getting it right" from a very early stage. A links to "pick a mentor" (somewhere really easy to see, so they're likely to hit it, perhaps) would be a good idea. But really excellently-structured interactive video tutorials would be such a good thing to look into, from this start. One of the options in the article workflow "I don't feel confident yet - I want to do the tutorial" as one of the options. Probably the top one! ThatPeskyCommoner 08:02, 14 September 2011 (UTC)

An alternative idea to videos is, an interactive tutorial, similar to those in many computer games - where the user sees the same Wikipedia edit-screens but receives instruction and help at the same time; for example, imagine it asks the user to put a [[wikilink]] in the edit-screen, and then when they get it a bit wrong, it highlights the error and explains the problem ("you need to put TWO square brackets around it") - and if they get it wrong again, just does it for them. I think that'd be an excellent system; I discussed this some time ago with Sage Ross, but nothing came to fruition. Chzz 09:27, 30 October 2011 (UTC)

Are we really examining the entire workflow here?

I realize that this change is happening now for reasons aside from new page patrol workload. That seems to be what's driving its implementation at the moment, though, so in the interest of brevity I'm going to address it primarily from that perspective.

I'd like to start with a brief anecdote: I had a discussion with Neilk recently about the community's response to UploadWizard. I was curious why so many people were opposed to what is an obvious, major improvement in usability for contributors. His perspective, in summary, is that we only solved part of the problem. While the old interface was confusing for new contributors, that wasn't an issue for the established community. The community had a problem with categorization and sorting. We did little to solve that problem. Instead we made it worse, from the perspective of the people in the trenches, by inviting a torrent of new contribution.

I think there's a lot to be learned from that. One lesson might be that improving UI is bad, and the technical barriers we have in place are beneficial because they keep out the riff raff. I think that's the wrong lesson. This entire movement is built on people feeling empowered to contribute.

Instead, I think we need to be more mindful of the entire, end-to-end workflow for new content creation. Clearly at this point, there's a mandatory review of all new pages (via NPP). Our current approach sees improvements to that step as out-of-scope. I really like the current proposal, but I don't think we're going to get broad support from page patrollers until we include them in it.

Furthermore, addressing only one part of the problem carries additional risk. For example: we hope that educating people about Wikipedia policies as part of the process will help reduce the overall workload on page patrollers. Currently, about 30% of all new pages are deleted. Let's assume we're successful, and our education efforts reduce that number to 18%, but our usability improvements double the number of new pages created. In a sense, this outcome would be wonderful, but it would actually result in an increased NPP workload.

I tried doing some NPP recently. I set up Twinkle, read the documentation, and checked out Special:NewPages. While I didn't mark any pages (I don't feel that I'm personally experienced enough), I saw many areas where the process could be improved with WMF support. I'm sure the experienced new page patrollers know way better than I do. The central issues, as I see them:

• The documentation is long and confusing, which I bet keeps people from learning NPP
• While there's a clear workflow, the available tools don't guide the patroller through that workflow
• The existing process is inefficient (requires many clicks)
• The existing process requires the patroller to keep a lot of minutae in their head
• There does not appear to be automated infrastructure for recruiting new patrollers

Data shows that workload per new page patroller is actually decreasing, and has been for some time. However, it's clear that there's a perception that workload is increasing, or that the work itself is terrible. The source of this perception is a mystery to me, but I suspect it may stem from a sense of frustration and disempowerment that comes from years facing the same endless torrent of spam and vandalism. Perhaps if we were to work with these people to improve their tools and actively recruit new members to their ranks, the sense of futility would wane.

Of course, we can't do all things at once, and I'm not proposing that. Rather, I think we should broaden our scope when making plans, and balance improvements that create an influx of new users with features that make dealing with that influx easier. The most important thing is that we consider the entire process, and make it clear that we're doing so to the people who are affected.

tl;dr

Our current plan to address the NPP workload:

• Improve the quality of new articles by effectively educating new users.

This proposal:

• Improve the quality of new articles by effectively educating new users.
• Improve the efficiency of the new page patrol workflow
• Recruit additional new page patrollers by building tools for that purpose, and make software that helps to train them more effectively
• Get the new page patrollers whatever else they need to work effectively

Raindrift 01:23, 15 September 2011 (UTC)

This is the last comment I'll make here, since I'm sick of being patronized. It's not addressing the problem of an influx of new users because people don't read what we give them. Someone who wants to write about The Sound of Perseverance (band) (see WP:GARAGE) will do it, and someone who wants to write "Let's expose all burakus for what they are!!!!" and link to a website with a list of all the burakumin in Nagano Prefecture doesn't care what we want them to do, they'll do it. This will enable them to do it and keep it around (and for those of you who think this is trivial, this is illegal in Japan, and the wrong person seeing it could lead to thousands of lives being destroyed; you're very lucky I caught it). I could point out some other problems, but I want to see if people here can really solve this problem being so far removed from actual New Page Patrolling on en.wiki. The Blade of the Northern Lights (話して下さい) 02:59, 15 September 2011 (UTC)

In my opinion, Raindrift's proposal is the first step in the right direction. Any proposal of this scope needs to equally take into consideration both the needs of new users and the needs of experienced editors who will largely be managing the new users' contributions. You may have followed the autoconfirmed trial debacle. Our long-term plan was to first implement a trial restricting article creation to autoconfirmed users, and the second step was to start drafting improvements to NPP. In any case, I've patrolled pages for awhile — not nearly as much as some others like Blade of the Northern Lights or Kudpung, but enough to know what's wrong with the system. At the very least, I can offer my personal answers to some of your questions.

In particular, you mention that workload per patroller is decreasing while the perception is that it is increasing. I think I might be able to shed some light on this one. Patrolling an article encompasses a wide spectrum of potential tasks, and which tasks are performed depends on the patroller. For instance, on one end of the spectrum, many patrollers will simply check to make sure that the article is not overt vandalism, and mark it as patrolled if it passes this simple test. On the other (ideal) end of the spectrum, a patroller will check everything on this checklist, and actually fix various problems with the article before moving on to the next one. This side of the spectrum requires not only more time, but more experience from the patroller.

Anyway, the point of the story is that workload per patroller is decreasing because patrollers are doing less work on each article. The reason they are doing this is because of the constant pressure from knowing that if the Special:Newpages queue reaches 30 days, then articles are going to fall off the list and never get patrolled. So, they feel like they are stuck between two bad choices: maximize their patrolling speed by skipping steps, or allow the queue to overflow. The problems are relatively simple:

• There are too many articles for not enough patrollers.
• NPP is often seen by new users as a way to quickly increase your edit count, therefore patrollers are often inexperienced users who aren't equipped to recognize (no less fix) many problems with articles.

How do we solve this problem? Many of your suggestions will certainly help. Better patrolling tools, better training for patrollers. One idea that we've been throwing around is requiring patrollers to have a user right in order to mark a page as patrolled. This will prevent very new, inexperienced users from marking inappropriate articles as patrolled. It will also allow us to revoke the user right if we determine that a user is doing a particularly poor job at patrolling. Another frequently requested feature is to make the "Mark this page as patrolled" link appear on any unpatrolled article, regardless of whether you accessed it via Special:NewPages or not. This would allow patrollers to patrol even when they're doing other tasks and they happen to come upon a new, unpatrolled article. My personal opinion is that we should combine both ideas and make the "Mark this page as patrolled" link much larger and more visible for users with the aforementioned user right.

NPP is definitely a broken process, and therefore I'm sure other patrollers have many more ideas than I do. You may want to consider posting a notice to this discussion at en:WT:NPP. Snottywong 03:32, 15 September 2011 (UTC)

First of all, I should mention to everyone that there's been some discussion of how NPP works now and its issues over at Patroller Workload. It's worth reading that discussion.

To add to the list of issues, it seems there's a concurrency problem when multiple NPPers are working at the same end of the queue. Once there's more than 3-5 simultaneously, they start generating edit conflicts with one another. I'm concerned that more patrollers on the current interface would make that worse.

Snottywong, thanks for your input. It sounds like the process itself actually involves many people with varying levels of skill, but the only differentiation in the task is which end of the queue one examines. I wonder if we could start improving the tools by storing more granular information about which aspects of an article have been reviewed. This way, we could promote greater specialization (doing NPP now requires a lot of knowledge), and the tool itself could be used to teach new skills.

For example, imagine a tool that shows one new article at a time, choosing it based on a set of criteria (age, what's been checked, who the patroller is, etc). NPPers could start out patrolling for vandalism and spam, which are easy to recognize. After patrolling 25 articles for those criteria, the tool explains how to look for a good title and how to move an article (and so on). This way, new patrollers are gently led along the learning curve while accomplishing useful work at the same time. At some point, they could start only reviewing articles that had been vetted as not-vandalism and not-spam, on the assumption that new patrollers were handling those.

For very new patrollers, it might make sense to show their edits to someone more experienced to see if they agree.

Tracking the specific review steps would allow us to expose which steps an article had passed. This is handy for finding articles to patrol that match a patroller's skillset, but it might also help to reduce newbie-biting. Instead of telling someone, "Your article lacks references," we could instead say, "Your article is notable, has a good title, is properly categorized, nicely formatted, has great spelling, but lacks references." That kind of positive reinforcement is very specific, which makes it feel very sincere.

Well designed, I think such a process could actually be less work. Ideally people are looking at these things anyway, so it'd only be an extra moment to check a box when done. In return, we'd see a significant reduction in duplicated effort. Also, we could build a UI that keeps all the resources necessary for effectively patrolling a page handy, which would streamline the process further. Then again, perhaps this wouldn't help at all and there's some important aspect of the process I just don't get yet. I'm glad we're discussing it, though.

Secondly, it seems that a very small number of people do most of the page patrolling, and especially the more skilled (end of queue) portion. That's a pretty hefty burden for a small number of people. Training new patrollers will help with that, but we also need to be able to call on them when they're needed. I'm thinking a simple system that monitors the age of the queue, and starts notifying known NPPers when there are many unreviewed articles that match their skillset.

Lastly, the 30-day deadline for NPP seems like it might be useful for setting targets and motivating work, but could also be getting in the way and leading to necessary patrol not happening. With this hypothetical system, we could apply a more nuanced view of how long is reasonable for patrol to take. For example, the deadline for spam-checking should probably be a day or less, but the deadline for reference checks could perhaps be more than 30 days without ill effect. When a task runs past the deadline, automatically deciding to skip it is probably the wrong course of action. The point here not that we should implement any specific change, but that it's worth examining whether this deadline (and how it's implemented) is serving us well, and if not, what could take its place.

Ideally, a tool for this sort of thing could be generalized for many types of patrols (ie. not just new page patrol), but I'm also wary of scope creep, and I realize that just because these things sound similar doesn't mean they are. I'd like to identify the areas where the process could find the greatest benefit, and address those things first. Raindrift 23:22, 15 September 2011 (UTC)

I'm encouraged that you're taking the time to independently discover many of the problems with NPP. You might be interested to learn that volunteers have taken it upon themselves to at least partially mitigate some of these problems. For instance, I have created a tool which tells you how many people are working on each side of the newpages queue (see http://toolserver.org/~snottywong/cgi-bin/patrolreport.cgi). I've also created a tool which tracks how close we've gotten to the 30-day limit (see http://toolserver.org/~snottywong/cgi-bin/patrolgraph.cgi) along with a defcon template which is updated hourly by my bot (see en:User:Snottywong/NPPdefcon). My bot also runs a task which notices when the newpages queue overruns its 30-day limit, and keeps tracks of any unpatrolled articles which were forced off the list (see en:WP:NPP30). Luckily, the queue hasn't been overrun for a few months, but earlier in the year there were hundreds of unpatrolled articles overflowing the queue every month.

Clearly, many of these problems could be solved more efficiently and effectively by changes to the mw software. Patrollers have been screaming about the 30-day limit for a long time, but have never convinced anyone to address it.

I think your idea about making multiple levels of patrolling is a step in the right direction, but I think I'd have to see a more detailed proposal before I could support it. My fear is that it will actually create more work, because 4 or 5 people will end up reading through the whole article as it goes through all of the different patrolling stages. The important part is that we make patrolling a user right which must be requested and which can be taken away if the patroller consistently does a poor job. Pair that with an intuitive, interactive education system on how to correctly patrol and I think we'll be making some progress. Snottywong 00:02, 16 September 2011 (UTC)

And one last word of advice. Kudpung and I are the main presence at NPP; do not ask us for help unless forging ahead with ACTRIAL is a part of the deal. We spent a tremendous amount of time on it only to be spat in the face, and we do not want to waste our time if our ideas will be disregarded. The Blade of the Northern Lights (話して下さい) 01:16, 16 September 2011 (UTC)

Snottywong: Thanks for linking to the tools you created. I'd seen some of them, but hadn't run across the patrolreport yet. I think this work is really good, and should form part of the basis for a more integrated interface.

I have to say, it upsets me that you've needed to code a bot to keep track of unpatrolled articles that run off the end of the queue. It really demonstrates how Mediawiki hasn't been updated to reflect the reality of how people are using it in this area in a very long time.

The multiple levels of patrolling idea is just a brainstorm at this point. The underlying issue I see is that there are people with many different levels of skill, and coordinating them effectively and training them up is hard. There are probably multiple ways to address that issue, and I'm going to ask if other people here can come up with more promising designs. In any case, I feel like I'll need to understand the problem better and work more directly with people who do NPP regularly to craft a proposal that can actually work. You're totally right that, implemented naively, such an interface could be worse than useless.

I like the idea of making patrolling a userright. I've read the discussions about how much damage a sloppy NPPer can do, though I'm still unclear on exactly how pervasive that problem is. If anything, though, the userright would make identifying NPPers to request their help easy. However, rather than making it request-only, I wonder if inviting people would lead to a greater number of NPPers and reduced overall workload. I think we could come up with some criteria by which good potential patrollers could be identified (some combination of edit count and types of previous activity), and manage this part of the process automatically. It could even be the sort of thing that is only triggered when the number of active NPPers gets below some threshold, to make sure we don't request help when it's not needed. Conversely, triggering invitations could also be managed by people if there's no clear-cut way to do it with code.

The Blade of the Northern Lights: I hear you. I have about as much ability to directly implement ACTRIAL as you do, so I've intentionally avoided forming a strong opinion about it. However, I think there are a lot of other angles from which this issue can be approached, and I'd like to focus on the ultimate goals (reduced NPP workload, higher-quality Wikipedia, more contribution in all areas from a more diverse userbase). You have a lot of experience here, and your input, if/when you feel ready to give it, would be of value. However, I also understand that you don't necessarily feel enough trust to do that right now. Raindrift 19:10, 16 September 2011 (UTC)

greetings Raindrift,

Regarding the userright idea, at least initially there would probably be no need to actively recruit people to get the userright. History has shown that there is nothing more fashionable among Wikipedians than acquiring the latest new userright. There will probably be a stampede of editors when it becomes available. Many of them will likely not use it much, but I think that simply the act of making it a userright would initially serve as an adequate form of recruitment. Snottywong 21:37, 16 September 2011 (UTC)

some thoughts on your post.

• The documentation is long and confusing, which I bet keeps people from learning NPP

i found the docs to be fine. true, theres a fair bit to know but (like anything) you just focus on one part until you're comfortable then move on to the next thing. for instance, i've been patrolling for a while but only yesterday made my first submission to afd.

• While there's a clear workflow, the available tools don't guide the patroller through that workflow

not really sure what you mean here, as you say the flow is clear and i find the tools to be fine.

• The existing process is inefficient (requires many clicks)

dont agree, i have no probem with the tools, just for the record i use twinkle and the "New Page Patroller" script, plus some firefox plugins like mouse gestures and tab mix plus. i find it to be fast and efficient.

• The existing process requires the patroller to keep a lot of minutae in their head

sure, but thats the nature of the beast no? and besides, as i said above when you're starting you're not going to memorise everything, you just start with a section, study G11, work out what exactly "uambiguous advertising" is before moving onto the next thing. hmmm but maybe that approach should be suggested somewhere.

• There does not appear to be automated infrastructure for recruiting new patrollers

not sure about this at all, what i see is people tryng it out and then most move on. pretty much every time i'm patrolling there are names in the patrol log i havent seen before, thats subjective tho, no data.

• However, it's clear that there's a perception that workload is increasing, or that the work itself is terrible.

dont agree, i think theres a few people saying that yes, but if you look at the npp logs, most of the people doing npp are not complaining on the talk pages, at least i havent seen that. maybe i'm not looking at the right talk pages?

as to it being 'terrible', i think thats a hard call, it seems to me most people come to "build an encyclopedia" they're creative types, they're sociable, they like to help people out and they are very sincere and genuine in this. for them i think yes it can be a terrible job because a lot of what you do on npp can be *perceived* as quite negative and it really goes against the grain for them.

for myself, i enjoy it and every now and again when the torrent of crap gets too much , i take a break and that helps a LOT.

ok, so three things that i think would help :-

• putting "Mark this page as patrolled" link on a page even if it you didnt get to it from the npp backlog. i suspect that just doing this would help a lot.

• some way of filtering the npp log, so i only see unpatrolled articles that have certain words in. for example, i might know a lot about garage bands, so any articles with that phrase get put to the top of my list. i think this would help because it would mean a npp could just focus on their area of expertise and get used to the rules surrounding that area.

• this is a touchy one, admins ;) the docs only get you so far, you learn a lot (or at least i do) from just doing something and then paying attention to how its handled. for example, and again i have no data but... i might tag some article with G11, it gets deleted and i think "ok, so thats valid for that corner case" then i tag a similar article G11 and BANG! all hell breaks loose. each admin themselves tends to be quite consistent, but amongst themselves, not so much. this, imo, leads to confusion and may drive people away from npp cos you dont know if you're going to get slapped or not and it makes it hard to figure out the edge cases.

cheers -- The Elves Of Dunsimore 04:01, 16 September 2011 (UTC)

Good point, about how the link should always be present for patrollers, rather than just when they're doing NPP. It looks like this has been tried before, but had performance problems. I think it could be implemented in a way that takes advantage of caching using JavaScript, so it's totally possible, and should definitely go on the list.

I agree it's essential that NPPers be able to filter the list of articles by some criteria, or have articles shown to them based on those criteria. That would streamline the process a lot. It'd also help with the concurrency problem a little, though I think there are better ways to address that. Regardless, people shouldn't waste their time searching for articles they know how to patrol.

It sounds like the current interface works pretty well for you. That makes a certain amount of sense, since you've chosen to do NPP. It sounds like you're pretty fluent in how the web works, you don't mind tracking down tools to do the things you want (scripts, browser extensions, etc). Also, you seem to be pretty organized in how you learn from documentation, mastering each part in-turn rather then overwhelming yourself with information. My comments came from approaching the subject as a new user, tempered by some experience designing UI for people who don't use computers the way I do. I strongly suspect that the way things work is okay with a small number of people, but even little improvements could dramatically increase that number.

Just as an example, people seldom approach a new computing task by reading documentation first. Rather, they expect the software to either be immediately understandable, or to teach them. We don't have any imperative to meet that expectation, but if we don't, we lose those contributors.

I'm trying to synthesize a number of perspectives to find the best way to make improvements, and I'm glad to have yours. It's good to hear from people for whom the current system works.

While it's totally not something you have to care about at all, if you have any interest in learning about how UI is designed, I recommend checking out Joel Spolsky's article series on it from way back in 2000. The examples are a little dated, but the content has stood the test of time. It starts with Controlling Your Environment Makes You Happy. In this specific case, the article about providing options instead of expecting people to remember things is particularly relevant. Raindrift 19:39, 16 September 2011 (UTC)

NPP is a broken process and needs a solution now

To be sure that it does not get buried, I'll repost my message in the Moodbar comments section here, because Raindrift's comments synthesise broader issues and do not address the specific problems outlined by Blade and Snottywong that need immediate solutions:

'Specific feedback' has already been provided, but Brandon and Erik Moeler, as evidenced by their comments at Bugzilla, apparently do not wish to entertain it. It should not be a foregone conclusion that WMF office bods are more competent than the volunteers who do the grunt work, and if Steve wants experienced editors to show up very very early in the design process and provide you (the WMF) with specific feedback about the potential process and policy implications of new features, then a more civil and friendly approach should be considered by those who dismiss the good proposals for solutions that have already been made by groups of highly competent editors who have hands-on, first-hand experience of the problems.
All these vague suggestions above for 'new' solutions are so similar in other guises to the en:WP:ACTRIAL that was reached by an overwhelming consensus of the community at en.Wiki, that the original trial might just as well be allowed to take place - it has many safeguards that are not even being mentioned here.
A solution is required now for the en.Wiki, not in two or three years time - which is what will happen if this discussion on vague alternatives is allowed to continue. Note that the goal of Snottywong and Blade with their ACTRIAL was never to delete poorly written articles, and is not the product of a cabal of exclusionists as was suggested at Bugzilla; it was simply intended to prevent the creation of thousands of uncontroversially useless new pages, and at the same time offer three parallel avenues for fast-tracking serious articles to live mainspace - al with relatively uncomplicated and minor changes to the site software and user interface. The current decline in potentially serious new editors is due to their being driven away by the daunting text-walls of dozens of pages of policy, guidelines, and other instructions, while we are leaving the door open to a deluge of spam, copyvio, vandal, test, attack, and nonsense pages that even a squadron of mature, experienced patrollers would not be able to cope with on a daily basis. NPP is a magnet for the least experienced and least mature of users, and is therefore a broken system, and careful long-term research by en.Wiki editors (and not by WMF projects such as the Summer of Reserch), has already offered more than sufficient evidence of it. --Kudpung 20:28, 18 September 2011 (UTC)

Kudpung, I'm going to have to take you to task for your comments about people being "uncivil". Reading everything, the conversation has been fairly civil. I'll admit that I was aggressive in the bug when I said that NPP is often staffed by new editors who want to "rack up edit counts", and I'll accept chastisement for that statement (a statement which you appear to agree with, by the way). You are clearly frustrated, and I wish that we could move beyond that and into a constructive dialog.

I have been engaged as much as I can be with people about this over the past several days. Many people are providing input to us, both on-wiki and on IRC. I've actually worked all weekend on an idea for a revamped interface. We are absolutely trying to work with Good Faith here and are thinking hard about how this works, what's broken, and how it should work.

We would very much like your constructive help with this. We are trying to set up a system for people (New Page Patrollers, in this case) to record screencasts of how they go about working, say, for 15 minutes to half an hour - so that we can get as many experiences as possible to work from. Your input would be very much appreciated with this.

Also, I don't think that this is a situation of "all or nothing". I'm fairly certain that there are other ways to go about combatting the problems you describe than adding another user right and applying ACTRIAL. There is always another way. Always.

(One idea that we've been turning over is a way to better crowd-source page patrol, where the "tagging" of articles doesn't result in higher edit count, and that an article has to reach a defined threshold of the same tag (given by different users) in order to have the tag go "Active". So, for example, if four people mark a new article as "spam" then it will be considered spam, but if only two people do, it won't hit the threshold. This would help solve for the problem of inexperienced patrollers making bad judgement calls since the responsibility for accuracy would be distributed.)

For the record, just so identity is clear in this issue, I am employed by the Foundation. My title is "Senior Designer." Erik is my grand-boss of sorts - he is the Vice President of Engineering (and, I believe, still the Deputy Director of the Foundation). Steven Walling and Ian (Raindrift) are also Foundation employees (Steven works for the Community Department as a Fellow, and Ian is a Software Developer in the Features team).

I really hope that you can bring your experience to play here. This is a very hard problem (the kind I enjoy solving), and the more brains we have the better.--Jorm (WMF) 22:16, 18 September 2011 (UTC)

I'm concerned that a lot of the solutions to the NPP problem that being thought up by the WMF involve an increase in the amount of work required to patrol an article. A fundamental concept that you need to understand is that there is already too much work for the current pool of patrollers to keep up with. At this point, most articles exist for 20-30 days before one patroller gets a chance to look at them. Any solution that is going to require multiple patrollers must be coupled with a guaranteed solution to increase the number of patrollers by a corresponding factor, or increase another variable in the equation. For instance, if it's going to take 4 people to mark an article as patrolled before it is "fully" patrolled, then one (or a combination) of these things would need to happen concurrently:

1. The number of new page patrollers would need to increase by a factor of 4.
2. The Special:NewPages queue timeout would have to be increased by a factor of 4 (i.e. from 30 days to 120 days).
3. The time it takes to patrol an article would have to be reduced by a factor of 4.

Numbers 1 and 3 would be very difficult (if not impossible) to acheive, and number 2 is problematic because do we really want terrible articles floating around on Wikipedia for up to 120 days before someone gets a chance to look at it? While distributing responsibility for patrolling articles is a good idea in theory, in reality it is unlikely to work.

At the risk of sounding like a broken record, the ACTRIAL idea was an attempt to solve the problem from the other end; i.e. by reducing the number of articles that need to be patrolled. If you consider that nearly three-quarters of all articles created by non-autoconfirmed users are eventually deleted (and there is hard evidence to support that), this is the low-hanging fruit that we saw as the easiest solution. On average, non-autoconfirmed users create 695 articles per day, only 191 of them are not deleted after they get patrolled. This is an average of 504 articles per day that are injected not only into the workload of the new page patrollers, but also into the workload of admins who patrol speedy deletion requests, admins and users who patrol PROD requests, users who comment at AfD discussions, admins that close AfD discussions, and users who comment at DRV discussions. The impact of finding a way to cut down on the number of inappropriate articles created per day (whether it be by the ACTRIAL method or some other way) would be huge, and it would lessen the workload of a lot more users than just new page patrollers. This is a major inefficiency with the way wikipedia currently works, and it's only going to get worse as the number of new things to write articles about continues to decrease. Attempts to improve methods of educating new users on how to create better new articles can only accomplish so much, and in my opinion it won't do nearly enough. Snottywong 21:53, 19 September 2011 (UTC)

Item (2) won't do much good; if NPP can't keep up then it can't keep up. The size of the backlog is irrelevant. ErikHaugen 22:13, 19 September 2011 (UTC)

I'm aware of these issues; I actually have a design for a feature that operates from the other end of this spectrum - the patrolling interface itself. I'm in the process of writing it up and will publish it either late tonight or tomorrow.--Jorm (WMF) 21:58, 19 September 2011 (UTC)

Multiple Extensions/Projects

Looking over the proposal as is and how it could be, it is clear that there are several issues here which dovetail into one another. Many (most?) of these elements can be applied across several workflows in Wikipedia.

First, I'm going to Be Bold and say it: MediaWiki is great for what it is but it's really not designed for the scale of the workflow that is being demanded of it. The software has been very "generic" for the most part and not targeted at the specific needs of Wikipedia (such as the New Page Patrol workload). As Raindrift stated above, there are several "degrees" of NPP; the software was never designed to accomodate that.

The following is a list of identified features that may or may not be useful in the overall zeitgeist of the problem. Feel free to add to it.--Jorm (WMF) 18:46, 16 September 2011 (UTC)

• Better Landing and Interstitial Pages - this design document currently focuses on this in particular.
• Better Help System - this should be a context sensitive, targeted, and word-budgeted help system. Additional links can take the user to "Full Monty" documents, but for the most part editor education should be a gradual process rather than Encyclopedia Writing 101.
  • This feature would be an extension, smart, and be able to be inserted with parser hooks to sections on a page (e.g., {{help-hook|template-writing}}.
  • Additional features within this extension could include a stream of "did you know..." tips that can be paged through.
• Article Tagging System - this should be an easy-to-use panel that allows a user to tag an article in many ways, such as "needs sources," "more photographs", "spam", etc. This system could be expanded to work within the main namespace on existing articles, possibly replacing the large Orange Boxes at the top of many articles (and thus possibly reducing server/template overhead)
  • Storing tags in a metadata format would allow for them to be easily searched ("Show me articles lacking sources within WikiProject Military History").
  • Such a tool could be easily converted into a "Work List". One of the issues known to plague new editors is that they simply don't know where to start working. This, combined with an interests graph provided by GlobalProfile would go a long way towards showing people things that they can do - especially if we ask them questions like "Do you like copy-editing?," "Do you like researching sources?", etc.
  • The system could easily be built so that the tags could be defined by the community at large. With integrated localization, it could operate trans-wiki.
• Content Analysis System - an AbuseFilter-like system that gets run across a new article and checks that it meets various criteria (
  • This should include as sophisticated a "copyright violation" search system as possible. I'm not sure that we can win big with this, but plugging it into multiple search engines for text matching may be doable.
• Safe Harbor Workspace - this is described (vaguely) in the main design document.
  • Depending on configuration, this could reduce spam and vandalism pages if publication to the main namespace required review for all articles (e.g., you cannot publish your own article).
• New Page Patrol Call-to-Action System - this would be a simple call-to-action banner system that would appear to users who have been identified as previous or current patrollers.
  • Ideally, this system would funnel people into addressing elements that they have done before (copyediting, reference checking, etc.)
• Connection to Feedback Dashboard - this could be a way for new editors to request help.

Update on WMF conversations today

I'm not going to be able to respond in detail probably before next week, but I want to at least make an effort to counteract the normal bias that discussions happen internally at WMF, and aren't shared publicly, by recapping some of the conversations I've had today.

Earlier today, I met with Steven Walling, Ian Baker (User:Raindrift), Howie Fung (User:Howief), and Brandon (User:Jorm (WMF)) to further discuss the different problem areas we've been talking about (new page patrolling vs. straight article creation vs. article creation through an improved AFC-like mechanism). Essentially, we have different hypotheses how we may be able to positively influence inflow, quality and user experiences through targeted interventions, without necessarily creating new restrictions to page creation:

1) We hypothesize that improving the NPP tooling efficiency itself is likely going to be essential to keep up with the backlog, reduce NPP frustration, and bring more people into the fold.

2) We hypothesize that NPP patrolling tools could also be used to more effectively shepherd promising new users into environments where they can be mentored and supported.

3) We hypothesize that an initial interstitial as illustrated on the mock-ups on this page may help socially sort users into those who don't mind an experience that can get a bit rough (but who want instant gratification) vs. those who would like to do things in a guided and "correct" way, being recognized and supported along the way. This could reduce friction and frustration in the second group.

4) We hypothesize that an improved AFC process/tooling can not only help newbies make better pages, but it can also connect them with people who want to help them with their their specific article more quickly.

5) Last but not least, we hypothesize that friendlier messages/templates can go a long way in helping new good faith users feel welcome.

If we are to make a difference, we have to carefully stage interventions along these lines, and measure the impact. I've asked Howie to develop these hypotheses more clearly, and we'll probably start re-structuring the page consistent with that. Needless to say, the above is a loose characterization of what we've discussed, and I appreciate corrections/clarifications from the participants.

In order to improve NPP efficiency, we'll need more than first-hand experience -- we'll need to watch experienced users doing NPP work and explaining what they are doing. To do this with minimal cost, we want to explore using screencasting tools. We've worked with usertesting.com to get a simple version of their Java-based screencasting tool up and running so we can make it trivial to upload screencasts for people who aren't familiar with screencasting tools.

We'll talk more about that in a few relevant places as we finalize the tooling review, but if you want to already go ahead and record a 15-30 minute screencast of your NPP work, it would be tremendously helpful. Any explanations of the specific judgments you are making as you're doing the NPP work are appreciated.

As I mentioned a couple of times, we're serious about engaging with these problems. I hope we can formulate a set of hypotheses together that we all agree are worth testing. If, after doing so, we still think we need to test the autoconfirmed hypothesis, then we can revisit that question, but I suggest we start with hypotheses that are less controversial in light of our goals to attract new users and minimize barriers to participation.--Eloquence 01:58, 17 September 2011 (UTC)

I do not actually see a professional attempt to engage these problems. I see a lot of talk and positing of new hypotheses, and I see a marked resistance to properly examine the reports, stats, empirical findings, and solutions that have already been offered from the fold of experienced volunteers outside the WMF office walls, and that are the result of long, intense research since the beginning of October 2010. There appears to be some difficulty at MediaWiki in understanding that the en.Wiki NPP is a fundamentally broken process, because unless NPP is converted into a user right for mature and experienced editors, or unless en:WP:ACTRIAL is implemented, the problems will persist and get worse, and it will never be known without this trial, what further or other solutions should be preferred and explored. What en.Wiki basically has at present as its firewall against totally unacceptable new pages is an NPP system operated mainly by a batallion of the least experienced and mature editors, newbies themselves, and a very, very small platoon of seasoned users and admins trying to put right what they are doing wrong. Attempts have been made to make the NPP instructions as plain as possible, and to engage the patrollers in it, and hundreds of friendly requests have been placed on patrollers' talk pages asking them to improve their work, but 1. You can lead a horse to water but you can't make it drink, and 2. The NPP instructions are complex because they are based on the maze of walls of text and instruction creep of en:WP:DELETION, and en:WP:CSD, and all their variants and exceptions, and further explanatory essays. --Kudpung 20:55, 18 September 2011 (UTC)

Just to be clear on one point: we haven't really discussed making patrolling a userright at the WMF, either internally or in places such as Bugzilla, except that Raindrift (Ian) brought it up as an idea he supports. If English Wikipedia wants to improve the quality of patrolling by making it a userright that you control access to, I don't think anyone would oppose that. Steven Walling (WMF) • talk 02:15, 19 September 2011 (UTC)

The user right idea was a solution originally intended to be implemented after ACTRIAL was implemented, simply because there is a valid fear that making patrolling a user right would lead to a decline in patrollers. There is already a shortage of patrollers with respect to the number of articles created per day, and while many of the patrollers are doing a particularly sub-standard job, some believe that any amount of patrolling is better than allowing the article to fall off the 30-day queue at Special:NewPages and never get patrolled by anyone. I continue to believe that creating a user right for patrollers is a great idea, but I think it needs to be paired with either an increase in patrolling efficiency through interface changes (as proposed by Raindrift above) or a decrease in the number of inappropriate articles created per day (as proposed by ACTRIAL). Snottywong 21:58, 19 September 2011 (UTC)

SW, can you tell me (in simple words, because I'm genuinely confused here) why it matters if the "Mark as patrolled" button gets clicked?

I know why it matters that somebody look at the page and identify any serious problems: if we don't double-check, we may not find orphaned libel or vandalism for years. But I see a fair number of non-patrolled pages that have been edited by someone else, yet still aren't marked "patrolled". Why do we care if every single article is marked "patrolled"? WhatamIdoing 15:19, 28 September 2011 (UTC)

Marking it as patrolled removes it from the list at Special:NewPages, so that other patrollers won't waste their time patrolling the same article that you just patrolled. If pages didn't get marked as patrolled, then we would just have a static list of "new pages", and each individual patroller would have no idea what pages other patrollers have already evaluated. Snottywong 22:47, 28 September 2011 (UTC)

So it's strictly a matter of the convenience of editors, with zero effect on readers. Getting stuff marked as patrolled doesn't sound very important then.

Perhaps we should have a bot that clicks the button whenever a second (autoconfirmed?) editor edits it for any reason. That would doubtless pull a fraction of pages off the task list. WhatamIdoing 14:29, 29 September 2011 (UTC)

On required portals/introductions

"The new user may proceed only after viewing this content (this page will be dismissable)."

I hope there is a better way to introduce editors to this kind of info, without requiring an extra clickthrough and pageview. A two-column view for example, with the tutorial side-by-side with the editing screen. Extra required clickthroughs isn't fun the first time through, and becomes especially frustrating for anyone who edits as an IP from time to time. Sj 09:37, 17 September 2011 (UTC)

"Zoom" Interface

As promised, I have the stubs of a design document for a "Zoom" interface for new page patrolling.

This is really it's own project, however, so I have started its own design document at New Page Patrol Zoom Interface.

Please add comments and ideas there; this design is only in phase 1 of thinking. I don't normally like to post design documents that are this incomplete but I figure it is better to start early rather than later.--Jorm (WMF) 00:18, 20 September 2011 (UTC)

There still needs to be barriers to entry to article creation

I agree wholly with MZMcBride: MoodBar feedback belongs in /dev/null. I guess these were cherrypicked/edited for comprehensibility -- I saw the comments that MRG posted on en.wp:

• bad interdace,not easy,realy bad
• How do I email Tabercil - wiki admin on my personal bio page?
• "of when i ask you are not answer me why?"
• i want to write bt i can nt

Inviting users who can't even punctuate a sentence properly to create articles will only make things worse -- the community will find some other very bitey way to keep the garbage they create out. For this reason, we don't want to make this too easy to use (after all, editing Wikipedia requires a brain).

Running heuristics before page creation is the best aspect of this proposal. We've had ex-post heuristics for some time -- I created w:Template:Spamsearch some five years ago to identify spam pages in userspace. It is now an abuse filter. Intervention before the article is created stops nasty SD tags, talk page warnings and the sometimes unfriendly responses to questions regarding why blatantly unencyclopedic garbage gets deleted.

Something to consider is including an AJAX search box for the article title, e.g.

Article title: [Textbox]  [throbber]
First 5 search results for this title

We have plenty of users who don't STFW before creating an article (hence CSD A10). MER-C 05:50, 20 September 2011 (UTC)

The MoodBar is a tool that's presented to all new users after making an account and attempting their first edit. As such, it captures feedback from a wide variety of very different people: people of different ages, educational/cultural backgrounds, many folks for whom English is a second language, etc. Not all of them want to edit (they may have created an account for altogether different reasons, such as believing that it was required, and have found the edit function by accident); many of them shouldn't, but that doesn't justify discounting all the comments by those who do want to edit. Even the seemingly inarticulate ones may be examples of people who might be fluent in another language, or who are used to typing in slang in a feedback context, or who are dyslexic, or who simply have no mental map of Wikipedia yet (the comment you picked about Tabercil is a good example).

I would strongly dispute that the social and technical complexity of Wikipedia acts as any kind of neutral intelligence filter, and indeed, in addition to the MB comments telling us what problems people are reporting, we know (from user tests, surveys, etc.) that it filters out lots of people who we want as editors. We're going to keep an eye on the editors who've given us MB feedback and I'll bet you a non-virtual beer that among the folks you'd readily identify as inarticulate idiots are some who are or could be promising editors.

That doesn't discount the second part of what you're saying -- of course, if we increase the intake, we also have to improve intake management, and ideally in a way that's designed to avoid unnecessary biteyness, but that also takes into account that we have to show some people the door sooner rather than later. In case you haven't looked yet, New Page Patrol Zoom Interface goes in that direction. A part of the flow described on this current page that's easily overlooked is also that it proposes to sort people more quickly and effectively into those who are OK with a certain degree of roughness ("I know what I'm doing, lemme at it") vs. those who'd like a higher degree of human touch in a safe sandbox environment.

As for heuristics, I agree -- although again I would be careful not to pass judgment so quickly why/whether users have or haven't "STFW" yet. Empathy is a virtue. ;-) Some users have a harder time getting a full mental model of a site early; that doesn't make them stupid. There may be a red link they followed, or a search result page that invited them to create a page while they didn't notice the match.

It's certainly possible to provide more clues in the creation process, though. The Bugzilla implementation when filing a bug is a good example of a search to avoid duplicate reports integrated into the creation flow. I'd love to find a good, non-obtrusive way to include this type of functionality.--Eloquence 10:04, 20 September 2011 (UTC)

Regarding language issues: see here. Although it's from an OSS context, this part is extremely relevant. I can't speak for others, but I am much more likely to respond with heavy sarcasm to semi-literate, clueless comments like those seen on MB. That's why I wrote w:User:MER-C/SmartQuestions (it's still a draft). MER-C 13:52, 20 September 2011 (UTC)

Regarding: "Intervention before the article is created stops nasty SD tags". This intervention should include not letting every guy whose free time is only surpassed by his ego be a new page patroller. Regarding: "We have plenty of users who don't STFW before creating an article (hence CSD A10)". Included among them are editors having so many edits that the edit counter goes "Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 58 bytes)"; see w:Joannes Scotus Duns, now a redirect, for a duplicate article like that. Have mörser, will travel 19:12, 10 October 2011 (UTC)

Please record a screencast of yourself doing New Page Patrol

Moved this section to New Page Patrol Zoom Interface since it's actually the right place for the discussion.

Thoughts about presentation / feedback

(Norm an en contributor.) I like the proposed workflow and see few disadvantages. However, I'm worried about eh level of bureaucracy in making this happen, but I'm not really in a position to do anything about that. On a colour-of-the-bikeshed issue, however, can I just point out I thoroughly dislike the presentation of the proposed landing page. Ultimately, I find it not particularly visually appealing, and, if I'm honest, somewhat patronising. I'm an experienced contributor, but I still feel even new users, assuming they are adults, for example, will not be impressed with the condescending tone with words such as "though". This may be a problem if this goes to trial, because you are combining the change in the shape of the workflow with changes in the tone of the workflow. Aesthetically, it feels wrong. The superfluous indent, combined with options both above and below some more options, all presented differently. Thanks, Grandiose 14:58, 28 September 2011 (UTC)

Interactivity and editor retention

Let me start by saying that, so far as this proposal goes, I think there's a lot of good in it. Well done.

Let me also start by saying that I come here expecting my comments to be ignored. The ACTRIAL debacle burned a lot of trust. I don't ask anyone to address this, but I did want it "in the open."

In terms of smacking down relatively new editors and pushing them away from Wikipedia, in my view, the biggest problem with the status quo is the "handing a child a landmine" aspect of sending them directly to an article creation screen. Five of six new editors can't manage to create an article we'll leave around. Yes, we need to do a better job at effectively communicating our basic requirements to new editors. It's great that you see that, and I look forward to trying to think about distilling what those editors need to know. But.

But I fear that without more than just an educational screen, most of those editors will step on the landmine anyhow. Too much to pick up, too many requirements. All of which are being expressed in a very general way, as the screen is talking about issues that could apply to any article the editor might want to create. We have a lot of requirements. It seems to me that the right ways to help a brand new person navigate a landscape with a large number of requirements is to either do so more gradually (e.g., in steps, such as the Article Wizard), or to provide more interactivity.

Interactivity: If I save this comment right now without a edit summary, WP will immediately tell me that I need to add one. Feedback is friendly in this case because I get the feedback while I'm working. I'd be really annoyed if it told me that 12 hours later. Immediately, interactively, it's easy to go "oh, right", add it. And it's easy for WP to give me targeted "Hey, here's the thing that you need to do for *this* article right now the way it is", rather than a general list of rules I need to interpret and mentally apply. Targeted, automatic feedback is, to my mind, the only thing that will substantially reduce the deletion-based bite for new editors who are handed the landmine of a "just write whatever you want" article creation screen. So, my main point--those "automated checks" that you've got marked for a later version? I consider them pretty critical, if what you're trying to do is to help editor retention. Move them up in your schedule.

Finally, even with those improvements, that the basic article creation screen is a danger, a danger of deletion BITE. (Even if that BITE happens a week later, it's still a BITE.) If we gave more new editors incentive to use the Article Wizard rather than the "pro" screen, they'd lose fewer articles. As a result, we would retain more editors. Isn't that the goal? I urge you to consider ways to make the danger of the basic article creation screen apparent to new users, and to if necessary, even scare them into using an improved Wizard, and to focus on improvements that would make the ACW a more attractive option for new users, who ... are going to be deciding (based on very little information) which path to article creation they wish to take. --Joe Decker 23:25, 28 September 2011 (UTC)

We - and I think I feel safe saying "we" here, the Foundation - we are not trying to give the impression that we believe that only education (especially only the initial education screen) is emphatically not the full solution. The full set of features we are looking at is something that will take a great deal of time to implement and deploy and as such we'll have to do it in a staged manner. Since a single education screen is probably the easiest of these steps, we're looking at it first.

I think we'll end up addressing this issue on two fronts: from the editor's perspective and from the patroller's perspective. They are two sides to the same coin.

From the Editor's Perspective, we are looking at:

• Interstitial landing pages, such as the ones mocked up in this page;
• Automatic save-to-workspace technology, so that good-faith contributions are not lost due to inexperience or overzealous page queue running;
• Better help documentation - stuff that isn't filled with instruction creep, is friendly, and flows well;
• Automatic scanning of articles before publication to catch our most common errors (e.g., not allow an unsourced BLP get published, or articles with obvious attacks, or spam links);
• Better tools for collaboration, such as a way for page reviewers to mark articles in the workspace as needing attention in various areas;

From the Patroller's Perspective, we are looking at:

• Developing a native interface for patrolling (the New Page Patrol Zoom Interface)
• Developing smarter systems for how Special:NewPages defaults to sorting (e.g., auto-detecting possible vandalism and bubbling that up to the top of the stack, overtop newer articles)
• Developing better empathy mechanisms, such as Global Profile, to enable patrollers to more easily detect vandal accounts

Obviously, this is an abbreviated list. There's lots of other things we can think of. I think the most important thing to have on the table, though, is that we can think outside of the "normal" limitations that exist without developer interaction. We can write software, and we can take a step back and rethink the entire process if we decide that's what has to happen.

I absolutely agree that the software shouldn't let you do something that you're not supposed to do. That's, like, "Usability 101". These are very hard problems (which makes them enjoyable to solve, for me at least).

What you're talking about above, with the 12 hour thing - that falls into the "automatic scanning" line, I think.--Jorm (WMF) 01:31, 29 September 2011 (UTC)

Automagically identifying unsourced articles is going to be a particularly hard problem. Editors on the English Wikipedia are not required to use <ref> tags for their citations (so you can't just choke on anything without them), and even the presence of ref tags doesn't mean that there's an actual citation between the tags. WhatamIdoing 14:37, 29 September 2011 (UTC)

Agreed it's not easy, but there are ways (including with the current AbuseFilter) that you could also check for content such as sections with any likely names, such as "References", "Sources", "Notes", etc. so we're not necessarily limited to looking for ref tags. Steven Walling (WMF) • talk 18:55, 30 September 2011 (UTC)

The article creation wizard creates a ==References== section automatically. I'd suggest scanning for the presence of URLs (because most sources are online), but the ACW also pre-populates the ==External links== section with http:// example.com. WhatamIdoing 21:32, 2 October 2011 (UTC)

The Wizard makes new pages with a lot of pre-created stuff the creators don't know how to populate or remove. The ==References== section is just one of them and it would be easy for a filter to detect a missing {{reflist}} template, or as you say, no URLs on the page (somewhat less efficient because many of them are either primary sources or blatant spam). However, the Wizard needs a remake from the ground up by an experienced team that understands the psychology of web site users, visual perception, graphic design, and php & js programming.

While we are crying out for new editors, it would be a fallacy to assume that all the authors of new, well written articles are also interested in the backroom stuff that makes websites and electronic encylopedias work; we've all seen what a challenge it is for even some of the most mature and intellectual newbies to post a simple help message. For such people we need to make the process easier, (and friendlier) but in many ways - and paradoxically - the Wizard often makes it just more difficult.--Kudpung 02:31, 3 October 2011 (UTC)

The Wizard pre-adds the reflist template, so that's not helpful. I fairly often see a hand-typed list of sources after it.

I think the most we could do right now is scan for the absence of ref tags and the absence of http:// (that isn't associated with example.com), and ask a question about whether any sources were added. "Did you remember to add a citation to a reliable source so other people will know where you got this information?" WhatamIdoing 16:30, 3 October 2011 (UTC)

Regarding: "[...] needs a remake from the ground up by an experienced team [...]". I think the most difficult problems to solve are the human ones. One editor deleted a passage I had written after he declared it "vandalism" (translation: he didn't like what it said), even though it had an inline reference and all that. It took an inordinate amount of time at WP:ANI to get it sorted out, and others insisted one is allowed to remove whatever one believes to be vandalism without checking the source cited first. I almost quit Wikipedia during that incident. Learning the ropes of arguing within the framework of WP:THISANDTHAT with people whose intent appeared to me less than honest took me far longer than just copying some citation templates and changing the field values. Have mörser, will travel 19:46, 10 October 2011 (UTC)

Hi. Thank you very much for this information. We take your comments most seriously and they will be taken into consideration with our policy of user retention, and our current programme to greatly improve new users' first experience at Wikipedia. --Kudpung 01:29, 11 October 2011 (UTC)

Thank you to everybody

The whole editor retention issue is very important to me and, I believe, the long-term future of all WMF projects.

There is no way I can express how much appreciation I have for the WMF and the developers in stepping up to the plate to help solve this issue. I can't tell you how much it means to me that people are working on this problem and giving it such a high priority.

Our projects provide educational material to everybody in the entire world for free (everybody with a net connection). This educational material is compiled and organized by the generous volunteers we call editors. This is such an amazingly positive thing that humanity has done and it's been done out of the goodness of people's hearts. It has been extremely successful and a great benefit to mankind and I for one would like to see it continue long in to the future.

Our biggest problem for our future is the loss of editors. It is certainly true that we have issues with people trying to harm our projects, but that is a small percentage of users. The vast majority of people that contribute do so in good faith, and do so to help others.

In tackling the problem of bad-faith users, we have inadvertently caused an even worse problem that has been eating away at us like a cancer, dwindling our numbers. The loss of good-faith editors is more destructive than all the bad-faith editors, spammers, POV pushers, etc. put together. Without good-faith editors, all we'll have left with is the bad-faith editors—and that will mean the end.

The solution to all our problems is to gain more good-faith editors. These new editors will provide our new content. They will be the ones that protect us from the bad guys. They will be the ones that bring our articles up to FA status.

This is why the editor retention issue is so important to me and the many others that believe in this project. So I want to thank the developers and the WMF staff, very kindly, and from the bottom of my heart. I means a great deal to me and many others that all of you are working on this issue and trying to find a solution. Thank you all very much. I really appreciate what you are doing here and I hope you'll share my thanks with all the others that are helping in this area so they'll know that we care. We care enough to share our heart-felt thanks for your generous efforts. Best regards. - Hydroxonium (T•C•V) 05:37, 29 September 2011 (UTC)

I. . . don't know what to say, except "thank you."--Jorm (WMF) 05:57, 29 September 2011 (UTC)

Hydrox, what is your greatest concern: the lack of responsible, new users coming on board, or the good, experienced users who are jumping ship? I would be particularly interested to know what suggestions you might have for either the improvement of NPP as a system and/or the control of the new pages that arrive that are wholly, and uncontroversially, not fit for inclusion in any way. Jorm is especially (but not only) very interested in suggestions for improving the new page creation work flow. and making it a much improved experience for serious new users. Thanks. --Kudpung 03:55, 3 October 2011 (UTC)

My greatest concern is the lack of responsible, new users coming on board. There will always be a subset of experienced users that leave for normal valid reasons (i.e. real life obligations, getting bored with the project, etc.) and we need to replace them. I am also concerned about experienced users leaving because of problems with the project or other users and we should do something about that also.

In general, the world views Wikpedia as a great resource, but they view Wikipedians as hostile. The media reports about Wikipedia always criticize us for treating them negatively. They don't understand our processes and that we're trying to improve our quality. But do they need to? We are a big project, and the perception that people have of us is our problem. We can't expect people to understand our internal processes before making their first impression of us. I would like the rest of the world to view Wikipedians as warm, helpful and inviting. I believe it would be to our benefit to tweak our internal processes in a way that makes the world view us as positive rather than negative. I think that this Article creation workflow project will help.

I'm not really competent to make suggestions for improving NPP or the zoom interface, so I'll let others do that. Best regards. - Hydroxonium (T•C•V) 10:48, 9 October 2011 (UTC)

Thank you very much for this reply Hydrox. I think we all (us at Wikipedia, and the team at WMF) echo your views entirely. The issues have to be addressed internally from the software side, and I"m sure that the WMF are doing their best with public relations. We're already working on possible interface solutions to improve the landing pad for new users, and doing some crowdsourcing to improve NPP. --Kudpung 11:41, 9 October 2011 (UTC)

Screen mock ups

I really like these screen mock ups. By coincidence or design, they are a pleasant, graphical presentation of the solutions I proposed for ACTRIAL in order to channel new users to 1) the Wizard, 2) AfC, 3) making a draft article in user space

The idea being that their new article could be fast tracked by a reviewer instead of needing to wait the full 4 days and 10 edits to be autoconfirmed. However, in the absence of the article creation limitations as put forth in ACTRIAl, perhaps instead of these screenshots loading only when someone searches fro a non exsitent article, they should be presented to any non-autoconfirmed user who tries to open an edit window. This would eventually function as a first deterrent to the vandals and to the creators of uncontroversially unwanted pages that would qualify for speedy deletion. In simple terms, the desired reaction from the adolescent pranksters and spammers would be "Uh oh, I'm gonna be wasting my time here by posting crap!"

The screen mockups should therefore add to the "I want to..." list, a button for "...edit an article".
--Kudpung 06:45, 30 September 2011 (UTC)

My major problem with workflow while editing Wikipedia

I'm used to HTLM and some LaTeX document preparation. However, despite generally having simple syntax, the workflow of editing Wikipedia is considerably more obnoxious for one simple reason: instead of being able to have the source and rendered document side by side, which is easily arranged with HTML or LaTeX editors, in Wikipedia the preview region is way above the editing box. Once you hit preview and see that something is not as you intended, you have to memorize what is wrong, and find the offending code in the edit window while scrolling down, which removes the preview from sight. After making a change, you have to scroll back up again, or at least hitting preview does that, which again removes the relevant code region from sight. This back-and-forth gets tedious fast. Have mörser, will travel 19:35, 13 October 2011 (UTC)

FWIW, I have never found that to be a problem. Pages that are longer than a stub will have plenty of L2 and L3 headers, and can be very easily be edited by section only. --Kudpung 03:20, 14 October 2011 (UTC)

Side-by-side displays are also inaccurate for layout if any images, tables, or similar objects are involved. WhatamIdoing 14:57, 14 October 2011 (UTC)

Side-by-side display could be made possible and accurate; it's quite a simple fix but I think it's a solution looking for a problem. I use side-by-side all the time when working on Wikipedia, and it does not need a software implementation to the Wiki UI.--Kudpung 01:23, 30 October 2011 (UTC)

More G11 checks?

Are there any that check to see how many first-person pronouns are used in the article? →Στc. 08:59, 16 October 2011 (UTC)

Probably best if you repost this question on the English Wikipedia. w:User talk:WereSpielChequers uses a script for finding certain words in all pages of the encyclopedia. The problem with this though, is that there are tens of thousands of instances of w:Direct speech on pages. --Kudpung 09:10, 16 October 2011 (UTC)

Perhaps some sort of en:WP:Edit filter could be constructed to flag pages that are relatively new and contain such words. WhatamIdoing 16:56, 16 October 2011 (UTC)

See filter #354, but it only applies in userspace. MER-C 03:52, 20 October 2011 (UTC)

Sadly this filter is private. (Oh by the way: why?) So since there is already a filter, this should/can be easily expanded. Mabdul 13:36, 29 October 2011 (UTC)

I can't see any particularly good reason why it is private; it just looks for various words/phrases that might commonly appear on a spammy user/talk. I've asked in en:Wikipedia talk:Edit filter#354 Promotional text added by user to own user(-talk) page - Why private. Chzz 10:31, 30 October 2011 (UTC)

Regarding the private - Spammers earn money with spamming their site (or their SEOs get paid for it). It is private per en:WP:BEANS - spammers don't need to see which terms they need to avoid, especially since spammers are the ones who are more prone to actually try and avoid such terms.

Regarding the filter, one could easily write such a filter as what you suggest here - make a ratio of 'first-person pronouns' : 'size of page / total number of words', and make it trip on such. Is indeed similar to what 354 does, but not totally the same. If you need the code of 354, feel free to ask. --Beetstra 08:33, 31 October 2011 (UTC)

My impression from the recent AfC backlog

Basically, any form of review under the pressure of "let's eliminate the backlog" is going to be significantly affected by human error in that both unfit articles were accepted and in that okay articles with minor formatting errors being rejected. I don't see much reduction in BITE that way. The interface presented to the reviewers, quite different at AfC from NPP, matters little. Have mörser, will travel 10:02, 22 October 2011 (UTC)

Agreed. The fundamental difference in attitude at AFC -- or any other space which is outside the mainspace and is meant to be a safe haven for developing articles -- is that there is no deadline. That way there is no rush to approve things not ready, and no rush to decline things which are imperfect. I am very concerned that AFC is currently trending towards the speedy side of things; I've seen article declined within on hours, even though with some Googling one could see the subject was legitimate enough to let someone develop something in draft form. Steven Walling (WMF) • talk 04:54, 23 October 2011 (UTC)

I have already asked Snottywong earlier today if he can provided some stats and a graph to give a clearer overview of of latest trends in AfC. A brief look seemed to show me that there has been a dramatic rise in the last two months in the number of submissions to AfC. --Kudpung 07:21, 23 October 2011 (UTC)

What I asked for was, over the last there months

• Number of articles submitted over this period
• Number of articles accepted over this period
• Number of articles declined over this period
• Monthly backlogs over this period

--Kudpung 07:51, 23 October 2011 (UTC)

That's useful to have stats, but I think the point here is that there should be no concept of a time-based backlog in AfC. Submissions are not time sensitive, and pressuring the community to treat AFC as if it were like NPP is the wrong approach. Steven Walling (WMF) • talk 20:49, 23 October 2011 (UTC)

I think you may have misread this Steve. It's no way intended to put put anyone under stress to do more - the last thing we want is for people to be doing hurried, sub-standard work. We must not lose sight of the fact that Wikipedia is run locally by volunteers and stress should not come into it, if it did we would be driving dedicated editors away fast. This is for statistical purposes only to demonstrate the extra capacity that would be needed in AfC and NPP personnel. Snottywong already has a bot on trial that summarily declines pages at AfC based on their content; I'm sure he has made this based on the sudden and dramatic increase in submissions The failure to realise and understand the empirical findings was the reason the ACTRIAL was refused by people who have little or no overview of the work that is required patrolling new pages, and the admins who see the pages that have to be deleted - it seems clear that that WMF prefers stats for everything over empirical reports from those who do the work, so we're preempting by providing stats. The actual trial, whether or not the proposal would have been finally adopted or not, would have provided us with some of these essential stats. Any new solutions are going to increase the number of articles submitted through AfC, the Wizard, or user page drafts. Bearing in mind the current serious issue with IEP and its imminent extension, we need to be geared up for this and accelerate development of the Zoom and Article Creation Flow. Our NPP survey goes live this week, and we'll have some more stats to play with. --Kudpung 02:02, 24 October 2011 (UTC)

Random example of BITE instead of help [1]. I can produce more if needed, but the idea is clear I think. Have mörser, will travel 06:22, 24 October 2011 (UTC)

Also, perhaps an example of MEGABITE is making people go through the motions of adding inline refs for stuff that doesn't belong in Wikipedia. [2]. It was sent to AfD right after a subject-matter knowledgeable editor read it. Have mörser, will travel 06:58, 24 October 2011 (UTC)

There's a also a strange repetition of improper tagging with {{linkrot}} for AfC articles. I think there's something in the Wizard that adds the URLs explicitly next to the names and titles. Reviewers probably use some script that auto-tags those, even when additional info for the citation like author/title is present. Have mörser, will travel 07:47, 24 October 2011 (UTC)

I strongly oppose Snotbot by the way. No small number of AfC reviewers already act like near-bots. Have mörser, will travel 06:45, 24 October 2011 (UTC)

The first example is not just bitey, but suggests that someone's brain was out to lunch (which, to be fair, if you do enough work, is exactly the kind of mistake you have to expect on occasion). I've pinged two of those editors about their mistakes at en:Puppet Show, and hope that we will become enlightened about their thought processes before long. WhatamIdoing 15:37, 24 October 2011 (UTC)

The first example was me; mea culpa. I fucked up. I processed over 300 AFC's (clearing the backlog), and I got a couple wrong. Chzz 12:11, 26 October 2011 (UTC)

We had another ~200 article backup today that was cleared extremely fast. I've yet to look at any of those, but this caught my eye when it was resubmitted. Please note that the newbie numbered the refs and used paranthetical referencing; an entirely appropriate method per WP:V, if somewhat not chic. [FYI, I changed my user name; I'm "Have mörser, will travel" above.] ʔ 21:17, 26 October 2011 (UTC)

Well, that wasn't me, 'coz I'm scared to make mistakes now. Which might be a bit sad.

BTW, the username "?" is just silly, and will cause all kinds of problems with links. Chzz 03:06, 27 October 2011 (UTC)

Yes, I know it wasn't you; I just posted it here because it fits the topic, which is not "bash Chzz", or at least I never intended it to be that. As for my new user name, you're the 4th person to tell me that, so I've asked to be renamed away from this one. ʔ 06:51, 27 October 2011 (UTC)

This other editor's confusion about the use of inline citations other than ref tags is not unusual and not confined to AFC. I've politely smacked the editor for the silly claim that the lack of wikilinks made the article unencyclopedic. I think I'll take a look at the AFC directions and see whether it is possible for a greater level of clarity to be provided to reviewers. WhatamIdoing 15:57, 27 October 2011 (UTC)

Who do you think reads those instructions anyway? Certainly not happy sailors. [3] ʔ 20:45, 27 October 2011 (UTC)

Improved documentation never has an immediate effect, but in the long-term, it is usually very effective. We like to say that en:WP:Nobody reads the directions, but usually people getting involved in a new (to them) process read the directions—once, before their first-ever participation, and as far as they're concerned, those are the rules forever. Also, it gives us something to point folks at when we encounter good-faith mistakes. Given the turnover of editors, that means that in several months, many of them will be avoiding this mistake (and doubtless inventing new and more creative ones). WhatamIdoing 16:04, 28 October 2011 (UTC)

Also, to be fair, it's a valid decline, because the article names zero third-party sources. The message about declining it simply adds some unnecessary advice about reference formatting. WhatamIdoing 16:15, 28 October 2011 (UTC)

For the LOL, [4] was AfC-accepted, but it now looks like that after someone from w:WP:PHYSICS looked at it. Of course, it's difficult to have subject-matter experts on everything at AfC, so some fish just need to be let swim with the big sharks. ʔ 17:26, 27 October 2011 (UTC)

And book that scores 80K Google Books hits on a search for its title is non-notable [5], despite having a (poorly formatted) reception section fully compliant with WP:V. ʔ 09:10, 28 October 2011 (UTC)

I can't help but notice that many of these errors have been made by editor who aren't admins yet, but seem to be striving for that bit given the near-admin tools they display on their user pages: roolback, reviewer, etc. I vaguely recall that someone (from the WMF?) wrote that reviewing new pages is a way to "make admin faster". ʔ 09:14, 28 October 2011 (UTC)

(edit conflicted with the above...)

In an ideal world, the reviewer would - when appropriate† - post on the talk of a related wiki-project and ask for help.

†ie, when it needs 'expert' input but looks likely to be a viable article.

Again, it comes back to the problem that anyone can review AFC's^{I just saw an example; [6]} - and there are not enough good reviewers.

The whole enwiki focus needs to shift from the 'warn/block/csd' (MMPORPG) mentality, and towards helping users create content with friendly assistance. That's why I fully supported en:WP:ACTRIAL - it has to happen, and the sooner the better. Unfortunately, the more naive view (that restricting creation will make us lose editors) resulted in WMF overriding that consensus.

Yes, the interface needs improving - and it'll be great if/when that happens - but, such things take a long time and need to develop appropriately; meanwhile, every day, we lose more editors because they get their heads bitten off. Chzz 09:20, 28 October 2011 (UTC)

If I understand correctly what ACTRIAL is about, it's proposing to force all newbies to go through an AfC-like process. But as it's currently structured, although it doesn't lead to immediate deletion, the process can actually be more BITE-y. A newbie reviewer (in the extreme case a w:WP:RANDY) can single-handedly prevent a good article for entering main article space, unless the author is persistent and resubmits. At least for the CSD, an admin has to review the rejection before it becomes effective. ʔ 09:49, 28 October 2011 (UTC)

(Also, the reviewer you mentioned, Sefishalem, w:en:Special:Contributions/Sefishalem, seems to be involved in the promotion of those organizations.) ʔ 10:51, 28 October 2011 (UTC)

(Edit confliced; I wrote this reply before you added the 'Also' thing...)

I really don't want to get into that discussion again, simply because we've already debated it at great length, and the community consensus was that we should try it. I will comment very briefly though:

Both statistical and empirical evidence suggests that AFC-style 'rejection' through a 'decline' - which has the clear indications that the user may improve the article and resubmit at any time - are not as likely to deter editors than CSD of their first creation. AFC process does need to improve, but this is a chicken-and-egg thing; if WMF honoured the consensus shown, then AFC would be able to improve - it'd have much wider community attention, plus the NPP-workload would be vastly reduced, freeing up resources to help instead of scold. Chzz 10:55, 28 October 2011 (UTC)

P.S. You may find this interesting; I wrote that back in Feb. Chzz 11:04, 28 October 2011 (UTC)

P.P.S. Plenty of admins single-handedly delete articles; often, they make mistakes; when that happens, we non-admins can't even see them. At least when there are mistakes in AFC, they can be seen and fixed. Chzz 11:07, 28 October 2011 (UTC)

AfC vs "just write in mainspace"

Here's my opinion on this matter

• AfC pros:
  • Failed submission does not lead automatically to deletion like CSD/AfD.
  • Incremental feedback is given to some editors.
• AfC cons:
  • A single reviewer can fail an article, deletion processes typically require 2+ people to agree; it's unclear how many worthwhile articles are rejected because of this AfC loophole. Statistics are needed on the quality of the rejected submissions, but producing these is manpower intensive [re-review required], so no systematic data seems to exist. How many resubmission lead to acceptance because of substantive draft improvements vs. simply running into another reviewer is also unknown.
  • Reviewers sometimes reject a submission because of formatting issues rather than core policies.
  • Automated advice given to authors is focused on REFB tagging; this seems part of the AfC reviewer culture where submissions formatted in other ways are rejected almost automatically by some.
  • Much more limited supply of reviewers than in mainspace and often lacking subject-matter specialists; original research goes through if peppered with enough citations, as does other stuff with primary sources where the affiliations are less obvious.
  • A few articles still get prodded or sent to AfD right after they are AfC-accepted. Ecstasy and agony I suppose.

— ʔ 12:34, 28 October 2011 (UTC)

I do not agree. However, all these issues have already been extensively discussed in Proposal to require autoconfirmed status in order to create articles, /Trial duration, and Autoconfirmed article creation trial, so I do not see a benefit in reiterating the conclusions of the community here. Chzz 14:11, 28 October 2011 (UTC)

With everything I wrote or just some of the points? See for example w:User talk:Amienutter and (accept on 4th attempt) for another example of the last point. [I had my account renamed again, by the way.] ASCIIn2Bme 15:18, 29 October 2011 (UTC)

Arbitrary break

Let's not re- debate ACTRIAL here, instead let's keep this talk page for discussion on development of the software it belongs too. FWIW however, and so that everyone understands:

• ACTRIAL will not happen - the possibility was unambiguously ruled out by the WMF although clear consensus was reached by a Wikipedia discussion with around 500 particicpants.
• Declining ACTRIAL in this way has alienated dedicated users from Wikipedia. Furthermore, it has denied the WMF access to the very data they rely on, apparently largely in preference to the substantial empirical findings of the experienced volunteers.
• The extreme lack of sensitivity, maturity, and experience demonstrated by many of those who patrol new pages are counter productive to the WMF policy of user retention. By the same token, it also allows unwanted and often toxic pages to slip through unnoticed.
• There is always a risk that solutions proposed and developed by the WMF may be declined by the community. While hundreds of hours of volunteer time went into the research and preparation for ACTRIAL it was a waste of their good will, good faith, and dedication.
• A refusal by the community to adopt any solutions proposed by the WMF would be a serious waste of money - much of the financial resources are provided by the small amounts donated by the tens of thousands of volunteers themselves (and I've been, told that the WMF operates on a shoe-string), not to mention the private purchases by volunteers of books and software to help them with their work on Wikipedia, and their time and expense involved in attending real-life meetings or on live off-Wiki discussions
• The WMF may be staffed by experts in their professional domain, but they do not appear to have a cogent approach to working with large volunteer communities, and they do not have an in-depth, hands-on understanding of many of the processes on the 'factory floor'.
• There are discussions on WM talk pages by WMF staff that clearly demonstrate that they tend to forget (in good faith) that the community, unlike the employees at Google or Microsoft, are volunteers and will not, and do not have to take orders from the WMF. The staff can only ask the community if it would be prepared to do certain local tasks on their various language Wiki such as the policing of new articles and spending time editing and improving worthless pages for inclusion, especially the cleaning up of the considerable mess created by ill conceived and poorly prepared Global Education initiatives, that were devised with little participation of the experienced members of the volunteer community.
• Discussions on developments of this kind are carried out here at MediaWiki rather than on local Wikis in order to avoid unnecessary background noise. Unfortunately, some people who find links to these pages, simply offer empty comments, or begin threads that are best discussed in the relevant pages of their local Wikipedia.
• The Article Creation Workflow interface although an inefficient substitute for ACTRIAL, will not 'force' new pages to be reviewed by by others before going live. It will however present a few extra steps to new, new article creators before they reach the live editing window. As a result of this, there might be an increase in the number of new articles being submitted to AfC, and there might be a reduction in the work load for new page patrollers, and it might, just might, be a deterrent to the creators of the crap that constitutes 80% of the daily intake of new 'pages'.

There still remain the essential tasks of patrolling new pages as soon as they arrive in order to delete very quickly and uncontentiously the new pages that are uncontroversially toxic (SEO & spam, copyvio, attack, test, vandalism and nonsense). For this, experienced users are required, and not a transient team of patrollers that traditionally appears to be comprised largely of the least experienced users of whom many are newbies themselves. Therefore it is essential to develop the Zoom control panel parallel to Article Creation Flow, and (I'm expressing an opinion here) make NPP a user right and ensure that those who do it can demonstrate an adequate knowledge of deletion policy, and are prepared to undertake the small but essential minor editing tasks recommended by en:WP:NPP rather than treat page patrolling as a race for rewards.

Bottom line

Other solutions are still months ahead, little development has taken place for over a month, and even these talk pages are beginning to stagnate, or attract nonconstructive and/or off-topic distraction. Nevertheless,I fully support the new software proposals made by the WMF and although I was a major researcher and proponent of ACTRIAL and extremely taken aback and disappointed by the way it was received by the staff, I am wholly committed to working closely with them to achieve those goals in some way or another. We all have to learn to collaborate effectively and objectively if Wikipedia is to survive, and repair its flagging reputation for being a major contribution to the needs of society in the 21st century. If we can't do this, there is no point in any of us being here, whether salaried staff or volunteers. TL;DR for some , I know, and 'nuff said. --Kudpung 03:34, 30 October 2011 (UTC)

I'm not re-debating any would be trial, but you apparently are. You once described a much shorter frustrated post by a relative newbie as a "spammy soapboxing rant". [7] I wonder how your post above should be measured by that standard. I just offered my opinion on the strengths and weaknesses of two approaches, approaches which could surely be combined in some ways to benefit from the strengths of both. Anyway, it looks like someone needs to subscribe this page to the wikilove auto-dispenser and enable the sour grapes inhibitor. I'm outta here. Good luck with your future endeavors. ASCIIn2Bme 11:59, 30 October 2011 (UTC)

ASCIIn2Bme, please read the above post of mine again, try to be accurate in your comments, adopt some good faith, and be extremely careful of whom you accuse of things. If you have an account at Wikipedia I will be leaving a message there which I hope you will take in the good faith with which it is intended. --Kudpung 13:04, 30 October 2011 (UTC)

Like you promising to have me "investigated" and blocked [8] because I dare not sing to your autotune, and because I have expressed a few ideas of my own here? That's wikilove indeed. ASCIIn2Bme 13:40, 30 October 2011 (UTC)

Perhaps you shouldn't misrepresent what people are saying; what Kudpung actually said was that, if he found evidence that you abused multiple accounts, he would send it to an SPI. I've my own opinion on that, but I won't state it here. The Blade of the Northern Lights (話して下さい) 21:32, 4 November 2011 (UTC)

Probably an insightful example of a newbie writing a first article

Look at the edit history of w:Journal of Personal Selling & Sales Management. Insightful because he/she saved almost after every change. I've always been puzzled why some people have little ability to learn by analogy, i.e. by looking at the code and structure of another article in this case. Although he/she eventually figured out what needs to go in the article to have it approved (indexing information as this a journal) and what to remove (promotional language; the claim that the journal was leading in its field is rather exaggerated; it's more like middle of the pack c.f. [9]), some formatting was still not quite right even after a few days of editing. ASCIIn2Bme 20:01, 29 October 2011 (UTC)

Please see the above post. --Kudpung 03:39, 30 October 2011 (UTC)

There are some articles we should discourage

Many good-faith editors arrive at Wikipedia wanting to create an article which, for one reason or another, is never going to be acceptable, because they have not understood, and we have not explained, what Wikipedia is not for. There are those who think this is Myspace and want to write about themselves or their friends or their garage bands, those who think it is LinkedIn and want to post their CV, and those who think it is a free advertising service and want to boost their companies.

It is not really friendly to let these people go to all the trouble of creating an article which is inevitably going to be deleted. As an admin on en:wp I spend a lot of time dealing with people like this: some are indignant, but many are apologetic and I often find myself saying "Don't apologise, it is not your fault, WP is so keen to encourage contributors that it does not do a good job of explaining what it is not for."

Ideally, some explanation of what Wikipedia is NOT for should be provided during the account creation process. Failing that, can we put something brief on the landing page? I suggest something on the lines of:

"If you have come here to write about yourself, your friends, your band, your company, or anything with which you are closely connected, Wikipedia is probably not the right place for you. Before proceeding, please read the guidelines on Conflict of Interest and Notability."

JohnCD 18:02, 19 November 2011 (UTC)

That is an excellent idea. In fact a quick solution is very easy: any admin can edit the user interface and could include that on the editing window where it says:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable.

--Kudpung 03:03, 20 November 2011 (UTC)

I think it would be wrong to have too much below the edit window (and I'm not sure anyone reads what is there now). I gathered from the discussion further up that a "landing page" is proposed which people, particularly new users, would go through on the way to starting an article, and I hoped this message could be put there, as it is particularly addressed to people about to start an article and might get their attention there. JohnCD 16:48, 20 November 2011 (UTC)

There is a mock-up of the proposed new landing page on the main page of this talk page.--Kudpung 16:58, 20 November 2011 (UTC)

Hmm. I guess it would have to go at the bottom of the page, below the "Alternatively, you can request... " paragraph. It wouldn't fit in the "I know that" box. If it's felt that would clutter the page up, perhaps it could go on the "Educational content" page you would get to by clicking "Create this article myself." On the Article Wizard route, the point is made on en:Wikipedia:Article wizard/Subject.

This doesn't seem to be a very high-traffic page - do others watch it? is it the right place to make this suggestion? JohnCD 22:21, 22 November 2011 (UTC)

Tick tock

Well, we're about 4 1/2 months removed from the last comment at bug 30208, and, quite unsurprisingly, nothing has changed. I don't know how much longer we're expected to put up with the status quo, but my patience, which was wearing thin in September, is extremely low now. Though it's quite obvious what I'm still gunning for, I'm not looking to resurrect that here. Instead, I'd like to know when we're going to see anything implemented. It seems like there have been enormous amounts of kilobytes and man-hours expended upon this with no material result, and at en.wiki the pages keep on coming. At this point, I don't really care what is to be implemented, just that something is so we can see how, if at all, it affects the goings-on. The Blade of the Northern Lights (話して下さい) 01:10, 31 December 2011 (UTC)

I'm sure there will be something done by the end of January - just don't know if it's Jan 2022 or Jan 2032! — Preceding unsigned comment added by 31.52.204.31 (talk • contribs) 00:57, 5 January 2012

Comments from the WMF sugest that development of this and the NPP Triage have been shelved in favour of development of the AFT which is part of the Foundation's philosophy and drive to recruit more editors . The paradox is that we will still be left without sufficient mechanisms to address the new pages such a campaign will produce. --Kudpung 01:43, 14 January 2012 (UTC)

Hi Kudpung -- no, this is categorically untrue. AFTv5 is being developed with an outside vendor. The WMF-internal editor retention/engagement team (which is tackling the higher priority projects) is a) currently wrapping up the last round of work on the feedback dashboard, b) going to approach full bench strength in February (with Kaldari and Ian Baker joining the team full-time). So we'll get serious about NPP/article creation very soon (late Jan/early Feb).--Eloquence 02:59, 14 January 2012 (UTC)

Thanks for the update. I'm sorry if I had misunderstood - must have misread something somewhere. I'm still very eager to work on this together with whoever is allocated to the development. Kudpung 07:19, 14 January 2012 (UTC)

Likewise. Just about anything would be helpful. The Blade of the Northern Lights (話して下さい) 18:31, 16 January 2012 (UTC)

I remember now where I heard that the AFT bzw. the feedback dasboard had caused the delay. it was when someone had asked somebody about progress on the NPP Survey. Let's hope both projects move forward soon before the deluge from the next IEP and the USEP. I would like to do the video tutorial for NPP. and help out with the next IEP.--Kudpung 11:55, 17 January 2012 (UTC)

I thought the same a few minutes ago: "What happened to our ACTRAIL alternative?" and all what I'm seeing is: nothing... mabdul 12:09, 20 January 2012 (UTC)

The trial was always contingent upon the WMF supporting it (because only the WMF staff could have enabled some of the necessary changes to the system), and they did not support it. WhatamIdoing 20:48, 21 January 2012 (UTC)

All I know is that I'm rapidly approaching getting a carpal tunnel in my left index finger from having to hit the "delete" button. If there's anything I can do to push this along, I'd be happy to, though my computer skills are basically none; I'm basically only good for being a lab rat from an admin/non-admin perspective. The Blade of the Northern Lights (話して下さい) 19:41, 22 January 2012 (UTC)

Article titles

Too many new articles are created with incorrect use of case. There needs to be some step introduced to check the case of the title in comparison with the case used in the article. For example a user searches for a topic (and who bothers with the case when they're searching) such as "george bernard shaw", and is given the chance to create a new article on this topic. They'll happily create a decent article with correct use of case, starting "George Bernard Shaw...." which the software will save with the title of "George bernard shaw". Couldn't this be caught by comparison of title to the first line of text? Or offer the user the option to fix the title before creation, something a little more than just "Save"?

This is made more annoying since it could be easily be fixed at NPP by a move without redirect, but this is restricted to admins and global rollbackers (and I'm not going to get active on other wikis just to pick up global rollbacker privileges). So as a non-admin I move the page, raise a csd on the redir, and wait for an admin to act on the csd (or more infuriatingly give a load of bs about "redirects are cheap") - triple the workload.

As a consequence of the unnecessary extra work I've largely avoided fixing article titles on NPP. Admins can do the work in one step, why would I want to do 2 pointless steps before that? Bazj (talk) 20:07, 5 March 2012 (UTC)

This strikes me not simply as a fault in our article creation but our title setup as well. Why does "George bernard shaw" not lead to the same page as "George Bernard Shaw" when it clearly should? And why is a redirect so distasteful when a good redirect points titles that are clear mistakes to the proper title and clearly someone has already made that mistake. Daniel Friesen (Dantman) (talk) 21:37, 5 March 2012 (UTC)

Bazj, are you aware that deleting the redirect doesn't really delete it from the database? It just makes it invisible to readers. You're not really accomplishing anything by tagging the redirect for deletion. I'd just ignore it. WhatamIdoing (talk) 19:08, 6 March 2012 (UTC)

I am aware of that, yes. I trust you're aware wikipedia isn't a quiet little back-water of the internet. Its pages are propagated into clones and other derivative works. Its pages are often top result for google searches.

Redirects aren't just search pointers, they're articles (of a sort) in their own right, and they propagate out into the wiki clones and the wider internet. A couple of years ago I worked on "Sparrows Herne turnpike" which has a typo redir from the ..Hearne.. misspelling, about 80-90% of the results on google for the mis-spelt version traced back to the wiki redir via wiki-clones and derivative sites, in many cases appearing to present the typo as a correct version.

As you say, I'd just ignore it. Unfortunately the wider net doesn't.

The redirects we're talking about would also fall squarely under CSD R3.

I'd also disagree with the characterisation "someone has already made that mistake". When you know the search engine is case insensitive, why waste the effort in correctly using upper/lower case? It's the wiki software that freezes the search term into an article name. It's the wiki software that makes the mistake. Bazj (talk) 19:20, 6 March 2012 (UTC)

Redirects being treated as canonical content inside of searches and 3rd party systems is not something for article creation changes to fix. That is trying to fix a technical issue by implementing a social fix for it. Technical issues like that should be fixed with a proper technical solution for it. In this case the primary thing we need to fix is canonicalization. At the most basic level we don't even have proper rel=canonical links. Implementing things like that will start to fix cases where content is associated with the wrong url. Daniel Friesen (Dantman) (talk) 03:44, 7 March 2012 (UTC)

• Redirects being treated as canonical content... agreed. I was pointing out why redirects are not without consequence in response to WhatamIdoing's point, not arguing for a social fix.
• we need to fix ... canonicalization.... Um, I've no desire to make anything church law? If you mean capitalisation, yes, I wholeheartedly agree.
• proper rel=canonical links, what are they? Bazj (talk) 10:03, 7 March 2012 (UTC)

• Search engines are case-insensitive, so deleting a case-specific redirect has no effect on them.
• See http://catb.org/jargon/html/C/canonical.html for the definition of canonical. WhatamIdoing (talk) 17:44, 7 March 2012 (UTC)

I don't mean fixing capitalization or anything to do with churches, I mean what I said, canonicalization. See Wikipedia:Canonicalization. Or more specifically Wikipedia:URL normalization.

I'm talking about <link rel="canonical" href="...">. It's a standard bit of metadata pages can have. Say we have https://en.wikipedia.org/wiki/Redirection and https://en.wikipedia.org/wiki/Redirect both of these are the same page. If we put a rel="canonical" on Redirection which points to Redirect this tells search engines, Facebook, etc... anyone who looks at the page and reads the canonical link that both Redirection and Redirect are the same page and Redirect is the canonical form.

In search engines this will have the effect of removing duplication and making the search engine index the page under the url we want it to be indexed by. All those links pointing to the misspelled redirect would now instead point their pagerank towards the proper canonical url and search engines will stop using the misspelled url.

Hence I'm saying that if we fix the real issue (broken rel=canonical support) we're back to redirects not having substance. Daniel Friesen (Dantman) (talk) 18:51, 7 March 2012 (UTC)

Do you know if there is any open request about this on bugzilla:?

What I found was bugzilla:18883#c10, where Krinkle says "MediaWiki already usees the meta link rel="canonical" tag to identify 'duplicate' pages by URL.". Helder 20:11, 7 March 2012 (UTC)

I remember multiple bug reports on the subject. We have bug 25882 for applying rel=canonical to all pages. However I cannot find the original bug asking for the inclusion of rel=canonical on redirects. So I filed bug 35022 for fixing the broken implementation. Daniel Friesen (Dantman) (talk) 21:39, 7 March 2012 (UTC)

I wonder whether it could be handled by a template like en:Template:R from other capitalisation. WhatamIdoing (talk) 19:12, 8 March 2012 (UTC)

Messages for new-article creators

An RfC is currently taking place at the en.Wiki Village Pump here.

Users interested in new-article/new user retention are invited to join the discussion.

--Kudpung (talk) 02:20, 2 August 2012 (UTC)

Notes on a landing page implementation

"redlink" is both a presentation style (the redness is actually triggered by "class=new"), and an additional parameter accompanying &action=edit. The redlink query parameter does not have much effect in EditPage.php, it just alters some page handling e.g. disables redirects.

There are some opportunities to put up relevant messages in EditPage.php:

• Links can supply an editintro query parameter to to EditPage, it is some page title that gets transcluded in showCustomIntro(). A contrived example: https://en.wikipedia.org/w/index.php?title=NoSuchPage&action=edit&editintro=Cleanova (I had trouble specifying a message from the MediaWiki namespace.)
• If editintro isn't set, user sees either newarticletext (on en-wiki this is a complicated template with much instruction) or newarticletextanon above the editing UI.
• EditPage calls hooks 'EditPage::showEditForm:initial' and 'EditPage::showEditForm:fields' before the editing UI.

All of these provide additions to the edit page. To interpose a landing page before editing, one of these would have to hide the edit UI using JavaScript.

Another approach might be to change URLs of missing pages. Linker.php detects if a link is broken and changes it to &action=edit&redlink=1. After doing so link() runs the hook 'LinkEnd', so an extension could change the broken link to Special:ArticleCreationLandingPage?title=Page_title — Preceding unsigned comment added by S Page (WMF) (talk • contribs) 01:35, 9 October 2012

&redlink=1's function is twofold. It's both handling to say "If I don't have permission to edit this page, show me the page itself instead of a view source page." but also handling to say "If someone already created the page before I saw the link show me the page instead of an edit form.". So replacing redlinks with urls to a creation page may not be the best thing to do. Daniel Friesen (Dantman) (talk) 01:55, 9 October 2012 (UTC)