Wikipedia talk:New pages patrol/Reviewers/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Request for comment on proposed additions to guidelines for granting New page reviewer permission

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Closing this early as comments seem to have slowed. All four proposals are unsuccessful. Some editors felt that the proposed additions would suffer from instruction creep as a result of being too detailed. Additionally, administrators already have wide discretion in deciding whether to grant the user right, so the proposed additions may not be necessary. Finally, since the RfC for adopting the current guidelines closed just 5 days before this RfC was initiated (24 October), it may be too soon to reopen debate on this topic at this time. Respectfully, Mz7 (talk) 22:43, 12 November 2016 (UTC)

---

Requesting comment on proposed additions to the criteria for granting the New page reviewer permission. --Pine^✉ 23:44, 29 October 2016 (UTC)

The current guidelines are:

"1. The editor should be a registered Wikipedia user for at least 90 days.

"2. The editor should have made 500 undeleted edits to mainspace that clearly demonstrate knowledge of page quality control. Edits and/or user status on other Foundation projects are not taken into consideration.

"3. The editor should have experience with moving pages in accordance with guidelines.

"4. The editor should have no behavioral blocks or 3RR violations for a span of 6 months prior to applying.

"The above items are guidelines and numerical compliance alone does not constitute a right to the user group. An administrator may also grant page reviewer rights to users they otherwise deem competent or may request experience above and beyond the above criteria."

I propose adding the following items after item 4. These proposals may be added independently, for example if items 6 through 8 get consensus but item 5 does not, then items 6 through 8 may be added to the criteria while item 5 would not, and the numbering of the criteria would be adjusted accordingly.

Proposed criterion 5

5. The editor should have basic proficiency with marking articles for merge or deletion. Although patrollers are not expected to be perfect and may have good-faith disagreements about proposed deletions and mergers, editors should have a minimum of 1 successful PROD, 1 successful proposed article or list merge, 1 successful proposed AFD nomination, and 1 successful proposed CSD nomination within the past 180 days. Also, at least 60% of the editor's combined total of merge proposals, AFD proposals, and CSD proposals within the past 90 days must have been successful.

Support criterion 5

1. Support as proposer. --Pine^✉ 23:40, 29 October 2016 (UTC)

Oppose criterion 5

1. Oppose - A lot of thought has gone into this over the past weeks and it was discussed at two major RfC. Personally, I don't believe this is the moment to be re-debating what was already achieved, and for adding to something some users have suggested as being already too bureaucratic. The decision whether or not to accord the right rests largely admin discretion - as do most additional user rights - using the powers of judgement we invested in them. The user right tutorial should provide admins with sufficient additional background if they need it. Kudpung กุดผึ้ง (talk) 16:51, 30 October 2016 (UTC)
2. Oppose Too much bureaucracy, and these requirements are too detailed. As User:Kudpung says, trust the admins. Tamwin (talk) 23:24, 30 October 2016 (UTC)
3. Oppose per Kudpung. It looks like instruction creep, and I think we should trust admins' discretion for evaluating which users qualify for the bit and who does not. It could involve AfD/CSD nominations, but it's CREEPy. I believe the suggestion reads more like a good suggestion for an admin to consider, but I think the current phrase an administrator may also grant page reviewer rights to users they otherwise deem competent or may request experience above and beyond the above criteria does not suggest that more criteria added is a good idea. — Andy W. (talk) 20:30, 31 October 2016 (UTC)
4. Oppose - Unreasonable. Pages outside the article namespace may be patrolled.— Godsy ^(TALK_CONT) 01:23, 1 November 2016 (UTC)
5. Oppose: Too arbitrary. Esquivalience (talk) 20:05, 2 November 2016 (UTC)
6. Oppose: appears to be too heavily regulated. Rubbish computer (HALP!: I dropped the bass?) 14:27, 3 November 2016 (UTC)
7. Oppose all other measures were good for weeding out those unfit, this one is just arbitrary. Iazyges Consermonor Opus meum 04:29, 5 November 2016 (UTC)

Neutral on criterion 5

Discussion on criterion 5

Proposed criterion 6

6. The editor should have a record of civil behavior toward other editors, particularly within the past 90 days, even when the editor has disagreements with others or nominates others' articles for deletion.

Support criterion 6

1. Support as proposer. --Pine^✉ 23:40, 29 October 2016 (UTC)
2. Support This one makes sense. Civility is important. Can we drop the 90 days thing? It sounds too detailed. Tamwin (talk) 23:24, 30 October 2016 (UTC)

Oppose criterion 6

1. Oppose - A lot of thought has gone into this over the past weeks and it was discussed at two major RfC. Personally, I don't believe this is the moment to be re-debating what was already achieved, and for adding to something some users have suggested as being already too bureaucratic. The decision whether or not to accord the right rests largely admin discretion - as do most additional user rights - using the powers of judgement we invested in them. The user right tutorial should provide admins with sufficient additional background if they need it. Kudpung กุดผึ้ง (talk) 16:51, 30 October 2016 (UTC)
2. Oppose per Kudpung. There's nothing really wrong with the motivation behind this point, but The editor should have a record of civil behavior toward other editors, particularly within the past 90 days ← this segment reasonably applies to those seeking any/all user rights, I'd say, and not specific to new page reviewer. (That doesn't mean that this statement should be added as criteria for all rights either. Admins already have a good idea who qualifies for the bit and who does not. — Andy W. (talk) 20:30, 31 October 2016 (UTC)
3. Oppose as civility in general, rather than over a 90 day period, should be expected for those requesting additional user rights-- and just from users in general-- and admins likely already know whether an editor is suitable for additional rights fron experience. Rubbish computer (HALP!: I dropped the bass?) 14:32, 3 November 2016 (UTC)
4. Oppose Per concerns above, all people have to be civil, or else get blocked, so this opens rooms for problems where there currently aren't any. Iazyges Consermonor Opus meum 04:30, 5 November 2016 (UTC)

Neutral on criterion 6

Discussion on criterion 6

Proposed criterion 7

7. Page reviewers are not expected to provide extensive guidance to page creators who need help, but candidates for the page reviewer permission should have a record of civilly providing links to resources such as help pages and the Teahouse that may assist good-faith page creators with resolving problems.

Support criterion 7

1. Support as proposer. --Pine^✉ 23:40, 29 October 2016 (UTC)
2. Support This one makes sense. Civility is important. Tamwin (talk) 23:24, 30 October 2016 (UTC)

Oppose criterion 7

1. Oppose - A lot of thought has gone into this over the past weeks and it was discussed at two major RfC. Personally, I don't believe this is the moment to be re-debating what was already achieved, and for adding to something some users have suggested as being already too bureaucratic. The decision whether or not to accord the right rests largely admin discretion - as do most additional user rights - using the powers of judgement we invested in them. The user right tutorial should provide admins with sufficient additional background if they need it. Kudpung กุดผึ้ง (talk) 16:51, 30 October 2016 (UTC)

   This appears to largely duplicate No.6 above.It's already clearly stated in a manner comprehensible for most native Englisg speakers: New Page Review is a vital function as the front line of interaction between new authors and community members devoted to policing the quality of the project, but as a concession, I have added ...and able to communicate in an appropriate manner with new users, to the job description which is a far as we can go without re-debating the whole thing. Generally common sense should make it clear that new page reviewers are the most common public face of Wikipedia and if they don't realise that already, they won't be accorded the right.

2. Oppose per Kudpung. It looks like a good suggestion for an admin to consider for granting, but doesn't seem necessary. Teahouse assistance should be up to the discretion of the granting administrator. A set of concise requirements has been agreed upon in a previous RfC per Kudpung. Less is more, more could be less here. — Andy W. (talk) 20:30, 31 October 2016 (UTC)
3. Oppose: as Andy M. Wang states, this is a good thing for a user to do, but should not be required. Rubbish computer (HALP!: I dropped the bass?) 14:34, 3 November 2016 (UTC)
4. Oppose as a teahouse host, I think its great to give new users invites, but that's not the point of NPP, NPP is about one thing: Fixing issues, either by tagging and fixing them, or by deletion, while it is great when people go the extra mile, it shouldn't be required, lest we have no NPP's because we made requirements so stringent and arbitrary. Iazyges Consermonor Opus meum 04:33, 5 November 2016 (UTC)

Neutral on criterion 7

Discussion on criterion 7

Proposed criterion 8

8. The editor should have a record of good judgment regarding the timing and communication for deletion proposals. For example, keeping in mind that hasty deletion nominations can discourage good-faith contributors, the editor requesting the reviewer permission, in general, should not propose deletion of a newly created article within 4 hours of the article's creation time, so long as the article is not an obviously bad-faith article or has other problems of such magnitude that speedy deletion is appropriate without waiting for the article creator to improve the article.

Support criterion 8

1. Support as proposer. --Pine^✉ 23:40, 29 October 2016 (UTC)

Oppose criterion 8

1. Oppose - A lot of thought has gone into this over the past weeks and it was discussed at two major RfC. Personally, I don't believe this is the moment to be re-debating what was already achieved, and for adding to something some users have suggested as being already too bureaucratic. The decision whether or not to accord the right rests largely admin discretion - as do most additional user rights - using the powers of judgement we invested in them. The user right tutorial should provide admins with sufficient additional background if they need it. Kudpung กุดผึ้ง (talk) 16:51, 30 October 2016 (UTC)

   I'll just add that this section attempts to address two different issues: the threshold criteria for access to the user right, and a deletion policy/guideline. The fiirst has been adequately discussed. The second is widely recognised as 15 - 20 minutes being an adequate delay before tagging for CSD-A1 and CSD-A2 - while the user might possible still be logged in, but experienced patrollers will have already noted that if an 'article' receives no further edits after much longer than that, it's most likely the work of a drive-by user who probably won't return. Reviewers with the required skill set (that's why the user right has been introduced) will recognise other articles that might have some potential (e.g. would probably survive an AfD if correctly completed) and explain briefly to the creator what needs to be done, or even move the page to Draft space. Kudpung กุดผึ้ง (talk) 02:05, 1 November 2016 (UTC)

2. Oppose Too much bureaucracy, and these requirements are too detailed. As User:Kudpung says, trust the admins. Tamwin (talk) 23:24, 30 October 2016 (UTC)
3. Oppose per above. "4 hours" appears to be only a suggestion, and seems WP:CREEPy. Is the candidate not qualified if PROD is placed 3 hours after creation? Looking at WP:PROD (policy), I cannot find the "4 hour" suggestion. A set of concise requirements has been agreed upon in a previous RfC. — Andy W. (talk) 20:30, 31 October 2016 (UTC)
4. Oppose: It is bad judgment to wait four hours to move towards disposing of encyclopedic garbage that for some reason did not make it through CSD. Esquivalience (talk) 20:09, 2 November 2016 (UTC)
5. Oppose as being too much of a specific requirement: there is also nothing at WP:PROD suggesting that this is preferable. Rubbish computer (HALP!: I dropped the bass?) 14:40, 3 November 2016 (UTC)
6. Oppose too much bureaucracy. Iazyges Consermonor Opus meum 04:40, 5 November 2016 (UTC)

Neutral on criterion 8

Discussion on criterion 8

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

Reported issues with the initial NPR grand-fathering list

A few users have contacted me regarding possible problems with the initial NPR grandfathering list. As WT:PERM is a bit busy and this is NPR specific, please discuss here. If there are additional lists we certainly can process them after they are vetted. — xaosflux ^Talk 18:21, 1 November 2016 (UTC)

• Reports are that up to 60% of valid editors may have been missed. — xaosflux ^Talk 18:29, 1 November 2016 (UTC)

  Yeah... the pagetraige_log table is supposed to record both kinds of patrols, but evidently it's missing some data, or I did it wrong, maybe both... The API seems the safest way to get the number of reviews by single person, such as [1]. I am working on creating a new list of users who have done any patrols since 1 January, then I can loop through and query the API. Again if anyone knows of a better way to do this please go for it! I do not claim to be good at SQL :) — MusikAnimal ^talk 19:00, 1 November 2016 (UTC)

  @MusikAnimal: Thanks for the note - if this will take more than a day we should postpone the 2nd half of the change for up to a week. — xaosflux ^Talk 19:18, 1 November 2016 (UTC)

  @MusikAnimal: I don't know if this might help: this point on the 1st RfC (a discussion which also involved User:Timothyjosephwood as in your above example) noted the distinction between event capture based on type=patrol versus type=pagetriage-curation, with the former capturing substantially more patrol activity than the latter. (This distinction was also the basis of my query on the 2nd RfC and at "Comments on draft" above.) AllyD (talk) 19:28, 1 November 2016 (UTC)

  @Xaosflux and AllyD: I believe this is our problem: phab:T149756. I asked for help on IRC and they suggested the same query I attempted: quarry:query/13787. This returns nearly 9,000 users, including some bots. Obviously the data is suffering what appears a bug. The bots have never made manual patrols, rather they have the autopatrol user right, yet still are being recorded as manual patrols. That being said I don't know if we can get the list we want efficiently, and it may very well be impossible — MusikAnimal ^talk 23:57, 1 November 2016 (UTC)

• Another list that was generated from log files is now here Wikipedia talk:New pages patrol/Reviewers/List2. — xaosflux ^Talk 00:53, 2 November 2016 (UTC)
  • Unfortunately the RfC tied that whole "grandfathering" thing in - and I'm not hearing anyone yet say they have confidence in the reports used to fulfill that - I suggest delaying phase 2 of the phab ticket while this is further investigated. Please note, I may be away for the next day or two with family business. — xaosflux ^Talk 00:55, 2 November 2016 (UTC)

    The bad data appears to exist prior to 31 March 2016, for instance try ClueBot NG and the "automatic" patrols stopped on 31 March. Sure enough, when I check my own log for March I see the same: [2]. I think this commit fixed it. So anyway, it may be that there's no way to get around the bad data, and we can only reliably go off of data since April Fools Day — MusikAnimal ^talk 01:03, 2 November 2016 (UTC)

(edit conflict)I don't understand any of this - I'm just a mere expert in creative writing and workflow, neither of which requires a profound knowledge of IT. I did point out that the search criteria used at quarry:query/2042, quarry:query/2093, quarry:query/8639 are the kind of thing that would have more accurately reported the results we were needing. But I don't know the first thing about consulting Wikipedia's SQL.

That said, however, I don't think we need to delay anything. AFAICS, the backlog at the feed has already dropped significantly (down 30%). However, I think we still very much need to insist on having a proper log that contains all new page patrolls for each user, irrespective of whether they were made with the Page Curation toolbar, or through Twinkle (which is the source of most of the confusion of course).

I also mentioned many times that Scottywong (now retired) once created an excellent tool for properly analysing page patrol stats and analysing individual users' patrols, but IIRR, the person or persons who undertook to port the tool to Labs either messed it up or went AWOL. Perhaps TParis or cyberpower678 could comment on this.Kudpung กุดผึ้ง (talk) 01:07, 2 November 2016 (UTC) PS: for more information see Wikipedia:New pages patrol/patrollers. Kudpung กุดผึ้ง (talk) 01:15, 2 November 2016 (UTC)

@Kudpung, Xaosflux, and AllyD: Boom: quarry:query/13795. This list of 121 users I'm quite confident in. That's still not everyone since it's only accounting for patrols since 1 April, but hopefully this uncovers more people that we missed. You can also try say, 100 patrols since 1 April and might get more that qualify: quarry:query/13796. Best — MusikAnimal ^talk 01:18, 2 November 2016 (UTC)

@MusikAnimal, Xaosflux, and AllyD: that quarry list might be missing an important criterion: My initial rquirement was for users who had made 200 or more New Page Patrolls (from all sources) from 1 January to 6 October. There was method in this - it was designed for a cut-off when the RfCs started, to avoid a rush of very fast patrolling to meet the criteria before the well-anticipated new user right came into effect. The rush of course happened, which is what I expected. And that's why I wanted all those newbies out of it.

If we have to process a few 100 more grandfathered accounts, we can handle that easy enough, and when I've sent the mass message to the other 1,800 former patrollers, there will be quite a few who will apply for the right at PERM, which is what we want - there are former prolific patrollers like Montanabw, for example, who are already requesting, and I'll go through a few lists I have and accord a few more without waiting for them to apply. We do need to insist on getting organised with a proper log though, and a permanent tool like Scottywong's because a more efficient system of patrolling the patrollers will still be needed to be done to some extent and is high on the work group's wish list. Kudpung กุดผึ้ง (talk) 01:36, 2 November 2016 (UTC)

The issue is there is corrupt data, so I don't think it's easy, if at all possible, to automate a list from 1 January. This is going by my discoveries today, and my tests seem to support the theory. Note also any patrol on new pages (less than 90 days old) using Page Curation will also show up in the normal patrol log, so all the users you see here at Wikipedia talk:New pages patrol/Reviewers/List3 (I just created it), should qualify. The only thing again is we're not accounting for contested patrols, but that is bound to happen even when they are perfectly good patrols. Going through this manually seems like the only concrete way to narrow down the users we want. I will go ahead and remove admins I see in the list, and others I know to already have the new pages reviewer permission — MusikAnimal ^talk 01:45, 2 November 2016 (UTC)

• @MusikAnimal: Thanks: intuitively that list does feature many account names that I recognise as regularly marking new pages with maintenance tags, CSD, Prod and AfD. Noting the scale, the new list includes 3-4 who more than meet the 200 patrols criterion each month and approx the top 40 of these missed accounts amount to a total weekly patrol throughput. To avoid detriment to NPP it is important to get this right (and in line with the RfC definition). AllyD (talk) 08:57, 2 November 2016 (UTC)

@L235: As the RfC Closer can you look over this and determine if the grandfathering part of the RfC is satisfied and/or if it should hold up part 2 of the technical change (removing patrol access from the old groups). — xaosflux ^Talk 01:54, 2 November 2016 (UTC)

I've cleaned up Wikipedia talk:New pages patrol/Reviewers/List3. Everyone listed there has not applied for NPR nor were they already notified that they qualify (cross referencing with Wikipedia:New pages patrol/Reviewers/grandfathered) — MusikAnimal ^talk 01:59, 2 November 2016 (UTC)

Speaking as the RfC closer: the RfC does not mandate any sort of delay – the close is deliberately open-ended on timing. No individual part of the qualifications RfC was so important in the sense of the community that there would not be consensus if it was not there, and the "grandfathering" clause was no exception. Speaking as not-RfC-closer, it would definitely be prudent to hold off a bit. Kevin (aka L235 · t · c) 03:40, 2 November 2016 (UTC)

Tracked in Phabricator
Task T149019

• A hold has been asked for on phab:T149019 - pending the community discussion and activities. Once completed, please remove the community consensus tag from the patch. — xaosflux ^Talk 12:57, 2 November 2016 (UTC)

• Y'all do know that patrols made using the page curation toolbar don't show up in the patrol log, right? They only show up in the page curation log. What shows up in the patrol log is patrols made using the "Mark this page as patrolled" and approvals made by people with pending changes reviewer rights. I don't think that's the intended behavior of that log, but it's what it's been doing. So I, for example, am not on any of the lists you've put together because almost all of my new page patrolling is done via page curation. Whatever you are using to generate the list of people to be grandfathered needs to look at both logs. ~ ONUnicorn^{(Talk|Contribs)}problem solving 14:30, 2 November 2016 (UTC)

  @ONUnicorn: It appears pending changes reviews do show up in the patrol log, but as an automatic patrol [3][4]. We've been going by manual patrols. Additionally page curation reviews do show up in the patrol log, if the article was under 90 days old (since older pages can't be patrolled) [5][6]. Many of your reviews are for older articles and hence only show up in the page curation log. This is the log we went off of for our first list of grandfathered users, but for some reason there's a lot of missing data in those tables in the replica database. I see only one record of a page curation review by you [7][8]. I know you've made significantly more reviews than this, but how to effectively query for the data amongst all users is something we're still trying to figure out — MusikAnimal ^talk 21:04, 2 November 2016 (UTC)

  That PC autoreviews are logged as autopatrolled is a bug, I've made phab:T150086. Cenarium (talk) 14:23, 5 November 2016 (UTC)

• I'll just repeat what I said above lest it be overlooked: We do need to insist on getting organised with a proper log though, and a permanent tool like Scottywong's because a more efficient system of patrolling the patrollers will still be needed to be done to some extent and is high on the work group's wish list. Also, we need to look into better methods of querying the database - these issues are not specifically user rights related, but they should not be used as reasons for delaying the roll out of new policy. Thanks. Kudpung กุดผึ้ง (talk) 20:28, 2 November 2016 (UTC)
• That the data can be retrieved should have been checked before giving it as a criteria for the RFC. It's no one's fault that this isn't practical to retrieve. It is not possible to retrieve manual patrol data before 1 April, when the commit I made (I'm a volunteer, FYI) to use a distinct action for autopatrol was deployed (and therefore allowed to 'patrol the patrollers'). The only way is to manually check the 507 284 users with more than 200 patrols, which may be manual or automatic, which should be a bit less if one removes admins and those already with the permission. For maintenance, or deletion tags, this looks even harder. Cenarium (talk) 14:23, 5 November 2016 (UTC)

This baffles me because Cryptic was able to pull any data out the hat I asked him for. I listed the Quarrys he used above. --Kudpung กุดผึ้ง (talk) 15:02, 5 November 2016 (UTC)

I've checked the queries. This only works for when those actions (patrol, maintenance of deletion tags) were done through page curation, not when they were done manually or with Twinkle. Cenarium (talk) 18:27, 5 November 2016 (UTC)

I'm somewhat more confident in the ones I used to generate Wikipedia:New pages patrol/patrollers/Apr2014-Mar2016: quarry:query/8767, quarry:query/8802, and quarry:query/8803, which queried the patrol log instead of pagetriage-curation and filter out the autopatrols with an unindexed text match on log_params. (Autopatrols do get "auto" in there, right?) The horrific manual subqueries were to work around quarry's timeouts. —Cryptic 18:54, 5 November 2016 (UTC)

@Cryptic: Good idea to have used a NOT LIKE on log_params, I would have expected a timeout (yes, autopatrols always get "auto" there). I've made a new query based on yours at quarry:query/13869 that also returns page curation reviews, since they aren't recorded as patrols if the article creation is no longer in recent changes. This should be enough for our purposes - it doesn't include addition of maintenance or deletion tags, but generally when doing so one also patrols. It gives 166 users. Cenarium (talk) 23:51, 5 November 2016 (UTC)

Just a note. The page curation tool logs a separate "marked page reviewed" for each separate action with the tool So, for instance, if I tag an article for deletion then place a series of maintinance tags there will be two "marked page reviewed". (See 27 Oct 2016 in my curation log [9] for where Joseph Allgood shows 3 "marked reviewed" entries.) Any curation action, regardless of if the page is marked reviewed or not, makes a reviewed entry. This does not really matter for this but it would be useful for the tool to not do that later.

For this process it would be useful to run a query against the potential grandfathered accounts to check for "unreviewed page" entries not done by the user themself. This would also be useful in the "Reviewing the Reviewers" project. Jbh^Talk 01:05, 6 November 2016 (UTC)

Shouldn't several curation actions count as a single patrol then? Just in case, here's a query counting only one review per page, this narrows down the list to 159 users. As for non-self unreview actions, I don't see how this could be done. Cenarium (talk) 13:39, 6 November 2016 (UTC)

In process

• I am working through MusikAnimal's new list, using Grandfathered per Wikipedia talk:New pages patrol/Reviewers/List3 as the es for the rights management log. When I have completed this task, I will add 'done' to all those who were approved and processed, if anyone (admins) wants to help with this they are of course more than welcome to do so. Then a mass mailing list can be made to send he the template message we have been using tothose who have been accorded. Kudpung กุดผึ้ง (talk) 20:45, 2 November 2016 (UTC)

The work list is at Wikipedia talk:New pages patrol/Reviewers/List3 accorded. --Kudpung กุดผึ้ง (talk) 21:06, 2 November 2016 (UTC)

• MusikAnimal are you still working through these - we need to decide to move forward or continue to delay part 2 of the patch. — xaosflux ^Talk 04:55, 8 November 2016 (UTC)

  @Xaosflux: I have not been working through this list, rather I just created it. I will help, though! I think it's fine to go ahead with part 2. There will likely be an influx of requests but given we are facing the issue of phab:T136493, it's going to be a while before we can get a concrete list of all grandfathered users. Having them come to us at their leisure might be the easiest way. @Kudpung: I noticed you haven't been sending out {{New Page Reviewer granted}}. I believe you were going to wait to go through the whole list first. Users receive a notification when their permissions are altered, so following up with the talk page notice shortly thereafter might help avoid confusion — MusikAnimal ^talk 00:26, 9 November 2016 (UTC)

I think we've rushed into several phases of this prematurely and/or got the order of the process wrong. IMO the PERM page shouldn't have gone live, categories should not have been created or anything else until the technical aspects - which I have nothing to do with - have been bugged out. It was therefore deliberate on my part not to inform the grandfathered list yet because in the normal run of things nobody needs to know yet. At this moment in time we have a RfC consensus, that's all, but everyone is getting to hear of PERM and grandfathering, I'm being swamped with rude messages from users from whom the right hasn't even been physically taken away yet. I realise as the one who has pioneered this user right for five years that a lot of the leg work would be left to me anyway - which I fully accepted. I did however make an an appeal for help with the grandmother list which was ignored. Finally, I was told more or less told (by the WMF?) that my work on this project is no longer needed and that the Wiki will now look after itself. My suggestion at this stage is that the PERM page be disactivated again, someone continues working through the grandfather list(s), and then, and only then should everyone be notified personally, and the former 1,400 patrollers - of whom around 50% are trolls and blocked/banned users, and leaving actually only around 300 who might be still active - by newsletter that they can then apply for the right. One thing has become clear through: better communications and a proper structured collaoration, and clearly defined Community/WMF roles, and a proper sharing/delegation of tasks, would have avoided this fiasco of one postponement after another. The only real help (for me) came from Fuhghettaboutit who spent several hours adding to and improving the tutorial I also completely re-wrote. Kudpung กุดผึ้ง (talk) 01:41, 9 November 2016 (UTC)

The PERM page should definitely stay open. This is only allowing that many more users to apply and hence reducing the influx of requests we'd get after deploying the second patch. And again, I don't think we should be altering user permissions and not telling them what it is. You could alternatively simply mark which users you would grant new page reviewer to, then later grant all the rights and issue the talk page notices at once. I certainly would be asking questions if I see I've been given a new permission that I know nothing about — MusikAnimal ^talk 17:33, 9 November 2016 (UTC)

@Xaosflux, MusikAnimal, Kudpung, and Cenarium: The newsletter that Kudpung speaks of cannot be constructed from Category:Wikipedian new page patrollers, as {{User wikipedia/NP Patrol}} no longer populates it. Probably need to count the userpage transclusions of {{User wikipedia/NP Patrol}} and {{User wikipedia/NP Patrol2}} (which is the ~1400 Kudpung speaks of), and filter it down (to ~300 as Kudpung estimates) of active unblocked ungranted users. From what I gather above in Kudpung's messages, this process is not complete until this newsletter goes out, which would further alleviate patrolling drought. (Just an observation, not trying to advocate any particular way to get this newsletter) — Andy W. (talk) 19:02, 9 November 2016 (UTC) 19:21, 9 November 2016 (UTC)

@Andy M. Wang: I'm not sure of the purpose of sending out those messages, can't the objective be reached more simply by adding a notice to Special:NewPages and Special:NewPagesFeed? Cenarium (talk) 00:40, 13 November 2016 (UTC)

Ahh, missed Wikipedia:New pages patrol/Reviewers/Mailing2. This is moot, looks like it was just sent — Andy W. (talk) 07:35, 13 November 2016 (UTC)

• I made a new list at Wikipedia talk:New pages patrol/Reviewers/List4 that includes all users with more than 200 patrols in 2016, excluding those blocked in 2016, sysops and patrollers. Cenarium (talk) 10:11, 9 November 2016 (UTC)

  @Cenarium: This is a fantastic query! I couldn't figure out how to query the log_params column, and I figured it probably time out anyway. It seems this data would fill the void the other queries left out, correct? So we have now identified all who meet the grandfathered criteria? — MusikAnimal ^talk 04:49, 10 November 2016 (UTC)

  @MusikAnimal: Using log_params was Cryptic's idea. Yes, I think we've found all users meeting the grandfathering criteria, and Graeme Bartlett has finished assigning the rights, so the grandfathering clause is complete as far as I can tell. Cenarium (talk) 00:40, 13 November 2016 (UTC)

A couple user scripts

I just created a couple userscripts based off of one that Omni Flames created. The scripts I created add a link at the top of any Wikipedia page to either Special:NewPages or Special:NewPagesFeed, depending on which one you install. They can both be active at the same time. And, yes, I gave credit where credit is due.

The installation instructions for the script for Special:NewPages can be found at User:Gestrid/NewPagesLink, while the instructions for the script for Special:NewPagesFeed can be found at User:Gestrid/NewPagesFeedLink. — Gestrid (talk) 01:04, 5 November 2016 (UTC)

Gestrid I think this might possibly not have quite the right effect. The clear leitmotif of this operation over the past four or five years is to wean people away from Twinkle and getting only suitably experience people to do the reviewing of new pages and to be using a standardised system. It would otherwise be impossible to monitor the quality of patrolling which is what this is all about. One thing has recently become evident throughout this process is that the majority of users still mistakenly believe that the sole purpose of New Page Patrol is to tag pages for deletion and that concerns about biting newbies are of minor importance. The Page Curation tool is designed to encourage an interaction between the patroller and the creator and its New Page Feed provides a lot of clues on possible misuse of Wikipedia by spammers and paid editors. Twinkle and the old feed no neither. Kudpung กุดผึ้ง (talk) 02:12, 9 November 2016 (UTC)

@Kudpung กุดผึ้ง: I think there may be a misunderstanding here. I'm not sure if it's me or you. The two userscipts I created don't use Twinkle at all. They simply make it easier to get to either Special:NewPages or Special:NewPagesFeed by making a direct link appear up at the top of every Wikipedia page between "Sandbox" and "Preferences", the same as Omni Flames' original userscript links to Special:PendingChanges. Again, it depends on which one(s) the user installs. — Gestrid (talk) 08:20, 12 November 2016 (UTC)

That's right, Gestrid - the whole purpose of this new user right is to get people away from Special:NewPages for routinely reviewing new pages, and to get them to use the purpose built Special:NewPagesFeed and its Curation Tool instead so that we can excercise proper control over the process, more accurately delete spam, and actively encourage bona fidae good faith editors to improve their articles without biting them. Twinkle does none of this, but Special:NewPages - which does not offer all the clues the reviewers need either, leads them to it. Kudpung กุดผึ้ง (talk) 09:48, 12 November 2016 (UTC)

Ok, I see what you mean. Feel free, then, to delete the Special:NewPages userscript. — Gestrid (talk) 16:55, 12 November 2016 (UTC)

@Kudpung กุดผึ้ง: The one for Special:NewPages has been deleted under WP:U1. — Gestrid (talk) 04:50, 14 November 2016 (UTC)

Call for any objections to allow phase 2 of the patch

If anyone has any objections to the existing process and believes the second part of the patch needs to be further delayed, please speak up now. This will remove patrol access from all the groups except the new group and admins. — xaosflux ^Talk 23:50, 8 November 2016 (UTC)

@Xaosflux: Does this mean the little "[Mark this page as patrolled]" clicker at the bottom of New Pages is going to disappear for the rest of us? I (very) occasionally "manually" patrol some new articles, and I'm hoping I don't have to sign up for the new Page Patrollers group just to be able to keep doing that... TIA. --IJBall (contribs • talk) 00:02, 9 November 2016 (UTC)

@IJBall: Yes it does, but "that it is changing" was already decided by community RfC - the only outstanding issue on patch delay is if the execution of the grandfathering provision has been successful yet. — xaosflux ^Talk 00:19, 9 November 2016 (UTC)

@Xaosflux, Kudpung, and MusikAnimal: Full support for November 10 19:00 UTC. I believe the remaining users listed at Wikipedia talk:New pages patrol/Reviewers/List3 accorded can be evaluated independently. — Andy W. (talk) 01:25, 9 November 2016 (UTC)

SEe my long post at #In process above. Kudpung กุดผึ้ง (talk) 01:47, 9 November 2016 (UTC)

Kudpung Seen - but as far as the specific question at hand for tomorrow - do you want to postpone removing patrol access from the (auto)confirmed users for now? — xaosflux ^Talk 02:01, 9 November 2016 (UTC)

Xaosflux, My recommendations are above. Having been told that my shelf life on this project has expired, I have no further comment. Tha's what Wikipedia does to people who show initative.Kudpung กุดผึ้ง (talk) 02:16, 9 November 2016 (UTC)

• I've no objection per se, but we should then quickly post a notice to WP:AN to get the list finished. I'll look into it also. Cenarium (talk) 07:05, 9 November 2016 (UTC)
• Request for clarification: from the RFC, there were no added conditions, as far as I can see, to be grandfathered, beyond 200 uncontested patrols and not blocked, however in Wikipedia talk:New pages patrol/Reviewers/List3 accorded, several users were rejected. The reasons for doing so seem reasonable, however I'm unsure what standard admins should use. Does the "500 undeleted edits to mainspace, and have a registered account for at least 90 days" clause apply there as well, for example? What about the clause "plus appropriate experience of a kind that clearly demonstrates knowledge of article quality control."? At the moment, I'm not confindent in granting/denying requests, and don't know what to say in the AN request for admins to help out. Pinging L235 as RFC closer. Cenarium (talk) 10:48, 9 November 2016 (UTC)
• Anyone who meets the criteria in the RfC for grandfathering must be granted the right, and may not have the right removed except according to the "Criteria for revocation" in RfC 1. To be perfectly clear, administrators may not choose to not grant the right to anyone who "has made 200 uncontested or unreverted patrols, maintenance, or deletion tags between 1 January 2016 and 06 October 2016 and who have a clean block log since 01 January 2016" – there are no additional requirements to be grandfathered, and no aspect of the grandfathering procedure is subject to admin discretion. Kevin (aka L235 · t · c) 14:56, 9 November 2016 (UTC)

@L235: I presume this means that admins must give grandfathered, but can decide for non grandfathered right? Iazyges Consermonor Opus meum 15:16, 9 November 2016 (UTC)

• OK, it appears the community is not yet satisfied this is complete, asking for additional delay on part 2. — xaosflux ^Talk 17:18, 9 November 2016 (UTC)

• At the end of the day, where Wikilawyering is more important than keeping Wikipedia free of undesirable content, not biting new users, and a modicum of common sense, the grandfather clause can be enacted, and the right can then be easily revoked on further, immediate review. I'm sure that will work for most admins, and certainly for the benefit of Wikipedia. But why create even more work for admins where this user right is supposed to reduce their workload? Kudpung กุดผึ้ง (talk) 03:44, 11 November 2016 (UTC)

• This is set to go out this week, phab:T149019 - most of the concerns were addressed and information was sent out. The "grandfathering" will never be perfect, but applications have been swiftly processed at WP:PERM - and any editor can ask at perm or to any admin to enact a missing grandfathered flag. If you disagree and think there is a reason to continue to delay, please raise your concerns at phabricator. — xaosflux ^Talk 22:24, 15 November 2016 (UTC)

Newsletter sent

Newsletter sent to just under 1,500 users. The list included around 50 indef blocked users, while the vast majority of the rest were either users whose only edit (or one of their first 5 or so edits) was to add the userbox to their user page never to edit again, users who have not edited for many years, or users with extremely low edit counts. As anticipated - mainly on an opinion based on the complex NPP survey I designed and ran a few years ago, in which the total list came to 3,937 users having patrolled new pages, excluding blocked editors. Only 1,255 responded to that survey, of which after removing the nonsense responses only 304 usable replies were left, which then cast an erroneous profile of the average New Page Patroler. Kudpung กุดผึ้ง (talk) 05:16, 13 November 2016 (UTC)

@Kudpung: is it possible to restrict the adding of the category to people with the right? Iazyges Consermonor Opus meum 05:21, 13 November 2016 (UTC)

Iazyges, that was my obvious intention, but I am not a programmer. The technical issue is that all such cats are automatically populated by a script in the uboxes when an editor places one on their userpage. I am of the opinion that as with the Admin and other user rights uboxen and top icons, only qualified users should feature in the respective category. Others do not appear to agree and my attempts to deprecate the old categories have been reverted. Kudpung กุดผึ้ง (talk) 06:10, 13 November 2016 (UTC)

• I was stalking User talk:Vanjagenije, and it seems a mass message was sent to them. Vanja is an administrator, and my understanding is that the right is being added as part of the administrator toolset. Make sure we aren't asking administrators to sign up for a right they don't need. Mz7 (talk) 15:41, 13 November 2016 (UTC)

As admins they shuold be aware of new developments so they will probably know that the message wasn't meant for them. Kudpung กุดผึ้ง (talk) 13:40, 15 November 2016 (UTC)

Don't worry, admins have also received a message explaining that they are automatically included (User talk:Anne Delong#A new user right for New Page Patrollers). If that other mass message mentioned by Mz7 is to be sent to more people, though, it might be a good idea to change the word "exiting" to "exciting", to make the meaning more clear.—Anne Delong (talk) 14:50, 15 November 2016 (UTC)

As you probably know, I spend a lot of my time reviewing CAT:CSD (indeed it was the main reason I finally got persuaded to get the admin tools). Will this new right stop people carpet bombing new articles with tags that are just ridiculous and badly tagging pages? If not, can I still advise them to stop it or face a block (I've not blocked anyone yet simply because the warning and a message of advice has always been enough so far). Ritchie333 ^{(talk) (cont)} 15:33, 15 November 2016 (UTC)

@Ritchie333: This right only removes the ability to mark a page as patrolled and use the curation toolbar - nothing else. It's a quality control to ensure pages don't fly under the radar when poorly reviewed. Tagging from newer editors is still possible, and disruptive editing can be handled as usual, of course. ~ Rob₁₃^Talk 16:30, 15 November 2016 (UTC)

By 'handled as usual' Rob, you actually mean 'not at all', because except DGG and me, nobody much else is doing it, and what we are able to do is only a drop in the ocean. Except GB fan also more came up with some conclusive evidence today that New Page Reviewing is just as bad as it ever was - even with the user right. Kudpung กุดผึ้ง (talk) 17:10, 28 November 2016 (UTC)

'Move to draft' tool

This 'Move to Draft' tool

What is this tool? Is there a one-click version of this? Because it isn't in the curation toolbar. Or is it just the permission to move articles to draftspace via the normal 'move' mechanism? Should be clearer in the documentation. czar 15:19, 15 November 2016 (UTC)

The manual process I generally use to draft an article is to undelete it, move it without redirect, removing any CSD tags (which are usually the cause of me rescuing a draft in the first place) and adding {{subst:AFC draft|username}}. Once you've done a couple, it doesn't become particularly onerous in my view. Ritchie333 ^{(talk) (cont)} 15:35, 15 November 2016 (UTC)

(edit conflict) I think it is not even a defined process other than "move it and tell the creator". There should probably be a defined process which can be captured and automated. At a minimum, in my view, would be 1)Move page and talk page without redirect for admins and extended-movers or tag the redirects CSD-G6. 2) a standard notice with an input box for a required explanation/justification for the move. This should be posted to the author's talk page and if possible recorded in the log. 3) a guideline that explains what to do when the move is objected to by the author and/or other editors ie is the mover required to undo the move if it is objected to. 4)Add {{subst:AFC draft|username}} to the article. (per Ritchie333 above.)

The criteria for moving an article to draft should be defined as well. There are a lot of articles that I, personally, do not think are ready for main space but I am sure there would be no consensus to move to draft or at the very least would spark "discussion". The primary example of what I think should be moved, and which I believe BLP supports, are BLPs that while having sourcing sufficient to disallow BLPPRODing nonetheless have no actual reliable sources ie based entirely on personal web pages or PR bios or have a RS but the vast majority of the information is completely unsourced. More controversial would be articles on companies which are sourced to PR and primary material but have some chance of passing NORG and are not quite CSD-G11. Further afield are articles, of any type, which are unsourced - this, I believe, would take an RfC becuase there is consensus is OK because of some hand-wavy interpretation of WP:V.

Moving to draft should be less controversial now that new pages are NOINDEXed until patrolled or for 90 days so it is not like a soft delete which removes the article from search engines. Working against the "should" is the fact that most editors do not know this and will see it as tantamount to out of process deletion. Having written criteria and a defined process will, I think,the reviewers who are both willing and experienced enough to use this option by giving them some foundation to base their decisions on and a criteria for others to judge their actions against. Jbh^Talk 16:10, 15 November 2016 (UTC) Last edited: 16:50, 15 November 2016 (UTC)

Add: A big reason for the need for this is because non-admins may be making these decisions. Particularly extended-movers who can do the whole process without admin intervention and therefore no perceived review. Editors are predisposed to accepting admin judgement on deletion processes, and this will be seen as many as a 'deletion'. An analogue would be an extended-mover closing an AFD as userfy or move to draft. Jbh^Talk 16:20, 15 November 2016 (UTC)

I will generally restore anything to draft on request by the creator provided it is not G3, G10 or G12 (or any other speedy criteria where I think even having the article around as draft is an issue). If it gets rejected 6 times at AfC and finally deleted via G13, well we're not short of disk space.... Ritchie333 ^{(talk) (cont)} 16:29, 15 November 2016 (UTC)

I agree with that but I do think there needs to be a defined procedure because there will be editors of varying experience and temperament making more moves, especially if it is part of the 'toolbox'. The fewer conflicts the less controversy. Also, communication with the author is key in this, explaining that it was moved and why, telling the that they can ask to have it restored and it will be, maybe making it explicit that it was moved because it did not meet Wikipedia's content criteria and if it is in main space it would likely be subject to deletion processes but draft space gives more time to make it better etc. These are all things 500/90 editors almost certainly will not know to do on their own and even experienced editors may not think about if new to NPP. Jbh^Talk 16:50, 15 November 2016 (UTC)

Jbhunley, new, New Page Reviewers are committed to having read and fully understood the tutorial before being granted the right. If the tutorial is still not sufficiently explicit on this point, please let me or Fuhghettaboutit know. --Kudpung กุดผึ้ง (talk) 02:49, 16 November 2016 (UTC)

The tutorial is very well written and informative. I would suggest though that a section dedicated to the move-to-draft tool that provides a) something like the four steps mentioned above that defines the process and b) some description of what move candidates may look like - I suggested three criteria above - be added. I think the BLP one would be supported by policy, the other two are more iffy.

Having the ability to move as part of the tool is likely to increase the number of people doing moves and decrease the experience level of people doing the moves - "It is in the toolbox so it must be OK". Because of that I think there should be some concretes guidance the problem is, for the most part, sending an article to draft is an "I know it when I see it" kind of thing so maybe the criteria are not really quantifiable/documentable.

Even if the criteria can not be written, the procedures can be. I would suggest something like

When you move an article to draft space ensure you have done all of the following:

1. Moved both the page and its talk page, if one exists, to DRAFT
2. If redirects were left tag them WP:CSD#G6
3. Remove all tags and categories
4. Tag the article with {{subst:AFC draft|username}}
5. Notify the author and explain to them why it was moved and what needs to be improved
6. If the author objects move it back and see what the author does. Depending on the situation:
   1. If the author fixes it - leave it.
   2. Stub it.
   3. AfD it.
   4. Improve it to minimum standards yourself.

I am sure someone can write better instructions than I but I think that those are the essentials. Jbh^Talk 04:25, 16 November 2016 (UTC)

I have strong concerns about this option; it seems to go counter to the fundamental notion that editors collaborate to produce & improve articles. It should not be used merely because the article needs substantial work to be ready for mainspace, but only in special cases that should be defined and enforced. For most newbie editors it is equivalent to deletion, because they have no clue how to improve the article or even how to submit it for re-review. Espresso Addict (talk) 01:44, 16 November 2016 (UTC)e

The Foundation devs are already looking at these issues (or they say they are). From our end , the project is being managed at WP:NPPAFC and includes the possibility of locally enacting WP:ACTRIAL if the WMF still refuses to complete the New Creator landing page they started in 2012. The WMF CEO has been made aware of these critical issues. However, if you prefer, you are welcome to make the suggestion that patrollers should continue to simply mark all unsuitable pages for deletion even if they may have potential if the creators were to better understand the principles of page creation.Kudpung กุดผึ้ง (talk) 02:22, 16 November 2016 (UTC)

• This has gone off-topic from my question, which was about what "tool" exists to automate the move. I have no issue with trusting someone with this right to only move pages that are below the GNG as drafted and just need some help/guidance from AfC links and an AfC reviewer. I have been doing this for a while and have a full workflow that includes a message for the author's talk page. If a programmer is interested in coding the workflow into either the Curation Tool or Twinkle—just let me know and I'll write it out for you.  czar 16:20, 19 November 2016 (UTC)

  Please do write out the workflow. Whether it is coded in the near future or not having a set of documented procedures will be worthwhile. Jbh^Talk 16:39, 19 November 2016 (UTC)

Building on Jbhunley's workflow I'd suggest...

When you move an article to draft space ensure you have done all of the following:

1. Mark the page as patrolled
2. Move both the page and its talk page, if one exists, to DRAFT, including [[WP:PM/C#6]] in the edit summary if the redirect is suppressed
3. If redirects were left tag them WP:CSD#G6
4. Remove all tags and suppress the categories by adding leading colons ([[Category: -> [[:Category)
5. Tag the article with {{subst:AFC draft|username}}
6. Notify the author and explain to them why it was moved and what needs to be improved
7. If the author objects move it back and see what the author does. Depending on the situation:
   1. If the author fixes it - leave it.
   2. Stub it.
   3. AfD it.
   4. Improve it to minimum standards yourself.

for the following reasons:

• Patrol before move prevents the draft appearing on SNP but not being patrol-able.
• [[WP:PM/C#6]] is a stylistic thing I've noticed among Page Movers to justify the use of suppressredirect.
• Suppress the categories rather than removing them saves the need to re-add them from scratch when the article passes review.

--Cabayi (talk) 16:33, 28 November 2016 (UTC)

Question About When

I see that this is a discussion about Move to Draft. There has long been discussion about whether patrollers or others should be able to move new articles to draft space, and, to the best of my knowledge, there hasn't been a conclusive decision on when that can be done. Are criteria for it documented anywhere? I don't mean to be difficult. I would just like to know when this is intended to be done appropriately. I have seen it done during a deletion discussion, but that is a compromise between Keep and Delete in response to the well-documented AFD process. What are the criteria for moving things to draft space? Robert McClenon (talk) 16:24, 19 November 2016 (UTC)

The only criterion is common sense. I find it amusing that so many people think it's something new. We've been manually userfying new pages or moving them to draft for years. Of course, it's not supposed to be a catch all for pages that patrollers can't make their minds up about, and indeed over the six years or so that I've been closely monitoring NPP I've never seen it abused. Why do we now suddenly need to write a whole set of by-laws to govern it? Of course, it is probably something that perhaps only the accredited New Page Reviewers ought to be permitted to do - and that's not technically difficult either.As far as 'when' is concerned, the answer is: as soon as the boss of WMF devs decides to do it. Kudpung กุดผึ้ง (talk) 17:05, 19 November 2016 (UTC)

While it has always been physically possible to move a page to draft just via the Move function, it has also always been controversial. A few months ago, one reviewer complained about PRODing of low-quality pages by new editors. This resulted in discussion of whether editors who create low-quality pages are low-quality editors or whether they need a lot of hand-holding to become good editors. The suggestion was then made that low-quality pages should be moved to Draft space rather than PROD'd, but there were objections that this would further increase the burden on AFC. The result is that there wasn't any consensus. It has always been possible, and there has always been no consensus, in my view. Robert McClenon (talk) 19:48, 19 November 2016 (UTC)

Rob, let's be clear about WP:PROD. It is a deletion of inapprpriate content, not a flag for an article that's just a bit below par. Most PRODS end up being deleted. The benchmark is whether it would survive an AfD. Most won't. This is the opening text from the policy:

Proposed deletion (PROD) is a way to suggest an article for uncontroversial deletion. It is an easier method of removing articles than the articles for deletion process (AfD), and is meant for uncomplicated deletion proposals that do not meet the strict criteria for speedy deletion. PROD must only be used if no opposition to the deletion is expected. It must never be used simultaneously with an AfD, and it may only be placed on an article a single time. Any editor (including the article's creator) may object to the deletion by simply removing the tag; this action permanently cancels the proposed deletion via PROD.

It may give seven days grace, but PROD is not to be confused with 'giving the user time to get his creation up to scratch'. Rewiewers will need to learn and exercise these different paths correctly. Kudpung กุดผึ้ง (talk) 08:07, 25 November 2016 (UTC)

Okay. We may need a clarification. I understand that PROD is for articles that were crud, usually one or two sentences of crud, that wouldn't have a snowball's chance at AFD, but that don't happen to fall within any of the specific CSD criteria. Articles that are merely low-quality should be tagged, or maybe AFD'd. My real question still is about unilaterally moving articles from article space to draft space. I know that one result of an AFD can be to move an article from article space to draft space. I was asking whether there are any criteria for moving an article unilaterally from article space to draft space, and it appears that this is a matter of judgment, and should be done seldom. Robert McClenon (talk) 15:53, 25 November 2016 (UTC)

THat's a fairly god summary, Rob, seldom, but often enough to to need a helper script to do it. Kudpung กุดผึ้ง (talk) 17:04, 28 November 2016 (UTC)

User:Kudpung - What and where is the script? Robert McClenon (talk) 18:25, 28 November 2016 (UTC)

Patrolling the Mass Message about the new group

Typo: User group: New Page Reviewr. Missing an e. Crow^Caw 18:00, 19 November 2016 (UTC)

Comments and Questions

I have again been working the New Pages feed, after not having been working it for a while. I have a few observations and questions. First, sometimes I see a number of usually longish articles show up at the top of the feed with a check mark. I am assuming that those are new articles by editors who have the autopatrol (or whatever it is called) privilege so that their pages do not have to be patrolled. If my understanding is correct, then that is all right. Second, I don't think that the feed is consistent on what it does to the status of pages that I have marked for speedy deletion. I do see that it consistently doesn't mark pages as patrolled if I PROD'd them, so that I need to mark the page as patrolled after PRODing it. Am I correct that I should, in general, mark a page as patrolled if I have tagged it for any of the deletion processes, to mean that a reviewer has reviewed the page, and it doesn't need further review by reviewers? (If the page has been nominated for deletion, it will get further attention via AFD for seven days.) I also think that there are inconsistencies as to whether a page is watchlisted if I PROD or CSD it. (It isn't watchlisted if I mark it as patrolled, and I don't want to watchlist it then. A page is watchlisted if I accept it via AFC, but that is a physical move, and is a different sort of thing.) Robert McClenon (talk) 19:56, 19 November 2016 (UTC)

@Robert McClenon: I used to mark a page patrolled if I nominated it for deletion so that other people wouldn't see it on the list and bother with it. However, now that we have enabled no index for unpatrolled pages, I hesitate to mark an article nominated for deletion as patrolled because I don't want it indexed. ~ ONUnicorn^{(Talk|Contribs)}problem solving 16:48, 28 November 2016 (UTC)

Doesn't the page curation tool automatically mark pages as patrolled if you add a deletion tag to them? I took my lead from that and marked them manually when nominating via Twinkle, but I agree it seems rather counterintuitive to de-noindex an article that will in all likelihood be deleted shortly. Maybe the functionality should be changed. Joe Roe (talk) 17:27, 28 November 2016 (UTC)

Well, it is my understanding that the CSD templates transclude Noindex, so that if a page that has marked for speedy deletion is marked as patrolled, that prevents it from being indexed. That raises two related questions. First, does PROD transclude Noindex? Second, does AFD transclude Noindex? Robert McClenon (talk) 18:30, 28 November 2016 (UTC)

@Robert McClenon and Joe Roe: Only CSD templates mark articles as noindex. There is no reason to noindex an article that is merely PRODed or AfDed. If they show up in Google, that's not a big deal. The things we want to not show up in Google are blatant spam, hoaxes, attack pages, etc. Please mark everything else as reviewed once it has been reviewed. There is no sense keeping these in the unreviewed queue after you've already reviewed them. It just creates redundant work and keeps the backlog from being cleared. Hope that helps to clear up the confusion. Kaldari (talk) 22:58, 28 November 2016 (UTC)

• Actually, the details don't matter. We just need to get the result: the acceptable articles into mainspace, the not yet acceptable but improvable ones improved, and the impossible ones removed; there are multiple valid pathways for doing this. It's better to get the unacceptable ones NOINDESED, especially the bBLPs, but since we presumably will be speedying the damaging one, it doesn't really matter if we miss a few. We shou.d have a guide for those starting out but everyone will develop their own pattern of work. DGG ( talk ) 22:34, 28 November 2016 (UTC)

Thank you. I have already been marking things as reviewed if I PROD or AFD them and will continue to do so. I would prefer that PROD transclude NOINDEX, but it isn't a big deal. Robert McClenon (talk) 00:38, 29 November 2016 (UTC)

• Deletion tags naturally all make sure an article is noc indexed. I think the varoius deletion tags do it by transclusion. How they do that technically is not my concern but I thought Kaldari had made that clear several times. Kudpung กุดผึ้ง (talk) 22:47, 28 November 2016 (UTC)

• They seem to use {{NOINDEX}}, but not all do. Of two I clicked randomly, db-g6 does not but db-g10 does. Pinguinn 🐧 02:27, 30 November 2016 (UTC)

Giving Autopatrolled to more prolific article writers

Given that the NPP backlog is so huge, I think we could cut it down quite a bit by granting autopatrol rights to more editors who are prolific page creators. I see quite a few editors who habitually create at least a page or two a day, and there is nothing wrong with their articles. They're notable, well written, and reliably sourced. There's no reason why such editors shouldn't have autopatrolled rights, and it would hopefully help cut down the backlog so we could spend more time on articles that are a problem. White Arabian Filly ^Neigh 00:17, 24 November 2016 (UTC)

Absolutely. Could you please list these editors here (you do not need to link to their pages in order to not trigger automatic notification).--Ymblanter (talk) 14:04, 24 November 2016 (UTC)

This is a campaign I've (slowly) been waging for a while. Every week or so, I try to hit up Special:NewPagesFeed and look through contributors with >1,000 edits to determine if they're eligible for the autopatrolled right. This is one of those things admins can be doing to help out which requires a low investment of time but has a large payoff for the new page patrollers on the ground. I definitely support this, and I welcome any new page reviewers to nominate potential candidates at WP:PERM/AP. Keep in mind that the editors don't have to nominate themselves for this particular user right. ~ Rob₁₃^Talk 14:24, 24 November 2016 (UTC)

Some editors who I think are suitable for the Autopatrolled right are: Lewisthejayhawk, Qwe144, Mateusz K, and OceanH (undoubtedly there are a lot more, but I encounter most of these editors routinely as their pages show up in the Newartbot feeds I watchlist). As far as I know, none of them currently have the right, but all have created over 25 articles which meet the guidelines for inclusion and don't seem to have issues.

It's good to know you can nominate others for rights, I didn't know that! I thought if an editor wanted a right, they had to request it themselves. White Arabian Filly ^Neigh 15:35, 24 November 2016 (UTC)

Thanks a lot for the suggestions. I flagged Qwe144. The account OceanH is not registered, it must be a spelling error in the name. Mateusz K is one month old, and I am a bit scared to give an autopatroller flag to a month old account, but would definitely not object if someone else does. Concerning Lewisthejayhawk, there are couple of red flags, such as suspected sockpuppetry (likely unfounded) and a recent article which was AfDed (the discussion is headed to no consensus). I would personally still grant the flag, but I would appreciate a second opinion.--Ymblanter (talk) 16:10, 24 November 2016 (UTC)

Sorry, it's Oceanh. I capitalized the H when it's actually lowercase. I know Mateusz K is new, but their contributions are solid, which is why I felt comfortable reccomending them. White Arabian Filly ^Neigh 16:39, 24 November 2016 (UTC)

Thanks again. Oceanh is autopatrolled.--Ymblanter (talk) 17:29, 24 November 2016 (UTC)

"Mark this page as patrolled" confirmation

Is there a reason marking a page as patrolled now requires an extra confirmation step? Not once have I clicked that link by mistake. It may seem like a small issue, but it's enough of an extra hassle that I find myself just not bothering with NPP anymore. Kolbasz (talk) 15:25, 25 November 2016 (UTC)

I don't know, but I'm wondering about it too. It's pretty hard to hit the link by accident even on a touchscreen device, because of its location down at the bottom of the page. White Arabian Filly ^Neigh 19:22, 25 November 2016 (UTC)

@Kolbasz and White Arabian Filly:, it might be an idea to consider it as a bug that can be addressed rather than give upon patrolling. I am unable to replicate it - from wherever I access a new unreviewed page (the old list or the Special:NewPagesFeed), the 'Mark this page as patrolled' shows as a superb vertical toolbar. Click the 'tick' button to mark as patrolled. If tags are needed, the option to use Twinkle is still open, but the Curation Tool is bursting with additional features and the WMF is working on more features right now . (FYI: Kaldari) .Kudpung กุดผึ้ง (talk) 08:16, 26 November 2016 (UTC)

This is a bug of sorts, but I think it's related to the site JavaScript, and not making a page as patrolled. E.g. I've had the same issue lately when adding pages to my watchlist. Does the two step process happen every time you click the link? It is irregular for me.

Kudpung, the "Mark page as patrolled" link is not shown if the Page Curation tool is open. Click the X on the toolbar to hide it. To those above who would like to use Page Curation, look for the "Curate this page" link in the "toolbox" on the left side. Note also for pages other than articles and user pages, the Page Curation tool is not available and hence you will see the link instead if the page has not been patrolled — MusikAnimal ^talk 15:26, 26 November 2016 (UTC)

I also have experienced this irregularly, but it is not a new problem. I think it happens more often when I am patrolling newer pages then when I patrol from the back. -- AntiCompositeNumber (Leave a message) 21:24, 26 November 2016 (UTC)

This is with javascript disallowed. Attempting to mark a page as patrolled nets you a confirmation page with "Mark revision [xxxxxxxxx] as patrolled?". Kolbasz (talk) 00:48, 27 November 2016 (UTC)

Newsletter

The newsletter on my talkpage goes on about a backlog somewhere. Might of been useful to maybe link to that in someway. Oh well. Lugnuts}} ^{Precious bodily fluids} 18:15, 26 November 2016 (UTC)

Lugnuts The current backlog is displayed and updates every time you load or refresh the feed when you do any patrolling. --Kudpung กุดผึ้ง (talk) 20:51, 26 November 2016 (UTC)

Just came here to say that this newsletter is helping to motivate me to get out and review pages after a period of inactivity, so thank you! --Slashme (talk) 22:22, 27 November 2016 (UTC)

Visibility

At a current RfA, I was using the new article grease fire as an example. One point was that this page is the #3 hit on google for the topic, even though it isn't very good yet. Given all the recent developments, I was wondering about its patrol status but this is not easy to see. The history for a page doesn't show who patrolled it and when. That would be the best place to have the information but currently I do a log search instead and that doesn't work so well. In this case, it draws a blank but maybe I didn't do it right. Is there some convenient link on or around a page which provides its patrol history and status? Would it be possible to add this information to the edit history? Andrew D. (talk) 11:59, 29 November 2016 (UTC)

It wasn't patrolled, which I guess is why it didn't show up in the logs! I've just marked it as patrolled now, and that shows up in the page log. Although that raises the question of why it showed up on Google when unpatrolled pages are supposed to be noindexed? Joe Roe (talk) 14:38, 29 November 2016 (UTC)

I believe it was created before the noindex thing started. It was created in September and the noindexing new pages started on or about October 20th. ~ ONUnicorn^{(Talk|Contribs)}problem solving 15:43, 29 November 2016 (UTC)