Talk:Page Curation/2011

Comment

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

<pre>[17:25] SigmaWP Ironholds: Will CSDing a page with your proposed NPP interface automatically notify the author? [17:25] SigmaWP Oops tabfail [17:25] SigmaWP jorm: ^ <irrelevant material /> [17:25] jorm I don't see why it can't, SigmaWP. we have the information. [17:26] SigmaWP Excellent! [17:26] SigmaWP This will make TW obsolete! [17:26] jorm Once we're using native code, everything is doable. [17:26] jorm Hey, can you add that as a comment on the talk page? [17:26] SigmaWP Right

Σ 00:35, 20 September 2011 (UTC) 00:42, 20 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Idea Log

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Just a place for me to store ideas for now. Ignore or comment.

• Automatically add a personal log entry to a specified section in the Patroller's user space
• Show who is reviewing an article specifically
• Show current session counts (e.g., articles patrolled, number of users welcomed, etc.)
• Automatically skip articles that are currently being patrolled Jorm (WMF) 00:43, 20 September 2011 (UTC)

Another frequent problem is that articles are often tagged for speedy deletion within minutes of creation. Special:NewPages specifically instructs patrollers not to speedy delete A1 (no context) or A3 (no content) within minutes of creation, but this instruction is often ignored and contributes significantly to biting the noobs. Perhaps it would possible to implement something that would check how old the article is and not give options for certain speedy deletion criteria if the article is extremely new? Snottywong 00:55, 20 September 2011 (UTC)

I'm loving that idea - and it leads to a "teaching" moment thing - but it requires additional artificial intelligence (which I want to include).

Not obvious, however, is the fact that my initial intention is to have this tool start from the back of the queue rather than the front of the queue, so this should be less of a problem naturally. But your point is valid, and one I want to address.

In a perfect world, the system should be able to automatically suggest tags to the user. Jorm (WMF) 00:58, 20 September 2011 (UTC)

Will there be an option to patrol the front of the queue? →Στc. 07:21, 21 September 2011 (UTC)

Yes. It's a visible control in the mock-up; I just haven't gotten around to writing it up yet. Jorm (WMF) 17:16, 21 September 2011 (UTC)

Also: Very glad to see you getting involved with this discussion. Jorm (WMF) 00:59, 20 September 2011 (UTC)

If you can't beat em, join em. Snottywong 22:23, 20 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Initial thoughts

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Thanks for busting this out! Some initial fly-by-the-seat-of-my-pants thoughts and interface nitpicking:

• I understand the idea of "zooming in" is the reason for the previous and next buttons being at the bottom or top, but the previous article button plus the large amount of space given to Article and User areas visually takes up a lot when I first scanned the page. I had a hard time parsing all that at first glance, and thus got "stuck" a bit before moving on to the detailed patrolling actions. Perhaps removing the metadata and just having the buttons would make it less distracting?
• Considering that the stats available suggest people mostly patrol from the front of the queue despite the fact that the documentation strongly suggests you should patrol from the back, I think making the oldest patrolled articles the default should be a priority, though we should include the option to see the most recent ones. The current interface encourages one to patrol articles that may be only minutes or hours old.
• Why are we showing edit section buttons but no main edit button the whole article? It should probably be all or nothing.
• The deletion section should actually say "Nominate for deletion". The language makes a difference especially if we're not restricting the tool to experienced users.
• I'd suggest "and..." instead of "But also". The caps on both lead-in instructions are a lot as well.
• Not that I think it's a bad choice, but what was the reasoning behind making the patrolling and deletion actions menu on the left? I feel like we're used to seeing article content start from the left after the sidebar, and I'm supposed to/naturally want to start reading from the left before my eye moves to the right to take action on the content I've just read.
• Would things like categorizing and page moves happen inside the tool? Or do the arrows indicate I would leave to do so?

Thanks again Brandon Steven Walling (WMF) • talk 00:45, 20 September 2011 (UTC)

Comments, in order:

• Having additional metadata was a strong request from everyone I talked to. Reading over all the NPP pages and how-tos, it seemed also that this was super-desirable. Investigating into the third party tools also showed that this was something that we wanted.
• Yes, I want to start from the back of the queue. The document itself should outline that process better; I'm working on it.
• A very good point. That screen there is really, and truly, a screen cap cut and paste. We'll have to massage it.
• Noted. Fixed in my copy.
• Noted. Fixed in my copy.
• We have most of our actionable "chrome" on the left. I'm not married either way. This interface is very clunky right now and not what I'm actually envisioning in the end.
• Yes, they would. It's not obvious (yet) but those actions will cause flyouts to happen where you add categories and/or rename the page. The arrows indicate that there are sub-menus. Jorm (WMF) 00:56, 20 September 2011 (UTC)

One reason for focussing on the front of the queue is to quickly get rid of the attack pages. Currently this is one of the things NPP does very well, I'm more critical than most about the quality of tagging and the number of incorrect deletions, but I scarcely ever see an incorrect G10 tag. I occasionally see articles tagged as A7 or BLPprod that should be G10 and would have been deleted more quickly if they had been. But G10s at the back of the queue or in mainspace are thankfully rare.

Deleting G10s ASAP is important - some will be being used for cyber-bullying and if so we want them gone before everyone in the school has had the text linking them to the new Wikipedia article about one of the girls in the school being a pornstar or hooker. Shifting our focus from the front to the back of the queue can only be done if we first find an effective way to screen the G10s and ideally some of the G3s out.

A large proportion of the articles that get to the back of the queue are Goodfaith but borderline notability, somewhat spammy or on obscure subjects, the ones that are easy calls either to patrol or to delete are usually dealt with upfront. I'm pretty sure that most of the unpatrolled articles are actually looked at by a patroller at the front of the queue, otherwise we'd see more G10s at the back. So I'd be very uncomfortable encouraging some of our newest patrollers to shift to the back of the queue. WereSpielChequers 19:58, 22 September 2011 (UTC)

It's true that we do need to continue dealing with attack pages quickly, but considering that they're only about 5% of CSD (while A7 and G11 together are about 45%) that's a compelling reason for any new tool to obey the current instructions at WP:NPP and encourage people to start at the back of queue, though naturally there should be an option to switch to the front. Steven Walling (WMF) • talk 20:51, 22 September 2011 (UTC)

Personally I wouldn't lose sleep if we made a change that meant a thousand extra articles at any one time on Myspace bands who will have their first rehearsal next week if they can find a drummer, and bright new upcoming footballers who haven't actually played their first professional game. I really can't see that causing Jeremy Paxman to want to interview someone about that on Newsnight or the Information Commissioner summoning in the chair of Wikimedia UK for a meeting about the precise relationship between the chapter and the Foundation. But a change that meant up to a thousand extra attack pages on the site at any one time - I'd hate to be the person who had to justify that to the press. If we did it knowingly and deliberately I'd be embarrassed to be associated with the project.

The back of the queue often bumps up to the thirty day mark, though with most articles patrolled or deleted in their first few minutes the actual queue is rarely more than 10,000 or so unpatrolled articles. If you could shift the emphasis to the back of the queue and process as many articles a day then in theory you would have an extra 500 attack pages on the site as a result of this change. But the length of the queue oscillates widely as it depends on volunteer numbers - so sometimes it would be much more.

The 5% of new articles that are attack pages currently get deleted so quickly that most people take a while at NPP to realise how common attack pages are, and lots of people who haven't spent time at NPP or cat Speedy would be quite shocked to learn its as high as 5%. WereSpielChequers 21:22, 22 September 2011 (UTC)

There is a danger, or even an irresponsibility in say only 5%. Let's say that most attack pages get deleted fairly quickly. The solution requested by the community at WP:ACTRIAL was not conjured up by a group of exclusionists as was suggested by the WMF at Bugzilla, but from far deeper concerns such as for example, that Sod's Law is that the one attack page that doesn't get quickly deleted is the one that could involve the Foundation in a litigation for millions of dollars. Since the deal was struck with Google to reference Wikipedia pages at the speed of light, this is not good. It's a risk we should neither be taking with donated funds nor with the inconsitency of amature patrolling at such a crucial stage of page creation. It's my guess that most patrollers are fascinated by the live feed in the side bar, and when those ten entries are lost from view, the unpatrolled pages rely on people working directly from special:new pages which as far as I understand has to be constantly manually refreshed.

The immediate problem therefore is not the number of patrollers who are available for work, but those who are totally incompetent to be doing it. Unfortunately there are no bots that can count the number of times I have deleted attack pages that were labelled A7 because the patrollers were not interested in taking time to read past the first sentence of the often long and carefully crafted pieces of libel.

Let's also not forget that there are, or have been times, that the 30 day period has been greatly exceeded, hence the creation of the Snotbot last fall as a desperate measure to get at least something done to track the unpatrolled pages.

These are all reasons why it is most important to listen to what the the mature editors and admins have to say who have had long and involved experience at NPP specifically to research its weaknesses. Kudpung 11:02, 23 September 2011 (UTC)

Working from the back is indeed good advice for actually clearing out the backlog, but it shouldn't be forced on everyone. The wiki benefits from the fact that the advice is not always followed. The front of the queue always contains things that clearly shouldn't be on the wiki. Even if someone intends to work from the back, taking a short look at the front first can be greatly beneficial in keeping out attack pages and other wholly inappropriate content. Reach Out to the Truth 03:05, 23 September 2011 (UTC)

Of course, it seems that the real underlying problem is that we put attack pages which should truly be speedily deleted into the same queue as notability problems or promotional articles at all. We should also be figuring out a way to put the egregious, obvious CSD stuff at the front-and-center of people's attention immediately, but leave time for quality patrolling and editing of articles for things that deserve. Steven Walling (WMF) • talk 21:11, 23 September 2011 (UTC)

Agree. Patrolling for new attack pages should almost fall under vandalism patrolling and recent changes patrolling. It's almost as if there should be two levels of patrolling, one which is done as soon as possible after the article is created just to check that it's not a "dangerous" article (i.e. not an attack page or a copyvio, or otherwise worth of speedy deletion), and then a second level of patrolling to identify issues with articles that actually have a chance of sticking around. Noob patrollers should be more than capable of the first level of patrolling, but we don't want them to hit the "mark this page as patrolled" button when they're done, because they've only checked maybe 10% of the things that should be checked. Snottywong 22:31, 23 September 2011 (UTC)

Two-tier patrolling is not a bad idea for speed, but who is going to do this checking as soon as possible after the article is created? It still does not address the problem that noobs far too often can't tell the difference between G10 attack, G3 hoax, G1 nonsense, A1 no context, and A3 no content. Kudpung 14:29, 24 September 2011 (UTC)

I was going to say, this is assuming most NPPers can actually tell the difference. I watch CAT:CSD and frequently check the articles tagged G1; almost every single time, they're either G3 or G10. I frequently have to tell users to slow down so they can use the right criterion, because many of them try to go faster than they can (I move very quickly, but that's because my reading speed is in the top quarter of the 99th percentile; most people cannot read like that, and make bad mistakes when they try to move too fast). In short, there are only a very few NPPers I'd trust to accurately make the distinctions, and they're a small enough percentage that far too many pages run the risk of being miscategorized. The Blade of the Northern Lights (話して下さい) 22:50, 24 September 2011 (UTC)

Right, so that confirms that we're basically back to square one with this sugestion of two-tier patrolling, i.e. patrolling the patrollers. Kudpung 06:38, 25 September 2011 (UTC)

For an example everyone can view, see the history of The Mad Russian; tagged G1 but a clear G3 (I happened to know a good place to redirect it, but the edit history is there). The Blade of the Northern Lights (話して下さい) 15:37, 25 September 2011 (UTC)

Blade, I'm not sure io this message of yours is complete. Should there be some links to something? Kudpung 09:03, 26 September 2011 (UTC)

Yeah, fixed; not sure what happened. Just type it in on en.wiki, as I can't seem to link things from here. The Blade of the Northern Lights (話して下さい) 13:49, 26 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Tooltips

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Some ideas for the tooltips under each "mark as patrolled but also..." and "mark for deletion because..." entry. In terms of objective readability algorithms, I'm looking at these drafts through SMOG Index; a good one would be between 15 and 16 on the scale (Gunning Fog relies too much on punctuation, which with tooltips could lead to under-estimations). Ironholds 01:09, 20 September 2011 (UTC)

• Change Title: If you have been editing for four days and have made at least ten edits, you can change this page's title. Changing a title should be done where the existing title contains spelling mistakes, problems with the grammar, or is simply incorrect. If you find you cannot change the title, leave a message at the requested moves page and an administrator will do it for you. (Smog Index:15.5) Ironholds 01:06, 20 September 2011 (UTC)

I will use this as the example when I get around to it. Jorm (WMF) 01:09, 20 September 2011 (UTC)

Ironholds' suggestion is important. Patrollers encounter a large number of new pages with poorly spellt, mis-punctuated, or inappropriate page titles. Most new page creators are unaware of the 'move' feature, and their common errorr is to simply create another new page with the correct title.

On en.Wiki there is currently no explanation readily available to new users for moving pages, and the term 'move' is itself confusing. As a very new user, I could neither understand nor figure out whay it is impossible to reedit a pagename, and I made copypaste 'moves' because I did not know any better, and would not have known how or where to look for the instructions.

Although perhaps slightly off-topic in this thread, maybe it could be considered to software-force non autoconfirmed users to use the preview button before they can use the save button. This would also address the very common error of creating the grey boxes that are caused by paragraph indentations. it's actually quite amazing that so many new editors do not review their created pages immediately and make the obvious corrections (actually, paragraph indents are not such an obvious cause). My own opinion is that many of these errors are made by SPA, CIO, and SEO agents in their haste to get their new page online and indexed by Google. More often than not, such pages are anyway destined to be deleted by one process or another.

More instructions of this kind are needed on the edit window page, but will probably adequately addressed in the proposed new Article Creation Flow interface. Kudpung 02:34, 31 October 2011 (UTC)

Another thing I've seen new users often do is create an article, and then copy/paste the article's content to a new title, possibly to create what they think redirects are. →Στc. 06:01, 31 October 2011 (UTC)

Some wikis use a small JavaScript code to force the preview for anons. See e.g.: Manual:Force preview or b:pt:MediaWiki:Common.js/edit.js. Helder 19:16, 7 March 2012 (UTC)

I totally agree with the general point about the readability of tooltips. I hadn't considered an objective readability index for that, and it's a great idea.

Regarding this specific example, it should be fairly trivial to make the tools aware of the patroller's current userrights, and adapt the text accordingly. Also, I believe the patrol status in Special:NewPages isn't available to non-autoconfirmed users. The new tool should mirror that (autoconfirmed required to patrol), so the text regarding whether the user's autoconfirmed is irrelevant. Raindrift (talk) 00:18, 8 March 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Positive reinforcement

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Thanks for getting this up :-). Let me focus a bit on the area of positive/negative reinforcement (with no prejudice to the importance of the area of workflow efficiency, which is clearly crucial for this type of feature to succeed).

I really like the fact that "welcome" and "WikiLove" are already part of the workflow. I think it's safe to say that the folks doing NPP work would appreciate having better tools as part of the workflow that also help them motivate and appreciate new editors. I would hypothesize that it would make NPP itself more appealing as an activity as well.

Perhaps instead of ".. but also", the "Mark as patrolled" should say ".. and also", and include things like:

[x] send thank-you system message
[ ] send personal appreciation
[ ] invite to WikiProject
[ ] welcome new user

(Clearly, the relevance of these actions depends somewhat on whether/how new the user is.)

This would make it a more integrated part of the NPP workflow, as opposed to drawing a dividing line between "Flagging pages for problems" vs. "Welcoming and appreciating editors".

The idea of a thank-you system message is that any article that passes basic muster probably should lead to a standard thank-you. It would be worded to not imply that the article will definitely stay forever, but just simply express appreciation for the editor's effort. And I would suggest making it a system message (could be email, talk or both), because that would require less of a personal endorsement and raise fewer expectations by the receiving user, with the option of sending a personalized message if desired.

And of course, there's the template language, which we definitely need to keep in sync with vis-a-vis the ongoing efforts by Steven et al. in that area. I've experimented a little bit in my own time with changing messaging that is negative/didactic to messaging that is positive/helpful. Specifically, I rewrote the message that's placed on every user's talk page on Commons when they upload a file without categories:

• Before: http://commons.wikimedia.org/w/index.php?title=Template:Please_link_images/en&oldid=55610558
• After: http://commons.wikimedia.org/w/index.php?title=Template:Please_link_images/en&oldid=58988018

Essentially, I think a lot of the time when we're saying "Please do X", we want to be saying "Thanks! By the way, it's really nice to do X, because ..." That's obviously just a reasoned hypothesis and testing will bear out which approaches work best. Eloquence 02:23, 20 September 2011 (UTC)

Hey, that's a great idea, integrating the positive reinforcement stuff with the actions themselves. I wonder if we can't also do so with the "Nominate for deletion" section as well. Jorm (WMF) 02:25, 20 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

New page PATROLLERS

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Some good ideas here. They will only ever be of any use if New Page Patroller is made into a user right. The ideas here do not address the serious and immediate problems, such as for example, the fact that New Page Patroll attract the newest, least mature, and least experienced of all users who do not understand the principles involved, and who do ot read the instructions. A solution to this immediate problem was proposed that would restric the creation of new pages to en:WP:autoconfirmed editors. The restriction was adopted in Mrch 2011 by a clear majority consensus on a heavily subscribed RfC, but the request to implement the required software change was refused by the WMF. Kudpung 07:16, 20 September 2011 (UTC)

They will only ever be of any use if New Page Patroller is made into a user right. The ideas here do not address the serious and immediate problems, such as for example, the fact that New Page Patroll attract the newest, least mature, and least experienced of all users who do not understand the principles involved, and who do ot read the instructions.

If the quality of NPP work by new patrollers remains low even with an improved interface (and instructions for new patrollers can be simplified and made more accessible), there may be additional options as well to train new folks on NPP. For example, it would be possible to allow any registered user to perform proposed NPP actions, but to require sign-off by an experienced patroller, who could leave quick feedback for the new patroller and ultimately promote the user to have the same permission-set. In that way, the experienced NPP pool could scale significantly faster than through more conventional user right promotion processes relying exclusively on an editor's prior track record. Eloquence 09:17, 20 September 2011 (UTC)

We don't have an 'experienced NPP pool'. We have - according to the research and stats that has already carried out since October 2010 by Snottywong, Blade, and myself - a vast army of occasional, extremely inexperienced patrollers who appear to ignore all attempts to educate them, and a just a handful of experienced editors much of whose work is cleaning up after the other patrollers. Any solutions concerning improvements to NPP would require software implementation to prevent just anyone from patrolling and tagging pages. Solutions are really needed now, not after another year of discussion by people new to the problems and who don't understand them. Kudpung 12:37, 20 September 2011 (UTC)

Well, that might be an exaggeration. I think there are more than just the three of us experienced users patrolling (and I have been quite inactive at NPP lately, since I've been exploring AfC). At least at the beginning of the year, there were some more experienced users patrolling. See these stats. Snottywong 15:33, 20 September 2011 (UTC)

I think he was saying that the three of us carried out the study, not that we were the only three (although it sometimes feels like it). Perhaps unsurprisingly, I don't think a change to the interface will materially change the quality of NPP. As I have said elsewhere, nothing short of a hard restriction (this applies both to article creation and to being allowed to do NPP) will get anything done; people don't read the directions we already give them. An improved interface won't prevent someone from writing "Let's expose all burakus for what they are!!!!!!!!" with a link to a list of burakumin in Nagano Prefecture, nor will it stop a 13 year old who isn't paying attention from patrolling it; in fact, it will further enable people to mark such blatant attack pages patrolled without checking. We need ways to slow it down, and the only good way to slow NPP down is to slow down the number of pages being created. If it is slowed down, people will be able to check everything more carefully; as it is now, pages like the one described above are slipping through (the example came dangerously close, and if it had gotten through could have done horrific damage to thousands of people). A better interface would be good for patrollers like the three of us, who know what we're doing, but not for those who don't, which is around 95% of the rest of the people doing NPP now. The Blade of the Northern Lights (話して下さい) 21:17, 20 September 2011 (UTC)

I agree with you on most of your points. More time spent with each article (in creation and patrol, frankly) will certainly improve the overall quality of the encyclopedia. While efficiency improvements are a focus (ideally leading to more time spent reading and understanding the content and less time interacting with UI), I don't believe that's the primary goal of the proposed interface. Rather, they help to support the primary goals. If I had to outline them as I see them now, I think I'd say:

• Make NPP less complex to learn and vexing to do, to attract more experienced editors into it.
• Create an interface that can be used to train some of those newbies, in order to get more people working on the problem.

The eventual point is to get more (trained) people looking, so each of them can spend more time and be more accurate and less stressed (ie. reduced workload per patroller). Jorm's mock-up is just the first step in that direction, but I think it's a good start.

There's a long history of websites having content moderation problems, and approaching those problems by recruiting more moderators. Websites that are infamous for their trolling have managed to solve this problem without even disabling anonymous contribution, and have been doing so for over a decade. Most such sites have a system for giving moderation privileges only to people who are deemed trustworthy (via some impartial metric). I think such a metric is a reasonable thing for us to have, but we have to address these problems in the right order so as to avoid overwhelming anyone. The best system is probably one that requires agreement between multiple patrollers, since that seeks impartiality as well as accuracy, but (as has been pointed out) that's not possible until there's a lot more patrollers.

There are a lot of existing solutions out there, parts of which are probably worth adopting. Our challenges are certainly unique in some ways, but I don't think they're insurmountable by any means. Raindrift 22:24, 20 September 2011 (UTC)

I don't think we can Make NPP less complex to learn and vexing to do. Snottywong and I have tried already by recasting the New Page Patrol project page, but short of dressing it with an attractive layout with pretty graphics and buttons - which we have not done, notability & CSD are such extremely complex and ambivalent areas that even after gnashig our teeth and banging our heads against the wall over it, we have not been able to come up with something simpler. Other ideas and suggestions are more than welcome. Kudpung 12:39, 24 September 2011 (UTC)

I see where you're coming from. Policy is complicated, and it needs to be since the world that Wikipedia tries to model is a complicated place. At the same time, getting people to take the time to understand it is hard.

Let's say each person comes to NPP with a finite amount of time and effort they're willing to invest. Maybe 1-2% of those people manage to become involved enough to understand the entire process and become experienced NPPers. If we want to increase that number, we can take a few approaches:

1. Reduce the time and effort required to learn the necessary information.
2. Increase the amount of time people are willing to invest, by making NPP feel more rewarding overall, or by making it feel more rewarding further back on the learning curve.
3. Increase specialization, such that each individual needs to learn fewer things to be effective.

You've made inroads here, for sure, but we can probably do even better if we put the information directly in the software and present it incrementally as people work. Presumably some number of people do NPP because they find the process of doing it well, the impact it has, or learning in general to be intrinsically rewarding. Those are the people who we want to encourage. If we can create a way for people to have those feelings with less initial investment, they'll be willing to continue making an effort.

Looking at it another way, what we have now is a an excellent textbook on how to do NPP. Let's figure out how to teach the class. Raindrift 18:49, 26 September 2011 (UTC)

We've been slowly turning the page at WP:NPP on the sly into a tutorial, and I've already done some NPP coaching. Ironically, I'm a teacher and a Grade school and High School textbook author, but let's not run away with the idea that we can sit 600 NPP students in a lecture theatre for a couple of 3-hour sessions, make them sit an MCQ for an hour, and then give them a ticket to tag.

However, I had the idea at the weekend that perhaps I could develop this idea of a screencast one very big stage further, and and make a video tutorial for NPP. Now, that might be a way of at least being sure that they would 'read' the instructions. There's more to this than meets the eye, because this would pave the way to solving another very disturbing problem that I'm working on (Philippe know about it). Nevertheless, all solutions for NPP whatever they are, still look as if we're not going to escape the stick 'n carrot of making it a user right, and at the same time, we must develop some ideas to boost new-user retention.

What I need right now is to find a screencast package that works on my platform. Kudpung 00:16, 27 September 2011 (UTC)

But Kudpung, if NPP does become a userright, what is to stop an incompetent patroller from slapping db-tags on a page without patrolling it?

I'm not sure I agree with all the above points, but I can't come up with any alternatives right now. Σ 01:03, 21 September 2011 (UTC)

It will allow admins to filter out the people who shouldn't be doing NPP and/or revoke their rights if they screw up too much. If they're flaunting the spirit of the rule, it's rather easier to sanction them for it; as is, the situation now is pretty much like what he described. The Blade of the Northern Lights (話して下さい) 15:28, 21 September 2011 (UTC)

I'm very leery of creating a Priesthood of Article Gatekeepers. User rights are not things that should simply be created just because they can be. I'm also opposed to making the process more complicated - which is what additional rights always do. Jorm (WMF) 18:07, 21 September 2011 (UTC)

There has to be some way of preventing people from patrolling if they are doing a terrible job of patrolling. Without a user right, the only other alternative is to block them, which is non-ideal. And making a user right might have the added benefit of creating a (likely temporary) increase in the number of patrollers, since there are a lot of user right whores out there who will be clambering for the latest badge... ;) Snottywong 18:14, 21 September 2011 (UTC)

So, I get what you're saying. It's clearly a problem, and probably a super-frustrating one. Here's an idea I've been kicking around:

Maybe we have a user right - pagepatroller - but instead of it being granted to you by a Magical Wizard, you'll automatically earn it over time. It can still be taken away from you, though - which will set you back to step 1.

Let's say it works like this:

Bob decides to page patrol. He fires up the interface and goes to town. His first attempts at page patrol, however, automatically require review by someone who has the pagepatroller right. Say, his first ten. He patrols ten pages, and they're marked as "patrolled, but needing review" (so technically unpatrolled).

Then, someone who has the right (say, Snottywong), can review his reviews. And mark them as "good" or "bad". Once Bob has ten reviews marked "good", he is automatically awarded the pagepatroller user right (and with it the ability to review other people's patrols that "need review").

Obviously the numbers will need working out, and it will increase workload in the very short term (but possibly not, since, as you say, you guys are already re-reviewing anyway), but will decrease it overall (since you won't have to re-review these guys once they earn the right).

And if Bob goofs up? A conversation and a couple clicks by an admin and the right is revoked. He has to start over again, and earn ten "good" re-reviews.

What I'm trying to avoid is a situation where there's a whole level of bureaucracy that a potential patroller has to go through before they can start (another "RfA" type process). We should be open with letting people into the door, but be able to push them back out if need be.

Obviously, the numbers involved can be modified. And with decent messaging we can make this user-acceptable and friendly:

"Hey! You've just patrolled your first page! That's great! Just so you know, everyone who starts patrolling has a grace period where their work is reviewed by a more experienced patroller. Once the review period is over, we'll let you know, and you'll then be able to do reviews yourself!" or something along those lines.

What do you think? Jorm (WMF) 23:53, 21 September 2011 (UTC)

I feel like this is becoming unnecessarily complicated. I'm certainly not envisioning an "RfA" type process for handing out pagepatroller user rights. That would be way over the top. I think it should be handled like all other uncontroversial user rights are handled, like w:Wikipedia:Requests for permissions/Rollback or w:Wikipedia:Requests for permissions/Confirmed. We would just set up another Request for permissions subpage like w:Wikipedia:Requests for permissions/Pagepatroller, and anyone can ask for the permission there. As long as they satisfy a basic list of criteria, then the user right would be given to them. As for the criteria, I'm envisioning something like:

• Account has more than 500 edits
• Account is more than 3 months old
• If pagepatroller user right has been revoked in the past, require an explanation for how previous problems have been addressed

The numbers could be tweaked, those are just off-the-cuff suggestions. If a user satisifies the above criteria and has enough clue to actually find the place to request permissions, then there's a good chance they have enough clue to patrol pages at a basic level. This doesn't mean that we can't or shouldn't still build in some kind of process to allow review of their patrols by more experienced users, but I think handing out the user right should be handled like all other uncontroversial user rights are handled. Snottywong 20:04, 22 September 2011 (UTC)

One of the principle reasons for advocating NPP as a user right is that the only recourse we have at the moment for patrollers who persistently refuse to improve is to block them for being disruptive to the process. We have sadly had to do this on occasions, but it's a bit drastic, like taking a sledge hammer to crack a peanut. We should be looking at ways to retain potential good (and perhaps young) new editors rather than piss them off entirely. As SW says, a user right can easily be revoked without much ado. Whether user rights, like adminship, are a big deal or not, they give people a sense of responsibility and the desire to do a better job. Kudpung 03:25, 23 September 2011 (UTC)

This forum software is so confusing :( It appears that I have made the very same suggestion as you somewhere else on this page today. Would just add to that that there should be a guideline for the admins who accord the rights. Naturally they would seriously need to check the user's talk page, and not accord the right to anyone who has been warned or blocked for anything, or who has received CSD, PROD, or AfD notices for their own creations, and whose own creations are tagged, or missing cats, stubs, refs, and anything else that NPPers themselves are supposed to repair on other people's articles. Kudpung 14:45, 24 September 2011 (UTC)

SW, I couldn't agree more. So I've expanded a bit on that theme in another thread (I think) on this forum - if you can figure out how this forum works, because I cant! Kudpung 11:56, 24 September 2011 (UTC)

Serious editors and admins at en.Wiki realised from their solid year of research and experience that turning the vast army of inexperienced and ineducable NPPers into gatekeepers would probably not be feasible, so they agree with you there, if not for the same reasons. So they looked at another solution - which you also summarily, and apparently personally, dismissed. Kudpung 09:35, 24 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Is this really what is wanted?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm sorry but this seems like development for development's sake. JUST MAKE THE MARK AS PATROLLED BUTTON MORE ACCESSIBLE!!!! But that's too hard to code properly and ruins performance, but a fancy new interface is the answer. KISS principle, please. If every time you (maybe just opt-in, maybe just autoconfirmed, maybe everyone) read an unpatrolled page you saw the little "Mark as patrolled", then I'm sure the backlog would disappear in days. At least have a trial.The-Pope 12:38, 20 September 2011 (UTC)

I understand your frustration on the issue of the bug request. Asking for seemingly simple things and having them closed or delayed for performance reasons is not fun. But please understand that not only are some of the responses are years old, they're not made by the same people who have worked on the very early stages of this draft design. We're not a hive mind (yet) at the Foundation. ;-) The truth is, this interface might also be rejected for performance reasons too, we won't know until we ask someone to code it. At this stage we're just trying to think of a variety of solutions.

P.S. Thanks for dropping your comment here as well as on English Wikipedia. Steven Walling (WMF) • talk 17:43, 20 September 2011 (UTC)

To be honest, we need to build interfaces like this for several reasons above and beyond New Page Patrol. We have a large set of what we call "curation" problems, some of which are only just now beginning to surface. Rapid scan-and-tag systems will be needed for many, many things - not the least of which is image curation for commons.

A button alone will not be of much help if the primary problem is that people are not educated as to how to patrol, or what constitutes a patrol. Jorm (WMF) 23:49, 20 September 2011 (UTC)

A button would be very useful if it made more efficient use of volunteer time and brought experienced editors in on articles they understand. Quite a few of the articles that reach the back of the queue have actually been categorised or otherwise cleaned up, especially if the back of the queue is running to thirty days. The people doing that are often very experienced editors, they may even be members of wikiprojects looking at articles that have just turned up in the high level categories for their project and which need checking for hoaxes and often a more appropriate category applied. If those editors also had the option to just click the appropriate ones as patrolled it would take some of the pressure off the end of the queue, and save everyone time.

Please don't underestimate the importance of that Bugzilla request - there are a few medium sized opportunities to improve NPP, but this is the only uncontentious big improvement on the table. WereSpielChequers 19:03, 22 September 2011 (UTC)

I welcome the signs that Brandon is slowly but surely warming to the idea that the transient mass of New Page Patrollers is basically uneducable. The next thing for software developers to understand is that there is a limit to the amount of human experience that can be replaced by scripts and filters on a php driven website - it's probably not such a good idea to be constantly searching for electronic solutions just because Wikipedia happens to be an electronic encyclopedia. As I've intoned before, sophisticated tools are only of any use when in the hands of experienced users. Kudpung 08:52, 23 September 2011 (UTC)

I do not believe, in any way, that people are uneducable. Jorm (WMF) 16:26, 23 September 2011 (UTC)

That remains to be seen ;) There appears to be some kind of consensus (here at least) that NPP should be a user right for competent patollers. It is hoped that the current survey will shed more light on this. Whichever way the survey itself goes, the need for a user right would appear to be inescapable.

I am currently working on the development of a video tutorial for NPP, but much of the completion of it depends on the development of the excellent Zoom project that IMHO so accurately addresses NPP issues already, that all it requires now is coding up and putting on TestWiki for us to tinker with and suggest minor changes and/or additions. Kudpung 02:05, 31 October 2011 (UTC)

I suggest we consult the Village Pump on the affected wikis before proceeding further with the idea of making a new userright. It might be more controversial than the conversations on this page show. →Στc. 06:33, 31 October 2011 (UTC)

There is absolutely no intention to impose new user rights without consensus from the community. The overall community feeling regarding an NPP user right is hoped to be demonstrated by the results of an NPP survey which will take a couple of weeks to complete and analyse. Development of the Zoom tool should continue, because it will be used whether or not a user right is installed. Kudpung 09:57, 31 October 2011 (UTC)

I've struck the bit about PagePatroller rights as that was opposed by a majority in the survey. I think that a detailed proposition with a clear explanation as to how it would work might be able to get consensus support on EN wiki, but you'd need an RFC for it. More importantly ThePope's point is valid - making the mark as patrolled box visible to any autoconfirmed editor who opens an unpatrolled page would solve the problem and in a far more wiki way than Zoom intends. Currently you only see that box at special newpages so all the people categorising articles and looking at new articles that have turned up in their wikiprojects categories don't get the opportunity to patrol them. WereSpielChequers (talk) 08:51, 27 February 2012 (UTC)

I believe the word is ineducable, not "uneducable" :-) Chzz 10:51, 31 October 2011 (UTC)

Did you notice that U and I are neighbouring keys on a keyboard? Kudpung 15:48, 31 October 2011 (UTC)

(I'm not sure where to put this; I really dislike Liquid threads.) I see two really major problems in the proposed implementation which to me would make everything very much more difficult: One. the list view is much more expanded. the way I patrol, the way i think most experienced people patrol, is to scan an entire large portion of list for something which strikes us as worth our noticing. By this I mean , not anything that needs attention, but something that needs the particular attention that I in particular can and want to give it at this particular time. There is no way i can reduce this to a single algorithm, because I know I look for a very wide range of different things at different times, depending on my degree of alertness, the time available, and what I am most concerned with that day. Some of the things I look for could be made into an algorithm, but not all. I rely of my sense of what seems weird to me; I normally scan a screen's worth and pick out a single particular questionable item. Sometimes in a half-minute,sometimes slower. (I do not even attempt to go systematically--I find what I find; there's too much to see everything.) Now, perhaps it is intended that the expanded list version displayed will be collapsable, but unless the default view is as compact as the present one, I'll have no use for it. The best thing you could do to help me patrol is to maintain the present interface exactly as it is--as an alternate. I say as an alternate, because others probably would do better with a different display. But for me, there is no change in the display that would be an improvement. Two, you seem to have defined New Pages as pages that have not yet been patrolled. That's of little value to me. What I am really looking for is errors in the pages that have been patrolled. I'm not actually patrolling new pages; I'm patrolling the patrollers--both at the explicitly patrolled pages and the autopatrolled ones. Again, maintaining the exact same current interface as an alternate would let me do what I want to do, and what I know how to do. (I assume others think it of some value, whether or not they want to work the way I do). DGG (talk) 03:04, 3 March 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Please record a screencast of yourself doing New Page Patrol

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

(moved from Talk:Article_creation_workflow since this is a more appropriate place)

Hi, everyone. Thanks for all your ideas and feedback. I'm really excited about this project--I think we have a chance of making something really useful.

One of the things we've realized in talking with new page patrollers is that, in the absence of any real coherent UI, everyone has tailored their own custom interface from scripts, browser plugins, etc. This has its good and bad points, but it's also meant that we at the WMF can't actually examine the interface most of your are using, because we don't have it.

Any good software design effort starts with understanding what people are doing now. So, we're hoping that a few of you could send us screencasts of yourselves doing NPP. Here's specifically what we'd like you to do:

1. Begin recording a screencast of your NPP session. I think 10-15 minutes would be about right, but feel free to take more or less time as you see fit.
2. Clearly state your username, so we can easily link your comments with your video.
3. Start doing NPP. Spend about the first half of the time moving slowly, talking through the process and explaining what you're doing, why you chose that specific tool, what you like/dislike about it, and any other options you tried in the past. If you're using gestures or other off-screen interface elements, describe them. Also tell us about what you're looking for in the article, the policy decisions you're making, and your thought process. If you suspect copyvio, tell us what feature triggered that suspicion; if something seems like spam, what's spammy about it? Show us your process.
4. Spend the rest of the time running through NPP in your usual way. This gives us an idea of the pace at which things happen, how long specific steps take, etc. Don't try to go faster or slower than you normally would here. The idea is to understand where the bulk of the time and effort go, so we can streamline that process.
5. Wrap up the video.
6. If you're using the usertesting.com tool, upload the video per the instructions below. If you're using your own tool, send your video (the whole file, or a link if it's really big) to me at ian@wikimedia.org.
7. Send any additional comments you have in an email to ian@wikimedia.org.
8. Feel free to post a link to your video and your comments as a followup to this message. This is encouraged, but a video of one's personal computer is, well, personal, and I want to protect your privacy as well.

If you want to user the usertesting.org tools (this is the quickest/easiest route if you don't already have screencasting software), follow these handy instructions from Jorm:

1. Go to our usertesting.com launch page.
2. Click the "start" link (it's the only link available)
   • Do not close this tab or window. It's okay to background it, but don't close it.
3. The Java applet may require rights to run. Grant the rights as needed.
4. A few moments later, a "box" interface will appear. Resize it to contain your entire work area (either your entire desktop or all the tools you use at once)
5. Press the red button in the lower left of the interface to begin recording.
6. A countdown will start. Once the countdown has finished, the recording has begun.
7. Speak aloud your thoughts as you work. This is very important.
8. When you are finished, click the "Done" button (down near where the start button was)
9. The browser window (that you didn't close earlier) will then refresh with a screen cap from your session and ask you to upload the file.
10. Click "Upload this file". The upload will begin. This may take a while.
11. You'll be presented a list of screencasts. The filenames will be datestamps. Please note which one is yours and list it below, if possible.

If you have your own screencasting software, feel free to use it, and send your video and comments to ian@wikipedia.org. If you can't get the usertesting.com stuff to work (it's still quite beta) or you just want to get some screencasting software anyway, here's a list of tools, and here's another one.

Once we've received what seems like a representative sample, I'll compile all videos, we'll look them over, and we'll let you all know what we've learned.

Thanks in advance for your help. This will be invaluable information for making a tool that's actually useful to existing new page patrollers.Raindrift 20:59, 20 September 2011 (UTC)

There's also a great deal of material WikiProject Screencast, though it focuses on creating how-to screencasts for general consumption, not screencasts for user experience research. Do we want to make a MediaWiki-focused general documentation page for this here, including materials on usertesting.com? Steven Walling (WMF) • talk 21:35, 20 September 2011 (UTC)

Would closed captioning be an acceptable replacement to using a voice? →Στc. 07:12, 21 September 2011 (UTC)

Absolutely. Raindrift 16:43, 21 September 2011 (UTC)

In my very honest opinion, I believe requesting screencasts of new page patrolling is a demonstration of lack of WMF faith, recognition, and confidence in the stats based evidence that experienced users and admins have taken a year to research and produce through sheer dedication, determination, and long hours at the unappetising task of new page patrol. Add to that the WMF accusations that those researchers are a bunch of diehard deletionists. Adequate proof that NPP is a broken process manned mainly by a transient pool of raw beginners has been provided - now is the time to look for a solution that directly addresses the problem - nifty tools that streamline the work of those who already know what they are doing are most welcome, but they can be developed later. Kudpung 03:42, 23 September 2011 (UTC)

Hey Kudpung: I'm sorry if you feel like the screencasting is about doubting your hard work on the quantitative statistics side. It's truly not. The request got put out because those working on engineering at the WMF, like Raindrift, are very interested in helping solve these problems, but they aren't New Page Patrollers. The point of asking for a screencast is to have you lend us a little of your hands-on experience in patrolling, which is what we lack. It's certainly not going to tell us the hard numbers which I think you're referring to, or refute anything of that kind. Steven Walling (WMF) • talk 21:23, 23 September 2011 (UTC)

Steve, I do understand, and I don't doubt for a moment that it is well intended. It may not be a demonstration of lack of confidence in the work that Snottywong, Blade, and I and others have already researched since October last year, but it certainly does appear that you are not satisfied with that feedback, and that this NPP Zoom project is still lacking focus on critical issues. I still feel therefore this request for screencasts will only serve to duplicate, rather than substantiate, the information that has already been made available to you and your team in the form of adequate tables and stats by mature and dedicated users - who are not , BTW, a bunch of dedicated exclusionists. Snottywong is an expert at providing data and has already provided plenty of scripts that were to be used to extract data for the ACTRIAL. If you require more tables and up-to-date data runs, I am sure that if he is asked nicely he would be only too pleased to oblige - he is after all, like me and Blade, deeply concerned with these NPP and new page creation issues.

As far as the request for screencasts is concerned, the wannabe Wikipedians who are patrolling new pages supercficially at the speed of light will not want to slow down in order to address such a request, while we, the experienced patrollers, are also content builders and admins, and won't necessarily have the time or inclination to engage on a mission so complex. It requires downloading special software - which I am not even aware of being available for my computer platfiorm - fiddling with it until it works, then uploading the files to some destination that you will no doubt create.

Because of the difference between the work of newbies (that will most probably never be made available as screencasts anyway) and screencasts of the more professional patrolling done by established editors and admins, I doubt that the screencasts will ever provide you with useful new information. I for example do most of my patrolling one one computer screen that has a dedicated Wikipedia window for NPP, while flitting back and forth from other Wikipedia tasks such as adding content, deleting pages, following up SPI, and answering new messages on my talk page.

Thus with all due respect, I would strongly suggest that for the time it would take for you to review the content of several three-hour screencasts, you may prefer to consider doing some new page patrolling yourself in that time, and gain some first-hand empirical experience. If other members of your WMF team, such as Raindrift (best if those who design cars have actually driven one), and perhaps those who heavily criticised our efforts at ACTRIAL without even reading the background to the trial, would also do the same, you would have some first-hand notes to compare.

You may also wish to review these slightly older, but equally important statistics prepared by BlanchardB: w:en:User:Blanchardb/CSD_statistics BlanchardB that provide a similar experience. The actual situation today is however far worse. Kudpung 06:28, 24 September 2011 (UTC)

I've spent aa few hours over the weekend looking more closely into this screencast idea, and I'm beginning to see where it could indeed possibly help the developers understand more about the NPP process. Unfortunately, in spite of all my web design work, I've never needed to make any screencasts and I don't have the software to do it. None of Steve's suggestions work, and the only available solutions for my platform cost money. Perhaps the WMF could buy me a licence for one ;) Kudpung 09:12, 26 September 2011 (UTC)

VLC Media Player can record stuff off the desktop (select File->Open Capture Device and select "desktop" for the capture mode), but you will need to edit the video afterward to add the audio track. MER-C 10:31, 26 September 2011 (UTC)

Unfortunately that didn't work either. FWIW I use Mac OS 10.6.8. Kudpung 13:39, 26 September 2011 (UTC)

Hey, Kudpung. Thanks for taking the time to try recording a screencast for us. It'll be really helpful!

It just happens that I, also, run OSX 10.6.8. The usertesting.org screencast software works okay for me. It's rather beta, but I did manage to record a test with it. If it works for you, that's probably the most expedient way.

If you prefer to use a piece of desktop software, Telestream ScreenFlow is probably the best option. The demo is fully functional, but will leave a watermark on your exported video. That's fine, though. I'm sure we can ignore it.  :)

If you use ScreenFlow: It's not obvious now to stop recording if you haven't set a key combo in the preferences. If you switch back to the ScreenFlow application and hit 'File->New Recording', it'll ask if you want to stop the current one instead. When exporting, I recommend using the "Web - Low (multi-pass)", and scaling to the smallest size that maintains readability. 75% worked for me, but it'll depend on the size of your fonts. That produced ~500kbit video, which is small enough that 15 minutes of it could still be emailed.

As you might have surmised, we don't need the screencasts to understand the nature of the issue. The data you and others have collected are quite clear in that regard. Rather, we'd like to use them in designing a solution. I'm imagining a toolset that makes newbie page patrolling easier and more accurate, and provides a way for experienced patrollers to quality-check and mentor the newbies in a way that encourages them to learn, but also to disable patrolling for the ones who just can't get it. A whole host of very useful features depend on getting (mostly) everyone together in one place, which means we have to try to meet everyone's needs.

We're not terribly concerned with the workflow of newbie NPPers—we need to understand how they work to some degree, but it seems education is a more important goal here than efficiency. Also, I can become a newbie NPPer in short order, so that research is easy to do locally. Serious experience, on the other hand, is hard to get. It seems like each experienced NPPer has built their own UI to some degree, or at least uses Mediawiki very differently. To capture some of that functionality in the code we write, we need to see how you all work. Raindrift 18:13, 26 September 2011 (UTC)

Hi Raindrift, thanks for all those tips. I'll try some of them out when I get home this evening. Please search around this confusing talk page - you'll find a thread somewhere I posted today with more detail on what I've got lined up for a screencast if I can get the software to work. Kudpung 02:12, 27 September 2011 (UTC)

I'm still struggling with challenge of royalty-free screencast software, but in the meantime, i'd like to expand on one or two points you made. The serious NPPer probably hasn't built him/herself a sophisticated interface - they are not all geeks - they mainly just limit themselves to Twinkle - which is perfectly adequate, is quick, and takes up no screen space. The less experienced users often don't even know what Twinkle is - which ironically is probably not a bad thing, except that users do not get notified of CSD tags. I first found out what Twinkle is when (what seems) years ago, when I stumbled on a user page that had a "I patrol pages with Twinkle" userbox on it and I wondered what Twinkle was. I probably have one of the best possible working environments for optimal Wikipedia workflow, with several Mac Minis, a MacBookPro, all with large screens in a row and all sharing, and all operated from one keyboard and one magic track pad.

You say that you can become a newbie NPPer in short order, so that research is easy to do locally. Yes, and if you already have a solid knowledge of policy, page creation, and standard editing tools already, and spent two hours reading the instructions listed at WP:NPP, WP:DP, and WP:CSD and consigned most of the notability acronyms and around 30 CSD criteria to memoire, in less than an hour you'll be as proficient at NPP as our best patrollers. BUT, you are an adult, have an analytical mind, and probably a PhD - any page patrolling you do will not put you in the shoes of a 12 - 13 year old. However, you might wish to count how many pages you treat, doing all the steps required at WP:NPP, in one hour's solid patrolling without getting distracted, but you will be if you also have en.Wiki admin tools. What slows me down is that I do physical deletions too, ans sometimes salt pages and block the users when I'm patrolling. All this can dramatically reduce the actual number of pages patrolled. A 15 minute screencast may show me getting through 15 new pages or as few as three. There is also the fact that I cherry pick: from the front of the queue the page titles that I know are going to be a challenge for the average patroller, and of course pages with any spammy sounding names, and bios. At the back of the queue, I usually go for the bios first, then the ages with Indian sounding names. To save time, I go through about 10 - 20 picked pages on the list and let them start loading in separate browser tabs while I work. I have monitors and widows open with my 'tool box' user sub pages. Kudpung 09:24, 29 September 2011 (UTC)

I should point out that I do a lot of work in the lesser namespaces, and quite often find material that is legally problematic and therefore needs to be oversighted. As such, I'm not sure it'd be a good idea to record my discovery thereof. DragonflySixtyseven 14:12, 29 September 2011 (UTC)

This... is a very good point.

Would it be possible for you to do your recordings in a namespace that is less likely to run into this type of stuff? Jorm (WMF) 22:56, 29 September 2011 (UTC)

Perhaps you could share your page patrolling session in real time through screen sharing on a video conference with maybe Steve and Ian? I think the major issues are more about establishing how many pages you are able to fully examine during your patrol session, what percentage of new pages you empirically find to be really in need of rapid deletion, what pages are passed as 'OK' patrolled that should'nt be , and the frequency with which you have to correct a patroller's tagging. Also as an admin, roughly the percentage of new pages you summarily delete immediately. Kudpung 02:40, 30 September 2011 (UTC)

Yeah, we'd be happy to do a screenshare any time. Steven Walling (WMF) • talk 17:31, 30 September 2011 (UTC)

I think we need to set up a screenshare session. I had another go with test.com. this morning. It took 29 minutes for a 10 minute session to upload, and when I got the result back after waiting another 14 minutes, it started and then just hung. Kudpung 10:36, 4 October 2011 (UTC)

Okay, email sent about scheduling a time... Steven Walling (WMF) • talk 21:54, 6 October 2011 (UTC)

I've done a test run with Blade about screensharing andit worked perfectly. I'm nevertheless still looking into solutions for making screencasts on Mac. it looks as if the free trial of SnapzPro might be worth looking at. Kudpung 04:04, 8 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Can we apply a similar anti-vandalism approach to NPP?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Wikipedia faces the problem of vandalism via edits, which we cannot solve by restricting edits to registered users. In any case, it has been mostly solved by ClueBot NG. Similarly, with the declining of the AC trial, could we instead have a ClueBot equivalent that patrols new pages for unsuitable articles and applies simple-to-judge CSD tags (I believe they are A1 and 3, G1, 2, 3, and 10)? Σ 03:16, 21 September 2011 (UTC)

See here. MER-C 05:38, 21 September 2011 (UTC)

That does not address my concern. What I am worried about is a vandal slapping a crap reference on an attack page or vandalism page just to get past the checks. As the bot would look at content and nothing more, it would be perfect for dealing with clear cases of the aforementioned criteria, as those are the criteria where borderline cases are less often encountered. →Στc. 06:59, 21 September 2011 (UTC)

I think the appropriate place to request that would be w:WP:BOTREQ, and I think you'd find a ton of editors who would oppose that goes around tagging articles for speedy deletion. It's just too easy for an automated script to make a mistake, and that's a task where mistakes can have big consequences. Snottywong 14:18, 21 September 2011 (UTC)

You have a good point—fully automated checks have some serious pitfalls. However, content-aware bots could be handy too. Once we have a data model in place for article tagging (for tracking things like, "Which patrol checks are completed?" for example), bots could use an API to attach tags like "probable-vandalism" and "probable-spam", maybe even with a score parameter. Then, it'd be possible to search for those articles in the NPP interface, or to configure the zoom interface to show them at the top.

Since those are usually clear-cut cases (vandalism is usually obvious and finding it requires learning only a small amount of policy), they could be a good place to start newbie NPPers.

In some future where we have lots of patrollers and can move to multiple people agreeing on a decision before applying templates (there's got to be a short name for that), the bot's vote could count for a couple human reviewers, speeding up the process. Raindrift 17:40, 21 September 2011 (UTC)

Tagging probably vandalism and spam sounds a lot like what AbuseFilter already does. Steven Walling (WMF) • talk 19:05, 21 September 2011 (UTC)

Good point.  :) Raindrift 20:09, 21 September 2011 (UTC)

Fair point, but according to 28bytes, the filters use more resources. →Στc. 02:24, 22 September 2011 (UTC)

A1 and A3 are in my experience the most likely tags to be incorrectly applied and the easiest articles to rescue. I suspect we could get an abuse filter or admin bot that could handle certain types of G10s, such as any article containing certain phrases and where the author's previous contribution was deleted G10. WereSpielChequers 19:37, 22 September 2011 (UTC)

Of course there will be false positives - even the almighty ClueBot NG has them. →Στc. 06:41, 24 September 2011 (UTC)

Yes but the rate of false positives needs to be very low for community acceptance. A1 and A3 are very difficult ones for a bot to get right, not least because most of the ones where it is ultimately valid will be manually tagged before a bot would think they were legitimate tags. Also it is not easy for a bot to click what links here and do the other basic checks you need to do before you can decide that an A1 or A3 article can't be salvaged through ordinary editing and does indeed need a deletion tag.

G3 and G10 however I think I could see a bot being coded for. "mmmmm is Gay" and so forth are fairly easy tests that could identify quite a few articles that merit summary deletion.

However this isn't really the place for bot requests. If someone can design a bot that reliably spots G3 or G10 articles then I'm sure there would be interest at the bot request page. The difficult bit is coming up with a design that won't have an unacceptable number of false positives. WereSpielChequers 18:01, 27 September 2011 (UTC)

I don't believe the control of A1 and A3 can sensibly and usefully be dehumanised. There is almost always something on the page, and in my own experience, it is fairly rare that they are in fact the beginnings of a serious new article. Whether they are or not, a bot can't replace the cognition of an experienced patroller, or the deleting admin. With even very little content A1 and A3, apart from sometimes being random hits at a keyboard, are often attack, linkspam, or test pages that should be summarily deleted, and fast. I guard against looking for electronic solutions for everything just because Wikipedia is an electronic encyclopedia. Kudpung 05:09, 29 September 2011 (UTC)

WSC, I don't know anything much at all about filters and how they work, but as they obviously function on a vast catalogue of keywords, perhaps, if I've understood the ideas you explained to me, they could indeed be used to red-flag certain new pages at the moment of creation (most especially particularly A1, A2, A3, A10, G1, G2, G3, G4, G10 and if CorenBot is someday up and running again, G12 (Copyvio) , and effect some automated functions such as, just for example:

• Deactivate them from live mainspace and put them in a holding bay
• Prevent them being indexed by Google
• Add them to a category: Pages awaiting admin approval
• Signal an alert to the admin dashboard
• Leave a message on the creator's talk page something like:

Welcome to Wikipedia. The page you just created may not be suitable for immediate inclusion in the encyclopedia and has been temporarily put on hold. Please contact an administrator from this list, who will review your article in a few moments. Thank you.

Nevertheless, in the absence of the ACTRIAL solution, it may be worth considering channelling all new pages from non autoconfirmed to a much improved Article Wizard, Articles for Creation, or a user sub page/sandbox (with a link to the Video tutorial on creating a user page sandbox, on opening an edit window. from a start page on the lines of Article creation workflow.

Anticipated questions:

• Q: Why can't a new Page Patroller do the review of the bot/filter flagged pages?

A: Because empirical findings have demonstrated that many patrollers lack basic understanding of the new page patrol process, their tagging is not accurate, and they often pass attack pages as patrolled (or tag them with a less urgent criterion).

• Q: Why should an admin review the page?

A: Because admins can immediately delete such pages without further ado if need be.

• Q: Isn't this the same as, or similar to, Pending Changes or vandalism patrol?

A: No. It only affects certain new pages, and those created by non-autoconfirmed users. Kudpung 02:13, 1 October 2011 (UTC)

Hi Kudpung. I think it would be a mistake to put goodfaith articles into a badfaith stream. So if we can get a filter that puts most G3 and G10 into a separately coloured stream then I think we should just do that. The A ones are supposed to be goodfaith, and anything that is correctly filtered as an A code can sit around a little without any risk of harm - A1 andA3 we are supposed not to tag or delete until their creator has had a few minutes to add the second sentence that makes sense of them. WereSpielChequers 23:14, 2 October 2011 (UTC)

I'm aware of the principle on which they are sorted in to As and Gs, etc. However, my own experience is that the vast majority of A1 and A3 rarely in fact develop into serious articles. I religiously wait 15 - 30 minutes before tagging an A1 or A2 that is clearly not vandalism and when I return to them, it's usually to delete them. Nevertheless, this is not to say that they are bad faith creations. I sometimes find (you won't get NPPers to do this kind of research) that the author has simply abandoned that attempt, to start over by recreating the articlepage under a different page name. They don't know yet about sophisticated mechanisms such as 'moving' new pages, creating redirects, making dab pages, etc., and this is one of the areas where we fail to make the creation of new pages a more welcoming experience.
I well remember the first, and only grave error I made when I started creating pages for the first time: I had misspellt the name of a French wine. It took me ages to find out how to correct or change the title of the page, and I had no inkling that in Wikispeak, move means rename; I finished by doing a a copy-paste move. At that time, nobody had left a welcome message on my tp with that nice catalogue of links to all the tutorials and info pages. Now there's a thought for Jorm's user landing page at Article creation workflow.

Welcoming and profusely thanking new editors for all their incredibly invaluable creations is one thing, but perhaps if would be better if new registrations were to get a partially pre-formatted user page that already includes that list of links? People are working on a better user page design, here's one, and I seem to remember Fetchcomms has been working on another, but I forget how to link to it. Kudpung 01:48, 3 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Don't encourage templating

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

While we don't know for certain why the community has gone off the boil since the rise of templating in circa 2007. I'm sure I'm not the only one who thinks that the drift from improving articles to templating them has been a major cause.

I'm not sure that this software is really going in the right direction if it is simply making it easier for editors to do more drive by tagging of articles rather than actually improving them. In particular we need to think of the newbies in this, it is self evidently more friendly to greet a newbie by categorising and wikifying their contribution than by adding a category needed or Wikify template. I'm pretty sure the newbie is more likely to learn the bit of coding you've just added to their article by seeing what change yu've made than by clicking the links in a maintenance template and reading the relevant policy. May I suggest that like hotcat this software should encourage the patroller to improve articles not just tag them. WereSpielChequers 20:17, 22 September 2011 (UTC)

A good point to consider. I think Brandon tried a first pass at a tool that (generally speaking) works with the activities happening in NPP currently, which of course includes improvement banners. But perhaps we could convert some of them into very specific User talk templates? For example: instead of applying {{One source}} and never telling the author what to do, we send someone a message which thanks them for their article, tells them what they did right, but then clearly invites them to add more sources. Just an idea... Steven Walling (WMF) • talk 20:59, 22 September 2011 (UTC)

I agree that the ideal activity of a patroller would be to fix all problems with the article instead of tagging them. However, there currently are not enough patrollers available to spend this amount of time on each article. If the problem of patroller quantity could be resolved, then I'm in complete agreement that the new patrolling interface should actively encourage fixing problems rather than tagging them. I also have a feeling that this would happen more or less naturally if the newpages queue wasn't always in jeopardy of being overrun. Snottywong 21:20, 22 September 2011 (UTC)

In my experience some patrollers just tag and template, others do a lot of categorising typo fixing and so forth. I suspect that the system currently relies on those who tag and template to handle the sheer volume of newpages, and I wouldn't suggest simply withdrawing the templates because NPP as currently constituted would immediately get swamped. But as I read this proposal it is channeling patrollers into just tagging and templating articles - shifting the balance further towards templating and away from article improvement. I don't see that as healthy. WereSpielChequers 21:42, 22 September 2011 (UTC)

In an ideal world, we'd move from the "tagging an article using a template" system to "tagging an article using stored metadata tags" system, which we could make friendlier and less obtrusive.

I suspect that a lot of problems arise for new users who take "improvement templates" personally - like they are critiques upon their writing or whatever. Which they are - just not "hostile" critiques. As it were.

I'd like to introduce a system of "welcoming and appreciation" alongside of "tagging for improvement." There's another thread (started by User:Eloquence that goes into this more, and I want to modify the design to include it (though I haven't had any good time spent in The Cave to do so lately). Jorm (WMF) 00:48, 23 September 2011 (UTC)

I've mentioned somewhere on this forum already that I very often place a custom message such as: Welcome to Wikipedia and thank you for contributing XXXXXXXXX. The article has been reviewed and a couple of points have been flagged for attention that could be resolved from your knowledge of the subject. Please consider returning to the page and addressing those items, and if you need any help, don't hesitate to ask me on my talk page. I have always wondered why it is not possible, or perhaps not desired, for Twinkle to do this for us when adding maintenance tags. This is just one tiny way we could help make the reception a little bit warmer for potentially serious new editors, and encourage them to clean up what they have started without waiting for therm to do something horrendously wrong before contacting them. I think it's a lot nicer than their first contact with us being a message to tell them that because it's not been referenced/is crap/is not notable, it's been PRODed/CSD'd/AfD'd, so clean it up or else. Kudpung 13:28, 24 September 2011 (UTC)

I suppose if we could get the templates friendly enough this might be better than "Welcome I've tagged your article for deletion". But my fear would be that however friendly we started the templates, and however much we focussed them initially on entry level problems, within a year or so someone would have added more emphasis by adding the red stop sign warning we give vandals and rolled the process out to other maintenance templates that are less like newbie tasks - de-orphaning perhaps or infobox missing.

But maybe there's another group we could enrol here. A large proportion of new articles by newbies are uncategorised. If Hotcat had an option "If I categorise a new article contributed by an author with a redlinked talkpage, also welcome the newbie". Then a lot of newbies who'd get a message from someone that would be likely to perceive as a helpful collaborator. WereSpielChequers 18:23, 25 September 2011 (UTC)

Unfortunately I too have noticed that a lot of tinkering goes on with template messages at the UW template project, and many changes get slipped through with out much consensus. hence the reason why so many of those templates are absolutely TLDR, and are not necessarily written by people who have a fine touch for prose. I have sneakily improved a lot of them myself, but some are so complex with their layers of embedded php calls that I can't always find the location of the text block I wish to modify. I'm no stranger to php, but the way some of these templates are conceived is a real headache if you're not the original developer. It's a bugger for a lot of others too, because quite often the original template author has done a bunk.

Your Hotcat idea is good, and it brings me to another idea: I'm not too enthusiastic about Brandon's Zoom Inteface, but that's because it's too soon, and does not address the the main, and more urgent problems with the NPPers. It does however load some very interesting meta information about the new page and its author, and I think we could build on that. It does however have some distinct disadvantages over the tried and trusted Twinkle that people like you and I, SW, and Blade are using when patrolling, but I'll probably have to talk to Brandon separately about that. (one aspect I sorely miss is the analog list of new pages). If development of Zoom and development on a solution of either ACTRIAL or making NPP a user right could advance in tandem, and fairly quickly, I think we could make progress. That said, the more I look at Zoom, the more I actually like it, but it's still only going to be a tool for policy-savvy patrollers - and ones with a very wide monitor! Kudpung 08:57, 26 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Prompt to look at "other unpatrolled articles created by"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Whether you are marking articles as patrolled or tagging them for deletion, it would be really helpful to have a prompt for "other unpatrolled articles created by" when the author has contributed other unpatrolled articles. There are a few generalists who will aim to handle any article regardless of the subject, but many of us specialise or at least ignore certain types of article. Most people who create multiple articles in the same month will be writing on similar subjects, which is why you can usually handle the second third or fourth article by the same author much more quickly than the first. Often they need to be added to the same categories. I'm pretty sure that this feature would enable some of our patrollers to do more patrolling per hour. WereSpielChequers 20:33, 22 September 2011 (UTC)

I've mentioned something like this in another thread here today in reply to a post of yours. It's about the meta information that is or could be shown on the Zoom interface. Kudpung 09:07, 26 September 2011 (UTC)

This is a good point, and it should be easy to find this out. Raindrift 18:16, 26 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Possible badfaith colour

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Currently we have a very simple colour scheme - yellow for unpatrolled and white for patrolled. I'd like to make this more complex in various ways. but the simplest would be a warning red colour for possible badfaith articles. This could be done with a few pretty simple rules:

1. any article created by an account whose previous 5 article creations include one deleted as either G3 or G10
2. any article containing certain obvious trigger words such as the ones used by friends of gays.

Of course many of these articles will turn out to be innocuous and uncontentious, or articles about the sort of rock groups who use strong language in the album titles and even band names. But in those cases marking them as patrolled or tagging them as A7s would immediately turn them from red to white without the author ever knowing that their article had been flashing red on someone's screen. If the interface defaulted to displaying red articles first regardless of their place in the queue and whether the patroller was otherwise working at the front or the back then we might actually speed up our deletion of G3 and G10 articles - and I would hope we could all count that as a positive. WereSpielChequers 20:51, 22 September 2011 (UTC)

I'm gonna have to say that I don't understand what "friends of gays" means here in this context. Could you elaborate? Jorm (WMF) 21:33, 22 September 2011 (UTC)

Sorry I thought it was one of our better known memes. The essay got moved to meta. meta:Friends of gays should not be allowed to edit articles WereSpielChequers 21:46, 22 September 2011 (UTC)

Oh, okay. I was confused there for a moment...

Anyways, to the meat of your comment.

I agree wholeheartedly. I have been advocating for us to basically "embed Cluebot" into our core software - not necessarily to do reversions, but to tag and mark revisions as "suspect". This would be something that would show up in the Zoom's "List View" most obviously, but with more detailed reports in the Zoom view.

Your first suggestion - checking the revision vis-a-vis the editor's previous contributions - is probably not doable. The system doesn't track why an article was deleted, merely that it is no longer there. Further, even discovering that an editor has deleted pages is probably a difficult call to make. Jorm (WMF) 00:52, 23 September 2011 (UTC)

I appreciate that only admins and researchers have access to deleted revisions, so the initial concept of one of their last few creations has been deleted G3 or G10 might not be easy to code. As it would compromise the idea of deleted edits only being viewable by admins I suppose in theory it should require assent from legal and consensus from the community. But I can't imagine that either would object.

An alternative way to do this would be to check the editor's talkpage, and ideally talkpage history, looking for recent G3 or G10 warnings. That wouldn't pick up everything, some of the more childish stuff just gets summarily deleted without comment, and some G10s get initially tagged as A7 or BLPprod, I doubt if many admins change the warning message even when we delete under a different code than the tag. WereSpielChequers 06:58, 23 September 2011 (UTC)

Well I do, but as the NPPers refuse to be educated I`'m beginning to wonder if it's worth bothering. Kudpung 15:46, 23 September 2011 (UTC)

I'm inconsistent as regards giving feedback to patrollers. But my experience, such as it is, is not quite as negative as yours. Some patrollers seem eager to get it right and happy to learn. Others just see me as that "hemp clad patchouli smoking sandal wearing rabid inclusionist" from the Article Rescue Squadron and get annoyed when I explain that "would probably be deleted at AFD" is not a speedy deletion criterion. WereSpielChequers 16:22, 23 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Patrolled pages need to stay in the queue as well (plus pages moved out of userspace have to be added!)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

From what I'm reading here, a page that has been marked as patrolled would no longer be available in the NPP portal at all. This would be a terrible step back. When I do NPP, I don't care whether pages are marked as patrolled or not, and there isn't that much difference in quality of articles between them. Looking at the current NP log at the English wikipedia, I see pages marked as patrolled like "Brüggen (needs moving) and Dr. Liston Bochette III (an unsourced BLP that needs moving, but a bigger problem is that it is a copyright violation of [1]). I don't mind people who only check unpatrolled pages, but the option to see all recently created pages, independent of their patrol status, needs to remain available.

Another major problem is that pages that have been created in the userspace and get moved to the main namespace need to be added to the NP queue as well. Currently this is not the case, and it lets many problematic articles slip through. Fram 08:45, 23 September 2011 (UTC)

Perhaps special:new pages should be programmed to have a four-tier colour highlighting code for the duration of its 30 days, for example:

1. Yellow = unpatrolled (not edited since creation)
2. Orange = has received minor edits and/or maintenance tags (stubs, orphan, uncat, typos, moves for typos in page name, format, copyediting, linkrot, etc.)
3. Red = Has been CSD, PROD, AfD'd, or tagged for serious issues such as Copyvio, noref, linkspam, etc.
4. Green (or no colour) = passed OK for inclusion (perhaps with only minor deficiencies).

Additionally, and as part of the editor retention policy, Twinkle could place polite messages on the creator's tp when a new article is tagged for maintenance, rather than only when tagged for some form of deletion. This is something I do regularly, manually, using my own custom messages. Kudpung 09:12, 23 September 2011 (UTC)

I agree that we need a multi-colour solution. But I wouldn't combine those that need urgent attention with those that have been tagged for deletion and most non-admins would want to ignore. I'd also add an extra choice for New page patrollers, instead of simply "mark as patrolled" give them two buttons. "Ready for mainspace" and "Goodfaith but needs attention" this could then support the following colours:

• Red - probable badfaith article. Contains rude words or other tell-tale phrases, or the author has recently been templated for G3 or G10 creation.
• Yellow other new articles not yet marked as patrolled - much as at present. But maybe a darker shade of yellow.
• pale yellow - a patroller has looked at this article and clicked "Goodfaith but needs attention"
• Grey - currently in the deletion process.
• White - pretty much as now but without the articles tagged for deletion.

As a further refinement we could create an extra flag for confirmed article creator, this could be given to editors who aren't ready for the Autopatroller flag but who contribute large numbers of articles. As their articles don't need urgent attention this could take much of the pressure off newpage patrol and particularly the front of the queue.

The default for special new pages at the front of the queue would be red and dark yellow only. This would be a much more manageable flow that would hopefully lead to fewer errors from people rushing to stay on top of the flow.

Advantages:

1. We would be able to easily find and look at the articles that no-one has even eyeballed or approved the author. Currently there are some badfaith articles that slip past the front of the queue in its busiest moments and aren't looked at until they reach the back of the queue perhaps a month later.
2. Inexperienced patrollers needn't waste their time looking at articles that fellow new patrollers are unsure of - they can leave the pale yellows to those who are confident in dealing with them.
3. There is no longer a need to mark articles with deletion tags as patrolled
4. When someone removes a deletion tag the article reverts to yellow for unpatrolled rather than as at present remaining white.
5. Inexperienced patrollers may be less likely to fall into the trap of expecting there to be a speedy deletion category for everything. Where currently they may be hesitating and not sure what to do they would now have a button to mark an article as Goodfaith, and move on.
6. It would be a simpler system with less actual rework and greater opportunity for people to target the specific areas they are interested in. WereSpielChequers 16:01, 23 September 2011 (UTC)

Thank you (all three of you) these notes. They're really, really helpful in thinking about the different layers of patrolling required. Steven Walling (WMF) • talk 21:47, 23 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Default to the back or the front of the queue?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Newpage patrol currently works as a two stage filter, almost everything gets looked at almost as soon as it is created and most articles are marked as patrolled or tagged for deletion in their first few minutes.

The current default for newpage patrol is the front of the queue, but with a small exhortation encouraging editors to also try the back of the queue. This is reasonably effective at recruiting a trickle of newpage patrollers to start looking at the back of the queue after they have gained experience at the front.

The second stage filter is the back of the queue where the oldest unpatrolled articles are looked at by a relatively small group of generally more experienced Wikipedians.

The front of the queue is the principal filter and the vast majority of new pages, especially the clearcut cases for either deletion or inclusion are resolved at this stage. It can seem like supping from the firehose as more new article come in than any one editor can possibly patrol, this can be disconcerting especially at times when the flow of new articles is greater than the patrollers can patrol at that moment. Some editors make the mistake of trying to keep up and that inevitably leads to burnout and stress.

The back of the queue is less frenetic, with typically two to three hundred articles per day of the backlog. But for the most part these are not clearcut cases as those have been resolved up front, so the need for volunteer time may not be as disproportionate as the workflow would suggest.

Shifting the default from the front to the back would have the advantage of being less disruptive for new good faith contributors, but the disadvantages that the really bad stuff would stick around for longer, and there might be more mistakes as relatively inexperienced patrollers no longer thought they had the option of leaving closecalls to the more experienced patrollers at the back of the queue.

On the whole I'd suggest leaving the default as the front of the queue, but I'd be less concerned if you could find an alternative way to filter out the badfaith stuff as it comes in. WereSpielChequers 15:08, 23 September 2011 (UTC)

This is a good summary WSC, but because the bad faith stuff can be as much as 80% of a day's intake of new pages, I'd like to make some refinements, and some further suggestions.

NPP is a magnet for younger and inexperienced wannabe Wikipedians. Firstly because it gives them a sense of power over the content of one of the world's biggest web sites, a power that requires neither qualifications nor user-group permission, whereas they would need to climb a very greasy pole to become a moderator of even a modest run-of-the-mill Internet forum. Secondly, they love gadgets, and the live feed in the left side bar is a huge attraction - because the special:new pages does not refresh automatically in real time.

The first technical suggestion that needs consideration therefore is to increase (or offer options for) the number of new pages in the side bar feed from its default of only ten page names; interest gets lost as soon as they are pushed off the list by new arrivals. At peak times, new pages can arrive at a rate of one every ten seconds; this is enough to keep several patrollers occupied and what they miss or can't do, becomes dependent on people working from special:new pages or from the back of the list.

The second technical suggestion that could be taken into consideration, would be to introduce a more sophisticated system of colour cding for the highlighting of the entries in the special:new pages as I have described in a posting elsewhere on this forum.

A third technical possibility that could be introduced depends on patrollers being schooled to do all the tasks that are recommended in the instructions at WP:NPP. Similar to the way issues are queued at OTRS (or any other ticket system software for that matter), as soon as a new page is under review, it could be flagged as 'grabbed and in process'. What we are now talking about are refinements to the Zoom Interface that incorporate more of the kind of features of the OTRS interface. Naturally this will only be understood by participants here who are OTRS agents or who have worked on customer support ticket systems. With a suitably qualified army of New page Patrollers, it might even be possible to control all new pages within an hour or two. This would not only avoid a backlog building up, but it would be a work around for the orgiinal p^roposal that Snottywong, Blade, and I designed at WP:ACTRIAL. features could be introduced such as a button 'Send to AfC' that couold automatically leave a mdessage on the creators' talk p)ages such as "Welcome to Wikipedia and thaynyou for your contribution. Your new article has been transferred to Articles for Ccration where it will shortly be reviewed for publication." At AfC it will then either be passes as patrolled, or tagged per usual for maintenance, or tagged for deletion by admins. This suggestion depends however, very much on New Page Patroller being a user right. I've read plenty of arguments against creating user rights, but wehave created them before, some as unbundled admin tools, and some for other tasks such as the now redundant 'reviewer' from the Pending Changes episode - perhaps these reviewers could be the first candidates for an NPP quqlficqtion, but on the other hand, the 'Reviewer' righ was handed out indiscriminately, even to individuals with a known history of disruptive editing.

These are just Ideas, but I hope that anyone reading this, especially the WMF, will accord them due audience, and not write them off again just because they have not been conceived by the WMF staff themselves. Kudpung 04:47, 24 September 2011 (UTC)

Kudpung, I want you to know that I am absolutely thrilled that you are engaging in this conversation. I don't mean that in any sarcastic or ironic way - I'm truly happy that you're here, because even though we disagree about a couple of things, I (and the Foundation, as a whole) value your input. You are clearly an authority figure with regards to this subject.

I, personally, love hearing ideas from "outside" sources. Not because they are likely right or wrong, but because they help to better define The Problem that is Being Solved. I've a philosophy which says that "the problem contains the solution". This means that once you understand the Problem correctly, the Solution becomes obvious.

I actually believe that you and I are in "furious agreement" with regards to the overall zeitgeist of the problem, but our differences come when looking at solutions.

There is a previous thread about "page patrol as a user right" which I've commented on. It describes a scenario whereby patroller right is a gradual process.

I was thinking some more about this and wondering if it wouldn't be possible (in the future) to set up a system whereby "new" patrollers are given what amounts to a sequence of simple tests that could be graduated from.

Let's create a hypothetical system. Let's say we have a "granted" user right for NPP over time. There are a series of pages that have been marked as spam by Fully Fledged NPP'ers. We have them in archive.

"New" patrollers are then given a test. They have to run through a number of pages - say, 30 - and answer "is this spam? y/n?" This contains pages that we KNOW are spam, and some that we know are NOT. And if they get 100% accuracy, they can "graduate" towards checking for attack pages, or copyvio, or whatever.

In this way, we educate people - new patrollers - in a "sandbox" situation so that they are better equipped to hit the "real queue". It's an auto-training mechanism.

How does something like that sound? Jorm (WMF) 05:02, 24 September 2011 (UTC)

In a normal situation it might work, but I have the following concerns, so I hope this posting is not TL;DR:

1. We're sometimes forgetting that NPP goes far beyond just tagging pages for deletion or attention. Done properly and in depth, it's an excellent way of identifying Copyvio, slow burning vandals, and sock puppets, and bringing them to justice. The Copyvio issue is especially urgent since Corenbot is down, so we don't quite have forever to find an alternative to ACTRIAL.
2. We're dealing with a vast army of youngsters and/or near-but-non-native English speakers who make up the majority of the transient pool of patrollers. I've already mentioned why patrolling pages at Wikipedia attracts them.
3. We probably don't have the reserves of people power to put the NPP candidates through the hoops you suggest. Also, to do so would be to make them run a similar gauntlet to the questions that get posed at Requests for Adminship (RfA) on the English Wikipedia, and we all know what a fiasco the current RfA system is.
4. They would soon figure out the answers to the questions through their off-Wiki communications. Just for example, I get candidates asking me off-Wiki , how they should answer a question that has just been posed on their RfA. I tell them they have to figure it out for themselves, but NPP is run by kids, for kids, and kids help kids - they even organise competitions among themselves to see who can tag the most pages in an hour and award each other barnstars for it. It's a question of maturity vs.adult responsibility, vs. cognitive levels for grasping the huge and unwieldy catalogue (and growing) of CSD & often vague and ambiguous notability criteria. To illustrate this last point, I've been around on Wikipedia a while, I'm even an admin, and I'm not a stupid person (I hope) but even I don't have it all consigned to memory and I still often have to look stuff up sometimes before tagging something, or commenting on or closing an AfD. The irony is, that by the time I've found it, and run all the other strictly required NPP controls, an NPPer has tagged the page already, and more often than not, incorrectly of course.
5. Because of the speed with which the kids want to patrol pages - without doing the other tasks that are supposed to be done as described in the instructions at WP:NPP - as soon as they have got themselves 'qualified' there is a high risk they will revert to their old superficial patrolling methods.
6. Hence, the idea to make NPP a 'gatekeeper' task, which you are leary of on the one hand, but perhaps coupled with a test that on the contrary, you are suggesting. It would still therefore be a user right nevertheless, and out of it we might achieve quality patrolling based on a carrot & stick principle., i.e. giving them a right gives them a sense of responsibility and a user right they wouldn't want to lose by abusing it. As I 've mentioned before, this would be a much better solution than blocking them from editing the entire Wikipedia as I unfortunately occasionally have to do, i.e. using a sledge hammer to crack a peanut.
7. The challenges of implementing a software controlled environment for this user right are, however, immense. Whether we select them through a test - or by any other method (see below), how do we - or more accurately, the devs - find a technical method for enforcing it? The vast majority of truly established users are perfectly capable of patrolling a new page, and as some of them occasionally do - they would need to be automatically included in such a right.
8. If we could agree to move ahead on that principle, and continue to encourage children and offer them a chance to participate in the making and running of Wikipedia, then your 'Zoom ' control panel for NPP would be an excellent tool, and help avoid mis-tagging - especially if a few refinements could be incorporated into it such as on the OTRS software.

Snottywong, Blade, and I (and a lot of others, as established by the RfC) clearly identified and classified the Problem, and came up with the solution of restricting the creation of new pages (as opposed to new articles) to autoconfirmed users, while at the same time offering some ideas (three) of fast-tracking the creation of new articles for serious authors. This would certainly have been the simplest solution, and easy for the devs to implement. I nevertheless do now believe that the WMF, as a result, is now genuinely committed to devoting resources to finding better solutions even if those solutions might put greater pressure on the developers to implement them than ACTRIAL would have done.

Steve's (or your) Zoom is a start, but it's still a bit like inventing the automatic gearbox for automobiles where everyone who can drive safely is already quite happy with a manual gearshift. What we need to do is to teach the NPPers to drive the car first, and get them to pass their driving test. Then they can have the luxury of the automatic transmission.

I think we already have a functioning system for according minor rights, such as for example a new one for NPPers, to users of the right calibre. It's at Requests for permissions. The admins who watch that page regularly and accord these rights are pretty good at it. And finally, I still believe that ACTRIAL is still worth the trial. if not adopted as a permanent measure, it would certainly provide us with a lot of urgently needed stats that we still desperately need for correctly focusing on any alternative solutions we suggest. The fears that such a trial would lose us serious users are totally unfounded.

Nevertheless, in keeping with that important policy of user retention and finding ways to make the new user experience more enjoyable, a parallel project must be conducted to develop those 'fast-track' ideas that were also proposed as part of ACTRIAL. I feel therefore that it is also essential for the WMF to allocate discussion and resources to improvement of the New Article Wizard, and make it as much a priority as this NPP issue. While it is a separate issue from the point of view of those who can design the GUI and the programmes behind it, it cannot be divorced from this NPP issue - the two solutions go hand in hand. AFAIK nobody is actively developing the Wizard right now, but I may be wrong. Kudpung 11:44, 24 September 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Delayed action tags

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

One of the perennial problems at New Page Patrol is the dissonance between the instinct of newpage patrollers to tag everything as fast as it comes in and the desire of article creators to create articles incrementally saving a sentence at a time. At Special Newpages this is a recipe for edit conflicts, bitten newbies and patrollers whose RFAs combust when the community assesses their tagging.

A partial but simple solution would be to put a time delay on certain edits.

So when a tagger uses the new Zoom feature to tag a new article as A1 or A3 the software could simply tell them that "As the article is only 4 minutes old the tag will be added when the article is one hour old, provided it has not been edited in the meantime". If the article then changed colour within Zoom and wasn't shown to other zoomers it would prevent those awkward newbie biting moments. If the article wasn't edited within its first hour it would then be tagged; If the article was further edited then it could in effect go back in the unpatrolled queue for further consideration. WereSpielChequers 15:20, 27 September 2011 (UTC)

I'd certainly like a person re-visit queue of some type. Right now when I see a new article that would qualify for A1 or A3 I have to remember to go back to it later. Of course when I do go back I often find it already tagged by someone that didn't wait. I would also be good to quantify some minimum wait time. As it stands now the time to wait is completely vague. Eeekster 01:48, 28 September 2011 (UTC)

Any competent patroller would know about the 10-minute rule. A forced minimum would be helpful, but what about something like an article called "where can i do foobar" with the content "Hey guys i dont know anything about foobar so i was wondering if you could tell me stuff about it", or worse, stuff like "What was today's homework for foobar class?" that are glaringly obvious that the page creator cannot be arsed to expand further on the topic? As A3 was designed to cover those types of pages, the 10-minute rule would be a barrier to preserving Wikipedia's quality. →Στc. 04:49, 28 September 2011 (UTC)

What ten minute rule? I haven't seen any rule specifying a number of minutes. Eeekster 04:42, 29 September 2011 (UTC)

Research and empirical evidence has shown that we don't actually appear to have many active competent patrollers. Unfortunately, even the more experienced ones don't always wait either. Kudpung 04:44, 29 September 2011 (UTC)

Perhaps we could create a hard time limit for inclusion of various templates for new patrollers, and then when they become more experienced, open it up and make it an alert that theyd'd have to click through instead. That way the software can keep track of the time, but with experience it would start trusting you to use your judgement about what to do. Raindrift 23:40, 29 September 2011 (UTC)

This again relies on the possibility of creating a user-group for patrollers Kudpung 00:22, 30 September 2011 (UTC)

Hi Raindrift. At the moment the only ones where we have consensus not to apply them immediately are A1 and A3. Whether other articles and especially some of the A7s should be applied to brand new articles is contentious.

As for the hard time limit idea, I'm not convinced it would work. I think you'd risk having some patrollers get confused, and others use a different speedy tag. What do you think of the idea that taggers could still use zoom to click A1 or A3 but that it would then say "As the article is less than one hour old, Your edit is being stored and the A1/A3 tag will be added in x minutes if the article has not been further expanded." Ideally you'd want Zoom to bring the article to the attention of that zoomer or another if it was subsequently expanded and is an hour old "this article was going to be tagged A1 but has been subsequently edited". WereSpielChequers 08:06, 3 October 2011 (UTC)

I think it's nevertheless important to catch the creators while they are still online and logged in. Perhaps a Twinkle feature to put a message on their talk page such as:

Welcome to Wikipedia and thank you for contributing a new page at XXXX. Please consider substantially expanding this article in the next 30 minutes to avoid it eventually being deleted. Alternatively, you may wish to develop it in your user space at User:username/articlename (draft) or through the Article creation Wizard. If you are not sure how to do this, don't hesitate to ask me for help on my talk page. Kudpung 09:02, 3 October 2011 (UTC)

Um actually the idea behind this proposal is to try and not interrupt people while they are creating their new article, and especially not to threaten to delete their article after their first sentence. A Twinkle feature to warn editors to expand their article or see it deleted would be pretty much the same as allowing A1 and A3 tags in the first minutes of an articles life, and that is unlikely to get consensus. WereSpielChequers 09:31, 4 October 2011 (UTC)

Again, this depends entirely on how the messages are worded. Research has shown that most newbies don't know that these messages are templates and that's why they get browned off. Note that the messages I use are not TLDR diatribes with shedloads of links to obscure policies; I tend to think a creator would be really happy if someone came on line, saw what they were doing, and offered some help to get it right. I know I would, but in the days when I created my first pages, I didn't even receive a welcome template for month - and when it came, I had no idea it was only a template and I was overjoyed at thought that someone 'up there' had really noticed my painstaking work on wine. In fact one of my very first edits was to create a cut 'n paste move - I had absolutely no idea where all the rules were, especially for repairing a misspelt page name, and nobody noticed and put me right - or chided me for it! Kudpung 13:37, 7 October 2011 (UTC)

I'm not convinced this is a wording issue, politely interrupting someone to tell them you have a problem with their new article is still going to be perceived as an unwelcome interruption and a rejection of someone's work.

Clearly we have two very different interpretations of newbie behaviour. Some people it important to template them during their first edit session, others including myself think it important not to. A bit of research might establish whether either view is correct, or whether some combination would be better. For example how cool would it be if someone was trying to save a page of Arabic text on the English language wikipedia and the the system said to them in Arabic and English "This is the English language Wikipedia and that page seems to mostly be in Arabic. Would you rather add it it to the Arabic Wikipedia? Yes/No. And if they tick yes it moves them and their page to the Arabic Wikipedia. WereSpielChequers 13:51, 31 October 2011 (UTC)

For me, it depends on what the new user has done. If I've come across someone who clearly doesn't understand that we aren't MySpace, I will tell them that they should consider going to a social networking site instead; I find that heads off those kinds of problems at the pass. When I encounter the types listed here, a template is fine; I'm not going to spend any length of time writing a custom message to someone whose first edit is to brag about his gigantic penis. However, I think the handwritten approach is effective with people who look like they're well intentioned but just screwed up; those are the sorts we need to focus on. I also really like your idea about redirecting people to the correct language Wikipedia above; I see that happen with some frequency, and I think that would make it a lot easier for everyone. The Blade of the Northern Lights (話して下さい) 23:40, 1 November 2011 (UTC)

I don't think the problem of articles in other languages is as common on wikis in languages other than English... Helder 19:03, 7 March 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Two other "in situ patrolling" interfaces

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

For reference during our process, there are two Huggle-like interfaces for New Page Patrol that exist:

1. Kissle
2. NPWatcher

Neither of them seem to be very commonly used, but I thought I should point them out since they're shooting for the same end goal. Steven Walling (WMF) • talk 22:57, 27 September 2011 (UTC)

The last comment about NPWatcher was that it was buggy. That was nearly two years ago. See: w:en:User_talk:Martinp23/NPWatcher Kudpung 07:08, 3 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Finally!

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Finally, an in-wiki program for patrollers. This is long overdue. A couple of questions:

• Would it be difficult to adapt this for regular vandalism patrols, too? That would make Huggle essentially obsolete, but it'd be more convenient.
• Is a mobile version of this planned or considered at this point?

I'm really liking this approach because it means everything can be done in a web browser rather than a separate application, and there's no need for sometimes buggy scripts or gadgets. Fetchcomms 04:06, 28 September 2011 (UTC)

Two questions, two answers:

• No. In fact, this is where I think we should go for all our curation tools.
• Yes. In fact, the design is focused towards mobiles and tablets. Jorm (WMF) 04:18, 28 September 2011 (UTC)

Two answers, two comments:

• I agree that all tools should be available through the browser, that way there would be cross-platform compatibility and the users of OSX and Linux would not be denied the privileges of them.
• I've lost count of the times when I have corrected a patrollers's tag and left a message on their tp, to get an answer on the lines of: "Yeah, I'm editing from my iPhone on the school bus." With all the other problems, is priority development time for mobile platforms absolutely essential? Kudpung 04:54, 29 September 2011 (UTC)

I'm a bit nervous about having this designed specifically for mobiles, especially before we find out the proportions of mobile and PC users among the patrollers.

Many of the opportunities to improve the process rely on using the screens and keyboards of PCs. If everything has to be mobile compatible then we risk losing some opportunities to really improve the process.

By all means make sure there is a mobile version, but please don't constrain the PC version to the same limitations. For example with a mobile version I would expect that rather than have a mix of patrolled unpatrolled and if we implement it other colours on the screen you would choose the colour stream and just surf through that.

Also I'm very worried that mobile editing might exacerbate the trend from improving articles to templating them, presumably it would be easier to look at an article on a mobile and choose the relevant template than it would be to actually improve the article?

I'm one of those who suspects that the rise of templating since 2007 is a cause of the decline in the community and the increase in snarkiness that has happened in the same period (though I appreciate there are some who see the two simultaneous phenomena as unrelated and coincidental). So I would be concerned about a new page patroller tool for mobiles that exacerbated the templating trend. WereSpielChequers 08:37, 3 October 2011 (UTC)

Considering that it is hard to write substantial amounts of text on mobile/tablets, I think you're correct to be wary of creating more shallow kinds of participation in the new page patrol process. But I think there are ways we can engineer the interface to avoid templating and other kinds of impersonal interactions between people. Steven Walling (WMF) • talk 03:54, 7 October 2011 (UTC)

I've just done the mobile platform survey. FWIW, I don't use my smart phone much for Internet stuff, but from what I see, I believe it would be most inadvisable to even suggest that serious maintenance work by patrollers and admins should be carried out on one. See my true anecdote that I posted somewhere else about a patroller who was patrolling on his iPhone in the back of the school bus! Kudpung 03:59, 8 October 2011 (UTC)

I've done project-related patrols from my iPhone while I was walking at a fast pace outside at night to get exercise and fresh air. Mobile is the future, and you'll eventually be able to connect to eyewear for a full screen effect or you'll be able to project the interface on a wall or flat surface. I'm surprised that anyone would even be against this. Viriditas 11:08, 9 October 2011 (UTC)

At the current level of NPP, I believe it is unlikely that our patrollers would invest in such technology. As I've said before, I do not believe that walking down the street or sitting in the school bus are ideal places for doing concentrated serious maintenance work on the encyclopedia. I really feel that mobile solutions are a low priority here - most people probably do such work from the comfort of their home, office, or school computer room, using a desktop computer, or a laptop with a large screen. A survey on NPP that is due to be launched shortly may shed light on these issues. Kudpung 01:47, 11 October 2011 (UTC)

I couldn't disagree more strongly. The desktop computer is dead in the water and will really only be used for hardware support, under the hood. On the frontend of human computer interaction, we will have gestural input in the air (Leap Motion), virtual retinal display (Google, Microsoft) touch screen tablets embedded into common surfaces (Microsoft Surface) and projection of virtual desktops from your cellphone on any flat surface (LG, Samsung, etc.) This is not science fiction, it is happening right now as I write this screed. As far as users, your comments about what people are doing and how they are doing it is far, far off the mark. Go outside. People are walking down the street and sitting on the bus working on tablet computers. The idea that people a year from now, will still be working primarily from their home, office, and computer room using a desktop computer is WRONG. We are slowly evolving into the pervasive computing paradigm. I can imagine, let's say a year from now, where page patrollers are decoupled from any desktop, with many having trouble understanding what a "desktop" is supposed to be. The page patroller of the future might have a pair of sunglasses on (during the day) which will alert him or her to any new pages or edits made to articles based on his location, giving us a pseudo-amateur-expert approach based on location aware patrolling features. This kind of decentralization of patrolling will distribute the crowd around the world and allow us to monitor topics in real time based on where we are at the moment. Continuing to think in terms of sitting down at a computer in front of a desktop is just ridiculous. Data will be delivered, not scanned, content will be entered with the help of virtual keyboards we can type in the air, not from a piece of plastic, and screens will appear everywhere, even embedded into the sleeves of our clothes. With the maturation of cloud computing services, it won't matter what device you use (and such arguments will seem peculiar in a few years) because the data will be pervasive; you will access it from all devices. Desktop computing is important to the future of Wikipedia in the same way that typewriters are important to the future of book publishing. Viriditas (talk) 00:40, 25 May 2012 (UTC)

This is probably only possible with holographics. But I agree that if we could have virtual keyboards in the air, as well as virtual screens, we would no longer have the main drawbacks of smartphones and tablets. Jasper Deng (talk) 01:00, 25 May 2012 (UTC)

It's possible now with tablets and Leap. Imagine page patrol in an app which allows side scrolling pages which can be pushed in either direction to browse the queue. People using this interface will have the ability to also "grab" a page and "toss" it in a cleanup queue, where other editors will pass it on or fix it. Now, imagine extending this interface in 3D. You could view the entire life cycle (timeline) of an article like a plant growing from a seed into a flower, and play around with branches and leaves of that plant to link disparate editors, related topics, etc. Viriditas (talk) 03:31, 25 May 2012 (UTC)

That would be quite a lot of programming and engineering... Jasper Deng (talk) 03:39, 25 May 2012 (UTC)

I don't think so; most of this stuff already exists, probably as open source. Is it WebKit that allows one to side scroll through web pages in Safari on the iPhone? Has anyone experimented with side scrolling features? This would make page patrol much easier and pave the way for gestural input. Viriditas (talk) 04:58, 25 May 2012 (UTC)

Well, I was talking about 3D. Jasper Deng (talk) 05:03, 25 May 2012 (UTC)

While I disagree with Viriditas on mobile phone usage, this probably will have to be a mobile feature. If the WMF doesn't have one, a third-party dev. could make one. Jasper Deng (talk) 00:55, 25 May 2012 (UTC)

On this topic: the current beta of the New Page Feed works pretty well on mobile Safari on an iPad. I'd encourage anyone interested to give it a try. Steven Walling (WMF) • talk 20:00, 25 May 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

KISS

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Keep it simple! For me, I just have a gadget on my sidebar, and then we go! The thing, I would like is at the bottom, there is the info of the last revision, to tag the page, CSD. That being on the top (not history), makes me have to go up and down, up and down. Also, by marking as reviewed, please make it so that the {{New unreviewed article }} disappears. Ebe123 (talk-to-me hour) No returns! 10:32, 28 September 2011 (UTC)

Not a reply, but a add-on - coming from meta:Research talk:New Page Patrol survey#What a mess!.

I've read a couple good ideas in here - like making the patrol-link easily accessible, or marking as patrolled as soon as a 'patroller' edits the article; or making it easier to sort and pick new pages. But overall the proposal is absolutely horrible and un-wiki, as I understand it. You are trying to make a full blown graphical application. I presume someone thinks that is good, this forum works more or less on thal principle, no? Well, this forum is horrible. I had to wait for a page to load while it goes bumping all over has stuff gets loaded and suddenly gets hid away by some Java-thingie. Someone is overdoing it. Reminds me of a nice text about game design over-developing, not exactly the same here, but close enough. Please, keep it simple. Probably all it needs a some simple aid (say some bot could help categorise and sort, also largely reducing the number of templates). - Nabla 16:26, 8 December 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

NPP training

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

So an user called Physics is all gnomes conducted NPP training. How about patrollers could do more of the type and with the right, already experienced patrollers can give the permission such as Image-reviewer on commons:. Ebe123 12:58, 2 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Enable No Index in mainspace. Put Noindex in badfaith speedy templates and all articles until patrolled

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

One of the problems of the current system is that {{Noindex }} doesn't work in mainspace - if it did we'd be putting it in the templates for G3, G10 and probably G11 and G12. But if it is now possible to get IT resource to improve NPP then maybe we can start thinking big.

If unpatrolled new articles all had noindex then we'd have some huge painless changes at NPP.

Noindex would mean that Google etc would ignore and not cache these articles or add them to search engine until they were patrolled.

Attack pages and vandalism which currently persist in Google caches would be gone as soon as we'd deleted them.

Spammers who rely on the Google caches and that sometimes their spam persists for weeks would find us a much less tempting target. Some of them might even go elsewhere or try to write in a somewhat less spammy style..

Immediatists who don't want us to accept poorly formatted unsourced new articles could console themselves that unpatrolled new articles were effectively drafts.

Goodfaith Article creators wouldn't get bitten because they wouldn't know their pages spent its first hours or days noindexed, just as today they don't know if their article has been marked as patrolled or not. So no newbies would be bitten by this change, but presumably all the people who wanted to not have a large subset of these articles created would see this as an improvement. WereSpielChequers 23:52, 2 October 2011 (UTC)

Support!

But what if vandals had bots that would noindex featured articles and such? →Στc. 07:04, 3 October 2011 (UTC)

Well one option would be to limit this to unpatrolled pages, that would be difficult for vandals to game as they don't have a "mark as unpatrolled" button. I'd like to also noindex anything that is tagged as G3 or G10, and that sometimes includes very old articles. But if there isn't an easy way to do this then I could leave with this just being unpatrolled articles. However if we could limit it to that then I think our FAs would be safe. If vandals start tagging Featured articles as G3 or G10 then the noindex aspect would be the least of our worries, if anything it would be a positive, as the brief moment when an FA was vandalised would not get Google cached.. WereSpielChequers 08:53, 3 October 2011 (UTC)

"What if vandals had bots that did foo." is a standard question. The answer is we'd block and revert. Rich Farmbrough 01:08, 21 February 2012 (UTC).
01:08, 21 February 2012 (UTC)

As Σ points out, the potential for abuse of {{Noindex }} in the mainspace seems really dangerous. Can you imagine what would happen if a particularly prolific or sneaky vandal managed to noindex any number of legitimate articles?

I think it's an important part of incubator-style spaces (such as what's proposed in Article creation workflow) that they be noindexed. But endangering our core mission by potentially preventing search engines from finding articles in the mainspace is a big risk to take.

Also, considering that many new articles (such as those about disasters or other breaking news) are extremely valuable, I can't imagine we'd want to have to wait for the backlog of patrolling to be done in order to make them visible to readers. Steven Walling (WMF) • talk 03:31, 7 October 2011 (UTC)

This is a case for adding a 'No index' feature to Twinkle that automatically noindexes any articles that are not good enough for publication but that might be eventually kept.

Before we get this far though, I think we need to consider a new page patroll process, similar to AfD or PROD, but not a proposal for deletion, that would noindex a page, send it to AfC, and leave a nice, friendly message on the creator's talk page. A not very often used solution, is to move pages to a creator's sub page. Very similar rally. I don't know if or where we have discussed such possibilities before.

These are also solutions that could be integrated in some way into the Creation workflow interface. BTW: is there actually any further development on that taking place? If ACTRIAL is never to be implemented, we need to be looking actively at these solutions, as well at further development of the Zoom tool. Kudpung 08:15, 7 October 2011 (UTC)

As far as, "noindex a page, send it to AfC, and leave a nice, friendly message on the creator's talk page" I heartily agree, though I would hope that rather than having to manually move to AfC and noindex, we could have tools to demote articles to the noindexed draft workspace Brandon described in Article creation workflow. A single click to "move to draft" rather than tag/delete would save a lot of newbie biting and still remove articles not yet up to snuff away from the mainspace and search engines. Steven Walling (WMF) • talk 20:43, 7 October 2011 (UTC)

Y

Agzin, as I have said many times, the sucess of tis would depend very much on patroller education - they should not use this feature indiscriminately instead of A1, A3, or PROD, for example. es, that's exactly what I had in mind. It's not difficult to programme Twinkle to automate these steps:

1. 'no-index' the page
2. Move the page to AfC or pre-titled user sub page
3. Semi-protect the page for page moving
4. Leave a nice friendly message on the user talk page.

This would of course depend very much on patroller education; we would not want them userfying pages indiscriminately instead of A1, A3, PROD, etc.

Who is actually developing Zoom - is it Ian or Brandon? Kudpung 03:40, 8 October 2011 (UTC)

Zoom is still in the design phase, so I am on point here.

I just want to point out that there are possible legal issues with automatically assigning NOINDEX to non-patrolled articles (which I would love to do). The issues stem with the idea of the Foundation expressing editorial judgement. We have a meeting with the legal team about this scheduled, but it won't be for a while yet (given that we have a week of "all hands" activity, followed by some vacations).

It is currently our plan to have our basic business requirements developed over the next two weeks, after which we begin a deep design phase. I can't speak to development resources (Ian is actually only working on this in his spare time - he isn't tasked with it) - so I don't have any schedules for that to give. Jorm (WMF) 03:44, 8 October 2011 (UTC)

Two points: 'no-inxex' wouold only apply to pâges moved to AfC or a user sub page - which as far as I know, are not indexed anyway. The main problem s that all new pages are indexed by Google at the speed of light, long before patrollers get to them. Kudpung 03:51, 8 October 2011 (UTC)

Yes. My ideal solution would be that an article is set to "NOINDEX" until it has been patrolled. However, as I said, there may be legal issues with this regarding the Foundation as an entity exercising editorial judgement. I don't think it's a problem, but I want to make sure we have coverage on it first.

And, to be honest, I'm willing to open a bug about this the instant we get the "okay". It seems like an obvious and simple thing we can do, and do quickly. Jorm (WMF) 21:00, 8 October 2011 (UTC)

Sound good. Even though we only have up to about 7 patrollers working at the best of times, Most pages, excep tthose that are so difficult they end up on the backlog, get viewed by a patroller within a few seconds, so unless they are summarily deleted by an admin on patrol or tagged for CSD or PROD , they would be marked by the pagtroller as 'patrolled' and indexed. This wouldn't stop them being visible, but it would prevent the Search engines getting them and caching them.

I still think that a useful new feature to add to Twinkle (and Zoom) though, would be 'userfy' really bad pages that could be improved by the author in time, but would be unreasonable to leave live online as PROD or BLPPROD. I've provided the automated steps somewhere else on this page. Kudpung 05:17, 9 October 2011 (UTC)

Userfy is contentious, partly because we don't know whether it comes off as any less bitey than deletion. Very occasionally I userfy something that the editor probably did intend to put in their sandbox or userpage, but I wouldn't suggest it for potential articles.

I wouldn't worry to much that anyone is going to argue that the Foundation is exercising editorial control as to whose articles are noindexed or not. Appointing admins and autopatrollers and marking edits as patrolled are all volunteer actions, not Foundation ones. Also no indexing new articles is a bit like flagged revisions, except without the snarky bit about telling people their edits are not live until they've been checked. The new pages would still be live, they'd just take a little longer to come up in search engines. WereSpielChequers 23:00, 10 October 2011 (UTC)

- and I believe preventing some article from showing up in search engines is the main issue. I still think 'userfy' is less understood by the NPPers, and not used often enough. The question of biteyness is one that can beaddressed in the mesage that goes with it. Unfortunately, some of the people who write the text for user messages and warning templates may not have the right kind of experience in human communications. Kudpung 01:55, 11 October 2011 (UTC)

That wouldn't be a problem since it is non-specific. Rich Farmbrough 13:39, 21 February 2012 (UTC).
13:39, 21 February 2012 (UTC)

I can't imagine that a breaking news story would be no-indexed for long if at all - remember all admins and Autopatrollers create articles that are already marked as patrolled, and most articles are tagged for deletion or marked as patrolled in their first few minutes. If we get the change that would display the "mark as patrolled" button to any experienced user then there is no risk of a significant newsevent being noindexed for even as long as ten minutes.

As for the risk of abuse in Mainspace, that would depend on how it was done. The most secure way would be to make this a feature of being patrolled. Since editors can't unpatrol an article they wouldn't be able to noindex one. I'd prefer that it also picked up on the G10 and G3 template and I suspect it would be possible to do this in a way that limited Noindex to those templates. But I wouldn't get too concerned at the risk of vandalism using the noindex tag, what motive would vandals have to hide their vandalism from people outside Wikipedia? Putting a penis photo in an article and simultaneously adding noindex would just mean the mirrors were less likely to repeat the vandalism. WereSpielChequers 12:03, 7 October 2011 (UTC)

No index is only dangerous in mainspace if you allow it to be applied indiscriminately. Currently even admins can't mark a patrolled article as unpatrolled, so making unpatrolled articles no index should be pretty safe. I can see that tagging G3 and G10 articles as no-index would be a little tricky to do without somehow enabling people to noindex an article without tagging it for deletion, I'm hoping the devs will say its possible; If not we'd have to just limit the idea to unpatrolled articles. WereSpielChequers 22:47, 10 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Effectiveness of "catching the creators while they are still online and logged in"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

One of the big divides at NPP is between those editors who think it is as Kudpung put it "important to catch the creators while they are still online and logged in". And those of us who think that while it is good to quickly warn bad faith editors, good faith editors respond best to being helped, having some slack cut for them and being given a little space; But are driven away by threats to reject their work and delete their article. This divide makes certain changes difficult to agree because we have very different perceptions of the problem, there are some changes that don't involve this and that both sides can support, but making changes at New Page patrol would be much easier if we had some research behind this to show whether very promptly templating articles and warning their creators encouraged or deterred the creators from fixing their articles, and in particular whether doing this very quickly was either more effective at getting articles improved or more efficient at driving newbies away .

I've done quite a bit of trawling through the BLPprod queues, and while I'm not claiming any statistical robustness, my impression is that if articles with a BLPprod tag get rescued it is usually an experienced editor who does so. But I would be open to persuasion on this, as I hope would be those who take the opposite view to me. Speedies are harder to measure in this way because they get deleted so quickly I find it difficult to spot ones where the author has been spurred on to make greater efforts to improve their article by the threat of deletion.

If we do some research it would be important to focus on the relatively recent data, as earlier this year the system on EN wiki was changed to default to emailing editors when they received a talkpage message. One would presume that this would reduce the advantage of catching the editor before they left.

Whether the results showed a pattern that the quicker the templating the less likely the editor was to stay, or the reverse, I believe it would be much easier to improve NPP if we had some research. I remember trying to get something like this into the WSOR program for 2011 and we might be able to use some of the datasets created for that program. NB G3, G7, G10, G11 and G12 tags need to be excluded, or better still the results analysed by deletion code otherwise you risk this being skewed by our effectiveness at targetting attack pages and driving away vandals. WereSpielChequers 10:14, 4 October 2011 (UTC)

Any solution(s) has:has to be addressed around the three main players: 1) The NPPer, 2) the article creator, and 3) the deleting admin (in the case of CSD). Gathering research is difficult and probably the best indication is the empirical experience from the kind of new page patrolling that I have spent 50 or so hours doing over the last few days. If anyone wants some feedback on how the patroller are performing, they can go herehttp://toolserver.org/~snottywong/cgi-bin/patrolreport.cgi than work their way systematically through the list looking at all the articles that have been patrolled, and if they have been wrongly patrolled, checking the NPPers' talk pages to see if they have been warned before, and than correcting any mis-tags on the fly. I'll list some points that I have mentioned many times before:

1. NPP needs to be either a right, or NPPers must undergo some form of gtraining. I have suggested a video turial as the best solution.
2. Article creators are often SPA and don't come back to see what has happened to their article. Almost all new pages are by newly registered accounts.
3. Do the deleting admins always check what has been tagged? Or do they take the NNPers at their word?Solutions:

• Train the NPPers and make NPP a user right.
• De-index and move very poor but possibly salvagable articles to AfC or user space; With of course a suitable message to the creators:

Welccome to Wikipedia and thank you for your contributions. The article articlename that you recently createdis unfortunately not suitable for immedate publication and has been moved to [xxxxxxxxxxx where you will be able to develop it further without fear of deletion. When the article is ready, it can be moved back to mainsspace by an established editor. Thank you, and happy editing!

• Get Twinkle to leave a message on the creator's talk page when any maintenance tag is applied. What takes up most of my patrolling time is placing custom messages such as:

Welcome to Wikipedia and thank you for your contributions. The article articlename that you recently created has been flagged for urgent attention. Please consider returning to the article and addressing the issues that have been pointed out. If the artice is likely to take longer to develop than you thought, perhaps you would prefer develop it in your user space. - an editor could move it there for you. Thank you, and happy editing!

Such features would be extremely easy to implement - but it appears these suggestions are not making resonance. As no solution for CorenBot seems to be forthcoming, and in the light of the dozens of new articles (all slated for deletion) coming from India in the wake of the India Education Program, something needs to be done quickly. Kudpung 02:35, 7 October 2011 (UTC)

I think we have threads for those suggestions, some I agree with and some I don't. The problem with using Twinkle to tell article creators about tags placed on their new article is that it may well be counter-productive. I'm aware that there are people who think it important to communicate with newbies before they log off. But there is the alternative interpretation that we are driving away newbies with our templates and warnings, and if that is the case doing that more thoroughly will drive away more newbies more quickly. Since the divide is in people's perceptions of what is going on, I'm suggesting that we undertake some research to see whether rapid tagging is an efficient way of driving away newbies or an efficient way of getting those newbies to improve articles. Until we have such research it would be wasteful to invest in making the NPP process more efficient at templating the newbies. WereSpielChequers 12:14, 7 October 2011 (UTC)

It depends how the templates are worded. Researcx has already shown that most newbies believe the first messages they get are hand-written. I do it all the time, and with great response from the article creators. Unfortunately, where everyone wants stats, there are no metrics to prove it. Kudpung 13:16, 7 October 2011 (UTC)

What research showed that? I've seen pretty clear evidence that people who receive the current, passive voice and institutional-sounding templates think that Wikipedia is automatically warning them, rather than it being communication from a human being. Steven Walling (WMF) • talk 21:10, 7 October 2011 (UTC)

Wiki is a huge place, and I can't remember where I saw it, but I certainly did, because it's one of the areas I work on. You hit the nail on the head though when you said 'insitutionalist sounding', and that's the brunt of the problem. I have never understood why at en.Wiki we can't have friendly messages instead of the pompous walls of text that are usually composed. Based on my old studies of comm.sci,, I have a very good idea why this is. All UK government official documents have lost their Dickensian touch over the last decade or so (probably thanks to the Internet) and websites are friendlier - even when applying online for a new passport or driving licence! To enhance the new user reception and experience, these concepts need to be borne in mind. The de;Wiki is different, almost everything in German sounds official, though I greatly appreciate that their more modern and more frequent use of 'Du' on their Wiki is very refreshing. Unfortunately, English is one of the few European languages that does not have such a distinction.

Note that the messages I use are not TLDR diatribes with shedloads of links to obscure policies; I tend to think a creator would be really happy if someone came on line, saw what they were doing, and offered some help to get it right. I know I would, but in the days when I created my first pages, I didn't even receive a welcome template for years - and when it came, I had no idea it was only a template and I was overjoyed at the thought that someone 'up there' had really noticed my painstaking work on Thailand articles. In fact one of my very first edits was to create a cut 'n paste move - I had absolutely no idea where all the rules were, especially for repairing a misspelt page name, and nobody noticed and put me right - or chided me for it! Kudpung 02:51, 8 October 2011 (UTC)

I think we need to remember that communication is not just a matter of posting messages on talkpages, communication also includes interacting by editing the same article. My modus operandi is to do a gnomish edit on an article, spot that another editor there has a redlinked talkpage and drop them a welcome template. I don't know whether 9% or 90% of newbies connect the two events, but my assumption is that at least a proprtion of editors think the same way as me.

However there is a huge easy win awaiting whoever starts testing welcome messages and announces which ones work better than others (from my direct marketing days the one thing I'm sure of is that the messages that work best won't be the ones that a random focus group would predict would work best). WereSpielChequers 23:14, 10 October 2011 (UTC)

I have found a lot of BLP prods are rescuable, but I know that several people work at the back of the 10 day queue. So it's hard to judge what gets lost that shouldn't. Rich Farmbrough 01:10, 21 February 2012 (UTC).
01:10, 21 February 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Queue/Stack Ordering

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

So, we've been talking about the list of New Pages as a queue. People either work from the front or the back of the queue, as it were. I want to step outside of that thinking and propose a different system because there are several problems with it (not the least of which being that people edit conflict each other when working on the same side of the queue).

Let us instead think of putting new pages into a "stack". This is programmer terminology, so I'm loathe to use it, but it's a more accurate term. A "queue" is a stack, but it's got a specified direction: "First in, first out" (FIFO), or "Last in, first out" (LIFO). Currently, patrolling from the front of the queue is a FIFO process, and patrolling from the back is a LIFO process.

We don't have to be bound by this idea. We can create unique stacks per user. We can also do things like "filter by categories" or other metadata that might be easy to pick up (and, in the future, with better metadata tags, get even fancier). Unique stacks would also help to alleviate edit conflicts and double patrolling.

Consider a system like the following:

Say that there are 1,000 articles in the total queue. They are (naturally) ordered by creation date. We have five people who start "Patrolling".

For each of those five people, the system will randomly select 20 articles from the entire queue, shuffle the order, and then present them to the Patroller. No two people will get the same articles as long as they are in the same "patrolling session". So if I start a session, the system may assign me articles #45 as part of my personal stack. As long as I'm in the session, no one else will be assigned article #45. If I end the session, or close it, or skip #45, it will be put back into the main pool and can be assigned to someone else.

It's like a deck of cards. Currently, we only ever see the cards in order: AH, 2H, 3H, 4H, 5H, etc. Let us instead shuffle the deck. When you deal hands in poker, no two people will ever have the same cards (unless, you know, someone is cheating). Further, we're guaranteed a more equitable distribution of attention across the entire queue.

Patrollers could still choose to focus on the front or the back (FIFO, LIFO), obviously. They could also create "stacks" based around categories or namespaces. It may be possible to do stack creation based around WikiProject but I think that's too much to hope for.

Thoughts? Jorm (WMF) 20:56, 8 October 2011 (UTC)

I certainly understand the function you are describing. However, we have to consider that very few volunteers actually do a 'session' in the way tasks would be allocated in an office environment. Even I, who works from a home office, often spends hours on end at NPP, relish the freedom to dodge around the site doing things such as working my own articles and doing other random editing, admin tasks, and doing other Wikipedia project work. When doing NPP people stop to discuss issues with each other such as for example today's conversation - we may even have a quick video chat to discuss some particularly difficult issues. To that there is the freedom of doing anything else in RL that comes along.

The same applies to the way we work for example at OTRS - and that's why I suggested a system similar to ticket enquiry software solutions. When you want, you grab a page and then it's blocked for you until you've dealt with it. Nevertheless, we must not forget that we rarely have more than 7 patrollers working at any time at the front, and perhaps one or two working at the back of the queue. Other people pop in and simple patrol a page or two on the fly. And that's for around 1,000 pages a day. When it's night time there in the US, I'm often the lone ranger - and that's when pages are flooding in from India, Asia , the Philippines, and Australia/NZ.

We need more patrollers, and ones who know how to do it, but it's most definitely not a task that appeals to everyone.

A useful tool developed by Snottywong clearly shows how this works. Kudpung 12:07, 9 October 2011 (UTC)

I like the idea of reducing edit conflicts. But I don't like the idea that attack pages sit for longer, so this would need to be combined with the red colour concept for high risk articles that are available to all patrollers. The category idea is good if it can be used to create wikiproject specific pages that would be subpages of each wikiproject, but the that is largely for mid-queue to assist the end of the queue team, as a large proportion of new articles are uncategorised - some for days.

The drawback of the stack idea is that a lot of us have ways of judging what sort of article something is from the couple of lines at special newpages, and I suspect a lot of us like the ability to pick and choose. What would make a difference would be something that allowed you to ignore articles that another patroller was in edit mode in. WereSpielChequers 22:38, 10 October 2011 (UTC)

You've made a very important point about the 'couple of lines at special newpages'. The entry on the special:new pages should be a little bit longer to provide adequate description. This would enable editors like me who generally cherry pick for articles on BLP and bands, or otherwise toxic, etc;, that are very likely to be customers for deletion

This should be a very easy software tweak and perhaps we should file a bug for it. We also need to include this in any advice we give tio NPPers. Kudpung 01:40, 11 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Demo

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is there some labs demo or beta to test? Kozuch 20:07, 15 October 2011 (UTC)

Keep an eye on the PageTriage extension. It doesn't do much more than print "Hello World" at the moment, so there's nothing to try out. Reach Out to the Truth 20:16, 15 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Twinkle

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

1. To what extent will this make Twinkle largely redundant?
2. The lists of templates in Twinkle are now so long it's quicker in many cases to type custom messages for creator talk pages.
3. A list needs to be made of Twinkle items that are NPP specific (many templates are for internal purposes only, and only some of them are regularly used). Kudpung 09:00, 19 October 2011 (UTC)

In regards to the list of templates in Twinkle, we made a list of the most common warnings in Twinkle out of random sample of 1,000 from the last year. We did this with WP:UWTEST in mind, so it doesn't include mainspace tags. But it does include AFD, CSD, and some other article related messages. Steven Walling (WMF) • talk 02:12, 21 October 2011 (UTC)

Thanks. Do we have a similar list for mainspace maintenance templates? If not , can we get one? Kudpung 06:33, 21 October 2011 (UTC)

I went ahead and asked our researcher who ran that query. Steven Walling (WMF) • talk 19:40, 21 October 2011 (UTC)

I really don't like the tagging feature of Twinkle. With all the sections, it's even harder to tag. Just get the notice tags, content problems tags and the style problems tags section. Nothing else please. Ebe123 20:09, 25 October 2011 (UTC)

This isn't a problem with Twinkle, it's a problem of people who write new templates and ask the developer to to add them to Twinkle. I've already mentioned somewhere that I now actually find it quicker to type custom messages or paste ones I made myself rather than hunt through the list at Twinkle.

A very quick remedy - which I think the Twinkle developer could be asked to do - would be to provide mouseover tooltips previews of the templates. They went halfway with the new Twinkle interface by offering a 'preview' button, but that's not quite the same as shortcut for choosing the template, it's more useful for previewing any manually typed additions to the template before it's finally posted.

Another quick solution would be to offer a feature in Twinkle prefs for users to customise their Twinkle lists.

Steve is currently running experiments with templates, including some stats about their use, but I feel again that this is an issue that should also take note of empirical reports; for example, I'm an extremely busy editor and use Twinkle a lot, but there are a great many uw that I have never had occasion to use. I might go through them all, and make a list of the ones I believe to be superfluous and/or redundant at least to to Twinkle, andbpost the list here for discussion. Kudpung 02:03, 26 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Specialist lists

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

There was a mention somewhere of the possibility of getting patrollers to specialise on articles on topics they are familiar with. I initially mentally discounted this as a possibility, but again, experience at OTRS is worth considering. As someone who has done a great deal of patrolling, I know empirically that a huge number of new articles are about movies and sports people. This is where perhaps the movie and sport projects could be brought into play. Perhaps the Zoom interface could have a feature to 'move' pages that are not nefarious enough to need CSD, ' to suject-specific special:new pages lists for attention from active members of those projects who have not only subject knowledge, but who are also familiar special notabilty polices and guidelines applicable to those topics. I must admit I almost always skip football, soccer, and other league sports because I haven't the slightest inkling of what constitutes amateur, professional, major, and minor leagues, etc., and how the players qualify for them. As someone who has absolutely no interest in sports whatsoever, I do not feel committed to learning all about it for the purpose of patrolling and deleting new pages, but I'm sure that we have plenty of editors who have this knowledge and can apply it to patrolling. Kudpung 10:19, 22 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Triage Principles section

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The "Triage Principles" section explains a system of having pages become "fully triaged" when either a user with the pagepatroller right of a certain number of users without the right patrol the page. I see a few problems with this:

• Allowing a certain number of users to be equivalent to an experienced user and able to mark a certain section of patrolling as "done" is going to encourage using socks, possibly even by helpful, productive users.
• Having a system where if one ordinary user patrols something and then an admin also looks at it it's as though the first patrol was useless could be quite discouraging.

I suggest replacing this system with having a list of people who've patrolled an article(/edit?), perhaps with icons next to names of users who are pagepatrollers/admins ("This page has been patrolled by Example and SomeAdmin.") with patrolling options to only look through completely unpatrolled pages, or pages that haven't been reviewed by a pagepatroller, or an admin, or by a user who is logged in, or a certain number of users, etc. Yair rand 19:54, 27 October 2011 (UTC)

Makes sense - particularly about patrollers not doing their best if they know their work is going to be checked anyway - but there are other issues.

It may be better to avoid hierarchic patrolling for several reasons. To mention but a few:

• Currently on en.Wiki there are on average never more than about 8 users patrolling pages, and this is not enough to cope with the flow of 1,000 - 1,500 new pages that arrive every 24 hrs.
• Most of the 8 or so patrollers do not carry out all the checks that are required.
• The frequency of mis-tagging, and marking pages as patrolled that should be tagged (or even deleted) is too high.
• A significantly high percentage of new pages are from developing and/or non-English speaking countries and they arrive when the US and most of Europe is asleep.
• There are even fewer admins on 'deletion duty' at any one time.There to my knowledge only very few admins residing in those time zones. There are periods ere in Asia when I can barely keep up with the actual deletion of pages that can be uncontroversially and summarily deleted, as they arrive.
• To ensure the retention of new users, pages need to be processed as soon as possible (not as quickly as possible)
• Some kinds of toxic pages need to be deleted extremely rapidly

Possible solutions would be to:

• Create a user right for patrollers. This would attract more users to the task of patrolling pages, because as one commentator above put it 'people are power whores'.
• Ensure that those who want to be page patrollers are given adequate training. (Carrot-n-stick principle)
• Currently the only part of page patrolling that needs the intervention of an admin is the actual deletion. There could be a feature to flag an article for a second opinion. This may also help reduce the 30-day backlog. It's the closest I think we could get to 'multiple view patrolling'

A detailed survey of patrollers is currently taking place, and we hope to publish some data in a couple of weeks. Kudpung 00:19, 28 October 2011 (UTC)

I think most stuff you wrote above is quite sound and reflects some of my [much more limited] experience in the area. I'm curious however how do you see the patrollers' selection or election process taking place, assuming a right is going to be implemented for that. Currently the NPP work is a stepping stone toward adminship, at least for some from what I hear; I didn't look at RfAs much myself. But RfAs are a big deal today unlike they were in the past. Presumably, gaining patrollership should be a less daunting process. How would you see that done in practical terms? ASCIIn2Bme 23:38, 30 October 2011 (UTC)

A survey is currently being carried out among patrollers that asks, among other things, for respondents to provide their opinions on whether NPP should be a right, and if so, by what criteria they suggest it be based upon, and by whom or how the right could be accorded. Based on this data, the Wikipedia community(ies) will be asked to reach a consensus on these matters; what we can do, and are doing here at MediaWiki , is bump start such proposals by listening to the community's needs, developing software solutions for them, and offering valuable statistics for the Wikipedia communitiy(ies) to take into consideration during their debates.

For those who have the tools, adminship is most definitely no big deal. As such, because it is not a goal to be achieved, there are no stepping stones to it. Having minor rights are sometimes taken into consideration by RfA !voters, but they are not a prerequisite for adminship. Nevertheless, experience drawn from research appears to demonstrate that many candidates for adminship and other rights may indeed be 'trophy hunters'. Kudpung 01:39, 31 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Checkboxes for patrolling for different problems?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think one issue that does appear to have been discussed is that not everyone is equally capable of patrolling for all the aspects that may require a page to be tossed.

For example, I have no inclination to search for copyright violations. But I did spot a month-old hoax at NPP, and some AFC-approved original research and also AFC-approved adverts (a bunch of these). So, maybe having some sort of separate checkboxes for what an article is normally patrolled for, e.g. verifiablity-notablity/advert/copyvio/attack/[insert issue here] would be a good way to allow different patrollers with different strengths to collaborate & communicate easily. ASCIIn2Bme 00:01, 31 October 2011 (UTC)

It's been discussed, but not as a checkbox system. There are hundreds of criteria and guidelines for notability, and no one editor can be expected to be familiar with them all. The suggestions are to 'send' the articles to different queues, for treatment by area and/or subject specialists in the way it is done at OTRS. Such a system would heavily rely on soliciting the collaboration of experienced members of subject-specific Wikiperia projects. Such typical areas for example, are math, science, and sport related topics where many patrollers (and/or admins) may not be in a position to decide for themselves if new articles have notable content. See the thread that was started at Specialist lists. Kudpung 01:10, 31 October 2011 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Status?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Can someone provide a quick status updat on this project idea please? I'm really interested by the concept and think it could be super-helpful. I'm also really keen to see development projects that assist the existing community to do their jobs better (and thereby accommodate newbies more easily) so I really hope this project (or some version of it) goes ahead. I note that the article page hasn't been edited since late October. Sincerely, Wittylama 14:39, 22 December 2011 (UTC)

Currently, as far as I know, this project likely to be the next major engagement by the Editor Engagement team. We'd decided to focus entirely on MoodBar/Feedback Dashboard for the past few weeks, so as to get it into a "maintainable" state while research was done into NPP and the survey results were analyzed. Then, of coure, The Holidays happened, and half of the team at any one time was on vacation or out.

However, with the new year, we'll be starting engines up soon, I should think. Jorm (WMF) 18:57, 3 January 2012 (UTC)

Good to know. Thanks :-) Can you keep in mind to post here again (or somewhere visible) when this project gets greenlighted? On a related note, I don't suppose you can also give an update on the status of LiquidThreads v.3 (as per our previous short discussion here)? I presume it's heavily dependent on the progress of the new parser/visual editor? Wittylama 22:16, 3 January 2012 (UTC)

Well. The project has been "greenlit" already. The issue is, as always, our resource spread. Resourcing and prioritization are always delicate balances.

A project like New Page Triage is a pretty big undertaking and is absolutely guaranteed to a) upset a lot of people, regardless of how well its designed and implemented and b) fundamentally change some of the underlying software. So we want to be very slow and careful. Doing something like throwing resources at it for a week just because we have them and just to get something out of the door is a Bad Idea, especially since this problem is difficult and volatile. If we only have a week or two of resources, better then that we apply them to smaller projects that won't cause explosions or can provide us with better data going forward (like the Feedback Dashboard stuff we did through December).

I know there's a growing concern that the WMF isn't moving fast enough on this project but this one is truly an example where being the Tortoise is better than being the Hare. Jorm (WMF) 22:37, 3 January 2012 (UTC)

I completely get you on the tortoise rather than hare analogy - and agree that deliberate pacing of software changes (with generous beta testing phases) is a better way forward than slap-dash. However, the perspective from "out here" is that the projects that are actually getting done are, for want of a better word, frivolous, when there's so many big problems that are already well known. For example, whilst I personally like the concept, the WikiLove tool got the brunt of that kind criticism.

So, allocating long term resources to New Page Triage, IMO, would be a winner not merely because it would address an already-identified trouble spot for newbies, but because it would be politically very helpful for the WMF to be investing time in software that is designed to help the EXISTING community do their jobs better. If all the long-term software development resources go to projects aimed specifically at the newbie experience then the existing community is going to increasingly feel alienated and rejected. That's my read of it at least... Wittylama 11:18, 4 January 2012 (UTC)

And to answer your LQT questions: LQT is in no way dependent on the visual editor or parser, so that's not a hold up. The hold up with LQ (or, actually, "messaging") is entirely about resources as well. And if NPP is a possible time-bomb, messaging is an even bigger one. But it needs to be addressed, in my opinion - just the issue is how and where. Jorm (WMF) 22:40, 3 January 2012 (UTC)

Yep! If NPP is hard then talkpages are even harder - but probably even more important because they affect everyone equally, newbies and oldbies alike.

And, 'messaging' can certainly be considered within the context of the new editor retention efforts because it will give us a viable option for newbies. "please join the discussion over here" will become a viable entry-point for new users (especially if they come via a call to action from the AFTv5) rather than the confusing mess it currently is.

I think my problem is that with these two big issues (NPP and LQT) already raised and partially worked-on, I find it frustrating to see all the actual progress happening on smaller, band-aid solutions that aren't even community supported. There's so many big things that could be worked on that affect new user retention and that have community buy-in to be overhauled (even if we don't agree *how* to overhaul them) that I find it frustrating to watch these important projects constantly languish when the personnel are allocated to little fripperies like the mood-bar. Of course, the WYSIWYG work is a great exception to this and it's awesome that that project is being fully supported! Sorry for the rant... Wittylama 21:28, 4 January 2012 (UTC)

So I think I might be able to clarify some stuff here, because I think there may be a misconception about how the Foundation has been spending its time.

First, WikiLove is by no means a "frivolity". I'm aware that there is a significant percentage of the experienced editor community who believe that, but they may or may not be looking at the numbers in return without bias. WikiLove has proven to be a tool that helps with editor retention: we've always known that expressions of gratitude help to promote newbie health, and that the Wikipedia community as a whole is generally perceived as hostile, so working to combat that status quo is a no-brainer. WikiLove is not and has never really been focused at "elite editors."

That said, the amount of time and resources spent on WikiLove was about 2 weeks of developer time, all told, spread over a month. It was a negligible, easy win, and we took it.

The most recent (and continuing) thrust of our work in new editor engagement has been Moodbar and the Feedback Dashboard, which have proven to be both a) effective (possibly more than predicted) and b) community supported (I've heard exactly zero negative comments about it). I've been told a number of times that Feedback Dashboard is "addictive" to patrol. It's extremely satisfying and easy to do, and with the current work we're doing, will provide 360 degree feedback. The Dashboard is a Big Deal, even if it's not been advertised heavily.

As to why we are focusing on Moodbar and the Dashboard now, the answers are simple:

• The effects of the work will take a couple of months to measure, so better to do it now than later; and
• The comments that come in from Moodbar help to inform us about the weak points we should focus on

From the inside (e.g., inside the community), it may appear that the "obvious" solution is, say, the editor, or messaging. But that may or may not be what new users actually think. They may think the problem lies with help documentation, or warning template language, or anything else within a whole spectrum of elements.

What we're doing now is testing waters. We're introducing concepts like Mark as Helpful slowly, in an attempt to get them right, before we go full bore into deeper waters, where not having these things right from the beginning can sink the ship.

I definitely feel your frustration. Believe me: I have done two iterations of an LQT design pass and I know how important it is. And sure: we could throw everything and everyone at it, and probably have a pretty solid tool that we can ship in two months. But what would happen then? Could we just roll out a massive change without an overwhelmingly negative response? No. These things take time - a lot of time.

Because of this we are doing work in areas that do less to upset status quo than not. Believe me: I want to upset the status quo. I'm a pit bull that way. But it's not practical at this time. Jorm (WMF) 21:47, 4 January 2012 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.