Help
Add this page to your book
Show book (0 pages)
Suggest pagesTalk:Page Triage
Contents
 First page |
 Previous page |
 Next page |
 Last page |
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.
Proof that they exist: [1], [2] (may disappear when examined), [3] (will not disappear).
Could someone explain what that obvious debug code is doing on production servers with hundreds of millions of users?
--81.231.245.214 14:35, 18 May 2012 (UTC)
From a research perspective, creating a log with an identifiable action type (nominating/removing nomination) is incredibly useful. </twocents>
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)
Hey, I may not be able to make it to IRC office hours, so I wanted to say I really really like the latest version of the list view mockup and the zoom view mockup.
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)
I will use this as the example when I get around to it.
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.
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.
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.
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.
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.
why do you perceive opening multiple tabs as inefficient?
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.
I do not believe, in any way, that people are uneducable.
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).
As currently designed the system doesn't allow you to fix a typo or add a category but leave an article unpatrolled. Instead it is designed to encourage the idea that patrolling is all about templating articles and tagging them for deletion. With the current system a large minority of patrollers have hotcat installed and a proportion of newpage actually get improved as part of the process, by designing out the most positive part of the newpage patrol process Zoom is likely to make the process even less welcoming to newbies than it currently is.
One theory for our decline as a community since 2007 is the shift from SoFixIt and crowd improving article to templating things for others to work on. By channeling patrollers away from hotcat, wikifying and typo fixing Zoom is liable to reinforce the trend that is undermining our community.
I fully agree, but is not it what en:WP:NPP suggests to do right now? It says very clearly that if there are problems they should be templated, nobody suggests to fix them (even though many of the problems such as categories or references can be fixed very easily).
We know from the survey that a lot of patrollers use hotcat, and there are things in the Newpage patrol instructions that go beyond just templating. For example "or add some appropriate categories to the bottom of the article. It is usually fairly easy to find two or three appropriate categories". I'd like to encourage more patrollers to fix things rather than tag them. Adding a category doesn't usually take much longer than tagging an article as uncategorised. So yes if Zoom cuts out the article improvement stuff and takes away the option of fixing a typo and moving on then I would be very concerned.
This is a known problem, and I came across it many times when I was still working in ru.wp. Now I went to the end of the que of the articles which were not patrolled (on en.wp) and experienced it again. If I see a two-line stub which has no references, no categories, unclear notability, and no internal links, the easiest is just to leave there a bunch of templates and leave it patrolled (or not patrolled). As a responsible editor, I am doing more, for instance, I am looking for sources and insert them to the article. But in this way, it costs at least half an hour to improve (not even to extend, meaning adding new material) to a two-line article which is not immediately in my field of expertise. We can not really expect that all editors are so responsible that they start spending half an hour for each two-line article, and if we require this, they would rather not touch them, and the patrolling backlog would grow enormously (this is what happened on ru.wp and then some patrollers decided to set records and started to mass-patrol edits with an understandable drop in the patrol quality). Currently, I do not know how this could be solved.
There are no easy answers to this one. But there are some partial answers:
- If you take off the deadline of it becoming automatically patrolled after 30 days then at least the pressure of working against a deadline falls away.
- Several of the templates we smear over articles should be automatically generated categories. Ideally hidden categories as our readers really don't need a category to tell them that an article has no categories or is an orphan. The templates that we show our readers really ought to be the ones such as unreferenced that are needed to warn our readers. If we gave our patrollers fewer templates that they could post and the patrolling screen had tools to easily de-orphan or categorise an article, then we might move a bit back to the SoFixIt mentality that built the pedia instead of the SoSmearItWithTemplates mentality that has so soured the project.
- One of our biggest problems with newpage patrol is that some patrollers think in terms of making sure that the badfaith stuff gets deleted, and others think in terms of whether articles are ready for mainspace. Both are of course worthy objectives, but you can't run both types of patrol with a binary patrolled/unpatrolled system. Or rather you can, but you get the current mess. The solution would be to move from a binary system to something slightly more complex that fits the patrollers mindsets. Instead of a binary choice give them an additional nuance. So the mark as patrolled box would become [Goodfaith/Ready for mainspace] if a patroller clicks Ready for mainspace then it gets marked as fully patrolled, if they click Goodfaith then it changes colour from yellow to green at specialnewpages and the next person to look at it just sees the option [Ready for mainspace]. At the front of the queue where the priority is screening out attack pages and other utter crap the aim would become making sure that everything was at least looked at and either tagged for deletion or marked as Goodfaith. I suspect many articles would get marked as ready for mainspace, but, and this is the crucial bit, everything would be looked at very soon after being created and I'd be surprised if the queue of completely unpatrolled "yellow" articles every ran to more than a few hours. The back of the queue of the screened "green" articles would continue as is, or possibly we might get more picky as to our minimum requirements for [ready for mainspace]. My suspicion is that deletionists and inclusionists alike would be happier under such a system - especially if we also had NoIndex set on unpatrolled articles. And of course the pressure on the "Green" articles could be changed from templating them for all sorts of improvements for others to do, to actually doing the necessary categorisation, wikifying and maybe even referencing before marking them as ready for mainspace.
1. I may already start sounding like a notorious proponent of flagged revisions / pending changes, but for me this is what all this stuff is about. I was doing NPP for half a year in Russian Wikipedia (I was one of the first patrollers), then NPP were replaced by FR and I was doing FR for two and a half years, about 3K revisions per month (excluding autopatrol). For me, it is just a logical continuation of NPP, since (a) it fixes the 30 day problem - now every article can be patrolled, not just those which got into main space very recently - and this is logical, since we have a lot of old stuff which is inappropriate, and NPP/FR is a mechanism to coordinate effort of users looking at these articles systematically; (b) once one does this, one also realizes that even an article which is ready for the mainspace can be made inappropriate for the main space, for instance by being vandalized or by being subject to introducing copyrighted material or whatever. And then one would need to patrol it on a regular basis. And the most logical thing to do if one wants to coordinate this effort is to facilitate patrolling of a single edit - which is FR. Let us see how the RFC which was promised to us will run. As an intermediate solution, I do not have such a good knowledge of mediawiki, but I assume that unpatrolled pages remain unpatrolled forever, so that there should be a way of bot-creating list of pages which failed to be patrolled in 30 days and which still could be patrolled, but I do not know how to do it.
2. I agree with that. Is this smth which needs technical means to implement?
3. Actually, I think this ONE statement - that the article is almost ready for the main space - can be implemented by a template or by a hidden cat. But then it should be indeed understanding what NPP is. There was a similar situation indeed on Russian Wikipedia, when some users though a patrolled article is ready for the main space, and others marked everything which had categories and was not a blatant copyvio. The idea with three or more colours id excellent, but it obviously requires discussion and I do not know how easy it is to realize.
The draft surprised me a bit because it's very focused on the "crowdsourcing" of patrolling, which as noted increases total workload but is supposed to reduce the per-user workload while involving also less experienced patrollers whose sole judgement couldn't be trusted normally; and it doesn't say much about what the articles' authors will see. The main flaw in the current system is IMHO that for instance the many speedy deleted pages can't be corrected by the author, both because they were deleted and because he doesn't know how to ask clarifications, receive feedback or challenge the decision (and has to use OTRS, which is very inefficient and obscure); at least if the page is not deleted the author is able to edit it and remove the tag, but the draft doesn't say what would happen here.
[edit] Nomenclature and other stuff
- Anyone who thinks "Triage" is a non-military term should read about it's 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."
Enable No Index in mainspace. Put Noindex in badfaith speedy templates and all articles until patrolled
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.
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..
"What if vandals had bots that did foo." is a standard question. The answer is we'd block and revert.
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.
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.
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.
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:
- 'no-index' the page
- Move the page to AfC or pre-titled user sub page
- Semi-protect the page for page moving
- 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?
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.
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.
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.
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.
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:
- 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.
- 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.
- 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.
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.
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.
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.
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!
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.
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.
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?
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.
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...
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.
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...
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.
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.
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)
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.
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.
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.
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.
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'.
First page |
Previous page |
Next page |
Last page |
