Wikipedia talk:New pages patrol/Reviewers/Archive 15
This is an archive of past discussions on Wikipedia:New pages patrol. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 10 | ← | Archive 13 | Archive 14 | Archive 15 | Archive 16 | Archive 17 | → | Archive 20 |
Inactive reviewers
- Mduvekot, the staggering and glaring issue is that 500 reviewers between them are unable to reduce the backlog by doing just 26 patrols each (yes, that's all it would take), not even now since the vast daily new page intake of trash has been eradicated. The filters would be irrelevant if the backlog were reduced to near zero. Everyone could patrol from the front of the queue and there should never be more than a day's new pages to process. All the talk about filters would be moot. Kudpung กุดผึ้ง (talk) 06:44, 23 September 2017 (UTC)
- Kudpung OK, I'll stop complaining about filters and just get on with it. FWIW, I do about 120 a month. I agree that it seems baffling why we are taking so long to reduce the backlog. Let me try an explanation: if we did them all on the same day, then of course you're right, it would only be 26 per reviewer. We have maybe 10 people who (can) do that.[1]. But we're not doing it all in one day, so you have to account for around 750 new pages each day, or whatever the number is now after ACTRIAL. That doesn't seem like a lot, but if we take a week, the number of reviews each of those reviewers would have to do, goes up to 36.5, if it's a month it becomes 71, and if we took six months to clear the backlog, like it seems we are… 296. Mduvekot (talk) 10:10, 23 September 2017 (UTC)
- Mduvekot, I probably do 150 a month, I'm not sure. That's an average of only 5 a day on the fly, and I'm not a New Page Reviewer - I just monitor the system. What gives me pause is that of the 500 users who asked for the right, some of them don't appear do be doing very much at all. If every one did 130 a month, that's a potential of 65,000 reviews a month - far more than we need to get the backlog down to zero... Kudpung กุดผึ้ง (talk) 10:23, 23 September 2017 (UTC)
- I'd recommend removing those rights from non-participants without warning per WP:HATSHOP. The filters do help productive reviewers in working the backlog. Chris Troutman (talk) 10:28, 23 September 2017 (UTC)
- Mduvekot, I probably do 150 a month, I'm not sure. That's an average of only 5 a day on the fly, and I'm not a New Page Reviewer - I just monitor the system. What gives me pause is that of the 500 users who asked for the right, some of them don't appear do be doing very much at all. If every one did 130 a month, that's a potential of 65,000 reviews a month - far more than we need to get the backlog down to zero... Kudpung กุดผึ้ง (talk) 10:23, 23 September 2017 (UTC)
- Kudpung OK, I'll stop complaining about filters and just get on with it. FWIW, I do about 120 a month. I agree that it seems baffling why we are taking so long to reduce the backlog. Let me try an explanation: if we did them all on the same day, then of course you're right, it would only be 26 per reviewer. We have maybe 10 people who (can) do that.[1]. But we're not doing it all in one day, so you have to account for around 750 new pages each day, or whatever the number is now after ACTRIAL. That doesn't seem like a lot, but if we take a week, the number of reviews each of those reviewers would have to do, goes up to 36.5, if it's a month it becomes 71, and if we took six months to clear the backlog, like it seems we are… 296. Mduvekot (talk) 10:10, 23 September 2017 (UTC)
- Mduvekot, the staggering and glaring issue is that 500 reviewers between them are unable to reduce the backlog by doing just 26 patrols each (yes, that's all it would take), not even now since the vast daily new page intake of trash has been eradicated. The filters would be irrelevant if the backlog were reduced to near zero. Everyone could patrol from the front of the queue and there should never be more than a day's new pages to process. All the talk about filters would be moot. Kudpung กุดผึ้ง (talk) 06:44, 23 September 2017 (UTC)
- A number of points in reply to the direction this discussion is taking...
- Precise stats of your reviews per month can be found at Wikipedia:Database reports/Top new article reviewers#Last 30 days. However,
- "Top" makes it sound too competitive.
- It doesn't (& can't) distinguish between those actually carrying out reviews and those searching out PROD nominations and marking them reviewed just to inflate their numbers.
- A number of points in reply to the direction this discussion is taking...
- ACTRIAL has been hugely effective at improving the quality of the articles presenting at NPR. The side effect is that, having removed the bulk of those articles which would have triggered an almost reflex CSD, each review now needs more thought and takes longer. The number of reviews per reviewer was bound to decline.
- Again with the talk of hat-collecting. The wiki is a volunteer project. Patrolling is a part of contributing to the project. It's not a full-time life-long commitment. If somebody doesn't use these particular tools for a while - so what? It would be more of a problem when they take the time to patrol a new article and find they're unable to follow through because their tools have been taken away. Removal for mis-use is fair enough, removal for lack of use is counter-productive.
- Just my 2¢. Cabayi (talk) 11:38, 23 September 2017 (UTC)
As one of the admins who has been regularly working PERM for years (for a long time I was the only one doing it), it's often blatantly obvious who the hat collectors are. However, we have to AGF in the first instance and if their editing history reveals nothing egregious, we generally accord the right if the rest of the criteria (numerical and experience) are fulfilled. We made no provision in the New Page Reviewer plicy for withdrawing rights for lack of use. Of course it was an oversight (mine), but to change the rules retrospectively would, as we all know, be extremely difficult. That said, WP:HATSHOP is one of the better Wikipedia essays, it should be promoted to Guideline. Kudpung กุดผึ้ง (talk) 11:55, 23 September 2017 (UTC)
- I'll agree WP:HATSHOP is a good essay but it's all about granting & recommending that the requester should consider their future use of the rights before applying. Chris was using it to support revocation which is a topic the essay doesn't touch upon at all. Cabayi (talk) 13:50, 23 September 2017 (UTC)
- @Cabayi:--It's an interesting observation that there exists some NPReviewer(s) who reviews PRODDed articles to inflate their count!Winged Blades of GodricOn leave 12:14, 23 September 2017 (UTC)
- I was under the impression that the NPR right was about restricting the technical ability to review pages to editors who can be trusted to use it properly, not a commitment to doing X reviews per day forever. I understand the frustration that very active reviewers must feel trying to make a dent in the massive backlog, but surely it's more productive to have a long tail of editors doing a handful of reviews here and there, than exclude them for... well, what exactly? Like Cabayi says Wikipedia is a volunteer effort. If someone has other obligations that don't leave time for reviewing, or they just don't fancy doing it for a few months, that doesn't make them hat collectors.
- On a more positive note I've found NPR a lot less frustrating since ACTRIAL kicked in, and have been doing more of it. Maybe other less active reviewers will find the same and the pace will pick up. – Joe (talk) 13:52, 23 September 2017 (UTC)
- @Cabayi: True, HATSHOP doesn't say anything about revocation; the spirit of the essay seems to intone that userrights are for working on the encyclopedia. My concern is, those managing this project are trying to estimate our progress but we have an unknown number of editors that have flags they're not using. Those inflated numbers create an impression we have more hands on deck than we do. Even if we AGF and agree that everyone is a volunteer, why would anyone object to having a userright taken away that they're not using? It seems like house-cleaning of this sort hurts no one and helps us understand how many we have actively clearing the backlog. Chris Troutman (talk) 14:11, 23 September 2017 (UTC)
- Honestly, who gives a crap about someone's deepest darkest desires? This isn't an exercise in morality. The only requirement is that the person hopefully spends more time productively using the right then it takes the guy at PERM to give it to them. If they manage to do that, then it's a net benefit. If a thousand qualified editors want to trade productive time for a hat, then let them hat away, pray that they hat more. Go collect hats and barnstars and trinkets till the end of the world as long as it improves the project. GMGtalk 14:15, 23 September 2017 (UTC)
- Chris troutman, stripping user rights just to make progress easier to count is perverse. As Joe Roe pointed out, it's about the long tail. Why object to someone who does just one review a year so long as they do it competently? Are the stats improved in any way by denying them the ability to make that contribution to the project?
- The target is to review new pages not to count reviewers and berate them for not doing enough. The only stat that counts is the backlog. And that's easily monitored at the NPP Dashboard without reference to individual efforts.
- Complaining about individual reviewers is futile when everybody is a part-time volunteer. We should accept what they bring to the table and be grateful for it. Cabayi (talk) 14:59, 23 September 2017 (UTC)
This discussion may be pertinent in a new talk section as it has extremely little to do with my original question/request. Tony, thank you for the response on the Phab project.--☾Loriendrew☽ ☏(ring-ring) 15:15, 23 September 2017 (UTC)
- I try to do some NPR when I can, and also work a bit at AfC but most of my time is spent checking them for notability and verifiability which is time consuming. Time is also spent dealing with creators/editors who argue over notability which takes up more time at AfD. I'm also involved in GA/FA reviews from time to time, article creation from time to time, working on Commons, helping new editors, and taking the occasional break to unwind with other productive editors who find a release in humor. I doubt that I'm the only one who operates that way so perhaps what we should be doing is recruiting more qualified editors to NPR so less time is spent arguing over notability, promotional articles and COI created articles. It would be nice if we could slap a G11, or A7 and the like on an article, or even PROD it and move on without having to return because the tag was removed. I'd venture a guess and say the music, film & sports industries are what inundate us because of all the ambiguities, fan advocacies, promoters/marketers using WP for promotional purposes. And then I think about all the undeserved criticism McClenon endured over his delete record. Atsme📞📧 15:31, 23 September 2017 (UTC)
- Well here we are changing topic, again, but I do think Robert's RfA was a bit of a blow for the project. I wouldn't be surprised if some editors are now put off patrolling because they're scared that it will tar them as a bitey deletionist and sink any plans they had to ask for the mop. – Joe (talk) 17:09, 23 September 2017 (UTC)
- I always advocated for that issue. In the beginning, I even thought of discussing removal of NPR flag from active editors who hadnt reviewed articles in 180 days. But later, I realised this wouldnt be too good either. I am on the same terms of Cabayi now. I actually go one step further. Now I believe we should find worthy editors and invite them to join the project. Thats how {{NPR invite}} was conceived. If we have lots of competent edtiors (lets say ~2000), and only ~1000 of them reviewed 5 articles each on a given day, we will have 5000 articles removed from the queue. Or if we assume 500 editors doing it, we will still remove 2500 articles. I regularly lurk at WP:RFR, and I know at least a dozen editors who havent reviewed even a dozen of articles yet. —usernamekiran(talk) 19:42, 23 September 2017 (UTC)
- I've thought about this a lot. and actually, I think that the user right should be removed from users who never really used it much (i.e. those that had it, reviewed a few articles, and hardly ever used it again), with a message sent to the talk page of the editor telling them that they can request it again if they want. We really don't want reviewers who only review one or two articles every few months, because it takes practice to review articles well, and I'd say about 100-200 or more reviews before a high level of competence starts developing. Users that previously did a bunch of reviewing but subsequently stopped reviewing for what ever reason (i.e. SwisterTwister) should retain reviewer status, as they clearly have the experience to know what they are doing if they ever decide to come back. — InsertCleverPhraseHere (or here) 00:12, 24 September 2017 (UTC)
- I always advocated for that issue. In the beginning, I even thought of discussing removal of NPR flag from active editors who hadnt reviewed articles in 180 days. But later, I realised this wouldnt be too good either. I am on the same terms of Cabayi now. I actually go one step further. Now I believe we should find worthy editors and invite them to join the project. Thats how {{NPR invite}} was conceived. If we have lots of competent edtiors (lets say ~2000), and only ~1000 of them reviewed 5 articles each on a given day, we will have 5000 articles removed from the queue. Or if we assume 500 editors doing it, we will still remove 2500 articles. I regularly lurk at WP:RFR, and I know at least a dozen editors who havent reviewed even a dozen of articles yet. —usernamekiran(talk) 19:42, 23 September 2017 (UTC)
- Well here we are changing topic, again, but I do think Robert's RfA was a bit of a blow for the project. I wouldn't be surprised if some editors are now put off patrolling because they're scared that it will tar them as a bitey deletionist and sink any plans they had to ask for the mop. – Joe (talk) 17:09, 23 September 2017 (UTC)
What would be the justification for revoking the right? It is a very limited technical ability to mark pages as ready to be indexed by Google. The only reason we normally revoke rights for inactivity is if they are sensitive and a potential for account compromise would somehow harm Wikipedia: pagemovers have the ability to perform de facto G6 deletions, and template editors have the ability to royally screw up some of the most highly visible pages on Wikipedia. The NPR right doesn't do anything near that level. There are some dangers re: paid and promotional accounts getting it as sleepers, but I'm not sure if the community would get behind revoking it for that potential. TonyBallioni (talk) 00:21, 24 September 2017 (UTC)
- Errors in reviewing are bad for Wikipedia's overall quality, because we are the only firewall. The justification would be that sparsely active reviewers are rarely a net positive to the project. Their inactivity leads to not developing the skills necessary to review new articles properly. While they might cumulatively review a fair amount of articles, many of the very poor reviews are due to users that are very inactive and only show up to review an article a few times a month. In other words, new reviewers generally suck at their job and I am obviously willing to forgive this if they have just been given the right, are still learning and are putting in the effort to learn. But for those that obviously don't intend to actually review enough articles to become competent at reviewing, I think we are probably better off without them reviewing the odd article badly. If they wan't to put in the effort to learn how to patrol properly, they can always request the user right again (and we should grant it if they say they are keen this time). — InsertCleverPhraseHere (or here) 00:32, 24 September 2017 (UTC)
- I just checked the revocation criteria again, and we can revoke it from those who have not edited in a year. I'm not sure if there is a bot that is currently monitoring that. If so, it would currently only apply to those who were grandfathered in and were inactive for a few months before the grandfather but accorded the right based on reviews, so I suppose my objection above is moot.In terms of practical concerns, we would need an RfC to change the revocation criteria, and I doubt we could get consensus for that. I'm not sure how I would feel on something beyond "Must have made a at least one reviewing action at least once every X period of time" myself, and it would also play into the (false) impression that some have that we chase off reviewers that are imperfect (this was actually one of the WMF's reasons for why ACTRIAL was unnecessary when they tried to float their lead ballon proposal). Part of attracting new people to this project is not projecting an image that it is a project where we chase people off for not being perfect. We don't do that, but we should also not be promoting the image that we do. TonyBallioni (talk) 00:48, 24 September 2017 (UTC)
- (I don't plan on following this closely, ping me if needed). I ran a database report of editors with patroller access, that have not edited in a year. There were only 5 editors in this situation, I revoked two as they marked themselves retired - can't see the other 3 actually being an issue, will probably clean them up one day with other group cleanups. — xaosflux Talk 04:04, 24 September 2017 (UTC)
- @Xaosflux: I think you did something wrong for HappyValleyEditor. You were supposed to remove that user from the "patroller" group, not the "autoreviewer" group. Can you fix that, please? GeoffreyT2000 (talk, contribs) 13:59, 24 September 2017 (UTC)
- Fixed. Alex ShihTalk 14:04, 24 September 2017 (UTC)
- Thank you @GeoffreyT2000 and Alex Shih:. — xaosflux Talk 14:09, 24 September 2017 (UTC)
- Fixed. Alex ShihTalk 14:04, 24 September 2017 (UTC)
- @Xaosflux: I think you did something wrong for HappyValleyEditor. You were supposed to remove that user from the "patroller" group, not the "autoreviewer" group. Can you fix that, please? GeoffreyT2000 (talk, contribs) 13:59, 24 September 2017 (UTC)
The situation is actually much worse...
It's been mentioned that approximately 90% of the reviewing is being done by about 10% of the reviewers. Bearing in mind we have 480 reviewers and that only about 50 of them are in any way truly active, in fact it's even less because apparently 30% of them are actually admins. Kudpung กุดผึ้ง (talk) 23:28, 23 September 2017 (UTC)
- The number ~500 reviwers always created problems. In one report, WMF stated "the current system is not sustainable". At that time we had ~400 flag holders, from which only around 45 were reviewers. That inflated number always caused some problem or other.
@Tony: I think we should at least discuss the criteria for removal of flag. We can later decide whether to run RfC or not. I say 60 articles in 90 days; let it be 90 articles in one go or 0.66 articles per day. But instead of "in last xyz das", i think we should use calendar quarters (eg: Jan to March, April to June). —usernamekiran(talk) 02:35, 24 September 2017 (UTC)- But wouldn't that just make the problem worse? While I do think that maybe reviewing at least an article or so per year to retain the flag, reviewers should be able to use the tool whenever. Otherwise, we would lose those who aren't very active, but who still occasionally review. RileyBugz会話投稿記録 02:38, 24 September 2017 (UTC)
- I would strongly oppose any criteria that was overly strict, and I also hate launching RfCs without a strong reason to do so because they test the community's patience. The current revocation criteria allow for revoking of users who haven't made any edits in a year. I get that we have a problem with activity. Hell, during the lead up to ACTRIAL, I was pulled in so many different directions with that and some other project space discussions on quality control for new pages that there were times where I was definitely not an active reviewer when it comes to the actual pages feed.I certainly get why people are mad that we don't have people using the right. I wish more people did it too. I'm just not personally in favour of launching a project-wide RfC to deal with hat collecting for the relatively minor technical ability to allow Google to index a page.The solution to getting more active reviewers is to recruit more active reviewers and to encourage those who have the right to use it. We do typically have an uptick in reviews around the times the newsletter goes out, because it reminds people "Oh, hey, I did sign up for the ability to do this." It also makes people feel a part of a group, which in turn increases their likelihood of helping that group out. I also plan on going through the database report soon and handing out a bunch of barnstars to people who have recently been awarded the right (check PERM archives) and who have been active with it. I'd encourage others to do this sort of thing too. You attract more flies with honey than vinegar, and while I think creating a new revocation criteria at some point might be worthwhile, we'll get more people active by being positive rather than threatening to revoke a right.We already have so much forward momentum as a project with ACTRIAL, there is no need to have a messy RfC that would suck out some of that energy and momentum now. If this was a year ago when we were coming up with the user right, I'd support including it in the original revocation standards, but now, there is a firm set of criteria for the user right, and any changes would need a project-wide RfC. That would waste a lot of energy for little return, which I consider a net-negative. TonyBallioni (talk) 03:21, 24 September 2017 (UTC)
- Yes. Inviting/suggesting long term editors to joining is more logical. We can surpass the number of inactive flag holders by increasing active editors. The advantage with active/long term editors is: even if they dont make NPR their priority, they would review on an individual average of 10-20 articles per week. That is good. So I support Tony partially. I still think we should get rid of those who have been inactive for more than an year. On another note, there appears to be a lot of long term regular editors who still dont know about NPR flag. And yes, systematically encouraging is always a good thing. —usernamekiran(talk) 03:18, 24 September 2017 (UTC)
- I would strongly oppose any criteria that was overly strict, and I also hate launching RfCs without a strong reason to do so because they test the community's patience. The current revocation criteria allow for revoking of users who haven't made any edits in a year. I get that we have a problem with activity. Hell, during the lead up to ACTRIAL, I was pulled in so many different directions with that and some other project space discussions on quality control for new pages that there were times where I was definitely not an active reviewer when it comes to the actual pages feed.I certainly get why people are mad that we don't have people using the right. I wish more people did it too. I'm just not personally in favour of launching a project-wide RfC to deal with hat collecting for the relatively minor technical ability to allow Google to index a page.The solution to getting more active reviewers is to recruit more active reviewers and to encourage those who have the right to use it. We do typically have an uptick in reviews around the times the newsletter goes out, because it reminds people "Oh, hey, I did sign up for the ability to do this." It also makes people feel a part of a group, which in turn increases their likelihood of helping that group out. I also plan on going through the database report soon and handing out a bunch of barnstars to people who have recently been awarded the right (check PERM archives) and who have been active with it. I'd encourage others to do this sort of thing too. You attract more flies with honey than vinegar, and while I think creating a new revocation criteria at some point might be worthwhile, we'll get more people active by being positive rather than threatening to revoke a right.We already have so much forward momentum as a project with ACTRIAL, there is no need to have a messy RfC that would suck out some of that energy and momentum now. If this was a year ago when we were coming up with the user right, I'd support including it in the original revocation standards, but now, there is a firm set of criteria for the user right, and any changes would need a project-wide RfC. That would waste a lot of energy for little return, which I consider a net-negative. TonyBallioni (talk) 03:21, 24 September 2017 (UTC)
- But wouldn't that just make the problem worse? While I do think that maybe reviewing at least an article or so per year to retain the flag, reviewers should be able to use the tool whenever. Otherwise, we would lose those who aren't very active, but who still occasionally review. RileyBugz会話投稿記録 02:38, 24 September 2017 (UTC)
- I'm not sure where I stand on this now after having listened to the various arguments. As an admin, I 'm probably biased towards the way we handle admin accounts; and the fact that we have 1,249 admins of whom around 600 are considered active based on a very weak criterion and that probably less than 50 are sharing the real workload. It's unlikely that our admins who have survived the rigors of RfA are hat collectors although there are indeed some who once given the tools have hardly used them and in some cases even semi-retired very shortly afterwards.
- I worry however about the motivations of those seeking minor rights, and as I mentioned, it's not without extensive experience according the whole range of them at PERM over the years. Their reasons for requesting range from the sublime to the ridiculous and even plain trolling, and the occasions when a user gets one and then comes back a few days later to ask for more needs no explanation. We know also that some have applied for and even been accorded these rights with the intention of using them for unethical purposes. Without wanting to look for reds under the beds, and without assuming bad faith, where there are plenty of sock farmers with sleepers waiting in the barn, it's reasonable to presume that some New Page Reviewer rights might have been acquired in preparation for something calculated.
- There is the very practical aspect therefore of not kidding ourselves that we have a well performing and highly motivated user group, or that the one-patrol-a-month users are making any kind of impact or will be encouraged to do more. Kudpung กุดผึ้ง (talk) 03:27, 24 September 2017 (UTC)
I don't think removing people's right is what we should be spending our time and energy on. A reminder message to those who are inactive might make them use it more: by being positive, offering them support if they're unsure about how to patrol, even perhaps asking them to let someone know if they don't want the right. I'm grateful for any contributions anyone gives, large or small. I don't see that this would be of any help. Boleyn (talk) 06:54, 24 September 2017 (UTC)
- Yeah. it probably isn't worth the effort. I don't support these "x edits in 90 days" ideas. If someone previously reviewed 200 articles in a few months, they clearly have the experience to come back at any time and should retain the right. Just because an experienced reviewer takes a break does not mean they would have 'reviewer' revoked. I've probably taken longer than a month break from reviewing before, but then come back and do a few hundred in a month, it's just how I operate. I only suggested removing it from reviewers that had recieved the right some time ago and never seriously began using it in the first place. But as Boleyn points out, this isn't worth our time to bother with. — InsertCleverPhraseHere (or here) 07:11, 24 September 2017 (UTC)
- Inserycleverphrasehere, I edit in a similar fashion, if I dedicate myself to one project for a while, I then move on to avoid burnout and boredom, but tend to go back to the same ones over time. I do wonder how long it was between me getting the right and actually using it, I'm guessing it was more than a year, but the newsletters eventually persuaded me to become an active reviewer, and then encouragement and kind words from other reviewers helped keep me involved. Boleyn (talk) 07:32, 24 September 2017 (UTC)
- Yeah. it probably isn't worth the effort. I don't support these "x edits in 90 days" ideas. If someone previously reviewed 200 articles in a few months, they clearly have the experience to come back at any time and should retain the right. Just because an experienced reviewer takes a break does not mean they would have 'reviewer' revoked. I've probably taken longer than a month break from reviewing before, but then come back and do a few hundred in a month, it's just how I operate. I only suggested removing it from reviewers that had recieved the right some time ago and never seriously began using it in the first place. But as Boleyn points out, this isn't worth our time to bother with. — InsertCleverPhraseHere (or here) 07:11, 24 September 2017 (UTC)
- Whatever the solution, subjecting the community right now to yet another RfC would certainly be counter productive. People are getting getting sick of hearing about NPP, NPR, AfC, ACTRIAL, and Article Wizard already. The trial should be allowed to run its course and by that time, the landscape of page patrolling might even have changed out of recognition, and then would be the time to consider structural changes. For the meantime, the monthly newsletter may serve to shake the hats from hat stands, or as very recently, handing in the right by some reviewers. Kudpung กุดผึ้ง (talk) 07:33, 24 September 2017 (UTC)
- There already is a policy for removing the flag after an year's inactivity. I am still not sure about what kind of activity though. Any activity, or page reviewing in an year? In any case this should be applied. I even believe if the editor is still active, but hasnt reviewed a page in an year, then removing flag (with a pre-notice) is in order.
@Kudpung: Your comment reminded me, there are still some editors that havent subscribed the newsletter. —usernamekiran(talk) 08:13, 24 September 2017 (UTC)- I'm personally less worried about inactive reviewers that are not doing shoddy reviews than very very very active reviewers that have astronomical reviewing figures but have clearly not spent any time checking the sources or the criteria for notability. They are the ones that are creating more work and letting shoddy articles past. The inactive reviewers are not a problem at all. If we need more reviewers then let's look for new ones rather than removing the right from someone else. Domdeparis (talk) 08:43, 24 September 2017 (UTC)
- There already is a policy for removing the flag after an year's inactivity. I am still not sure about what kind of activity though. Any activity, or page reviewing in an year? In any case this should be applied. I even believe if the editor is still active, but hasnt reviewed a page in an year, then removing flag (with a pre-notice) is in order.
- Until fairly recently (when Dispenser decided to take a crap) I was actively maintaining and pruning the WP:AFC/P list to shift inactive reviewers to the proper location (if only to get a better sense of "the numbers"). Not only was it rather tedious, but at one point there was a slew of "inactive" reviewers who suddenly went active again for whatever reason, and they had to get shifted back to active. While I can agree "the numbers look bad" from an NPR perspective, there are a lot of reasons why someone might drop a project for a while. As mentioned above, there's no harm in having a right you don't use every day, and if someone (through burnout, laziness, or disinterest) decides after a hiatus that they do want to come back, that's fantastic.
- I honestly think that (across the board) we should be (nicely) asking people why they don't use the tools they have (be it NPR, AFCH, etc). Just a nice note (not mass-message) along the lines of "hey, I noticed you haven't been reviewing any pages, what's up?" Some people might have forgotten, some might have decided it was too much effort, but until we have those metrics we won't even know why people are quitting, much less determine how to recruit new members. Primefac (talk) 11:34, 25 September 2017 (UTC)
Idea for a backlog drive
Kudpung's comment above that the backlog would be eliminated if everyone with the NPR right reviewed just 26 articles each had me thinking: another way of looking at that is that if every reviewer did just one review a day, we'd be rid of the backlog in less than a month. So how about we have a backlog drive where we ask editors to review an article per day? I.e. instead of having leaderboards, barnstars, etc. for the total number of articles reviewed, we have them for how long a "streak" of one-review-per-day people have managed to sustain. That way we avoid incentivising people doing quick, sloppy reviews to rack up their total. (Apologies if this has been suggested/discussed before.) – Joe (talk) 17:31, 23 September 2017 (UTC)
- Nice idea but it wouldn't work. It would be like paying a mortgage - you'd be paying the interest but not paying off the capital. It would clear the 15,000 backlog but it won't touch the 18,000 new arrivals (or whatever we're down to now), so you'd still be getting deeper into debt. Whether they are mostly hat collectors or not, or bit off more than they could chew, or were simply turned off by what they saw, 90% of the patrolling is being done by less than 10% of the reviewers. Less if you exclude me and DGG and perhaps one or to others who are only doing patrolling because we're there anyway monitoring the system and looking for stuff other patrollers have missed or wrongly tagged.
- Perhaps we can ask someone like Boleyn, Abishe, Joe Roe, PRehse, and Atlantic306 to tell us what their secret is. These tables weren't in anyway intended as a competition score sheet; they present essential feedback in order to understand what's wrong and perhaps why so many people who gave us admins grief at PERM to get the tools then never, or hardly, used them. Non admins don't generally go to see what goes on at PERM - and it's probably better they don't. Kudpung กุดผึ้ง (talk) 18:00, 23 September 2017 (UTC)
- A backlog drive could work if the effort was in addition to our current effort. As to why some people are so fast: I had a look at the page curation log for some of the reviewers Kudpung mentioned. One tagged (6%) of reviewed articles and marked (5%) for deletion. Another marked none for deletion. If I compare that to my own reviews, I tagged 25% and marked 22% for deletion (the remainder I tend to edit myself before I pass). No wonder I'm slow. Mduvekot (talk) 19:17, 23 September 2017 (UTC)
- My secret is probably neglect of my children and the housework :) In all seriousness, I use [2] a lot, so I'm targeting articles which have a high chance of notability or are in my area of interest, which makes it easier, quicker and more rewarding for me to patrol, so that means I spend more time on it. In many ways, I pick off the easier ones (like disambiguation pages), so high numbers do not indicate I'm contributing more to the project than people with lower numbers but who are tackling trickier ones. I also really believe in the project, so am prepared to give it my time and give very little time now to other areas of Wikipedia I used to contribute a lot to. Boleyn (talk) 19:39, 23 September 2017 (UTC)
- No secret I just limit myself to about 10 redirects and 10 articles more or less. It is amazing how a daily limit/goal eats away at the problem. PRehse (talk) 20:20, 23 September 2017 (UTC)
- Have been marking articles for deletion as unreviewed but will keep them as reviewed in future as it skews the stats. Also when I find a good article I go through the editor's list of creations to review which can be 20-30 good quality articles that don't need deletion or tags. I used to get bogged down in subjects out of my range such as science and health essays but now I pass on them and leave for more knowledgeable editors Atlantic306 (talk) 20:44, 23 September 2017 (UTC)
- No secret I just limit myself to about 10 redirects and 10 articles more or less. It is amazing how a daily limit/goal eats away at the problem. PRehse (talk) 20:20, 23 September 2017 (UTC)
- My secret is probably neglect of my children and the housework :) In all seriousness, I use [2] a lot, so I'm targeting articles which have a high chance of notability or are in my area of interest, which makes it easier, quicker and more rewarding for me to patrol, so that means I spend more time on it. In many ways, I pick off the easier ones (like disambiguation pages), so high numbers do not indicate I'm contributing more to the project than people with lower numbers but who are tackling trickier ones. I also really believe in the project, so am prepared to give it my time and give very little time now to other areas of Wikipedia I used to contribute a lot to. Boleyn (talk) 19:39, 23 September 2017 (UTC)
- A backlog drive could work if the effort was in addition to our current effort. As to why some people are so fast: I had a look at the page curation log for some of the reviewers Kudpung mentioned. One tagged (6%) of reviewed articles and marked (5%) for deletion. Another marked none for deletion. If I compare that to my own reviews, I tagged 25% and marked 22% for deletion (the remainder I tend to edit myself before I pass). No wonder I'm slow. Mduvekot (talk) 19:17, 23 September 2017 (UTC)
Okay so maybe it won't work, but does anyone object to giving it a try? – Joe (talk) 12:14, 25 September 2017 (UTC)
Reviewing pages tagged for CSD/PROD
- Articles that have been tagged for CSD and PROD should not be marked as reviewed IMO, because if the prod is removed and the original prodder didn't keep it on his/her watchlist or didn't notice, the article can fall out of the pew pages feed without being reviewed fully. AfD is a bit different since the taggs really can't be removed without someone noticing. — InsertCleverPhraseHere (or here) 20:53, 23 September 2017 (UTC)
- nor can CSD and prod be removed without notice, if the tagger keeps a Prodf and CSD logs, ( see Wikipedia:Twinkle/Preferences). Sometimes I don't marks as reviewed, if I want to make sure someone else sees it quickly, but usually it doesn't matter. DGG ( talk ) 05:11, 24 September 2017 (UTC)
- If I mark a page tagged for deletion as reviewed, I add it to my own watchlist and if the tag is removed, I investigate it carefully and decide it is notable or take to AfD. Most times they're deleted though. Boleyn (talk) 06:57, 24 September 2017 (UTC)
- nor can CSD and prod be removed without notice, if the tagger keeps a Prodf and CSD logs, ( see Wikipedia:Twinkle/Preferences). Sometimes I don't marks as reviewed, if I want to make sure someone else sees it quickly, but usually it doesn't matter. DGG ( talk ) 05:11, 24 September 2017 (UTC)
New feature suggestion: canned notes
When tagging articles with the curation toolbar, I'd find it very helpful if the note to page creator defaulted to a canned summary of the tags added. I usually end up doing this myself and it could easily be automated. Would others find this useful? Lineslarge (talk) 14:09, 24 September 2017 (UTC)
- It's been suggested that any tags should automatically leave a message on the creator's talk page such as: Thank you for creating xxxxxxx. Please consider returning to the article and addressing the issue(s) noted by the reviewer. It should be among the requested features listed at Page Curation/Suggested improvements, if it's not, please add it. Kudpung กุดผึ้ง (talk) 12:39, 25 September 2017 (UTC)
- Thanks for the reply. I realise that I posted this on the wrong page. Have gone through the suggestions and it's not there (except in specific context of naked URLs) so I will add it. Lineslarge (talk) 07:57, 26 September 2017 (UTC)
It is my duties and responsibilities to review main namespace
Yes I understand the fact that only about 5 or 6 New Pages Reviewers are reviewing the articles every day out of 480+ NPR in English Wikipedia. I am honoured and blessed to review some extraordinary articles as a New pages patroller.In last 2-3 days I would honestly say that I neglected editing for some time and devoted for reviewing articles and I also created article talk pages after reviewing them. That means, I didn't want to grab the opportunity entirely. Patrolling new articles, categorising them etc are hobbies of me and also I really like to do CSR towards Wikipedia. Abishe (talk) 01:32, 24 September 2017 (UTC)
- Abishe, thank you for your help. — Insertcleverphrasehere (or here) 23:26, 26 September 2017 (UTC)
Marking articles that have been tagged for CSD and PROD as reviewed - consensus?
In response to this edit, I'd like to see what the consensus is on marking articles that have been tagged for CSD and PROD. I'm not sure if we need a formal RfC for that. I have in the past argued in favor of marking them as reviewed, because I didn't think we could do anything more (I'd call that the "we're done here" argument), but Insertcleverphrasehere makes a compelling argument for not doing so, and I have been avoiding making such articles as reviewed. I really could live with both, as long as it is done consistently. Can we establish consensus on this or do we perhaps already have it and I just missed something? Mduvekot (talk) 21:07, 23 September 2017 (UTC)
- IMO, they shouldn't be marked as reviewed unless you think that it is incredibly obvious (which would only apply with CSD). Otherwise, we could have articles being approved even though they were just declined for speedy deletion/PROD. You shouldn't review no matter what for PROD because anybody can easily remove it. RileyBugz会話投稿記録 21:10, 23 September 2017 (UTC)
- (edit conflict) Page curation automatically marks something tagged through it as reviewed. If you search the archives I believe we had this conversation in June(?) of this year. I'm fine with CSD tags and AfDs being marked as reviewed. PROD is definitely the one that I think there is more of a case to be made for not marking reviewed. I don't feel strongly either way though. TonyBallioni (talk) 21:13, 23 September 2017 (UTC)
- As I previously stated, there is a significant risk of articles accidentally falling out of the new pages feed due to the reviewing user not checking to see if the PROD/CSD tag had been removed. This can result in articles not being reviewed fully. Aside for the hit to your own 'review count' they don't need to be marked as reviewed, because if they get deleted as CSD or prod they are gone, and if they don't they need to go back into the New Page Feed ideally.
- I suggest that either A) we codify that articles should not be marked as reviewed following a CSD/PROD (might still get some users marking as reviewed, so we should mention this in the next newsletter).
- or B) automatically mark articles as 'unreviewed' following the removal of a PROD or CSD tag (this might annoy some patrollers, as there would be quite a few false positives, similar to how articles converted to redirect and back end up in the New Page Feed).
- Perhaps I have missed something and A or B is already in place, and I just haven't noticed. But we need one of them. — InsertCleverPhraseHere (or here) 21:18, 23 September 2017 (UTC)
- If we decide not to mark any CSD/PRODed pages as reviewed, we'd have to unreview pages that we CSD/PRODed as part of the review. But there is also the option of only leaving those pages unreviewed that were not CSD/PRODed as part of NPP, but by someone else, before our review. We just need to make sure that we don't loose track of those pages that have been marked for deletion but where the deletion process is not yet complete. I watchlist such pages, but maybe not everyone does. Mduvekot (talk) 21:24, 23 September 2017 (UTC)
- (edit conflict) This is a technical issue with the page curation software. Any use of page curation should automatically mark a page as reviewed. The individual reviewer then has the option of unreviewing it if they see fit. I think the theory here is that if it has already been reviewed, you can filter it out of the new pages feed. I'd be fine with a technical change that automatically marks a page that has a PROD or CSD tag as unreviewed (similar to how we do with redirects). I get the technical reasons behind why the current system exists, however.tl;dr: having something marked as reviewed automatically has benefits from a standpoint of using the page curation software. If we wanted a technical change to make the software mark something unreviewed when a deletion tag is removed, that wouldn't be bad. TonyBallioni (talk) 21:26, 23 September 2017 (UTC)
- Even with the potential for some false positives, I also think that 'B' is better and much easier to implement. 'A' would require changing the page curation software (good luck with that). — InsertCleverPhraseHere (or here) 21:34, 23 September 2017 (UTC)
- I think it's important that pages tagged for deletion are also marked as reviewed. Otherwise they will continue to clutter the new pages feed and will waste lots of NPP time (that would otherwise go to backlog reduction) as multiple patrollers check if they were tagged appropriately. Tags being removed after reviewing is a risk, but it is down to the mechanics of the deletion processes so is not to be solved by not reviewing them. The current advice of keeping pages you tag on your watchlist is a reasonable stop-gap; a better solution may be a bot that marks pages unreviewed when deletion tags are removed by anyone without certain rights (admin, NPP, autopatrolled, perhaps). Lineslarge (talk) 07:40, 24 September 2017 (UTC)
- Lineslarge pages tagged for PROD, BLPPROD, CSD, and AfD are automatically markes as patrolled BUT they retain the NOINDEX tag placed by the template. If you repeat a 'patrolled' action, you will undo that and immediately release the offending article to the clutches of Goggle where it will be referenced within seconds. Kudpung กุดผึ้ง (talk) 08:00, 24 September 2017 (UTC)
- Kudpung I was not aware the NOINDEX tag was retained: clearly a good thing. I'm not sure what you mean by repeating a patrol action. If I mark a page that a non-patroller has tagged for deletion as patrolled, does that stay as NOINDEX? I'd certainly argue that it should. Lineslarge (talk) 13:48, 24 September 2017 (UTC)
- @Lineslarge: That's only a problem because the option to filter out pages that are tagged for deletion from the new pages feed doesn't work. There's a bug report so we can hope it will be fixed one day. – Joe (talk) 09:02, 24 September 2017 (UTC)
- @Joe Roe: but what about those tagged by those not able to mark as patrolled? Surely we still need to be able to vet them? Otherwise rogue tagging for deletion by-passes NPP. Lineslarge (talk) 13:48, 24 September 2017 (UTC)
- @Lineslarge: That's why it's an optional filter. Anyone who wants to look over deletion-tagged articles can (or could if the filter worked correctly). Although since anything tagged for deletion is by definition reviewed by an admin before they're actually deleted, I don't think that "rogue tagging" is something we need to worry about? – Joe (talk) 18:11, 24 September 2017(UTC)
- Joe Roe, I actually believe 'rogue tagging' by those not able to mark as patrolled is something we very much need to worry about. When accredited Reviewers and admins arrive to remove such tags, the damage has already been done. It's precisely what loses us new editors. However, the community vehemently insisted that inexperienced 'patrollers' should be allowed to do it. Kudpung กุดผึ้ง (talk) 12:59, 25 September 2017 (UTC)
- @Lineslarge: That's why it's an optional filter. Anyone who wants to look over deletion-tagged articles can (or could if the filter worked correctly). Although since anything tagged for deletion is by definition reviewed by an admin before they're actually deleted, I don't think that "rogue tagging" is something we need to worry about? – Joe (talk) 18:11, 24 September 2017(UTC)
- B would be the preferred option for me and if it could send a unreviewed message to the reviewer it would be even better.i have been guilty in the past of using prod as a means of giving a prod to lazy article creators that don't add sources and ignore the unsourced template. I recently got deprodding by a very experienced editor with the argument that there are many unsourced articles already out there. So I've stopped doing it because if even experienced editors do not consider that unsourced articles are a problem prodding is not the way to clean that up. Is there not a way of preventing unsourced articles being referenced by Google? Domdeparis (talk) 10:08, 24 September 2017 (UTC)
- @Joe Roe: but what about those tagged by those not able to mark as patrolled? Surely we still need to be able to vet them? Otherwise rogue tagging for deletion by-passes NPP. Lineslarge (talk) 13:48, 24 September 2017 (UTC)
- Lineslarge pages tagged for PROD, BLPPROD, CSD, and AfD are automatically markes as patrolled BUT they retain the NOINDEX tag placed by the template. If you repeat a 'patrolled' action, you will undo that and immediately release the offending article to the clutches of Goggle where it will be referenced within seconds. Kudpung กุดผึ้ง (talk) 08:00, 24 September 2017 (UTC)
- There are two issues being compounded here:
- The rules/policy for PROD should be discussed at WT:PROD. For anything else, as Tony mentioned, we already had these discussions. months ago with DannyH (WMF) and Kaldari, the developers.
- Technical issues can be discussed here and unless there is a clear bug, there are none that need changing. I will ping Kaldari to come and explain how it works again. There is the point that because the community insisted on allowing all and sundry to tag and bite new users, they can tag articles for deletion. On the other hand, because they are not members of the New Page Reviewer user group, they can't mark pages as patrolled - yes, it's all a bit topsy turvy but that's what happens in the Wikipedia democracy when people vote who don't know what the RfC is all about, never patrolled any pages, and never been an admin who works at PERM or who has to constantly decine CSD tags. Where the PROD, CSD, and AfD templates prevent an article from being indexed (they generally aren't indexed anyway if they have not been patroled up to 90 days) we again need a clear technical explanation of what happens if the templates get removed.
- There is no need to go into a panic huddle and demand 'Consensus! Consensus!' at every instance. To do so would set back any progress we have already made by several months. Kudpung กุดผึ้ง (talk) 14:22, 24 September 2017 (UTC)
- Hi @Kaldari: and @Kudpung: earlier on in this thread I read that "pages tagged for PROD, BLPPROD, CSD, and AfD are automatically markes as patrolled" but I can't find a trace of that in this Afd nom here. It was nominated for Afd by a NPP reviewer but using twinkle but I don't see a patrolled in the history. Do it mean automatically when using the curation tool? Also as far as I can tell a PROD that isn't a BLPPROD doesn't add the NOINDEX template according to Category:Wikipedia templates which apply NOINDEX. So if I PROD an article using the curation toolbar and the PROD is removed then the page will be indexed? If I now mark Lewis Owen McGibbon as reviewed to take it out of the new pages feed then, from what I gather, if the decision is keep then the reviewed tag will stay on and it will be indexed. This is not a problem because it has been discussed and and it has been closed as keep so no longer a problem article. A BLPPROD or CSD tag can be removed without discussion but this does not mean that the page should be immediately indexed so maybe it would be better to use twinkle for this rather than the curation toolbar? Sorry for maybe asking a question that may have already been answered in another thread. Domdeparis (talk) 16:23, 25 September 2017 (UTC)
- Re: the AfD with Twinkle: that is based on your Twinkle preferences. Its almost always worth marking as reviewed since if something survives an AfD, there really is no point to it being in the new pages feed. I don't have time to look at the NOINDEX/PROD technical question now, but PROD is supposed to add NOINDEX from what I've gathered based on previous discussions. If this is not the case, it should be fixed. TonyBallioni (talk) 16:27, 25 September 2017 (UTC)
- Thanks for that it is what I deduced for the AfD. Wikipedia:Controlling_search_engine_indexing#Standard_template_noindexing PROD doesn't appear in the list of standard templates. Domdeparis (talk) 16:31, 25 September 2017 (UTC)
- The {{Proposed deletion}} template transcludes {{NOINDEX}}Mduvekot (talk) 16:47, 25 September 2017 (UTC)
- So the list of standard templates needs updating as does the Wikipedia:Controlling search engine indexing page? Domdeparis (talk) 14:02, 26 September 2017 (UTC)
- Re: the AfD with Twinkle: that is based on your Twinkle preferences. Its almost always worth marking as reviewed since if something survives an AfD, there really is no point to it being in the new pages feed. I don't have time to look at the NOINDEX/PROD technical question now, but PROD is supposed to add NOINDEX from what I've gathered based on previous discussions. If this is not the case, it should be fixed. TonyBallioni (talk) 16:27, 25 September 2017 (UTC)
- Hi @Kaldari: and @Kudpung: earlier on in this thread I read that "pages tagged for PROD, BLPPROD, CSD, and AfD are automatically markes as patrolled" but I can't find a trace of that in this Afd nom here. It was nominated for Afd by a NPP reviewer but using twinkle but I don't see a patrolled in the history. Do it mean automatically when using the curation tool? Also as far as I can tell a PROD that isn't a BLPPROD doesn't add the NOINDEX template according to Category:Wikipedia templates which apply NOINDEX. So if I PROD an article using the curation toolbar and the PROD is removed then the page will be indexed? If I now mark Lewis Owen McGibbon as reviewed to take it out of the new pages feed then, from what I gather, if the decision is keep then the reviewed tag will stay on and it will be indexed. This is not a problem because it has been discussed and and it has been closed as keep so no longer a problem article. A BLPPROD or CSD tag can be removed without discussion but this does not mean that the page should be immediately indexed so maybe it would be better to use twinkle for this rather than the curation toolbar? Sorry for maybe asking a question that may have already been answered in another thread. Domdeparis (talk) 16:23, 25 September 2017 (UTC)
- Comment I'm going to start marking mine as 'reviewed' as that seems the most common practice, and I suspect that they get in the way when users are using the 'next' button to flip through unreviewed articles. I strongly recommend that we employ a system like the one that we currently have for redirects for CSD, PROD, and BLPPROD tags, where once removed these articles are automatically re-added to the new page queue. Even most articles that are declined for Speedy often need to be re-reviewed, or taken to AfD, and if these articles are allowed to fall out of the queue we have a problem. While I appreciate that most reviewers track the pages that they review afterward, it shouldn't be necessary, especially when it is easily fixable. I think that any extra work that might be generated by these articles being re-added to the queue would be offset by the lack of a need to follow all the articles you've tagged for CSD and PROD. Could someone that understands a bit more about how the current system with redirects works please explain to me how such a system can be implemented? I will then use this information to start an RfC over at WP:Village pump (proposals). Thanks everyone for your comments....... — Insertcleverphrasehere (or here) 23:22, 26 September 2017 (UTC)
- As I said befote, there is no need to go into a panic huddle and demand 'Consensus! Consensus!' at every instance. To do so would set back any progress we have already made by several months. This sees to me to be a purely technical/practical issue that can be addressed the normal way by engaging with the devs, finding out exactly what is supposed to happen, and then ironing out any bugs. Kudpung กุดผึ้ง (talk) 23:59, 26 September 2017 (UTC)
- I concur with Kudpung. This is not RfC-worthy. If there is a local consensus here for it (which I'm not sure there is), it should be enough to put it in phabricator. Another reason to avoid an RfC is that it likely wouldn't get implemented. See T159028 for a similar proposal that got unanimous support that has been stalled for 6 months. Taking the community's energy to discuss a minor technical change that could be 6 months to e year out if it ever gets implemented is not wise in my opinion. TonyBallioni (talk) 00:08, 27 September 2017 (UTC)
- So an RfC that shows demonstrates that the community wants a change makes it less??? likely for a change to be implemented by the WMF? While the above RfC result being ignored is pretty bad, why would an RfC be a bad thing? Or are you saying that submitting it to phabricator as a bug (i.e. saying that "page curation marks it as patrolled when adding the tag; it shouldn't remain patrolled when the tag is removed") makes it more likely that it will actually get dealt with? As for your previous example... why can't the WMF do their job? — Insertcleverphrasehere (or here) 01:16, 27 September 2017 (UTC)
- I submit requests to phabricator all the time for features that have consensus or are non-controversial. They rarely get answered quickly, but the ones I consider important I'll sometime touch base with a dev or two on the team before I submit it.I think Kudpung (who I'm pinging because he prefers it when he is mentioned) and my concerns with launching an RfC is that this is a relatively minor issue, and one that can be addressed through local consensus without the need to make a big deal about it.We've done a lot recently with ACTRIAL, the user right RfCs for ACTRIAL, the lead up to ACTRIAL where we were talking about the need for it all over Wikipedia, and before that the RfC that established the NPR user right. I don't think it'd be wisely using the community's time to launch a village pump RfC over a technical feature of the new pages feed that will likely take a long time to roll out. We've typically handles requests for page curation/technical features with local consensus here or on the suggested improvements page. I think that's enough in this case as well. If we get consensus here, just put it in phabricator as a feature request. TonyBallioni (talk) 01:27, 27 September 2017 (UTC)
- So an RfC that shows demonstrates that the community wants a change makes it less??? likely for a change to be implemented by the WMF? While the above RfC result being ignored is pretty bad, why would an RfC be a bad thing? Or are you saying that submitting it to phabricator as a bug (i.e. saying that "page curation marks it as patrolled when adding the tag; it shouldn't remain patrolled when the tag is removed") makes it more likely that it will actually get dealt with? As for your previous example... why can't the WMF do their job? — Insertcleverphrasehere (or here) 01:16, 27 September 2017 (UTC)
- I concur with Kudpung. This is not RfC-worthy. If there is a local consensus here for it (which I'm not sure there is), it should be enough to put it in phabricator. Another reason to avoid an RfC is that it likely wouldn't get implemented. See T159028 for a similar proposal that got unanimous support that has been stalled for 6 months. Taking the community's energy to discuss a minor technical change that could be 6 months to e year out if it ever gets implemented is not wise in my opinion. TonyBallioni (talk) 00:08, 27 September 2017 (UTC)
- As I said befote, there is no need to go into a panic huddle and demand 'Consensus! Consensus!' at every instance. To do so would set back any progress we have already made by several months. This sees to me to be a purely technical/practical issue that can be addressed the normal way by engaging with the devs, finding out exactly what is supposed to happen, and then ironing out any bugs. Kudpung กุดผึ้ง (talk) 23:59, 26 September 2017 (UTC)
Local consensus to unreview when CSD/PROD/BLPPROD tags are removed (totally not an RfC)
The proposal here is to implement the following change:
Whenever a CSD tag, PROD tag, or BLPPROD tag is removed from an article, that article should be marked as 'unreviewed' and added to the NPP queue.
If we support this locally we will submit a request to Phabricator.
The rationale for the change is given in the previous section, but in summary; the current system means that most/all of articles tagged are marked as 'reviewed' and makes it necessary for reviewers to follow articles that they PROD or tag for CSD to make sure that A) the tag is not removed by the author or B) that if the PROD or speedy is declined that the article is reviewed fully. With the current system, a minor oversight could result in articles 'falling out of the queue', having been marked as patrolled when tagged for PROD/CSD but not fully patrolled after the tag was removed. This change has the advantage of not requiring reviewers to rigorously follow PROD/CSD logs as much, as they can trust that removal of the tag will at least result in someone reviewing it a second time. This helps offset any duplicate patrol work which may result from pages being re-added to the queue, especially for particularly prolific reviewers (and we should be supporting them as much as possible).
As this change mostly only affects patrollers, I agree with Toni and Kudpung and don't see any reason to advertise this beyond this page. — Insertcleverphrasehere (or here) 02:15, 27 September 2017 (UTC)
- Support - As proposer. — Insertcleverphrasehere (or here) 02:15, 27 September 2017 (UTC)
Well, what can I say? I'm sorry I brough it up. My wording was poor. An RfC was completely unnecessary. After reading though the entrire history of this talk page, as Tony recommended, I do think it's fair to say that we're in agreement that PROD and CSD are implemented correctly in the page curation tool: pages nominated for deletion by the reviewer should be marked as reviewed. Pages tagged or nominated for deletion by editors who are not in the New page reviewers group should be (re)reviewed by a New page reviewer, not marked as reviewed indiscriminately. Reviers are advised to keep track of pages the nominate for deletion, either with the CSD or PROD log if they're using Twinkle, or with the Deletion tag log in Special:logs if they're using the page cuaration tool.
Here's to hoping I got it right this time. And if not, drinks are on me because we have almost cleared the backlog of the newpagesfeed for unreviewed pages that were created by new editors. Domdeparis, you deserve special mention for your work there. Bravo! Mduvekot (talk) 02:39, 27 September 2017 (UTC)
- I agree that the way it works currently reviewers must watch their logs, this proposal is aimed at reducing that workload and reducing the chance of things getting missed. I didn't mean to imply that anyone in particular was opposed to such a proposal, I just opened this section here to get a bit of clarity that everyone is in agreement that this is the way that things should work before we make a submission to Phabricator. I am aware that previously people have been opposed to way it currently works with redirects, and this proposal does cause extra articles to get added to the new page feed, even if it will reduce the workload in other areas. — Insertcleverphrasehere (or here) 03:01, 27 September 2017 (UTC)
- I have had confirmation (after all these years)on the Phab page today , that Phabricator, being a 3rd party development venue, poses no obligation on the WMF to take any notice of it at all if they don't want to. The advice given was to lobby people in the WMF directly. The usual excuse of the WMF not having sufficient resources was offered as an explanation. Kudpung กุดผึ้ง (talk) 03:38, 27 September 2017 (UTC)
- Support - Eminently sensible proposal that will improve NPP. Lineslarge (talk) 19:28, 27 September 2017 (UTC)
- Oppose for a number of reasons. I wouldn't be able to review and dePROD a article by a new editor that was incorrectly tagged. It would bring OLD articles back into the newpagesfeed, not just new ones. It's unncessary; there already is a way to track removals of speedy deletion templates by new editors at Special:AbuseLog. Mduvekot (talk) 20:26, 27 September 2017 (UTC)
- I just want to point out that as a user with the reviewer user right, you totally could dePROD an article and then mark it as reviewed with this proposed system (and are justified in doing so). Yes there are likely some older articles that get tagged for PROD or CSD that will end up in the page feed again; this is similar to the current system where old articles that get converted to redirects and back again end up in the new page feed. These are easily identified by those patrolling from the back of the backlog (I often do), and are very easily ticked off. Unless I am mistaken, the link you provided above only lets you search manually by user (if it listed all of them, and we had something similar for PRODs, I could see your point though). — Insertcleverphrasehere (or here) 21:34, 27 September 2017 (UTC)
- Insertcleverphrasehere, All you need is the number of the filter (29), and it will give you a (long) list of edits that triggered the filter. Mduvekot (talk) 21:41, 27 September 2017 (UTC)
- Ok, is there a similar version for PRODs and BLPPRODs as a temporary stopgap? In any case, the proposed change is superior to monitoring of these logs, as anyone wishing to review the logs will have to go through every change, has no way of knowing if it has already been looked at by someone else, and has no way to let others know that it has been looked at (leading to much duplication of work for anyone monitoring this log). As admins and reviewers often follow PROD/CSD removals for articles that they tagged, looking through this list would result in significant duplicate work even on the first pass. Not a great solution, and not something that I think would likely to be used. — Insertcleverphrasehere (or here) 21:51, 27 September 2017 (UTC)
- No. There was a discussion about that years ago at Wikipedia_talk:Edit_filter/Archive_4#Bring_Filter_200_Back_online. Mduvekot (talk) 22:17, 27 September 2017 (UTC)
- Ok thanks for the info. PROD templates are the bigger problem here, as there really aren't that many articles being CSDed at the moment, ACTRIAL has reduced this a lot. — Insertcleverphrasehere (or here) 22:21, 27 September 2017 (UTC)
- No. There was a discussion about that years ago at Wikipedia_talk:Edit_filter/Archive_4#Bring_Filter_200_Back_online. Mduvekot (talk) 22:17, 27 September 2017 (UTC)
- Ok, is there a similar version for PRODs and BLPPRODs as a temporary stopgap? In any case, the proposed change is superior to monitoring of these logs, as anyone wishing to review the logs will have to go through every change, has no way of knowing if it has already been looked at by someone else, and has no way to let others know that it has been looked at (leading to much duplication of work for anyone monitoring this log). As admins and reviewers often follow PROD/CSD removals for articles that they tagged, looking through this list would result in significant duplicate work even on the first pass. Not a great solution, and not something that I think would likely to be used. — Insertcleverphrasehere (or here) 21:51, 27 September 2017 (UTC)
- Insertcleverphrasehere, All you need is the number of the filter (29), and it will give you a (long) list of edits that triggered the filter. Mduvekot (talk) 21:41, 27 September 2017 (UTC)
- I just want to point out that as a user with the reviewer user right, you totally could dePROD an article and then mark it as reviewed with this proposed system (and are justified in doing so). Yes there are likely some older articles that get tagged for PROD or CSD that will end up in the page feed again; this is similar to the current system where old articles that get converted to redirects and back again end up in the new page feed. These are easily identified by those patrolling from the back of the backlog (I often do), and are very easily ticked off. Unless I am mistaken, the link you provided above only lets you search manually by user (if it listed all of them, and we had something similar for PRODs, I could see your point though). — Insertcleverphrasehere (or here) 21:34, 27 September 2017 (UTC)
Pre-ACTRIAL new user backlog eliminated
As of today, there are two articles in the new pages feed that were created before ACTRIAL. Both have been reviewed and tagged for deletion, so they don't require additional action by any reviewers. Thanks to everyone who took part in the drive to eliminate this part of the backlog. Last night I was able to sit at my computer for about 30 minutes, and review 10 articles, the overwhelming majority of which only had minor issues or were good for the green tick. Thanks to everyone who is continuing to work through the backlog: let's see if we can get it down to a respectable 100-200 pages before March! TonyBallioni (talk) 17:25, 28 September 2017 (UTC)
Brilliant news, TonyBallioni. Boleyn (talk) 18:18, 28 September 2017 (UTC)
- That's awesome. If any of you have scads of free time now that Article space is a bit less cluttered, feel free to make your way over to WP:AFC and help out there, we've got a mighty backlog ourselves. Primefac (talk) 18:20, 28 September 2017 (UTC)
- And as of 1 October, there are none. The New Pages feed, filtered by unreviewed pages that were created by new editors is at zero. Congratulations everyone. Mduvekot (talk) 16:02, 1 October 2017 (UTC)
Unreviewing
I'm sometimes getting this alert when unreviewing articles from the Curation tool :
- An error occurred while marking the page as unreviewed: Invalid CSRF token.
Can anyone shed any light on this, or is it something for Kaldari to look at? Kudpung กุดผึ้ง (talk) 02:38, 29 September 2017 (UTC)
- In my experience, I get an error like this when the interval is too long from when I first loaded the page to when the curation tool was invoked. Perhaps the token has some sort of timestamp built in? — jmcgnh(talk) (contribs) 03:00, 29 September 2017 (UTC)
- Filed a bug for this. If the problem is session expiraation, reloading the page should fix it. Kaldari (talk) 03:40, 29 September 2017 (UTC)
- I sometimes get this bug when I unreview a very short time after clicking the review button or adding a tag. I think it is because the wiki hasn't registered that it is 'reviewed' yet. — Insertcleverphrasehere (or here) 17:30, 1 October 2017 (UTC)
There is a discussion at the SPI talk page about handling large undeclared paid editing sock farms, and NPP has been brought up. All are invited to take part in the conversation. TonyBallioni (talk) 02:49, 2 October 2017 (UTC)
Thoughts about AfD
Currently, it seems that AfD is experiencing a drop in participants. Since this has an effect on what we do (try to keep the crap out), this would seem to be a problem for us, as AfD participation is needed so that we can keep the crap out. Although WP:NOQUORUM has probably helped a bit, there is still the fact of NAC being biased to relist, since they cannot close articles as delete. So, I think that we need more admins over at AfD. But at the same time, we need admins who can go and speedy delete articles. Luckily, due to WP:ACTRIAL, there seems to be a drop in the number of articles being tagged for speedy deletion (well, at least I'm not tagging as many articles). So, we should be able to have more admins spend more time closing AfDs (and participating). This should work out ok, since it seems that most of our active new page patrollers just have the NPP user right, and not the admin bit.
My conclusion is that admins participating at NPP should spend more time at AfD, while people who just have the NPP userright dedicate more time here, and possibly to AfD also. RileyBugz会話投稿記録 19:50, 23 September 2017 (UTC)
- We just got a new admin who specialising in AfD closures, hopefully something can be done to solve this though. Α Guy into Books™ § (Message) - 20:12, 23 September 2017 (UTC)
- Yeah, I know, but I thought that it would be good to let people know so they can see if they could contribute in that area. RileyBugz会話投稿記録 20:13, 23 September 2017 (UTC)
- Agree!! AfD is where the plumbing backs up. Atsme📞📧 20:20, 23 September 2017 (UTC)
- Yeah, I know, but I thought that it would be good to let people know so they can see if they could contribute in that area. RileyBugz会話投稿記録 20:13, 23 September 2017 (UTC)
- Re: WP:SOFTDELETE, it isn't that helpful because we currently have a significant number of non-admins who seem to hover over AfD with the sole purpose of relisting things with XfD closer. I'd encourage everyone who closes AfDs as a non-admin to read the very well-written essay WP:Relist bias. TonyBallioni (talk) 20:26, 23 September 2017 (UTC)
- Probably should have gone a bit more into that, and linked the essay. I do think that if you are closing/relisting AfDs as a non-admin that essay is required reading. Regardless, I think that encouraging more admins who participate here to go over to AfD should help. RileyBugz会話投稿記録 20:32, 23 September 2017 (UTC)
- @RileyBugz and TonyBallioni:--Over the recent days, I have informed the 6-7 faulty re-listers (IMO) (CRaju et al) to re-read WP:NOQUORUM prior to relisting any further AfD.It would be interesting to note the outcomes i.e. whether a new bunch rises to grab the job and again have to be informed of related policies.Regards:)Winged Blades of GodricOn leave 07:54, 2 October 2017 (UTC)
- Hopefully that will work. I actually have been seeing some new admins working on closing AfDs, so it seems that there is now more admin participation in terms of closing. RileyBugz会話投稿記録 11:00, 2 October 2017 (UTC)
- @RileyBugz and TonyBallioni:--Over the recent days, I have informed the 6-7 faulty re-listers (IMO) (CRaju et al) to re-read WP:NOQUORUM prior to relisting any further AfD.It would be interesting to note the outcomes i.e. whether a new bunch rises to grab the job and again have to be informed of related policies.Regards:)Winged Blades of GodricOn leave 07:54, 2 October 2017 (UTC)
- Probably should have gone a bit more into that, and linked the essay. I do think that if you are closing/relisting AfDs as a non-admin that essay is required reading. Regardless, I think that encouraging more admins who participate here to go over to AfD should help. RileyBugz会話投稿記録 20:32, 23 September 2017 (UTC)
Grant proposal on meta
There is a grant proposal at meta:Grants:Project/Sumit/Automatic suggestion of topics to drafts. All are invited to comment and offer feedback. TonyBallioni (talk) 04:48, 3 October 2017 (UTC)
Reopen curation toolbar
I clicked the "x" on the Curation Toolbar - it closed, and disappeared. I can't seem to find it to open it again. Can anyone tell me how I can reopen the curation toolbar? If anyone is not clear, here is what I am talking about: WP:Curation toolbar. Thanks in advance ---Steve Quinn (talk) 20:59, 2 October 2017 (UTC)
- This is what the manual at the page you linked to says: "If you close the Curation Toolbar accidentally, you can open it again by clicking on 'Curation Toolbar' in the 'Toolbox' section of the left sidebar; this option is not available though if you were the page creator."--Ymblanter (talk) 21:07, 2 October 2017 (UTC)
- Ymblanter thanks. I read this. But I am not seeing a "left sidebar" and cannot therefore see the "toolbox" section. Do you have a "left sidebar"? I am not being rhetorical or a wise guy with that question. I am really wondering. What I might do is delete the related .js script and then add it back. ---Steve Quinn (talk) 03:19, 3 October 2017 (UTC)
- I am not sure I have the same as you, but the left sidebar is this big field on the left where in particular one has interwiki. There is a "tools" section, where hopefully one finds a link to the Curation toolbar. I can not reproduce this since my Curation toolbar does not have the link to close it to start with.--Ymblanter (talk) 05:31, 3 October 2017 (UTC)
- For what it's worth, I've noticed that the toolbar option to open the page curation tool only shows up if the page hasn't been patrolled, so you'd have to find an unpatrolled page in order to get the link. Primefac (talk) 11:34, 3 October 2017 (UTC)
- Mine says "curate the page" on the left toolbar instead of "Curation Toolbar". Maybe that helps? TonyBallioni (talk) 15:01, 3 October 2017 (UTC)
- Ymblanter, Primefac, and TonyBallioni. Thank you all for jumping in here and offering solutions. I got this working a day or two ago, thanks to all of your help. First, I was looking to the right side of any given page, not the left, which didn't help. Finally, realizing my mistake I looked at the "left sidebar" (Duh!). Not seeing the "Curation toolbar" link in the "Toolbox" section of the sidebar, I went to a page that needed patrolling, but had not been patrolled per Primefac. Walla! There it was. I clicked on the link and have reopened the Curation toolbar. All's well that ends well? ---Steve Quinn (talk) 03:02, 7 October 2017 (UTC)
- Mine says "curate the page" on the left toolbar instead of "Curation Toolbar". Maybe that helps? TonyBallioni (talk) 15:01, 3 October 2017 (UTC)
- For what it's worth, I've noticed that the toolbar option to open the page curation tool only shows up if the page hasn't been patrolled, so you'd have to find an unpatrolled page in order to get the link. Primefac (talk) 11:34, 3 October 2017 (UTC)
- I am not sure I have the same as you, but the left sidebar is this big field on the left where in particular one has interwiki. There is a "tools" section, where hopefully one finds a link to the Curation toolbar. I can not reproduce this since my Curation toolbar does not have the link to close it to start with.--Ymblanter (talk) 05:31, 3 October 2017 (UTC)
- Ymblanter thanks. I read this. But I am not seeing a "left sidebar" and cannot therefore see the "toolbox" section. Do you have a "left sidebar"? I am not being rhetorical or a wise guy with that question. I am really wondering. What I might do is delete the related .js script and then add it back. ---Steve Quinn (talk) 03:19, 3 October 2017 (UTC)