Wikipedia talk:New pages patrol/Reviewers/Archives/Page Curation/Archive 1

Proposed first changes

This isn't, by a long shot, the entirety of New Page Triage: these are just some opening tweaks, and some things we need to know so that we can work on the bigger changes. However, these are still things worth commenting on :). The nature of the information the interface will provide, for example, is of paramount importance, and is discussed below. I'm sorry for the dearth of info on the project as a whole; we'll hopefully have some wireframes of the big bits available for you to look at by the end of the week. In the meantime, if you have any comments about these ideas, add them in the relevant talkpage section - and if you have any ideas of your own, drop them in a dedicated section of your own.

Providing more information to patrollers

One of the big changes we want to make is to display a lot more information to patrollers about the articles and their creators. This information will be displayed largely in the "list" view - what we now think of as Special:NewPages - meaning that patrollers can quickly look through and identify pages with attributes that line up with their patrolling interests. The data we plan to include so far is:

1. Article title
2. Whether an article is an orphan
3. A "snippet" showing the first few sentences from the article (not just an infobox, or the edit summary)
4. Whether categories are present
5. Whether the article has been marked for deletion
6. Patrol status
7. Article size
8. Number of edits
9. Date of creation

Optional extras (which we are throwing out here to gauge opinions on) include:

1. Whether maintenance tags are present
2. The type of deletion tag (CSD/PROD/BLP-PROD/AfD)

Please do provide any comments you have on whether these would be useful, particularly in relation to the optional data :). If you have any ideas for other information that should be made visible, bring them up too!

Note: the development of the API is proceeding at a brisk pace, and many of these elements are going to be included

All these items look good to me, including the 'optional ones'. I am wondering how these will be displayed without being an eyesore. --Greenmaven (talk) 06:25, 3 March 2012 (UTC)

• Currently we have the username of the creator and whether their usertalkpage is a redlink, and one of our filters is to look at all the other articles in the queue by that editor. I use all of that - I often choose to patrol articles by newbies with redlinked usertalkpages and if their article is "goodfaith" I'll welcome them, even if their article needs a bit more work before being patrolled. You will include "welcome newbie" as an option won't you? I also use the filter by username function to look at other articles by the same person - but I'd do that more often if there was a little button that said "look at x other unpatrolled articles by this editor". By contrast the orphan thing is less useful unless it also includes potential links based on a search. ϢereSpielChequers 08:19, 3 March 2012 (UTC)

  Of course; this data is a given :). I like the "look at..." option, and we really do need to surface the idea of welcoming newbies. Okeyes (WMF) (talk) 15:07, 3 March 2012 (UTC)

  There's an issue with welcoming users: I'm pretty sure the Foundation did some research into welcome templates and found they actually didn't help much, if at all. If we're rethinking NPP, we should probably be rethinking welcome templates along with them. —Tom Morris (talk) 21:40, 3 March 2012 (UTC)

  That was Doctor Kill's conclusion, yes. I'm not sure if that means we want to move away from templating entirely, which seems unrealistic in the short term, or just move to the best bad templates (which swalling and Maryana have been testing: we're meant to touch base with them on it soon). Okeyes (WMF) (talk) 21:43, 3 March 2012 (UTC)

  We had two different studies on newbies last year. Dr Kill's study in the WSOR which looked at the content of our welcomes and was rather critical, and a statistical study of newbie retention which showed that welcomed editors are more likely to stick around, despite a large proportion of welcomes being "welcome warnings". I think it would be really useful to repeat that study and split the "welcome warnings" away from the rest. So my reading of last year's various newbie welcoming research was that in practice the welcomes we use are better than nothing, but in theory they shouldn't be working and they could be radically improved. ϢereSpielChequers 02:32, 4 March 2012 (UTC)

• Will the information shown be based on only the current version of the articles? I can think of cases where it might be useful to have information contained in the page history displayed. For example, it would be nice to know not just whether a new article currently marked for deletion or PROD or has maintenance tags, but whether such tags were present in the past and have since been removed (and who added them and who removed them). Even if this is not possible, it would be good to have the page history of each article easily accessible as part of the system. Also, as well as the size of the article, a bit of data that is sometimes useful is the size of the initial edit (whether the article started as a large chunk added, or evolved as a series of edits expanding from a stub) and flagging up large removals of content (this can sometimes be removal of copyvio without any proper follow-up). Oh, and number of editors in the page history as well (is the article just the work of a single person, or have others looked at it?). Some of these don't really apply to unpatrolled pages, but are helpful statistics for those looking at patrolled pages to see how well patrolling is working. Carcharoth (talk) 17:15, 4 March 2012 (UTC)

  I believe it will be based on current-status; we have to try not to clog the interface, remember :). Number of editors is a useful metric: I'll bring that up. Okeyes (WMF) (talk) 19:17, 5 March 2012 (UTC)

Maybe the size of the article since its creating could be displayed by means of a small sparklines

Another thing which may be of interest is the number of references in the page. Helder 12:57, 8 March 2012 (UTC)

Would change-in-content be that useful? And references: those are surprisingly hard to do, I would imagine, given that there is a tendency of even some experienced editors to assume that "references" are outbound links in an external links section, or (as I often see from newbies) simply the text of the references written in bulleted list form. Okeyes (WMF) (talk) 14:42, 8 March 2012 (UTC)

• One of the things that was discussed at the Village Pump was whether to triage articles by brand new editors separately - either to flag them in this list, or to put them into an entirely separate queue. This seems sensible to me because such articles are the biggest problem here, with 80% of them getting deleted. Any thoughts on that? --MelanieN (talk) 01:55, 9 March 2012 (UTC)

  That would be great :). We are looking at more granular filtering; hopefully it will be possible to say "okay, I just want to see articles by non-autoconfirmed users", for example. Okeyes (WMF) (talk) 06:38, 9 March 2012 (UTC)

Removing the 30-day limit

Something that has been brought up several times is the 30-day limit on the patrol queue. There have been suggestions that it contributes to the "siege mentality" at new page patrol; the idea that the work is urgent because things that slip through are lost forever. To combat this, one of the more minor tweaks we'd like to make is to eliminate the 30-day maximum; extend it, or simply make it infinite. This isn't something necessarily tied to New Page Triage, and can be put into place using the existing interface. What do you think?
note: the Foundation has agreed to turn off the 30-day limit as part of the first New Page Triage development cycle

I suggest introducing a 60 day option to begin with. --Greenmaven (talk) 06:19, 3 March 2012 (UTC)

• There is no reason to impose any deadline unless you want to encourage deletionism by putting psychological pressure on patrollers to make a final decision on an article. It would be difficult to trial a 60 day deadline because it wouldn't be put to the test until 60 days was reached. ϢereSpielChequers 08:09, 3 March 2012 (UTC)
• The 30-day limit has always been a source of pressure, I think. When I was doing a mass of npp, and coming across significant numbers of serious copyvio's, I was a bit haunted by wondering how many more had disappeared into the black hole beyond 30 days. I think extending to 60 days on the usual list, but having a fast link available to get to older unpatrolled pages (listing from 60 days to infinite) would be good. Pesky (talk) 08:10, 3 March 2012 (UTC)
• No need for a limit - all unreviewed pages are new pages in my opinion, and we lose track of thousands of new articles to this limit every month. Osarius Talk 12:03, 3 March 2012 (UTC)

  I think an important thing to remember when working out times is that the amount of space on the buffer is dependent not so much on the limit as on patrollers workloads. If 30 days is giving us a siege mentality, 60 days would also give us a siege mentality - you'd just get a month-long breather while the queue filled up ;). Okeyes (WMF) (talk) 15:24, 3 March 2012 (UTC)

• Question What is the rationale for having a time limit? Blue Rasberry (talk) 23:31, 3 March 2012 (UTC)

I don't think it had a rationale, as I understand it this was a pre-existing feature that New Page patrol was bolted onto. ϢereSpielChequers 01:19, 4 March 2012 (UTC)

As I understand it (IANAP), the recent changes feed is 30 days long for reasons of space and ohmygodthecost of pulling up, say, 2 months worth of recent changes. And Special:NewPages is basically based on that. If we switch to having an individual new pages feed we can alter or eliminate size constraints. Okeyes (WMF) (talk) 02:26, 4 March 2012 (UTC)

• Comment Here's where the technological determinist in me steps in and says: the ideal size of any queue is empty. If the queue isn't empty, we as a community are doing something wrong. Hopefully, NPT will fix this to some extent, but we should probably be prepared to dream big in other ways about how to fix NPPing. That might mean leaderboards (like Special:FeedbackDashboard) Here's one little thing I'd do: modify the watchlist and the page we show after you've logged in to show the number of articles needing patrolling, and the number at AfC. And a few other admin things, like how many AIV, RfPP requests etc. For me, one thing I've found is that I'm not interested in fixing the really crappy stuff that's coming through: I'm happy to mark as patrolled the good stuff by non-new users, while I know people like WSC tend to handle newbie stuff better. (This is why I avoid AfC.) I hope that NPT will include better sorting and filtering to fit different styles of patrolling: I'd love to sort NewPages by the number of pages the user has created before and pick off the ones written by experienced users first, and leave the newbies to people who enjoy dealing with newbies more than I do. Advertise NPPing more, and have better tools for queue sorting and filtering, so we can all pitch in however we can. —Tom Morris (talk) 01:45, 4 March 2012 (UTC)

  That's the plan, and also why I want as many editors involved in development as possible. We hope to have far more detailed filtering available than is currently the case. Okeyes (WMF) (talk) 02:27, 4 March 2012 (UTC)

• Okay, guys! I've just got the notes for the first development cycle; we're eliminating the 30-day restriction :). This will either be deployed soon-as, or with the prototype, depending. Okeyes (WMF) (talk) 23:13, 6 March 2012 (UTC)

  Thanks, ϢereSpielChequers 22:01, 8 March 2012 (UTC)

NoIndex until patrolled

the Wikimedia Foundation will institute a system of noindexing pages until they have been patrolled. Several possible ways of doing this will be presented to the community for review and feedback before it is instituted.

One of the problems with new page patrol is that attack pages and spam will get picked up by search engines and mirrored - often for far longer than we had them up. One way to resolve that, and to reduce the deletionist pressure to get rid of articles that don't really meet the deletion criteria but aren't ready for mainspace, is to make all unpatrolled articles {{NOINDEX}}. This would be completely unbitey to newbies as they wouldn't know whether their article was unindexed any more than they know whether it has been patrolled, but it might make unpatrolled pages a bit more incubator like as they wouldn't be part of the pedia as far as mirrors and so forth were concerned. Currently we don't allow NoIndex in mainspace and this would be a specific exception. If this was simply an extra feature of whether an article was patroled or unpatrolled then there would be no extra work for patrollers from this. ϢereSpielChequers 08:28, 3 March 2012 (UTC)

Now that's a very smart idea :D Pesky (talk) 09:29, 3 March 2012 (UTC)

Aye – it sounds like 'an idea', and I'd support it, too; but NPT looks to me like WMF not giving a flying f-f-duck about what the "community" thinks, while it's spending its precious resources on fancy software. As Okeyes (WMF) says (more than 100 times, sigh), isn't it "awesome to finally get to start work on this"? I'm glad I didn't get that promo copy message on my talk... I've asked Jimbo directly about NPP and other things on his talk, with no response in over a week now; maybe I shouldn't be surprised, but I find it very disheartening not to even hear what he has to say. Nortonius (talk) 10:36, 3 March 2012 (UTC)

(this thread now continued under topic WMF cares what the community thinks: WP:NPT or...?)

I'm in very strong support of this. In the same tone, perhaps when new articles are created they could be placed in some kind of 'incubator' to keep them seperate from article mainspace until they have been reviewed? Osarius Talk 11:51, 3 March 2012 (UTC)

Well the idea of NoIndex for unpatrolled articles is that unpatrolled would in effect be a sort of incubator, but without all the problems that undermine the incubator idea, especially re orphaning, categorising and the mess you get when one person moves an article to an incubator and someone then starts the article in mainspace. ϢereSpielChequers 13:02, 3 March 2012 (UTC)

I was more meaning an incubator that new pages are placed into on the moment of creation until they are patrolled, in which case they are moved to mainspace by the software. No existing articles would be able to be moved into the incubator, eliminating the orphaning issues etc. Whether or not the Wikimedia Software would be able to do that or not, is something to be seen. Osarius Talk 14:42, 3 March 2012 (UTC)

OK orphaning would only be a problem when something is in the news and related articles are created at the same time or an editor creates several related articles. Neither of those is unheard of, but the bigger problems with incubators are that we don't allow mainspace categories outside of mainspace, yet categories attract Wikipedians who care about particular subjects. Also it is a complete pain when someone works up an article in a sandbox or incubator only to find that someone else creates an article on the same subject in mainspace. ϢereSpielChequers 01:26, 4 March 2012 (UTC)

No, no. I don't think you've got quite what I meant. ALL new articles would be placed inside an incubator - not only reserving the incubator page, but the mainspace page of the same title (eliminating the mexican standoff) - which would then be reviewed in exactly the same way as present. As soon as it has been reviewed, it would be "unincubated" by the system automatically into the already reserved mainspace slot unless it is eligable for CSD, whereupon it stays in the incubator. Any links on these pages pointing to pages also in the incubator would be redirected to that incubated article (eliminating any orphaning issues). So the idea is this - everything would work exactly as it would in mainspace, but it's held in an incubator AWAY from mainspace until AFTER it's been reviewed. This solves the NOINDEX issue, and gives us a defined area to process new articles. Osarius Talk 10:01, 4 March 2012 (UTC)

A large proportion of new Articles will be Autopatrolled so shouldn't need any incubation. The common feature of userfying and incubating articles to a place outside of mainspace is that it appears to the article creator to be a rejection of their work, probably as much as nominating it for deletion. So we lose those editors. The idea of new unpatrolled articles being {{NOINDEX}} is that the creators of these articles won't actually realise that they are in a sort of an incubator. So in theory we will be less likely to lose those editors, much less likely if we can get patrollers to categorise and otherwise improve articles rather than template bomb them. ϢereSpielChequers 21:00, 5 March 2012 (UTC)

Superb idea (NOINDEX) Pol430 talk to me 13:19, 3 March 2012 (UTC)

• I like the NOINDEX idea; I know it's something that's come up, and I'll check where the devs are on this. Okeyes (WMF) (talk) 15:02, 3 March 2012 (UTC)

  We're adding it to the provisional "to-do" list, and will check it's feasible in a meeting early next week. I can't imagine it's not feasible ;p. Okeyes (WMF) (talk) 20:22, 3 March 2012 (UTC)

  Thanks. ϢereSpielChequers 21:00, 5 March 2012 (UTC)

By all means, do this. It will reduce the spread and impact of crap with minimal problems. Although a full-fledged incubator could probably do a better job, it would be a touchy, difficult thing to get right, whereas this can safely be done with good effect and minimal risk. -R. S. Shaw (talk) 08:36, 6 March 2012 (UTC)

• I tend to feel we are already overusing noindex as a magically makes things not matter word. As a result I have my doubts with regard to this extension.©Geni 09:16, 7 March 2012 (UTC)

• I support this. Legal and ethical issues aside, shutting down the ability of newly-created attack pages or hoaxes to be "found" by Google will eliminate much of the incentive to create them — thereby reducing their rate of creation and easing the workload on NPP volunteers. Carrite (talk) 19:46, 7 March 2012 (UTC)
• Bump for prominence

  So, I've spent the last couple of hours meeting with Ian Baker, Kaldari and a couple of other devs. They're of the opinion that we can totally set up a system to noindex all unpatrolled pages, and furthermore noindex those pages that are CSDd with specific templates: for example, copyvio, attack pages, pure vandalism (the last two are often interchangeable). These two proposals are not interlinked, and we can run one or the other if people have an issue with it. They're also not linked to new page triage; they can work perfectly happily with the existing Special:NewPages system: as soon as we turn it on, it works, regardless of if NPT is finished yet. What I'm going to do is start drafting a formal RfC, to be held in a different location (probably Wikipedia:Request for Comment on NOINDEX or whatever) and then notify all and sundry. Comments, thoughts? Okeyes (WMF) (talk) 21:25, 8 March 2012 (UTC)

  Good to hear that. I'd be tempted to keep it simple and stick to NOINDEX = unpatrolled, especially if there is a chance of getting a separate colour for articles tagged for deletion so they don't need to be patrolled. There are a couple of drawbacks to putting NOINDEX into CSD templates, for starters if an article is blanked and tagged for deletion G10 we'd really quite like the mirrors etc to replace their copy of the article with the blanked and tagged version. This is an extreme example and quite rare as most G10s are picked up at NPP and therefore will be NoIndex before tagging for deletion, but it will be rather more common for Copyvio and they can stick at cat speedy for a while before processing. There's also the issue of how we prevent people adding NOINDEX to popular articles, if its a function of the article being unpatrolled then it is fairly safe from manipulation. ϢereSpielChequers 21:58, 8 March 2012 (UTC)

  The noindex command would be controlled via a list at a mediawiki page. Essentially, if a template or page is not in this list, it cannot call the noindex command. This both prevents abuse (you can't just add noindex to an article) and means that admins can expand the list of accepted noindex tags as the community sees fit (for example, it may be that the hideously-big-and-ugly-copyright-vio template should have noindex added to it, so that those articles also fall out of view).

  The scenario you describe isn't, as we understand things, possible. Google has a "special arrangement" when it comes to dealing with Wikipedia, because of our size; the spider searches Special:RecentChanges to identify what caches need updating or clearing. If I make an edit to a cached article, the spider notes that edit through recent changes and updates the cache. If I delete a cached article, it notes that edit and removes the cache. Adding a CSD template containing a noindex tag is itself going to be an edit - an edit the spider will note, and respond to by removing the article from google's searches entirely until the tag is removed. Okeyes (WMF) (talk) 22:45, 8 March 2012 (UTC)

• Excellent idea. I don't share Geni's concerns as doing this is rather effortless and is only part of the solution to the crap firehose problem. Can we turn this on immediately? MER-C 05:31, 11 March 2012 (UTC)
• I was just checking the discussion going on here, I think it's a good idea. What if a article is "Burning-news" outside Wikipedia, and still it's not patrolled, means people can't see it at Wikipedia? Need to look over it..... Dipankan says.. ^{("Be bold and edit!")} 05:09, 14 March 2012 (UTC)
  • In that case people will likely find the article by name or through links from other related articles. Diego (talk) 13:36, 14 March 2012 (UTC)

Redirects and userspace

note: both of these bugs will be fixed in the new system

Two big loopholes in the current newpage system are that editors can create articles in userspace and them move them to mainspace, or convert redirects into articles and they aren't picked up as newpages. Will these bug finally be resolved (one has been on bugzilla since 2007 as a serious live bug in mediawiki). ϢereSpielChequers 08:33, 3 March 2012 (UTC)

I have a few problems with userspace articles appearing in the new pages list.

1. It adds yet more aticles to an already congested list
2. Deleted userfy'd Articles would also be picked up
3. Users use their userspace for creating article before they go to mainspace - if they were classed as new pages, it kinda defeates the object doesn't it?

There's also a couple of problems with redirects converted into articles being classed as new pages.

1. They're not new pages
2. If an article existed, but was redirected, and another editor restored the previous content then that edit would be reverted, but it would still be classed as a new page in that short period of time - putting extra unnecessary load on the server.
3. Would this occur if a user redirected an article as an act of vandalism, and the edit were to be reverted?

Overall, I also think it would be very confusing to the patrollers! Just my 2cents. Osarius Talk 12:00, 3 March 2012 (UTC)

Yes it adds more work to a congested system, however this is work that needs doing.

Userfied articles would only be picked up if they returned to mainspace.

The idea of using sandboxes is to get an article to a certain standard before it goes to mainspace, not to circumvent newpage patrol. If someone is creating valid referenced articles in userspace and then moving them to mainspace the way they should be bypassing newpage patrol is if they have Autopatrolled status, not that they start in sandboxes.

Agreed they aren't new pages, but they are new articles, perhaps the page needs to be Special:NewArticles. I wouldn't think this would create heavy server load,if we have edit wars as to whether an article should be a redirect or not then it would show up, but that would be a good thing to make visible. ϢereSpielChequers 12:54, 3 March 2012 (UTC)

I see your point of view, but I'm still dubious as to whether it would be benefitial to the encyclopedia to pick up on articles that would be still under construction in users' space. I'm not sure NPP (NPT) is the right process to be putting these pages under. Perhaps a special category for these pages and their own seperate process for tagging and notifying the author. I don't know, there would have to be a general concensus on this. Osarius Talk 15:03, 3 March 2012 (UTC)

OK I see where you are coming from. I've rephrased it so that hopefully this is a bit clearer that articles moved from userspace should go into newpage patrol at the time they are moved from userspace to mainspace - i.e. after they have been worked on in userspace. ϢereSpielChequers 01:14, 4 March 2012 (UTC)

• I'm not sure how these would fit into how we currently get the data for Special:NewPages, but I'll find out. Okeyes (WMF) (talk) 15:06, 3 March 2012 (UTC)

"Triage"? RfC

Triage, to me, gives the impression that three patrollers would have to review a NP and agree on any actions to take on it. Is this the intended meaning? I feel the current term 'Patrolling', or the term 'Reviewing', are far more in line with what we are doing. I would love to know other editor's opinions on this. Could you please add your opinion below:

For Triage

For Patrolling

For Reviewing

For any others

Thanks, Osarius Talk 11:42, 3 March 2012 (UTC)

To my mind triage means we have three choices not two. As I consider the current system over simplistic I prefer moving to a triage system. Most of the newpages we see are either ready for deletion or ready for mainspace. But some are in between the two, hence triage. ϢereSpielChequers 12:57, 3 March 2012 (UTC)

Osarius, "triage" is a more accurate representation of what we do. It's not about the number of choices, it's simply down to the fact that a patroller's job consists, firstly, of filtering pages (into "good" and "bad", via the use of "patrol") and secondly of fixing it up. Note that "triage" is merely the internal name of the project - I'm not sure how far this terminology will make it into the software itself. I'll drop Brandon a note and find out (although, as it's a weekend, he may not reply until Monday: don't know). Okeyes (WMF) (talk) 15:05, 3 March 2012 (UTC)

Okay, looks like the terminology is making its way in; see the first screenshot for the list interface (which I'll be displaying more prominently for comment as soon as we've cleared up what data we want to see - that, obviously, will have an impact on what it looks like). I don't think triage inherently suggests that multiple users will be needed - although that is something we might consider - but what do you think of the rationale for the name overall? :). Okeyes (WMF) (talk) 20:00, 3 March 2012 (UTC)

The word "triage" doesn't actually have anything to do with "three"; as it says in the article about it in that encyclopedia thingie, "The term comes from the French verb trier, meaning to separate, sift or select." Pesky (talk) 06:57, 4 March 2012 (UTC)

Yes, real-world triage involves the sorting out of those that can't be helped, those that don't need (much) help, and those that need to be helped ASAP. This concept works for articles as well as people. An article that can't be helped would be CSD-tagged, one that doesn't need much help would be marked patrolled, and one that needs help ASAP (for the wiki-definition of "ASAP", which generally equates to "a few years down the road, maybe, if someone gets to it") would be tagged for improvement or just improved by the patroller. A fluffernutter is a sandwich! (talk) 16:37, 6 March 2012 (UTC)

previous articles

There are three bits of information that would be really useful to know re the previous articles created by the same editor. For badfaith editors who've had articles deleted G3 or G10 it would be really useful if their subsequent articles were highlighted in red on the screen so that people knew to check them first. For Goodfaith articles it would be useful to know how many articles someone has previously created, or at least to have a little prompt or filter for those who've done 50 or more so you can easily spot candidates for Autopatroller status. Also if you've just patrolled or tagged an article having the option "Look at x other unpatrolled articles by this author?". ϢereSpielChequers 13:08, 3 March 2012 (UTC)

Good ideas, all; I'll surface them. Okeyes (WMF) (talk) 15:05, 3 March 2012 (UTC)

I tend to find that the sports editors tend to create a whole stack of articles, usually using the same sources. If one is good, they are usually all good. I remember going through all the articles on the Grand National marking them as patrolled, for instance. WereSpielsChequers' suggestion of making it easy to see articles created by people who have had articles speedied is good too: I'd extend it to cover G12 as well as G3 and G10. Figuring out how to do this without basically turning these users into unforgiveable pariahs might be hard though. We've had users who have gone on to become admins who started out as vandals. (Not me, obviously.) —Tom Morris (talk) 21:24, 3 March 2012 (UTC)

But me ;p. I was 14 and messing around at school via t'IP address, to be fair, so it doesn't really count. Okeyes (WMF) (talk) 21:26, 3 March 2012 (UTC)

I suspect those of us who got our teenage years out of the way before Wikipedia was invented have an advantage here. I'm sure there's a parallel Universe somewhere where Turing is still alive, so the computer revolution came a generation earlier and my teenage self got permabanned from Wikipedia for POV editing and edit warring before Ironholds was born. As for the users creating a stack of articles, I once went through a couple of wolfpacks of Uboats adding a particular category and marking them as patrolled, another time I handled a bunch of Roman Consuls. If you've worked out an obscure category and checked one article in a series it is very easy to handle the rest of that series, but at the moment you need a bit of luck to guess that it is worth checking for that authors other unpatrolled articles. ϢereSpielChequers 01:41, 4 March 2012 (UTC)

I have a feeling that I'd be in the same boat as you, WSC! I dread to think what my teenage self might have done with the 'pedia! I personally would want to include G12's in the flags, as well. Pesky (talk) 07:01, 4 March 2012 (UTC)

Make mark as patrolled more visible

Currently you only get to see the Mark as patrolled box if you go through special newpages. If it was visible to editors in other areas such as the uncategorised queue or the wikiprojects then a lot more patrolling would happen. I gather this was tried a while back and had to be removed for performance issues. Perhaps with faster computers the performance issues could be more affordable, perhaps there are more efficient ways to code this, perhaps we could be more selective and only display this to people who've previously patrolled articles. But this would be a great way to get more patrolling done and to get more subject specific expertise involved in patrolling. ϢereSpielChequers 02:21, 4 March 2012 (UTC)

I'm not sure how good an idea that is, even assuming we limit it to only-people-who-have-patrolled-articles. So, it assumes that patrolled/unpatrolled is a bipolar state, and that "patrol" means that it is good to go (and, for that matter, that all patrollers have the same skillset). These aren't the case; we know it's a lot more nuanced than that. There are a thousand possible things that can be wrong with an article, and a thousand different patrollers, all of whom have completely different standards for what they consider makes an article "good". One patroller might hit patrol having verified that it isn't deletable - another might hit patrol having verified that it isn't deletable, and that it isn't filled with typos, and that the newbie has been properly welcomed, etc etc. The benefit of the new interface is that it accounts for this; it's being designed around the principle that people want to provide oversight to each other and make sure that patrolled equals good. I worry that moving to a completely decentralised system would lead to a loss of this. There's also the issue of "nothing within mediawiki itself distinguishes between wikiprojects and any other namespace page", for example. But I'll surface it to the devs in our meeting early next week, and see if they see it as providing performance issues/difficulties with implementation. Okeyes (WMF) (talk) 02:57, 4 March 2012 (UTC)

I agree. I think multiple patrolling of articles is good (though how it would work in practice is a bit difficult to foresee). Oversight of other patrollers is also needed, as I'm reminded of a case a few months ago that I need to check up on. Have you considered a system like that on wikisource where an article goes through several stages of checking? Carcharoth (talk) 17:25, 4 March 2012 (UTC)

That is being considered. What do people think of moving away from a binary patrolled/not patrolled system, to something with multiple levels of checks? Okeyes (WMF) (talk) 17:28, 4 March 2012 (UTC)

It would depend greatly on the design. I'm a big fan of triage, Id like to see a system where instead of [marks as patrolled] we had a dual box [goodfaith/ready for mainspace] and if people just clicked [goodfaith] the article changed colour in newpage patrol but needed another editor to click it as [ready for mainspace]. I wouldn't want to see a hierarchichal system where some editors could partially approve articles and others could fully approve them. But I do like the idea of being able to flag articles as "goodfaith but maybe not ready for mainspace". I suspect that the front of the queue would work much better and with far less newbie biting if we had such an option. I'm pretty sure that if we had such an option we could make sure that everything at the front of the queue was looked at and deleted, patrolled or tagged "goodfaith" PDQ - certainly within hours. At the moment we sometimes get gaps at newpage patrol and completely unpatrolled stuff, sometimes including outright attacks sits in mainspace for nearly a month before it gets to the back of the queue. If we had such a system it would be easy to include people who came across an article while checking a particular category. ϢereSpielChequers 20:49, 4 March 2012 (UTC)

Indeed. I'll bring these ideas up in my meeting on Tuesday. Okeyes (WMF) (talk) 19:22, 5 March 2012 (UTC)

Whilst I'm not all that comfortable with the idea of NPP being useright dependent I can see this as a practical way to deal with performance issues. If we only show the [mark as patrolled] button at special newpages or elsewhere if a page is new and unpatrolled and is being looked at by an editor with the relevant userright - say admin or reviewer, then the processing overhead should be much less. But the gain in extra patrolling midqueue could be quite considerable. It might also help make the newpage patrol process less bitey and more collaborative. One of the problems with the current system is that if you do fix a few typos or add a category then the [mark as patrolled button disappears.... So making it more available should increase the amount of patrolling by just giving our more experienced editors the opportunity to patrol articles they've otherwise improved. ϢereSpielChequers 21:07, 6 March 2012 (UTC)

We're looking into stopping that disappearance, but it's something that needs a bit more developer research done :). Okeyes (WMF) (talk) 21:15, 6 March 2012 (UTC)

How about having a "Mark as patrolled" option in Twinkle? Or as a separate tab at the top, next to "Edit", or something? Pesky (talk) 21:58, 10 March 2012 (UTC)

Reviewing and reversing patrolling

note: the existing reviewing mechanisms will remain in place, and an "un-triage" button will be introduced

Under the current system, it is possible to look through a list of what someone patrolled. I have two questions here. (1) Will it be possible to do this under the new system? (2) Will it be possible to reverse someone's patrolling of an article? If someone (with the best of intentions) tries to help out and clear a backlog of articles to be patrolled, but does so incorrectly (clicking through hundreds or thousands of articles before anyone notices) and misses lots of obvious problems, will it be possible to dump those patrolled articles back in the queue to be looked at again? Hopefully it wouldn't happen often, but it might sometimes be needed. Carcharoth (talk) 17:31, 4 March 2012 (UTC)

The patrol log will still be available, yes. On the second point, I honestly don't know - but it'd certainly be useful! Even if it's not the example of someone mis-clicking, I regularly get situations of "I'm-not-comfortable-with-this-person-patrolling-this-article-but-don't-quite-know-what-the-issue-is-can-someone-take-a-look-at-it". I'll find out :) Okeyes (WMF) (talk) 17:48, 4 March 2012 (UTC)

Thanks. I suspect it could be problematic (imagine people patrol-warring - "It's fine", "No it's not, you shouldn't be patrolling this article!", and so on - what you could do is make it so no-one can patrol the same article twice, so the only way to take anything further is to edit the article or its talk page). You have to keep things simple, but it would be good to have some way to do mass reverts if needed. The reason I raised this is because some months ago I (and others) came across a batch of articles (turned out to be thousands, sadly) that had come through the Article Wizard and been flagged as 'new unreviewed articles', and got 'reviewed' (possibly they were also tagged after dropping off the end of NPP, not sure), but problems were missed (still trying to sort out the best way to deal with that).

You also get new articles created through the articles for creation process. Do both of those processes fall outside the scope of new page patrol or not? Are there any other processes that result in the creation of new articles? I see the issue of userspace drafts being moved to mainspace has been raised. What about bot-generated articles (I'm not sure what the most recent example of that is)? Are those sent through new page patrol or are they considered separate and already 'approved'?

My other question concerns those with the autopatrol right - some with that right (it is bundled in with the admin rights, IIRC) are not really content creators, but might end up occasionally creating articles that should still get scrutiny, for the article creator's sake as much as anything (they might not realise the articles they are creating have problems). What I'm looking for is a toggle to view all created articles, regardless of whether the user has 'autopatrol' or not, or at least for 'autopatrolled' articles to end up in the same view as patrolled articles, so they can be picked up at that stage if need be (for those who might want to double-check what gets patrolled).

As a sanity check, what are the volumes involved? How many articles daily are: (a) created; (b) speedied/prodded/AfD'd; (c) how many arrive from AFC; (d) how many from userspaces; (e) how many from autopatrolled users? Just a rough idea of whether it is tens, hundreds or thousands each day or week. Apologies if this is all laid out somewhere I haven't read yet. Carcharoth (talk) 19:08, 4 March 2012 (UTC)

It's actually very difficult to see which articles come from AfC (they don't appear in the patrol log if they're moved). On the other data, it's something like 3,300 pages a day: see User:Scottywong/Article creation stats (although that doesn't properly distinguish between autopatrolled and "everything else"). I think the autopatrolled right is totally something we should take a look at - perhaps a wider RfC on it? What do people think? As for mass-unpatrols, we could theoretically do it, but I don't know if an unpatrol function is planned. I'll find out :). Okeyes (WMF) (talk) 19:25, 5 March 2012 (UTC)

I've appointed a hundred or more autopatrollers and removed the right from three or four Autopatrollers who were creating unreferenced BLPs (and to be fair to the admins who set them as Autopatrollers they probably became Autopatrollers before BLPprod came in). I don't think that we need to review Autopatrolled, it only quite recently was reviewed and the threshold lowered to 50. If we don't operate some sort of whitelisting the workload will shootup and we risk more false positives of incorrect deletion tags. The current system allows people to browse all newpages or just focus on the unpatrolled, and I'm assuming that the new system will have that option. Though perhaps defaulting to hide patrolled rather than as at present the opposite. ϢereSpielChequers 20:37, 5 March 2012 (UTC)

Sure, but I think the example Carcharoth brings up - admins who have gained autopatrolled automatically as part of being admins, but are not necessarily experienced at the do's and don'ts of article creation - isn't the sort of thing covered by what you're talking about. Okeyes (WMF) (talk) 21:45, 5 March 2012 (UTC)

Ah yes, there is a theoretical case for upbundling the Autopatroller right and taking it away from admins like myself who haven't created many articles. It's one of the ideas we've floated in the RFA reform discussions. I'd support such a proposal in principle though I can only think of one instance where it would have been useful. It might also seem odd to have someone who doesn't have the Autopatroller right give that right to others, yet I may not be the only admin active in appointing Autopatrollers despite rarely creating articles. If you do run with this then for the sake of the devs I'd suggest decoupling it from the Triage proposal and launching it as a separate RFC, as the symbolic value of changing the admin bundle would probably get more attention to this than it merits. ϢereSpielChequers 10:02, 6 March 2012 (UTC)

Indeed, as suggested above. Okeyes (WMF) (talk) 14:46, 6 March 2012 (UTC)

No. Carcharoth's suggestion is that as at present you have the option to look at all articles not just unpatrolled ones. Or possibly the option to focus on Autopatrolled ones as opposed to ones that a patroller has patrolled. Upbundling he Autopatroller right would be very different, it would mean that articles created by admins would go through newpage patrol as unpatrolled unless they had the specific Autopatrol right. ϢereSpielChequers 18:14, 6 March 2012 (UTC)

Threads and hatnotes

Hey guys. Sorry for the absence of info so far; I've got a meeting later today to pass all your suggestions on to the devs, get responses, etc. I'm also going to advertise this project a lot more widely, and hopefully set up our first office hours session. All of this means that the talkpage will (hopefully!) become a mass of useful and interesting ideas. This does mean it has the potential to get a bit big. What I'd suggest is that we copy what happened with the Terms of Use discussion on meta; when a decision is reached (yes, we will include X, no, we will not include X) the discussion is compressed, and a summary is added at the top explaining what it was about and the eventual decision made. Is that okay with you guys? Okeyes (WMF) (talk) 17:03, 6 March 2012 (UTC)

I'm a little nervous about TOU as a model as often issues were closed long before the page was updated. But we may need some sort of archiving system, if only because of the walls of text that can ensue, and if the same issues keep recurring then it helps be able to point to where a discussion has taken place. Perhaps with this discussion we can try linking from various parts of the spec to the relevant part of the talkpages? ϢereSpielChequers 18:21, 6 March 2012 (UTC)

That should work as soon as we get an updated set of features requirements. The problem we have there is we end up either linking across-wikis, forcing the devs to keep features requirements in two places (which they are unlikely to be happy with) or giving a less-detailed set of requirements here (which could still work out as TL;DR). Okeyes (WMF) (talk) 18:23, 6 March 2012 (UTC)

Deletion tagged as a separate colour

note: articles marked for deletion will be tagged with a distinct colour

Currently we have a two colour system - patrolled and unpatrolled with articles tagged for deletion usually getting marked as patrolled. This has several drawbacks, not least that marking an article as both patrolled and also tagged for deletion is counterintuitive, but it does take those that are tagged for deletion out of the unpatrolled queue. Ideally we need a multicolour system where you don't mark articles as patrolled when you deletion tag them, but those articles that currently have a deletion tag are shown in a different colour and can be filtered in or out depending on the types of articles that a patroller wants to look at. This would mean that when a CSD tag was removed the article would by default revert to unpatrolled rather than as at present becoming a patrolled article in mainspace. This is also a logical extension of the {{NOINDEX}} until patrolled idea, as it would be a bit odd if we removed the NoIndex status for the minutes or hours that an article was tagged for deletion and had that version picked up by search engines and mirrors. ϢereSpielChequers 11:17, 7 March 2012 (UTC)

• Interesting idea; anyone else have thoughts on this? Okeyes (WMF) (talk) 00:58, 8 March 2012 (UTC)
• Yes, good idea. It might be worth considering more kinds of colour-coding, as well. Pesky (talk) 11:42, 8 March 2012 (UTC)

  Unfortunately this isn't feasible right now. I've spent a couple of hours talking it through with Ian Baker, Kaldari and a couple of other people, and the we could totally set up a series of more tables for specific queues. But if we start doing that, there will be many, many other legitimate things that should have their own queue, and the interface just isn't designed to deal with that. We'll end up with bloatware: a ton of different states and queues without an interface capable of holding them. Having said that: a queue-based system is totally what we're considering for the second iteration of new page triage, which will happen at some point after this is done (I'm afraid I can't nail down specifics). So this suggestion is worth bringing up again when we move on to that stage, but can't really be done within the current framework - at least not elegantly, or without causing more problems than it solves.

  On the different colours idea; this may be feasible. I'm getting feedback on it over the next couple of days. Okeyes (WMF) (talk) 21:20, 8 March 2012 (UTC)

  Different colours is totally workable, looks like :). What we're going to do is have a distinct "queue" for articles tagged for deletion - so it'll be patrolled, unpatrolled, tagged for deletion, with distinct colours and a way of filtering to include/exclude tagged articles. Does that work? Okeyes (WMF) (talk) 23:18, 8 March 2012 (UTC)

That sounds good; how else can we use colour-coding? It's a good way of making any list very user-friendly, so that certain items stand out well. Would it be possible, for example, to colour-code any article which has no refs section, or unwanted external links (e.g. YouTube), or anything else that could easily be picked up by software? Come to think of it, would it be possible for software to auto-add an unreferenced tag to any article lacking a refs section? Pesky (talk) 08:37, 9 March 2012 (UTC)

Actually, that one's got me thinking ... there are a lot of things which patrollers do which could be semi-automated. It would reduce the workload quite a bit if anything which could easily be scripted would automatically sort new articles into "specific task required" sublists (maybe a single sortable list?) Pesky (talk) 08:57, 9 March 2012 (UTC)

The more "tag" colors there are, the lower the scanibility and usability of the tool. Color tagging must be done at broad levels - "triaged", "untriaged", "marked for deletion" - and that's it. Applying color tags at what amounts to "issues with the article" will reduce the value of color tagging. Now, something like "no references" could be included (and probably should be), but it should be called out as one of the standard "issues" and placed within the "issues" metadata tag section. Articles that have issues will stand out - there will be a big section with red and bold text - but they shouldn't be (and won't be) color coded. --Jorm (WMF) (talk) 09:42, 9 March 2012 (UTC)

I'm with you in this, and I agree that we shouldn't have too many colours and that the colours at newpage patrol should relate directly to where an article is in the newpage patrol process. But I think we could have a little more colour without making it too complex. My preference would be a system where things started in one of three colours:

1. Grey - as at present the article is fully patrolled and has gone straight into mainspace. Either the article was created by an editor with the Autopatroller flag or currently an admin.
2. Yellow - as at present an unpatrolled article.
3. Red - An unpatrolled article that can be by the system as "suspicious". For example created by an editor whose previous article was speedy deleted for badfaith reasons - G3 or G10, or the editor has recent warning templates, or the page has high risk words and phrases. Reds would be unlikely to last long in that colour as they would probably be look at quite quickly and would change colour.

Patrolled colours:

1. Pink, or maybe grey but with a strike-through - articles currently tagged for deletion.
2. Green - a new intermediate status for articles patrolled as being "Good faith"
3. Grey - As at present the article has either been created by someone with the Autopatroller flag or it has been marked as "ready for mainspace".

So patrollers would no longer have to patrol articles they'd tagged for deletion so that other patrollers would know they'd been dealt with. Removing a deletion tag would result in a article reverting to its previous colour rather than simply going into mainspace. Also if you aren't sure whether an article merits deletion, or don't have the time to fix it, but you are comfortable that it isn't a attack page or outright vandalism then taggng it as Goodfaith will at least tell others that someone has run an eye over it.

My expectation is that pink would only stay that colour very briefly and yellow usually would go grey or green within minutes. Occasionally a backlog would develop during busy parts of the day but the vast majority of articles would be at least minimally screened at the front of the queue. Currently almost all attack pages are picked up at the front of the queue, so the front of queue patrollers are looking at almost all new articles at the front of the queue. But as we don't currently have a tag to say "Goodfaith", some patrolling is overgenerous and some complex new articles probably get looked at by multiple editors before eventually getting to the back of the queue. If [mark as patrolled] was replaced by a choice of [Good faith] / [ready for mainspace] then my belief is that the system would be far less bitey and more efficient both at using people's time and at sifting out the total crap which is a proportion of our new pages. ϢereSpielChequers 19:40, 9 March 2012 (UTC)

I think the existing 3-part colour scheme pretty easily deals with articles tagged for deletion and letting other patrollers know they've been dealt with. And we can identify G3/G10/whatever without needing an extra colour scheme to complicate things. I also know that there are usability issues with the colour yellow - it is something a lot of devs passionately hate :P. I can find out the precise rationale if you're interested. Okeyes (WMF) (talk) 21:18, 9 March 2012 (UTC)

I've no objection to yellow or any of the specific colours I've suggested being replaced with something else, especially if there is a problem with that colour for colour blindness or something. I'm merely listing it to explain my proposal. So if the devs make "suspicious" articles blink or bold that would be cool with me, I'm mainly concerned that we can have them identified in some way. But the split between "Goodfaith" and "ready for mainspace" is an important one that would make the whole process more efficient and less hostile to newbies. ϢereSpielChequers 10:03, 10 March 2012 (UTC)

Agreed, and more granular ways to identify pages is something we really, really need to work on. Hopefully we'll have something closely aligned to the idea of "queues" in the second development cycle, which will take the place of colour-changes or whathaveyou. What I worry about is the learning curve. We're using one section - colours - to represent six different categories of page, some of which overlap, and all of which contain multiple variables ("tagged" and "patrolled", "not tagged" and "patrolled", "not tagged" and "unpatrolled" and "good faith", say). It seems far easier to break it down into chucks; have a minimal colour-based identifier (patrolled/unpatrolled/CSDd) and then use metadata displayed on other bits of the page to explain additional facts about the article and its status. Okeyes (WMF) (talk) 10:13, 10 March 2012 (UTC)

I agree that we don't want too many colours, and I think we have agreed that two is over simplistic and a lost opportunity. I'd be interested in any advice from ergonomists as to the realistic maximum for such a system, but I'd be surprised if it was lower than six. I don't see there is overlap in the 6 colour scheme that I suggested. Yes the articles tagged for deletion will include both patrolled and unpatrolled ones, but I think most people will consider that whilst they are deletion tagged that tag rather dominates their status. Equally the "suspicious" articles are only a subset of unpatrolled. but they are a distinctly high priority subset and of great interest to most patrollers. ϢereSpielChequers 10:29, 10 March 2012 (UTC)

AWB

Yes, I can see the reasoning there. What do you think about the possibilities of partial software-patrolling? Getting input from a few human patrollers on how they mentally-script certain functions (e.g. If A is absent/present, if B is absent/present ... then ... else, etc. Nested if-statements, kinda thing.) If it's possible for software to pick up even 40% of the things which patrollers look for, it would free up the patrollers to do more stuff which can only really be done by a human. Pesky (talk) 09:54, 9 March 2012 (UTC)

Auto wiki Browser has lots of uncontentious minor fixes that it will do to articles if you are running AWB and also fixing a typo etc. One way to improve new articles would be to build that in to the article creation process, so when someone clicks preview it could say "Wikipedia's computer also has the following suggestions but they need a human to accept them recommends the following changes". Or alternatively make it an option in zoom to also do AWB recommended fixes, my belief is that newbies will find the process much less bitey if other editors are at least making some effort to improve their work, even if they also tag it for deletion. ϢereSpielChequers 18:11, 9 March 2012 (UTC)

Unless I'm totally misremembering (quite possible at the mo!) AWB either doesn't work at all, or doesn't work reliably, with Macs? (And no, I'm not going to get a Windoze machine just to run AWB ... ;P ) Pesky (talk) 18:17, 9 March 2012 (UTC)

Yup AWB runs on Windows. I'm usually on Lynux myself, I have a little netbook PC that is on windows but it doesn't have a large enough screen for AWB. But this page is for discussing changes with the developers, and things that seem impossible to us may be trivial to them. Porting some or all AWB functionality into mediawiki so that it is an option for all editors is a possible development, and I think would achieve your suggestion of "partial software patrolling". PS sorry to hear about the morphine, get well soon. ϢereSpielChequers 18:35, 9 March 2012 (UTC)

See my reply below. Okeyes (WMF) (talk) 21:16, 9 March 2012 (UTC)

reflinks

... and how about some software which automatically runs Reflinks on new articles, on saving?

... and how about a bot which trawls for improperly formatted refs and bare urls, and goes in and fixes them? Ref problems are almost certainly the most common things at the tail-end of the new pages queue. And there's a heap (thousands) of articles with bare url's :o) Pesky (talk) 10:01, 9 March 2012 (UTC)

If it is a cosmetic thing that can be fixed by bot it doesn't need to be part of the newpage patrol process. ϢereSpielChequers 18:11, 9 March 2012 (UTC)

I wasn't thinking "cosmetic thing", just some stuff which could almost certainly be scripted somehow, which are things that (good) new page patrollers take time to do at the minute, which would free up that time for them to patrol and / or improve more new pages. I'm probably not making myself remotely clear, here. Blame the morphine! Pesky (talk) 18:19, 9 March 2012 (UTC)

I'm an advocate of the theory that the drift from fixing things to tagging them for others to fix is at the root of many of our community problems in the last few years. So I'm all for encouraging patrollers to step beyond template bombing and move the community back to the wp:SOFIXIT philosophy that prevailed in our golden years. But I suspect that our devs need specific suggestions that they can code. Porting AWB into mediawiki is one, recognising languages and offering to transfer editors to the wiki they rally want to be in is another. At the moment I'm very hopeful that this new tool for handling newpages could well be a much less of a template bombing process than the current one. But we need to come up with a system design that is less encouraging of template bombing or even dependent on drive by tagging and ideally instead have one that encourages collaborative editing. ϢereSpielChequers 18:53, 9 March 2012 (UTC)

Okay, completely replicatnig AWB and sticking it into core or a mediawiki extension sounds like a timesink (and possibly a problem with legal issues. I'm not sure; I'll see what the devs think before bothering the lawyers). These are good ideas, but we're going off-track. We have two months in which to replace Special:NewPages, develop an "article view" for when you select specific articles in that special page, and build an underlying API that can serve a large amount of metadata. We really don't have the time for replicating bots or complex editing tools. I would suggest holding suggestions like this until the second development cycle in a couple of months, where we will have more time to experiment and more freedom in our vision. Okeyes (WMF) (talk) 21:12, 9 March 2012 (UTC)

Rather than tell people to hold back on ideas for the second development cycle can I suggest that you consult the devs and just mark the various threads as "being implemented in stage 1", "Possible stage 1 implementation", "being implemented in stage 2", "Possible stage 2 implementation", "nice idea but not possible to do by computer" etc. That way it is up to the devs to say whether an idea is feasible, a minor tweak that they can do right now or a major change that would require a lot of new code. That way we can concentrate on what we want the system to do and how much we want various changes and why we do or don't want them. ϢereSpielChequers 10:12, 10 March 2012 (UTC)

Sure. I should make clear that I am not a developer; I can't say "X is complex to code" or "X is easy to code" with complete accuracy (although obviously if something is extremely hard or extremely easy, I'm usually right). What I can say is "this does not fit within the theme or methodology for the first sprint but does for the second, so it is exceedingly unlikely that we will develop it in the first, but it may be good for the second". I had an hour and a half-long meeting today to work out precisely what will go into the first sprint, and managed to get quite a few community requests in; Ian Baker (one of our devs) spent the afternoon inputting them into mingle, and as soon as he tells me he's done, I'm going to copy it over and have a full list of what we're doing first. Okeyes (WMF) (talk) 10:19, 10 March 2012 (UTC)

When it comes to that point, I have a gadzillion-and-one ideas for the software people to enjoy considering, which would (hopefully) help newbies to create better articles from stage one, and thereby reduce the load on new page patrollers, and so on :D Things which could become part of article creation wizard, etc. Pesky (talk) 10:43, 10 March 2012 (UTC)

• Do any of them look anything like mw:Article Creation Workflow/Landing System? :) Okeyes (WMF) (talk) 10:48, 10 March 2012 (UTC)

• That's the general idea, for quite a bit, but it would also include things like prompting to add citations, with fill-in-boxes/templates in pop-up windows, and options to save draft to userspace (combined with auto-dropping some decent refs help info on the user's talk page), and all sorts of other stuff. It would pick up where the user had had trouble, and auto-drop whichever info was most relevant onto their talk, with a link to the article either in main space or their user space, and so on, and so forth, and maybe create a to-do list for them ... like having an interactive online tutor / mentor. My best coding / prog work was always with Omnis 3 (database manager) and onwards, creating task buttons etc., so I can usually tell if something would be relatively easy to do or not, but I can't (yet?) write for WikiStuff. I created / helped to create a lot of mini-progs which worked on a kind of flowchart basis. I have a mass of ideas crawling around in my brain. Along with the morphine .... ;P Pesky (talk) 10:56, 10 March 2012 (UTC)

WMF cares what the community thinks: WP:NPT or...?

(contd. from comment in section NoIndex until patrolled by Nortonius (talk · contribs) @ 10:36, 3 March 2012 (UTC)

Nortonius, I've just created a suite of pages asking for editors' opinions on some proposed tweaks and tweaks they'd like to see. This is called "caring what the community thinks" :). Okeyes (WMF) (talk) 15:02, 3 March 2012 (UTC))

When it suits, maybe... But, I don't want to appear churlish, so thanks for the tip; right now though I'd be more impressed by a substantive contribution from anyone on your side of the fence, to that thread on Jimbo's talk which I already linked, before it disappears forever into the archive. Nortonius (talk) 15:17, 3 March 2012 (UTC)

Thanks for the link; I'm afraid I'm having some problems following the conversation (rather long) :). On the help front: we are (touch wood) bringing an editor in to work on improving the help interface and the quality of documentation - you might also want to look at WP:TEAHOUSE, which is a live Q&A venue, and I know that there are talks to create an actual live venue other than IRC that would live on-wiki. On the arbcom-taking-over-IRC-channels point: that's not, unfortunately, our baby :(. IRC channels live in this strange aether where neither the Foundation nor the community entirely controls them. Okeyes (WMF) (talk) 21:34, 3 March 2012 (UTC)

Yes, that thread is rather long, now; but your comment right here rather underlines the problem for me. If WMF really followed what goes on on Wikipedia, they'd already have a handle on what the WP community thinks, about the issues I've raised on Jimbo's talk, and about the present, related issue. The role of IRC, specifically its use for WP help, is problematic precisely because everyone says that it lives in "this strange aether"; but that's just passing the buck – obviously the community or WMF can do something about it. The community is at an impasse about it; Jimbo (for whatever reason) hasn't responded to several invitations to comment – i.e., he hasn't commented on that now rather lengthy thread on his own talk, though I happen to know that he has expressed concern elsewhere – and, apologies, but it seems that you have failed to grasp what that thread is really about! Thanks for trying to read it, but what you just said explains a lot, IMHO.

On the other hand, I'm interested to hear of these "talks to create an actual live venue other than IRC that would live on-wiki" – if that (or something similar on WP) were to become a replacement for en-help on IRC, placing WP help directly in the hands of the WP community, instead of this "strange aether" thing that no-one admits to owning, it looks to me like that could be a significant advance. As does talk here of isolating new pages until patrolled – that's beginning to look more and more like the old NPP proposal by another name! Who knows how many people lost interest when the community got that slap in the face, or were de-motivated through its knock-on effects? Forgive me if this seems impertinent, but remember that the vast majority of contributors to WP are giving their time, energy, knowledge and use of their material assets to this thing free of charge; over time, they get a feel for how the whole thing works, whether or not they understand the mechanics of how it works; and, at present, it seems that WMF is more interested in quantity than quality. It ill behoves WMF to disregard contributors' views and interests, therefore, as they have done in the past; and I very much hope that the present WP:NPT discussion leads to something which reflects that, including the notion that this is supposed to be an encyclopedia, not a social network, or social experiment. Thanks for reading. Nortonius (talk) 11:53, 4 March 2012 (UTC)

The Foundation does its best to follow; we have a dedicated liason, Maggie, whose job is to monitor what's happening. However, it's always worthwhile to point out that Jimbo does not make decisions on day-to-day matters, except in his role as a normal editor. His talkpage is probably not the best place to ask about that. However, if you want to email liasonwikimedia.org, I'm sure Maggie can find an answer for where we stand on this. The idea of on-wiki help is currently in its infancy (it's being worked on by one of our researchers in his pseudo-spare time) I'm afraid :(. On the restrictions front, we're talking about saying "articles won't be visible to google until they're patrolled". That's a long way away from "no new editor is ever allowed to create an article". As said, the point of this engagement strategy and this project is to consult with the community; I think it would be more productive to focus on what we can do to make patrolling better as part of New Page Triage than rehash old issues. Okeyes (WMF) (talk) 19:21, 5 March 2012 (UTC)

Okeyes, I'm in no doubt that WMF means well, and I understand that Jimbo doesn't make decisions on day-to-day matters; but, Jimbo aside, is this really a day-to-day matter?! According to the first paragraph of WP:NPT, "[the] New Page Triage project is an initiative of the Wikimedia Foundation to improve the quality of new articles, the ease of patrolling them, and the treatment of their creators." That sounds rather fundamental, to me. In that same paragraph, it says "[deficiencies] in the way new pages are currently created and managed, combined with problems with the existing software, led to understandable frustration which contributed to a proposal to turn off the ability of new editors to create pages." So, this "old issue" is raised right there, before I said anything here: may I humbly suggest that this is only an "old issue" because WMF made it so, over the heads of the WP community, per the Wikipedia Signpost article of 26 September 2011, "Foundation overrules community consensus on autoconfirmation trial"? That community consensus, as I understand it, was that it would be better in the long run for WP if only new articles by new editors were quarantined until the community had a chance to ensure that they met minimum, existing standards for inclusion in WP: I think it was a misapprehension on WMF's part to see this as a "restriction", and I think it's unbecoming to dismiss this "old issue" as being merely born out of "frustration". Clearly, the WP community has a very good handle on how WP functions on a "day-to-day" basis, and an empirical view of how it can best be taken forward. And, while the present drive for WP:NPT is consuming WMF's limited resources in creating new software, I'm given to understand that, besides quite possibly having put this whole issue to bed months ago, implementing the rejected WP consensus would have required the addition of approximately one line of code to existing software. That all of this has arisen because WMF was worried that "no new editor [would ever be] allowed to create an article" reminds me of the old story about Nero fiddling while Rome burned.

Thanks for the tip about emailing Maggie (did you mean "liaison@wikimedia.org"?), but I'd rather keep discussion of this on-WP. Talking of which, I'm alarmed to read that the "idea of on-wiki help is currently in its infancy (it's being worked on by one of our researchers in his pseudo-spare time)". In a response to comments from me on his talk page, Jimbo has said that "[on] the IRC issue, I can say this: I strongly support that all the IRC channels should be firmly under general community control, and I'm happy to take whatever action I can to ensure that this is the case. … I think it is within my remit to defend, strongly and using whatever influence I have up to and including contacting the Foundation and Freenode, to ensure that the community has an appropriate voice." I don't want to quote him out of context – i.e., he also says that he "[thinks] that the current status quo [regarding en-help on IRC] is not particularly broken, though [he] could be persuaded otherwise": I and some others think that it's shaky at best, and I'll try to persuade him of that. I think the point there is, anyhow, that WMF would do well to direct its resources there, rather than here. Cheers. Nortonius (talk) 13:06, 7 March 2012 (UTC)

Hi Nortonius, I appreciate that IRC and ACTRIAL are both interesting and contentious subjects. But this is a thread about a NOINDEX proposal on a new system for handling newpages, would you and OKeyes mind moving this part of the debate elsewhere? And yes I've heard the argument that we should do ACRIAL instead of improving the newpage patrol software, but the two are not alternatives. ACTRIAL was not a proposal to stop creating all newpages, so whether or not we ever go ahead with ACTRIAL we still have a bunch of issues to resolve at newpage patrol - including some like articles moved from userspace or created by turning redirects into articles that might well become more common if ACTRIAL ever went ahead. ϢereSpielChequers 16:55, 7 March 2012 (UTC)

Short answer, no, I don't mind a bit – though it started out directly relevant to the topic, it has become a bit of a "subthread"; I think it still belongs on this talk page, though. I'm a bit tied up IRL right now, I'll try to separate it into a new topic here later today. Understood about the other stuff, this sort of thing seems so fundamental I can't believe it doesn't get more attention, and hasn't been sorted out long ago. Cheers. Nortonius (talk) 17:45, 7 March 2012 (UTC)  Done

Thanks Nortonius, I think the whole ACTRIAL thing could have been handled very differently. At the very least it should have been the board making a decision to overrule a clear majority on our largest editing community. I know this may sound a tad hierarchical, and Kudos to the developer who intervened, but I think the community deserved a response from someone with the clout to offer an alternative. ϢereSpielChequers 18:00, 8 March 2012 (UTC)

Well, the board doesn't usually deal with specifics of the Foundation's work. And by "someone with the clout to offer an alternative"; Erik was the person who got involved and ended up speaking for the Foundation rather than individual devs. He's head of the Engineering department, and the reason New Page Triage is going ahead. I don't think an absence of clout is an issue here. Okeyes (WMF) (talk) 19:08, 8 March 2012 (UTC)

I'm not saying there is an absence of clout now. But the original decision to veto ACTRIAL was made by a developer not by Erik. Which is a bit of an awkward issue, as the idea had a clear majority and arguably a narrow consensus on the English Wikipedia. ACTRIAL's stated intent was to accept 27% false positives in that 27% of new articles by newbies don't get deleted but would have been kyboshed by ACTRIAL. I suspect that the incorrect deletions amongst the 73% that do get deleted would bring that up to 30% or more false positives. If a rollbacker had anything close to that high a false positive rate they'd lose Rollback PDQ, and if a Bot was functioning that badly we'd block it without hesitation. So ACTRIAL was groundbreaking and controversial, but I'm not convinced that the Foundation declined it in the most diplomatic way. ϢereSpielChequers 19:24, 8 March 2012 (UTC)

Oh, completely agreed; communications-wise, it could have been handled a lot better. But lets look at the practicalities of the situation; a bugzilla thread is posted. Now, Erik was clearly not aware of it immediately, otherwise he would've commented immediately: the people soonest aware were our developers. They're expected to address features requests when they come in, and did. Erik's only way of intervening at an earlier stage would be if he was aware of the specific bug report being filed. And I'm still not talking about an absence of clout now; Erik commented on the bugzilla thread. Erik said, very clearly, right back when the thread was filed, that it wasn't appropriate but that we would investigate alternate ways of dealing with the issue. He's been involved for almost the entire process, including most of the bugzilla discussion. It's not as simple as saying "it was just devs at the time of ACTRIAL, and only recently have Important People been paying attention".

For reference, the devs weren't saying "this isn't gonna happen". People like Brandon and Brion were giving their opinions. The eventual guy who declared "WONTFIX" was Erik himself. Similarly, I can make statements about how I think community engagement should go. But until Howie and Erik sign off on them, that's all they are: my statements. They're not a formal decision, and they're not What The Foundation Thinks.

In any case, this is off-topic and not particularly useful. We can totally revisit ACTRIAL if you want to keep discussing it over and over, but this isn't the venue and there's not going to be a change: the Foundation is not going to be switching it on. So any discussions to the tune of "they should" are a waste of time, and the sentiment that communicating the decision was done in a screwed-up fashion and we need to get better at discussing features with the community is a known thing shared by all of the staffers I've spoken to. Improving communications is why we're here right now. Okeyes (WMF) (talk) 21:05, 8 March 2012 (UTC)

I appreciate this clarification. MathewTownsend (talk) 18:33, 9 March 2012 (UTC)

Language detector

Every day we get new articles which are in the wrong language. I fear that some are speedied on sight, others go through a tagging and templating process which often results in their deletion, sometimes they are translated or become redirects. I suspect that this is more common on EN wikipedia than other languages, if only because www.wikipedia.org redirects to en.wikipedia.org. We could probably reduce this and make Wikipedia a more welcoming place for at least a thousand newbies a year. All we need is an edit filter that identified when people were trying to save a page in a language other than English, and then asked them in English and also the other language. "You are about to create a page in Arabic on the English language version of Wikipedia. Would you like to post it on the Arabic wikipedia instead? [Yes please, take me to the Arabic Wikipedia. No thanks, I am about to translate this]". Then if they chose to be taken to the other language it would shift them and their edit to the language version that they prefer. ϢereSpielChequers 18:26, 9 March 2012 (UTC)

Suggestion: the "No thanks, I am about to translate this" option should default to saving into a userspace draft until the translation has been done. Pesky (talk) 21:55, 10 March 2012 (UTC)

I'm a strong believer in the idea that articles belong in mainspace, so I wouldn't be comfortable about such a suggestion. I appreciate that some people prefer to start with drafts in userspace, and I wouldn't want to stop such a practice. But I don't think we should encourage it, as far as I'm aware all initiatives to encourage userfication and incubators have hit the problems that A Userfication is as much a rejection as deletion, except it doesn't need an admin to do it, so it probably comes across as more bitey to newbies. and B This is a crowd sourcing project, crowd sourcing functions in mainspace, it doesn't function or at least nowhere near as well in userspace or incubators. There is also the practical issue that some articles will get false positives on such a filter, I'm thinking of articles on Scandinavian Heavy metal groups and their albums, but they won't be the only ones. ϢereSpielChequers 02:06, 11 March 2012 (UTC)

That's a good idea. I'll throw this idea around in my end-of-week wrapup of community suggestions and see what people think. Okeyes (WMF) (talk) 21:19, 9 March 2012 (UTC)

And what do you do now when you something like that? Do you just move that article to the other language version? --21:36, 10 March 2012 (UTC), Utar (talk)

No. What you are supposed to do is template it with {{Not English}}, then you try and work out what language it is written in and you report it, and the language you think it is written in at Wikipedia:Pages needing translation into English. Hopefully someone there will translate it. Then you drop a tailored multilingual message on the creator's talkpage. What I suspect that some do is use an automated translator, have a look at the result and then delete it per the most likely speedy deletion category. ϢereSpielChequers 02:09, 11 March 2012 (UTC)

Although if you know the language and can tell it meets one of the CSD, you can tag it. Also, if you find the article was cut and pasted from a foreign language wiki, you tag it with db-A2 and link to the article it was copied from, though that doesn't happen often; I've only used A2 once in about a year and a half. The Blade of the Northern Lights (話して下さい) 05:08, 11 March 2012 (UTC)

I think I've seen the correct use of A2 once. Most of the time it comes from new patrollers who think that any non-English article gets {{db-a2}}. Reaper Eternal (talk) 16:54, 12 March 2012 (UTC)

That's mostly what I see too. Chegue was the one time I used A2; it was directly copied from Portuguese Wikipedia. The Blade of the Northern Lights (話して下さい) 17:30, 14 March 2012 (UTC)

• So, I've spoken to our developers about this. TL;DR version is "it's probably very complicated"; we haven't researched it in great detail, but on the face of it it looks difficult. Now, this doesn't mean that we can't do it: but it does mean we can't do it in the first development cycle, which is mostly scoped out. We can definitely revisit the idea for the second cycle, though :). Okeyes (WMF) (talk) 06:45, 14 March 2012 (UTC)

What can semi-qualified users do to help?

I would like to help, and I have been attempting to do so, but I am not sure how to help. If a page seems to be an obvious deletion, I mark it as such. I don't know all of the rules so I don't feel qualified to mark a new article as patrolled. I have some skills with the language and can copyedit and patrol for obvious errors. Is there some way to put those skills to work while pick up the remaining skills for new page patrolling? - UnbelievableError (talk) 05:29, 11 March 2012 (UTC)

There's nothing stopping you from doing any fixing and / or tagging which is obvious, and then leaving the page as "unpatrolled" for someone more experienced to double-check. Anything which you can do will reduce the workload for others. Pro-tip: follow a good patroller around in npp, then check the diffs on what they've done, to see what they thought needed to be done before they passed it. Pesky (talk) 07:34, 11 March 2012 (UTC)

Thanks for the tips. The problem is that I'm not very proficient at tagging without Twinkle. I found the setting to stop it from marking anything I tag as patrolled but it was too late for Slick2D. Another set of eyes on that one would be appreciated. - UnbelievableError (talk) 05:30, 13 March 2012 (UTC)

That one is a PROD. It would be a CSD for non-notable software if ever the community could agree on how to word such a category. Livit⇑^Eh?/_What? 18:10, 13 March 2012 (UTC)

Thanks for having a look. I noticed that the CSD policy wording didn't fit the case and considered PROD but wasn't sure at the time. - UnbelievableError (talk) 02:24, 14 March 2012 (UTC)

You might want to learn from an experienced users's patrol log available at Special:Log. Dipankan says.. ^{("Be bold and edit!")} 05:14, 14 March 2012 (UTC)

At sidebar?

note: a Special:NewPages link will be added to the sidebar

Hello. Probably we could include a link to NPT page at the Sidebar? Currently I have my own script, User:Dipankan001/New pages.js, which includes a quick link at the personal toolbar at the top right corner of the screen. It would really be easy, rather than typing the full name and pressing Enter, taking 5 or more seconds from your life..... Dipankan says.. ^{("Be bold and edit!")} 05:22, 14 March 2012 (UTC)

I concur. This would seem to fit with Recent Changes under the Interaction heading or within the Toolbox heading. If I had to choose, I believe New Pages would fit best near Recent Changes. - UnbelievableError (talk) 05:41, 14 March 2012 (UTC)

That's fine now. Dipankan says.. ^{("Be bold and edit!")} 05:45, 14 March 2012 (UTC)

• That's the plan :). One of the bottlenecks I identified through things like the survey was that there's really no clear indication to a lot of people that this page even exists. If we make it more prominent...well, we can't increase the workload :P. Okeyes (WMF) (talk) 06:44, 14 March 2012 (UTC)
• I have modified my script to bring it at Toolbox. If you need to bring under Recent Changes, then you have to edit the MediaWiki interface. Dipankan says.. ^{("Be bold and edit!")} 05:05, 21 March 2012 (UTC)

  Indeed! It's a fairly small tweak to make, really. Okeyes (WMF) (talk) 09:52, 21 March 2012 (UTC)

wikiprojects

Can the tool show if an article has been tagged for wikiproject? Spartaz ^Humbug! 18:35, 17 March 2012 (UTC)

That would be pretty awesome as metadata to indicate if other users have played around with it. I'm not sure how we'd fit it in, and there may be more accurate ways to find out if attention has been paid (number of distinct editors, say) but I'll see what the developers think :). Okeyes (WMF) (talk) 18:58, 17 March 2012 (UTC)

Bringing articles to the attention of wikiprojects is crucial to getting them improved and we lack a standard set of templates so you usually have to search for each wikiproject before you can add the tag to make sure you get the template right. We have sub sorters, a wikiproject sorting team would be cool too. Or better still standardization of template nomenclature so you have a decent chance of guessing right. Spartaz ^Humbug! 02:44, 18 March 2012 (UTC)

Or betterest, a system similar to HotCat that allows semi-automated addition of articles to projects (with some sort of tag to draw attention to them for verification & attention by project members). VQuakr (talk) 02:53, 18 March 2012 (UTC)

It can categorize their talk pages with some prefix, say %. You, as a member of that project, then just go through your project categories, from time to time, to sort those not-checked ones. --10:04, 18 March 2012 (UTC), Utar (talk)

The only one I find that's an enormous pain in the arse is WikiProject Music. And also WikiProject Mathematics. Most of the rest of the time, you can just guess. —Tom Morris (talk) 17:04, 19 March 2012 (UTC)

Yes I have had the displeasure of trying to tag something to wikiproject Music myself. I wouldn't recommend it as a useful way to spend any time for sure :-/ Spartaz ^Humbug! 17:07, 19 March 2012 (UTC)

What's the problem with these WikiProjects? --23:32, 19 March 2012 (UTC), Utar (talk)

• Over the week we were actually discussing Wikidata, which would be a really great way to remove categories and tags and handle those things through uniform metadata. It certainly won't be finished before we are, though :(. Okeyes (WMF) (talk) 15:51, 18 March 2012 (UTC)
  • One thing we really need to think through is making sure new pages are tagged to a wikiproject as that is a very common avenue for article improvement. Some thoughts on this would be really cool. Can a tool help us do this somehow? Spartaz ^Humbug! 02:27, 19 March 2012 (UTC)
    • We did a lot of this during the cleanup of unreferenced BLPs. At one point we identified that 20,000 of our unreferenced BLPs hadn't been tagged to Wikiprojects and several of us went on a huge exercise to tag those articles. But my conclusion from the exercise is that the active wikiprojects have categories that they keep tabs on, so the really important thing is to encourage patrollers to load up Hotcat and categorise new pages. I wouldn't say that Wikiproject tagging was a complete waste, especially for active projects such as Heavy Metal and LGBT, but my suggestion would be to focus on categorisation. ϢereSpielChequers 16:24, 19 March 2012 (UTC)
      • Now that's interesting. Thanks Spartaz ^Humbug! 17:07, 19 March 2012 (UTC)