|Thread title||Replies||Last modified|
|Modifying Page Info on disambiguation pages||2||08:48, 28 November 2014|
|A button for returning the new page feed page.||0||00:43, 29 November 2013|
|Nomenclature and other stuff||1||23:18, 22 November 2013|
|Newbie question||1||19:02, 1 April 2013|
|Other wikis||1||18:56, 7 January 2013|
|Will this be released as a Mediawiki extension?||1||21:30, 14 November 2012|
|Source code?||7||18:17, 11 October 2012|
|Two processes for new article reviews||2||14:21, 3 September 2012|
|Please record a screencast of yourself doing New Page Patrol||19||20:05, 19 June 2012|
|Finally!||15||20:00, 25 May 2012|
|Some debug code seems to have escaped||0||14:35, 18 May 2012|
|Log:Nominated for Deletion||0||19:57, 19 April 2012|
|Possibilites||0||19:29, 16 March 2012|
|Latest mockups (March 9th)||0||16:49, 9 March 2012|
|Tooltips||5||00:18, 8 March 2012|
|Delayed action tags||13||19:03, 7 March 2012|
|bulk selection||1||05:32, 7 March 2012|
|Engage article creators||0||23:48, 5 March 2012|
|Task analysis||0||23:39, 5 March 2012|
|Is this really what is wanted?||12||03:04, 3 March 2012|
It's usually a good thing that Page Info lists "No citations" under "Possible issues" – but not in the case of disambiguation pages, which are explicitly not supposed to have citations. Could the Page Curation toolbar be modified to prevent this notice from appearing on any page containing a disambiguation tag (of which there are several, including aliases)?
Nomenclature and other stuff[edit | edit source]
- Anyone who thinks "Triage" is a non-military term should read about its history.
- This talk page interface is pretty unusable - I am using what I consider a massive screen, and I can only see the contents.
- Does this exist or is it just mock ups?
1) True, "triage" as a system came from military hospitals, but its name has grown to be more general since then and simply means "sorting by urgency". Certainly "patrol" sounds like it's an obligation to walk the perimeter fence of the camp to make sure nothing gets in (which is precisely the feeling that all this focus on NPP is trying to avoid). 2) It's unfinished software. The newer, all-singing all-dancing, version is in the works LiquidThreads 3.0 3) As it says in the first line: "This document is a work in progress. Comments are appreciated but this is not a final draft."
If a page was reviewed, and then was updated, does it go back to unreviewed status? I'm currently using FlaggedRevs and was wondering if this could replace that.
Are there any plans to deploy the page curation toolbar on other language versions (by default, or on request)?
Will this be released as a Mediawiki extension? This is really a neat idea. I could see my organization using this tool.
I'd like to try to write some patches for this to fix small bugs I've encountered. Any chance I could at least see the source code? Thanks!
I'm certain that it's visible at the git repository. Do you have git access?
...I don't know. (Bear with me, I'm new to git) Someone at enwiki did give me a link to this gerrit repository, though. Is that right?
Yes, it does appear to be that repository. This is not properly documented. I spend 10 mins looking for it, and I'm an experienced dev that knows where to look.
Nathan, I'm sorry that I did not run across this earlier. Yes, I believe https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/PageTriage.git;a=summary is right. And if you could point to the page on enwiki where someone mentioned this to you, I'd be much obliged -- that way I can communicate with them as well. Thanks!
This might help those of us unfamiliar with git:
New mainspace articles are reviewed (or not) in two entirely different and completely independent processes.
Here is how articles are added to the All unreviewed new articles category:
- The New unreviewed article template is added automatically to articles created via the Wikipedia:Article wizard 2.0 (the discussion page is at WT:WIZ2). The template puts the article in the category. The Category:All unreviewed new articles list is independently generated and is not connected to the New Pages list, and the user’s Autopatrolled status does not affect articles in the category.
Here is how the autopatrolled right works:
- A person without the autopatrolled right creates a page. The MediaWiki software immediately lists the page at Special:NewPages, and highlights it in yellow. A human patroller, as part of the New Page Patrol process, reviews the article and clicks on the link to mark the page as patrolled if it does not qualify for speedy deletion.
- A person with the autopatrolled right creates a page. The MediaWiki software lists the page at Special:NewPages but marks it as patrolled and does not highlight it in yellow. The software (rather than a human) marks the page as patrolled.
- See new pages feed.
Anyone examining how new mainspace articles should be reviewed should study the two entirely different processes work now, and consider combining the processes or changing them to work together, rather than entirely independently.--Dthomsen8 (talk) 22:55, 4 August 2012 (UTC)
WIZS pipes articles through the AfC pocress now, however I would like to see support for the ureviewed article tagging in NPT.
Last edit: 20:05, 19 June 2012
(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:
- 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.
- Clearly state your username, so we can easily link your comments with your video.
- 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.
- 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.
- Wrap up the video.
- 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 firstname.lastname@example.org.
- Send any additional comments you have in an email to email@example.com.
- 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:
- Go to our usertesting.com launch page.
- 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.
- The Java applet may require rights to run. Grant the rights as needed.
- 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)
- Press the red button in the lower left of the interface to begin recording.
- A countdown will start. Once the countdown has finished, the recording has begun.
- Speak aloud your thoughts as you work. This is very important.
- When you are finished, click the "Done" button (down near where the start button was)
- 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.
- Click "Upload this file". The upload will begin. This may take a while.
- 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 firstname.lastname@example.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?
Would closed captioning be an acceptable replacement to using a voice?
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.
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.
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.
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 ;)
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.
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?
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.
Yeah, we'd be happy to do a screenshare any time.
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.
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.
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?
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.
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.
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!
Weird boxes saying "This is a tool icon" have started appearing on various pages on en.wikipedia, without discernable patterns. They disappear when making null edits, or even when just purging the page, but I suspect they'll reappear after a while (probably elsewhere, but whatever). Firebug, Google, a bunch of null edits, some friends who found some more examples, and Special:Code lead me here.
Could someone explain what that obvious debug code is doing on production servers with hundreds of millions of users?
--188.8.131.52 14:35, 18 May 2012 (UTC)
There is also chance that serve not only to new pages as well as for editions in pages? (I think it would be very useful to be able to mark the reason for the reversion in a manner similar to that used to delete)
And there was a chance to view pages revised by default(like flaggedrevs) instead of "protection page" (I think it would be helpful to protect fewer pages)
The list looks a lot more scannable because the boldest items are the patrolled status, title, and article metadata, which is what I primarily have scanned for when looking at the current Special page. The thing I like about the zoom view currently is that the largest and most noticeable thing is the edit button. Yay for editing pages instead of tagging them. :)
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' 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.
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.
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.
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.
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.
What ten minute rule? I haven't seen any rule specifying a number of minutes.
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.
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.
This again relies on the possibility of creating a user-group for patrollers
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".
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.
If one doesn't use a fast browser or have a fast internet connection, that might do it. Obviously that's speculation, but personally, since I use a fast browser and have a horrific internet connection, I find multiple tabs to be about as efficient as anything gets - open things (up to, oh, 40 or so) in the background so they're done loading when I actually go to deal with them... especially useful around here since a lot of the js doesn't activate until after everything loads, too.
If new pages have resolvable issues, then instead of merely tagging them, it may help our project if we try to engage the creators (assuming there is a recent and identifiable creator) by prompting them in a friendly way to improve their creations. This may give them the feeling they are part of a community, which is good for editor retention, and will probably be more effective in improving article quality than mere tagging without prompting. Can the tool offer support for this?
What I'm missing is a task analysis of the tasks a New Page triager (triagist?) is supposed to perform. Without such an analysis, it is hard to see how well a proposed design of the tool will support this.
The page en:Wikipedia:New pages patrol gives checklists for various namespaces. If NPPers are generally supposed to follow these checklists, they should perhaps be reflected (in a non-obtrusive way) in the interface, something that may in particular be helpful for new users.
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.
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.
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.
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.
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.
(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).