*<small>Please note that while this proposal adds a function to the sysop brief at [[WP:PERM]], this is '''NOT''' an RfC that seeks to arbitrarily expand the ''powers'' of administrators.</small>
*<small>Please note that while this proposal adds a function to the sysop brief at [[WP:PERM]], this is '''NOT''' an RfC that seeks to arbitrarily expand the ''powers'' of administrators.</small>
*<small>This RfC is ''not'' for discussing the entry threshold for new New Page Reviewers. This will be the subject of a further RfC if and when consensus here is reached for the user right in principle.</small>.
*<small>This RfC is ''not'' for discussing the entry threshold for new New Page Reviewers. This will be the subject of a further RfC if and when consensus here is reached for the user right in principle.</small>.
*<small>The mentions of '''Twinkle''' in this RfC are an illustration only. Primarily we are asked to discuss the introduction of a user threshold for NPP. Policy dictates how Twinkle is used - Twinkle does not stipulate how policy will be interpreted.</small>.
*<small>This RfC is ''not'' for discussing the software technicalities of the proposed right. In the case of a consensus this will be addressed at Phabricator.</small>.
*<small>This RfC is ''not'' for discussing the software technicalities of the proposed right. In the case of a consensus this will be addressed at Phabricator.</small>.
*<small>Alternative proposals: Please start your own RfC rather than detracting from this one to make your point.</small>.
*<small>Alternative proposals: Please start your own RfC rather than detracting from this one to make your point.</small>.
Revision as of 11:42, 29 August 2016
RfC for New Page Reviewer
This RfC will run for 30 days and be closed by an experienced, uninvolved user.
Notifications: Users who have previously participated in related discussions are being notified manually within the policy at WP:Canvass; apologies for any omissions. Related projects are also being informed. This RfC will also be notified on RfC Cent, the WP:VP, and on users' Watchlists.
Please note that while this proposal adds a function to the sysop brief at WP:PERM, this is NOT an RfC that seeks to arbitrarily expand the powers of administrators.
This RfC is not for discussing the entry threshold for new New Page Reviewers. This will be the subject of a further RfC if and when consensus here is reached for the user right in principle..
The mentions of Twinkle in this RfC are an illustration only. Primarily we are asked to discuss the introduction of a user threshold for NPP. Policy dictates how Twinkle is used - Twinkle does not stipulate how policy will be interpreted..
This RfC is not for discussing the software technicalities of the proposed right. In the case of a consensus this will be addressed at Phabricator..
Alternative proposals: Please start your own RfC rather than detracting from this one to make your point..
Please remain civil. Take your personal disagreements with contributors' comments elsewhere..
Introduction
New Page Patrol is a major cross-Wiki critical issue provided for by Page Curation/NewPagesFeed, a core MediaWiki software funded by the Foundation. Due to unfinished Foundation business at the time of its roll out, the intended creation of a new user group for its use was put on hold, along with the software that was under development to replace the Article Wizard in the aftermath of WP:ACTRIAL.
New Page Patrol is the only firewall (WP:ACTRIAL was rejected in 2011) against unwanted content in the form of new articles and it must be done responsibly and accurately. It's also the place where first-time good-faith article creators get bitten, and regular, competent users get harassed by incompetent patrollers. It is accepted knowledge and has been for many years that NPP is in urgent need of many more experienced, competent editors.
New Page Patrol is a critical, essential process. Done incorrectly it passes unsuitable (or even illegal) content into the encylopedia, deletes articles with potential, and bites good-faith new users. The complexities of the tasks for New page reviewers is described in detail at New pages patrol.
Compare: WP:Articles for creation (AfC) is neither a formal nor a strictly mandated process - it's a compromise that allows a) non-registered users to create an article, b) a review of articles that are created by new users, c) a review of articles moved (mainly by New Page Patrollers) to the Draft namespace for further development.
NPP does not require the least demonstration of competency or knowledge of policies or guidelines to operate the PageCuration dashboard.
Compare: AfC, with an intake of around 100 - 150 pages per day, has a list of active reviewers that is constantly monitored. Users who do not meet the criteria or who fail to perform appropriately, are regularly removed from the permission list (40 this year).
NPP has absolutely no control of, and no tools to provide information on who patrols pages, when they patrol, or the accuracy of their patrols. None t-banned, none blocked, possibly several dozen asked by various admins to refrain from patrolling.
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
14:58, 28 August 2016 (UTC)
Proposal: New Page Reviewer user right
It is proposed therefore to ensure that users are suitably experienced for patrolling new pages. This user right would bring it inline with the requirements for the WP:AfC (see WikiProject Articles for creation/Participants), and the systems for according minor user rights such as rollbacker, template editor, page mover, etc. (see: Requests for permissions). Note: Not proposed here: The numerical and experience qualifications for users to be authorised to patrol new pages. This will be determined in a subsequent RfC if this RfC gains consensus, and as such is not up for discussion here.
Patrollers who have effected 200 uncontested patrols between 27 March 2015 and the date of consensus (if any), and who have a clean block log will be grandfathered into the right.
The right will be requested at Requests for permissions in the same way as all other minor rights are granted by admins.
The existing NPP userbox will be deprecated and users will be notified by newsletter (in preparation) that they can reapply.
Twinkle
with the exception of WP:U1, in the same way that some scripts (e.g. blocking, protection, etc) are visible only to admins, all CSD, AfD, and PROD functions will only be visible to users accorded the New Page Reviewer right.
some features of Twinkle which were forgotten by the developers of page Curation will be added to the Page Curation tool, along with some new ones. (This is NOT up for discussion here)
Background - please read this before commenting
New Page Patrol is a critical issue. It is the only firewall against unwanted content in the form of new articles and it must be done responsibly and accurately.
In 2011 due to a massive backlog (around 35,000) and the Foundation's refusal to implement WP:ACTRIAL, we lobbied the Foundation for software to make the task of patrolling new pages easier for experienced users. In direct collaboration between the community task force and the WMF, the new New Page Feed and the Page Curation tool were developed. Five years later, due to its still needing absolutely no knowledge or experience, NPP remains a magnet to younger and/or inexperienced users and an area of disinterest to more experienced users because they perceive NPP as a never ending battle.
Further developments in content 'growth' over the following years however, has demonstrated a dramatic increase in the use of Wikipedia for advertising and promotional purposes. Such pages are now very subtle and are hard to detect even by experienced patrollers, as evidenced by the massive Orangemoody onslaught which is probably only the tip of the iceberg. It is therefore essential to encourage more users to take part in the reviewing of new pages while nevertheless insisting that they are adequately experienced for the task.
It is at NPP where all the 1,500 or so new pages that arrive every day get rightly and wrongly tagged for deletion, and rightly and wrongly passed for inclusion. It's also the place where first-time good-faith article creators get bitten, and regular, competent users get harassed by incompetent patrollers.
See:
Guidelines for granting
The editor should be a registered en.Wikipedia user with a number of mainspace edits and a period to be determined by a subsequent RfC. Edits and/or user status on other Foundation projects are not taken into consideration.
The editor should have made edits (to be determined above) to mainspace of a kind that clearly demonstrate knowledge of page quality control.
The editor should have experience with moving pages in accordance with guidelines.
The editor should have no behavioral blocks or 3RR violations for a span of 6 months prior to applying.
The above items are guidelines. An administrator may grant page reviewer rights to users they otherwise deem competent or may request experience above and beyond the above minimum criteria.
Criteria for revocation
The user right can be revoked for violating any of the above conduct standards and for other misconduct. Additionally, it can be revoked at any time by an administrator without any process or prior notice in any of the following circumstances:
The editor demonstrated a pattern of performing obviously controversial reviews without first determining consensus.
The editor demonstrated a pattern of failing to exercise sufficient care when reviewing pages, resulting in new users being offended or discouraged.
The editor used the permission to gain the upper hand in disputes, COI, or other disallowed inclusion criteria.
The editor performed any blatant vandalism (not limited to page reviewer vandalism).
The editor failed to report to an administrator after noticing unauthorized use of their account or otherwise neglected account security practices.
The editor has been inactive for 12 months.
Additionally, the right may be removed immediately at the request of the editor.
Recent patroller statistics, backlogs
Current backlogs
IRC, offline, and other discussions at Wikimania and meet ups suggest that due to the increasing need by experienced users to monitor the patrolling of less experienced users, experienced editors are less interested in devoting their time to basic patrolling:
8.4% [1] (that's nearly 10%!)(98) indeff blocked. Several of these were directly related to Orangemoody (which of course is ongoing).
39.3% (458) joined Wikipedia during the sample period
11.3% (132) had less than 100 edits
28.4% (331) had less than 500 edits
9.87% (115) had 501 to 1000 edits
36.2% (422) had more than 5,000 edits
48% (558) made only 1 - 10 patrols
12% (139) made only 1 patrol. 70.5% of these are accounts over 2 years old, many of them very old (including several admins), suggesting that these are established users just looking in to test the system.
Very slight support I'll have to support this. Inexperienced/otherwise incompetent NPPrs are, indeed, part of the problem. However, I am a bit hesitant. One of the conflicts I ran into with my previous, now-long-abandoned accounts was that I started out as an incredibly incompetent NPPr. I've learned from my mistakes. --I dream of horses(My talk page) (My edits) @ 07:36, 28 August 2016 (UTC)[reply]
Support. Thanks to the folks who prepared this RfC for the comprehensive background information and relevant API queries. I find myself concerned that over a third of the patrollers during the sample period had less than 100 edits. Of course, editors with this minimal level of experience will make some correct decisions during patrols, but I know I would have made a lot of errors because it takes more engagement than that to understand how policies and guidelines work in practice. In the interest of promoting better quality patrolling and also reducing discouragement from newer editors seeking to contribute, I think this proposal is a step in the right direction. I JethroBTdrop me a line 07:49, 28 August 2016 (UTC)[reply]
Speaking of which, I'm going to patrol some of that crazy backlog; anyone else want to help? I JethroBTdrop me a line 07:58, 28 August 2016 (UTC)[reply]
FWIW, I spent nearly 40 hours on NPP last week, but that was only a drop in the ocean. I'm very slow at it - practicing what I preach, I probably spend too much time on each new page, and also get distracted a lot by following suspicious leads to socks and COI. Which I suppose is what NPPers should be doing and why they need very sharp perception. --Kudpung กุดผึ้ง (talk) 08:18, 28 August 2016 (UTC)[reply]
Support the proposed changes. My sole hesitation is regarding the proposed Twinkle changes. In particular AfD and PROD-tagging have a significantly wider usage than New Pages only, though some of the CSD criteria beyond U1 also come up fairly frequently outside NPP, especially among vandal-fighters. On the other hand, so long as the templates themselves will remain available for use, people with the necessary experience to know of their existence and use ought to be able to find and use them, and deletion-tagging by users who don't understand where and how to find and use them quite probably is exactly the kind of tagging we need less of. (I would, however, oppose a proposal to make deletion-templates wholly unavailable for non-NPPers, as there are too many good and somewhat frequent reasons someone normally not involved in patrolling may need to CSD-tag, PROD or XfD-list a page). And yes, Jethro, I was just thinking the same.AddWittyNameHere (talk) 08:11, 28 August 2016 (UTC)[reply]
Valid points about Twinkle (esp. AfD and PROD-tagging), and noted. Thanks. Yes, It would need some fine tuning later if consensus is reached in principle for the user right. Kudpung กุดผึ้ง (talk) 08:25, 28 August 2016 (UTC)[reply]
You're welcome. Yes, exact fine-tuning can wait until it's clear whether consensus for the user right exists. AddWittyNameHere (talk) 08:38, 28 August 2016 (UTC)[reply]
(edit conflict) Support However, I too think that the Twinkle changes would be over the top. If you made it so only users with the new patroller right could see and click on the [Mark this page as patrolled] button in the bottom right corner of a un-patrolled page that would be enough. Then even if a user not in the user group tagged a page with a CSD, PROD or AFD template (using twinkle or otherwise) it would still come up at Special:NewPages highlighted yellow and would remain so until a patroller (a user in the new group) patrolled it. Twinkle would still be useful for many CSD criteria and starting XfD discussions. If only patrollers could start a XfD discussion — WP:AFD for example — we would probably end up with a lot of complaining and it would increase bureaucracy. Let's say a user without the patroller right found a page from five years ago that clearly failed WP:GNG it would be a lot easier if they could start a AFD discussion using twinkle than if they had to find a patroller to do it for them. The main idea behind this proposal is sound. Often new users see NPP as a easy way to increase edit counts or boost some of their stats. Once an article gets "through" NPP it may only get seen a few times a year by editors. We need to get the first "stage" right so only a very small amount of bad new content works its way on to Wikipedia. I think that the Twinkle issue should be discussed in a separate RFC if this RFC passes and you should explicitly state in the introduction text that that is the case. In summary, I support the general idea of a patroller user group but think more discussion is needed about the specifics, which has been stated by the proposers of this RFC. Thanks to Kudpung and Marvellous Spider-Man for initiating this RFC and their comprehensive evidence. - YellowDingo(talk) 08:55, 28 August 2016 (UTC)[reply]
Support for consistency with the other user rights listed: to be ready to check the work of others you need to have done significant primary editing yourself, to know the ropes and learn from mistakes: Noyster (talk), 09:27, 28 August 2016 (UTC)[reply]
Support with the exception of the changes to Twinkle, per above. NPP is often the only pair of eyes new articles get so mistakes (whether letting through spam or being too bitey) are very costly. It shouldn't be left to hat-collecting newbies, and hopefully this will also bring more experienced editors' attention to the flood of SPA- and COI-written spam that is threatening to turn Wikipedia into LinkedIn. It would also be good if the user right could be applied to AfC, which essentially serves the same function. Joe Roe (talk) 11:44, 28 August 2016 (UTC)[reply]
Support. Making NPP a user right helps ensure patrollers have the communication and interpersonal skills required for the role. The ability to distinguish users who are not here to improve Wikipedia from genuine editors and acting accordingly is also essential. If I recall correctly, the Orangemoody sockfarm was patrolling its own new pages. This measure will help curb this type of abuse. MER-C 11:59, 28 August 2016 (UTC)[reply]
To clarify, I oppose the changes to Twinkle. MER-C 07:37, 29 August 2016 (UTC)[reply]
Support. A WP:PERM-style gatekeeping function at NPP is a good idea, as it will help ensure that newcomers have their articles reviewed by experienced, qualified editors. /wiae/tlk 12:25, 28 August 2016 (UTC)[reply]
Support, long overdue.--Ymblanter (talk) 13:43, 28 August 2016 (UTC)[reply]
Support. Of the four posts on my talk page I recall ever receiving from patrollers, three were made by inexperienced users who didn't seem to know what they were doing. In two of these cases, the patrollers had placed blatantly inappropriate speedy deletion notices, and if I were a new contributor then I imagine that would likely have discouraged me from further participation. Now, my experience is hopefully not representative but NPP does seem to attract a fair share of newbies, who act overconfidently and do long-term damage to the project. Uanfala (talk) 13:51, 28 August 2016 (UTC)[reply]
Support; it's currently far too easy for people to abuse NPP. Jc86035 (talk • contribs) Use {{re|Jc86035}} to reply to me 14:10, 28 August 2016 (UTC)[reply]
Support NPP is really Wikipedia's only quality control. If an article gets through NPP without being put in appropriate maintinance groups, and often even then, it is likely no editor will ever see it again. A user permission will allow us to know that a reviewer has sufficient clue and experience to identify and manage poor or sub-standard content while avoiding major prat-falls.
I often see new users who think NPP is 'a good place to start' and then proceed not only without a firm grasp of our content PAGs but sometimes with their own "special" ideas of what is good content. Preventing this can only benefit the project. JbhTalk 14:12, 28 August 2016 (UTC)[reply]
As a point of interest as of now the NPP Tool is reporting, via the filter function, that all 13019 pages in the queue are from new users which means none of them, save the ones made by socks and paid editors, were created by editors familiar with our content guidelines. JbhTalk 15:42, 28 August 2016 (UTC)[reply]
Support - Noobs are fine (and essential), but the task of greenlighting or red-flagging new starts on notability grounds is not something that newcomers should be doing. It takes time to learn these ropes. Carrite (talk) 15:58, 28 August 2016 (UTC)[reply]
Support Proposers make what in my opinion is a compelling case that this would be beneficial because it would 1) reduce the # of editors doing NPPs incorrectly and for this reason would also 2) draw more users to it because they would not have to worry as much about newbies messing things up. Another big reason I'm here is because this is (as proposers also noted) more important than AFC, yet there are no requirements to be able to do this like there are for AFC. Everymorning(talk) 16:06, 28 August 2016 (UTC)[reply]
Support; my approach is based on pragmatism. Although I do share some of Monty845's concerns stated below, I can comfortably state such an approach would offer some benefits in the long run. We've had a relatively safe system at AfC since we implemented the minimum requirements a while back. It's not a fail-safe system, of course, but it does reduce the number of editor abuses we've all come to know, while allowing a stricter control of current acknowledged editors. FoCuScontribs; talk to me! 16:11, 28 August 2016 (UTC)[reply]
Support, including restricting Twinkle and hopefully Page Curation. People call Wikipedia an unreliable source, and we have not done anything significant as of yet to remedy our poor reputation. It is a peculiar matter on Wikipedia that we allow people with as few as four days of editing and ten edits to control what articles enter the most-used reference work in the world. Many poor articles and utter garbage have passed through our new page review system, to the embarrassment of Wikipedia, just because of poor-quality patrolling. We strive to be a serious reference work, but that does mean that, even in the spirit of openness, we allow almost every registered user to patrol articles. This must be done ASAP to salvage whatever openness people have to changing their minds regarding Wikipedia's reputation. And to address the issue of restricting Twinkle, editors with fewer than 500 mainspace edits and 90 days should be doing content or simple maintenance work. — Esquivalience (talk) 17:06, 28 August 2016 (UTC)[reply]
Support. Absolutely! Way too often that I see newbies marking unsourced BLPs as patrolled with no more than a "refimprove" tag, do not tag blatant spam, or place inappropriate CSD tags. --Randykitty (talk) 17:15, 28 August 2016 (UTC)[reply]
Support the page review, oppose the twinkle restrictions. As I admit myself I tried page curation as a new editor and screwed up a lot. It is a very good tool, but as with all things this tool should perhaps be kept to only those who know how to use it, and will not abuse it. Iazyges (talk) 17:20, 28 August 2016 (UTC)[reply]
Support the overall concept, although as with many others I'm a little leery of modifying the Twinkle tool access. I think simply making a restriction on who can mark pages patrolled is adequate; if Twinkle is being misused (poor CSD tagging, for example), I think that falls outside the purview of new page patrolling.— Preceding unsigned comment added by PGWG (talk • contribs)
Support, BUT don't modify Twinkle. You can still paste in the templates without Twinkle without tool access, so no technical ability is stopped rather everything just becomes more of a chore to apply for tool access. Otherwise, I can get behind this. -NottNott|talk 17:47, 28 August 2016 (UTC)[reply]
Support, strongly, yes. Firstly I want to thank the large number of New Page Patrollers who are doing a sound job, as I really don't want to discredit any of the hard and essential work they are doing, but poor NPP by newbies who really don't know what they're doing can be disproportionately harmful - bad patrolling can be very discouraging in a manner directly contrary to Wikipedia's attempts to attract and retain new editors (If I had a penny for every CSD A1 or A3 nomination I've seen slapped on within seconds of creation and then never another edit from the article creator... in fact, I recently saw one that had A1, A3 and G11 all slapped on within seconds, and all wrong.) I also want to thank those who have worked for years to try to improve NPP (especially my old friend Kudpung) and have stuck at that thankless task despite a number of setbacks. The main opposition (all bar one of the six !votes so far, if I understand them all correctly) seems to be concerned with proposed modifications to Twinkle. I'm personally somewhat ambivalent about that, as I tend to think that the same knowledge and experience proposed for the new NPP right should be pretty much what people should need in order to use Twinkle anyway. But if the Twinkle changes should present a difficult hurdle in getting this proposal accepted, how about putting them off for a future RFC - if this one is approved, we'll hold another one to decide what, if any, restrictions should be placed on Twinkle? Boing! said Zebedee (talk) 18:49, 28 August 2016 (UTC)[reply]
(edit conflict) Support along the lines of NottNott's comment; that is, such drastic changes should not be made to the Twinkle interface. Doing so would make listing articles at AfD a real pain; as someone who manually listed some before installing Twinkle, I can vouch for the fact that the process takes about ten minutes, which, compared with the one or two minutes using Twinkle takes, is alot of wasted time. Unless the requirements for Twinkle are going to change altogether (e.g., raising the level needed for installing Twinkle from autoconfirmed to 30/500), portions of the tool should not be restricted to certain user groups. That being said, this proposal does accurately describe the major shortcomings of NPP; while new users are discouraged from patrolling, many do so anyway, with the expected adverse effects of poor content getting through or articles being incorrectly tagged for speedy deletion. As such, the idea of a required approval/minimum experience level is welcomed. Colonel Wilhelm Klink (Complaints|Mistakes) 19:01, 28 August 2016 (UTC)[reply]
Support as one of the people who was at the heart of the ACTRIAL situation I have long known this to be a huge problem. The number of users who plainly have no business attending to these new pages is staggeringly high, and creates immense amounts of extra work for those of us who actually know what the hell we're doing. AfC has limits for people wanting to use the AfC helper script, so there's no reason why NPP should be any different. The Blade of the Northern Lights (話して下さい) 20:26, 28 August 2016 (UTC)[reply]
Support - and I've got no problem with the Twinkle changes either. I'm a bit bewildered at the large number of remarks that are variations of "I never want to file an AfD manually again." Really? So how's this for a fix? Apply for the flipping right. If you're too lazy to take the thirty seconds it'd take, and too impatient to handle the day it might take for approval, then you probably aren't a good fit for the requirements of deletion policy. Ravenswing 21:12, 28 August 2016 (UTC)[reply]
WP:NOTBUREAUCRACY. The proposed changes to Twinkle are a net negative ("Don't break what's not broken"). The rest of the proposal (the first part) is a good idea. --IJBall (contribs • talk) 00:36, 29 August 2016 (UTC)[reply]
Come now. That's just parroting a shibboleth for the sake of parroting a shibboleth, especially given those who think that unrestricted access to quick and easy tools to delete in the hands of inexperienced editors or sockpuppets IS broken. Ravenswing 01:36, 29 August 2016 (UTC)[reply]
<sarcasm>And here I thought that it was the admins that checked and verified every CSD tag that was applied. If I knew that I could delete things with Twinkle I would have been far more careful! </sarcasm> Shockingly, anyone can still apply the tags manually. Nobody is stopping a troll from quickly applying hundreds of {{db}} tags before they are caught. --Majora (talk) 01:47, 29 August 2016 (UTC)[reply]
That's quite true. Certainly, of course, we ought not be falling into the trap of failing to enact procedural changes just because means of vandalism the proposals might not explicitly thwart exist. Ravenswing 11:05, 29 August 2016 (UTC)[reply]
General support, but I would like to see some discussion if this right has to be requested or can be automatically conferred based on time/edits. Debresser (talk) 22:36, 28 August 2016 (UTC)[reply]
Support The proposal makes sense and Blade of the Northern Lights' position is one I can easily concur with. Lord Roem ~ (talk) 23:24, 28 August 2016 (UTC)[reply]
Support for the sake of progress. A bar for admission was a good idea at AfC and it's a good idea for NPP. The Twinkle changes need to be re-thought, though. Chris Troutman (talk) 00:02, 29 August 2016 (UTC)[reply]
Support Makes sense. Personally not overly concerned with the twinkle changes, but if that is a major sticking point then they can be easily tweaked. I do not think they should impede what is otherwise a well thought out proposal. AIRcorn(talk) 00:13, 29 August 2016 (UTC)[reply]
Strongly Support. I ran an unscientific test in April 2015 to see how four short new articles on valid subjects by a new user would be received. They all got nominated for deletion right away. See User:Bymatth2/New article test and the very long resulting discussion at Wikipedia:Village pump (proposals)/Archive 121#Discouraging biting the newbies. I am less concerned about whether a given new page gets rejected by an incompetent reviewer than whether a potentially productive contributor gives up when some idiot rejects their page. Given the damage that abuse can cause, NPP should be a privilege that must be earned and can be revoked. Aymatth2 (talk) 00:42, 29 August 2016 (UTC)[reply]
Support, BUT without the proposed changes to Twinkle deletion functions. Frankly, the inclusion of this point makes little sense. All deletion processes have a safety check (administrator, AfD discussion) to minimize mistakes. Building an artificial hurdle, that contradicts the "manual" handling outside of Twinkle, is not necessary and counterproductive. GermanJoe (talk) 01:18, 29 August 2016 (UTC)[reply]
Support There seems to be a default 'Delete' mentality when a new article is being built. Not all article writers are comfortable with perfecting the entire work in their Sandbox and then uploading it, preferring instead to release it in stages. In particular, this affects the person who writes their first article, unsure of whether it will upload or how it will look. The 'Delete' mentality is particularly harmful to such newbies. See Patricia Farr which I wrote and was immediately tagged for deletion, and was later crafted into a decent article as more editors found good reliably sourced info from sources that were not available online to me. Akld guy (talk) 01:23, 29 August 2016 (UTC)[reply]
Support I do however believe that it's not entirely necessary. Any user could just use a speedy delete template, so maybe an edit filter will have to come in to play. — Music1201talk 03:49, 29 August 2016 (UTC)[reply]
@Music1201: This proposal would put further restrictions on patrolling pages. The act of marking a page patrolled is intended to indicate that it meets our most critical polices and act as a checkpoint for new content (further explanation can be found at WP:NPP). Therefore, something is being taken away from users, as those who haven't been granted the new right would no longer have the ability to patrol a page. A page cannot be patrolled with a template. The main focus of this proposal is not to slow down or limit the ability of users to make deletion nominations, rather it is a side effect due to a portion of it, which I would argue (and do below) doesn't belong in this proposal.—Godsy(TALKCONT) 04:22, 29 August 2016 (UTC)[reply]
Support , as a first step. This cannot be expected to completely solve the problem of screening incoming articles, but it's a necessary first strep in developing a rational way of doing this. The key requirement is that it be done by experienced people. The preliminary to recruiting more experienced people is getting the beginners and the unskilled out of the process. Bas work at this stage requires an immense amount of followup, at every quality control and editing process; as our follow up will never be complete;, it leaves a good deal of junk in WP. Much worse, if the very first step is not done correctly, m=new editors will be discouraged--and once discouraged, they are never likely to return. Since the survival of Wikipedia requires a continuing acquisition of new editors, failure in this will gradually lead to our stagnation and obsolescence. I don't think we should concentrate now at whether this should be done by modify Twinkle, except that whatever we do, Twinkle must be compatible with it--it is designed to adjust to whatever review policy is, and can be adjust that way. Twinkle is not intended to set policy, but reflect it. I hope that whatever we do will eliminate some of the many loophole being used, sometimes in bad faith, to bypass the present review system. I think the proposal should not have specified twinkle--it's a red herring, and should be amended--we may want to use it--we may not. It's not the key factor. The key factor is adopting high and enforceable requirements for NPP, and only that . DGG ( talk ) 04:20, 29 August 2016 (UTC)[reply]
Reluctant support As this is probably necessary to stop the poor patrolling at NPP these days. I never particularly thought that making a new user right for patrolling pages was a good idea, but I think it's better than continuing to allow the "bad" patrollers to continue with what they do there. Omni Flames (talk) 07:15, 29 August 2016 (UTC)[reply]
Support, with conditions. Twinkle doesn't need to be touched. I think this should be similar to the extended autoconfirmed right where users automatically get it after x amount of edits and y amount of days, some possibilities could be 1000/90 or 1000/60. 1000 edits along with 2 or 3 months would make it so more experienced users are patrolling. I started patrolling before I reached those milestones, and I'll admit to having made some mistakes (I'm not saying everyone makes them, just my own personal experiences) early on. Having a barrier would hopefully mitigate the errors made. I am 100% against the restriction of CSD, A/XFD and PROD tagging. Anarchyte (work | talk) 07:46, 29 August 2016 (UTC)[reply]
Conditional support. Without the Twinkle part I'm fine with it. --Pgallert (talk) 08:26, 29 August 2016 (UTC)[reply]
Oppose
Oppose restrictions on Twinkle. Your not removing the ability to do anything with the restriction, your just making it slightly harder while reducing the likelihood a new user does it right. More generally, I think we would be better served by focusing on the act of marking a page patrolled, not tool access. Treat it like the auto-patrolled right, it doesn't grant any extra privileges, it just removes your new pages from needing to be patrolled, likewise we would assign the patroller right to New Page Patrollers when we feel they are good enough to not require a second look after they have patrolled a page. Monty845 14:41, 28 August 2016 (UTC)[reply]
Oppose per above. I know that I was incompentent before when I was editing under in a IP when I first started editing in December 2015 but in March 2016, I was being blocked from editing from an IP for being incompentent. And so far, I learned from my mistakes, blocks and the ANI disscusion when Winklevi has concerned that I was evading a block when trying not to. I'm autistc and I make some mistakes. Most knowingly, "The Autistc Korean Girl!" KGirlTrucker81talkwhat I'm been doing 14:56, 28 August 2016 (UTC)[reply]
Strong oppose Leave our Twinkle alone. That is my only sticking point. I do not want to have to apply for user rights. I do not want additional user rights. Even if I meet the requirements for them. Even if I would be "grandfathered" in. Leave our Twinkle alone. To have to apply for this right just to CSD or PROD things is insane. I work in the file namespace. Something that has absolutely nothing to do with NPP and something that doesn't even show up on the page curation tool. To have to get this user right just to CSD bad images easily is a nonstarter for me. Remove the Twinkle restrictions and you have my full support. Otherwise, strong oppose. --Majora (talk) 17:09, 28 August 2016 (UTC)[reply]
Oppose - Your plan for Twinkle doesn't only affect NPP it affects all CSD, all PROD, and all AfD. You're suggesting making it impossible for a user without the right to CSD, AfD, or PROD an article with Twinkle. Now, you can still do this without Twinkle using the correct template, e.g. {{db-g3}} but you're making this needlessly difficult for Twinkle users like myself. Imagine, seeing an old article just hanging around that has clear copyvio's in it, you don't do NPP and don't have the ability to use good ole fashioned twinkle to tag the page, now you have to spend 10-15 minutes trying to find the god damn bloody template cause you forgot what it was on account of using Twinkle for so long. Why not make this simple; remove the ability to mark a page as patrolled unless you have the NPP rights. CSD is checked by admins anyway, AfD can be snow closed, and PROD can be challenged by anybody. Right now, I vehemently oppose the suggestion on account of the Twinkle suggestion being massively beyond the intended scope of the proposal. Mr rnddude (talk) 17:11, 28 August 2016 (UTC)[reply]
Oppose the consequential parts of the proposal: I don't disagree with the diagnosis relating to poor outcomes resulting from inept NPPing. However once one gets past the Badge aspect of the proposed remedy (and one minor misgiving is that some people seem to just love collecting badges), the consequences seem far wider and deeper. Let's take an editor who lacks the new right: they spot a Copyvio but can't use Twinkle to flag CSD G12; they spot what they recognise to be an Attack page (not always evident across cultures etc) but can't use Twinkle to flag CSD G10. Really: is impediment to quick action on these concerns at all consistent with the project's priorities? AllyD (talk) 17:43, 28 August 2016 (UTC)[reply]
Support for the idea of getting something done, but having great reservations about this proposal I worked in deletion for three years (12,000 edits) without using Twinkle - or working in NPP. I worked in Special:Edits by New Accounts (or something like that). I also don't think I've ever marked a page as patrolled (except by something doing it automatically for me and not telling me...). Quite a few of the pages I nominated for CSD already had been patrolled, so I had little faith in it and checked everything I felt like checking regardless of patrolled status. Something does need doing about the tagging, though. I signed up to Wikipedia to remove some rubbish, and I've been involved with that ever since. If I'd been faced with the proposed apply for rights thing, I probably would have gone elsewhere, (Who said "Pity you didn't!"?) Mind you, I worked with the CSD page open on my computer, and learned the templates in time, so I'd have been OK where I was. I only started to Twinkle after getting my mop. Something I'm not sure about is the qualification for getting this right. I learned the rights and wrongs by tagging and taking in what got declined, and the explanations from some admins of how CSD worked. You're still going to be faced with this when someone gets the 'patrolled' right and is able to Twinkle tags - but still doesn't understand A7, A9, copyvio, and what is advertising. And what is an attack - more than once I've deleted something as spam when it had been tagged 'attack'. AllyD has made good points just above this overlong screed, and so have others. What is needed is education, possibly something like the 'New admin school'. But it would be good to be able to stop a totally inept tagger who simply won't listen, but who isn't guilty of bad-faith vandalism. I'll have a think, and come back when I've thunk. Peridon (talk) 18:22, 28 August 2016 (UTC)[reply]
For clarification, I am against restricting Twinkle. Won't help at all. Peridon (talk) 09:17, 29 August 2016 (UTC)[reply]
Oppose. Modifying a script to disable access to common tasks that editors remain free to do manually is terrible policy. Since editors don't need to seek permission before adding new scripts to their user space, I suspect many editors—experienced as well as naïve—would simply import their own versions of Twinkle, as they would have every right to do. That said, I support a technical change that reserves to a particular user group the right of marking pages as patrolled if and only if it applies no matter how the editor accesses the article (e.g., new pages, recent changes, or by chance; with the Page Curation tool or the "mark this page as patrolled" link). Rebbing 23:09, 28 August 2016 (UTC)[reply]
Oppose per Majora for mostly the same reasons. I patrol new files, which have nothing to do with new page patrol. I use Twinkle so I don't have to manually go through the 7 steps at FFD to get something up for review. -- AntiCompositeNumber (Leave a message) 23:23, 28 August 2016 (UTC)[reply]
Strong Oppose due to the proposed changes to twinkle. "All CSD, AFD, and PROD [Twinkle] functions" are not exclusive to patrolling, in fact, far from it. They have widespread applications outside of patrolling new articles (which is what this proposal hones in on, though other pages can be patrolled). Any user is entitled to nominate an article for speedy deletion, articles for deletion, or prod it. As long as that is the case, we shouldn't take a step backwards and de-streamline the process making it harder. "In the same way that some scripts (e.g. blocking, protection, etc) are visible only to admins", it isn't the same because non-admins aren't given the ability to block or protect, while they may make deletion nominations. If the Twinkle changes are stricken, I'd probably either support this proposal or remain neutral.—Godsy(TALKCONT) 23:23, 28 August 2016 (UTC)[reply]
Oppose proposed changes to Twinkle per Godsy. Twinkle's deletion functions are not exclusive to New Page Patrol, and moreover, I think any policy change in this area should not single out one user script, instead being stated generally to apply to all user scripts. — This, that and the other (talk) 23:55, 28 August 2016 (UTC)[reply]
Oppose the proposed Twinkle modifications. I can understand restricting access to the actual "mark as patrolled" button. However, it's far easier to deal with abusive AfDs, CSDs, and PRODs, since by their very nature they must be checked by either the community or an administrator before they are actioned. My impression is that restricting these Twinkle functions in the manner proposed would actually hinder legitimate efforts to participate in the deletion process. Mz7 (talk) 03:02, 29 August 2016 (UTC) (Note: I will likely move to support if the Twinkle aspect is struck from the proposal. Mz7 (talk) 03:02, 29 August 2016 (UTC))[reply]
Strong oppose. After consideration, I've concluded that this is a bad idea as formulated. Oddly, although I know this idea has been floating around for awhile, the RfC as written seems under-prepared. As I understand it, the argument is that 1) there are a lot of inexperienced people doing NPP; 2) inexperienced people perform poorly; 3) it is possible and feasible to exclude those people; and 4) experienced people will find the task more interesting/compelling/worthwhile if this is done. To unpack that one-by-one:
The statistics on offer do suggest there are a lot of inexperienced people using the Page Curation tools (more than I would've expected). However, my anecdotal opinion is that more experienced people are more likely to use the more flexible and customizable Twinkle for tagging and deletion functions. The source of the data is understandable - the Page Curation tool produces better logs - but, as can already be seen from the discussion, mentioning Twinkle only as a bundled-in afterthought has already caused distraction and made the proposal look unprepared for all the relevant use cases. (Surprisingly, the proposer has notified quite a few individuals about this RfC [2], but it was someone else who posted on the Twinkle talk page [3].)
The second step of the argument seems to have been omitted entirely. It's a plausible hypothesis, and I suppose the proposers simply took it as a given, but it's a shame to have collected the relevant data and then not actually tested the hypothesis before going on to propose a substantial change in policy on this basis. Of note is the fact that the top curator in the list has been to ANI at least twice for performance issues (1, 2), so experience isn't everything.
Apparently can't be evaluated here; we've been explicitly asked not to discuss feasibility of implementation. (Compare the Page Mover RfC, which instead explicitly listed the technical changes required to implement the proposal.)
Another untested hypothesis, which seems much less plausible to me. If experienced and qualified editors aren't doing this task now, why would they be more willing to do it if they have to go cap-in-hand to an admin in order to be granted a right to do something they could have started any time they liked? The introductory text says this RfC is not intended to "expand the powers of administrators", but of course it does; it takes a tool currently available to all and requires that in the future only users approved by admins may use it.
I happened to notice a couple of comments leading up to this proposa, either requesting that feedback be sent in private [4] or criticizing the way feedback was offered in public [5] (lest the "anti-admin brigade" get ahold of it). Given the unappreciated unintended consequences - see some of the comments above about working with files and getting attack pages/copyvio/etc tagged quickly - it all gives an impression that the proposal has been a bit isolated from critical outside feedback.
All that being said, though, this identifies a serious issue facing the project. Better, I think, to back up a bit and have a broader community brainstorm about how best to reorganize our approach to the incoming stream of new articles. (I'd suggest one, but we're not allowed to do that here... ;) Opabinia regalis (talk) 06:29, 29 August 2016 (UTC)[reply]
Oppose per Opabinia regalis. I will write more about Twinkle in the comments section. BethNaught (talk) 08:23, 29 August 2016 (UTC)[reply]
Oppose per Majora. --Wario-Man (talk) 08:35, 29 August 2016 (UTC)[reply]
Oppose per Opabinia. A wider discussion would indeed be preferable to this. I also echo all those pointing out what a terrible and ill-considered idea the proposed Twinkle changes are. --Begoontalk 09:00, 29 August 2016 (UTC)[reply]
Oppose per Opabina. This is a terrible idea. Is there any actual reason to exclude CSD, PROD, and AfD tagging per twinkle to anyone who doesn't have this user right? ThePlatypusofDoom(talk) 11:23, 29 August 2016 (UTC)[reply]
Comments
Consider me parked at Neutral for now, because while I do support this overall proposal, I too am concerned about the Twinkle part of the proposal which would force experienced editors such as myself who do AfD/PROD work, but who are not necessarily a NPP's, to get this new user right just to continue to do the same AfD/PROD work we've already been doing with Twinkle. That just doesn't seem right to me... --IJBall (contribs • talk) 16:00, 28 August 2016 (UTC)[reply]
Query: Under "Summary of technical changes: Technical Permission Changes" it says "1 Remove the (patrol) permission from the Autoconfirmed group, the Confirmed group, and the Pending changes reviewers group." – Shouldn't that also include the "Extended confirmed group"? Or is that yet to be determined?... And a side-comment: Some of us would also like to see the requirements for 'Pending changes reviewers' beefed up one of these days, so I guess including it in the "drop" list is fine for now, but it's possible that, in the future, the NPP right could be added back to the 'Pending changes reviewer' group if its requirements are increased... --IJBall (contribs • talk) 16:18, 28 August 2016 (UTC)[reply]
IJBall from a technical point of view, extended confirmed doesn't have this permission today (see Special:ListGroupRights) - from a practical point of view everyone that is extended confirmed is also auto confirmed; groups and permissions are cumulative - this change will require specific addition to this group in order to make use of the patrol right. — xaosfluxTalk 17:31, 28 August 2016 (UTC)[reply]
Like the idea, and support the premise of something needing to be done at NPP. I'd love to support this, but the Twinkle restrictions are a sticking point for me -- samtartalk or stalk 16:34, 28 August 2016 (UTC)[reply]
To illustrate the number of new users jumping into NPP, here is a plot on the right detailing the people who are actually "patrolling" the pages (using Page Curation). The huge lump near the left are mostly Orangemoody and other socks. — Esquivalience (talk) 17:11, 28 August 2016 (UTC)[reply]
Are we honestly thinking about restricting easy CSD tagging to only people that have this right? I made this comment in my oppose but I work in the file namespace. Something that have nothing to do with NPP. Are we honestly saying that I have to either get this user right or tag bad images for deletion the long way? Come on. How is that a net positive for the encyclopedia? Seems like someone forgot that Twinkle is used far more broadly than just on articles when they drew up this proposal. --Majora (talk) 17:18, 28 August 2016 (UTC)[reply]
Twinkle deletion facilities do not have to be invisible on all articles; e.g., only unpatrolled or new articles, which means not files or other pages. — Esquivalience (talk) 17:28, 28 August 2016 (UTC)[reply]
One, how would you effect this? and two, that is not what the proposal suggests; all CSD, AfD,and PROD functions will only be visible to users accorded the New Page Reviewer right.. Mr rnddude (talk) 17:29, 28 August 2016 (UTC)[reply]
(edit conflict) But that is not what this proposal says. This proposal clearly says that all CSD, AfD, and PROD tagging (only which CSD has anything to do with file space) will be restricted to only those that have this right. As it is written, this proposal is restricting easy CSD tagging on everything. That is insanity and is a net negative for those of us that maintain other areas of the project. --Majora (talk) 17:31, 28 August 2016 (UTC)[reply]
That is what consensus is for. If there are objections to aspects in the proposal, then a compromise decision can be made. — Esquivalience (talk) 17:32, 28 August 2016 (UTC)[reply]
It doesn't seem like a lot of people are aware of how ubiquitous Twinkle is across every aspect of this project. Compromise is great, but is impossible unless people know all the facts. Restricting Twinkle, as it is currently written, should raise alarms with everyone. It is a massive blow to people who maintain other areas of the project and it can't be overlooked. --Majora (talk) 17:44, 28 August 2016 (UTC)[reply]
Honestly I think that twinkle is hard to abuse or misuse and have it be missed, while on one hand the rollback could be abused, the vast majority of the tools afforded by it are helpful, the following tools: easy use of PROD, Easy rollback, and probably most of all the CSD tool, additionally the warn user, overall I am behind the addition of the Page review rights, but leave Twinkle alone. Iazyges (talk) 17:29, 28 August 2016 (UTC)[reply]
As it stands, the Watchlist notification simply says "Permission groups for New Pages Patrolers are being discussed at Patroler Right Proposal". The consequences go far beyond that and an editor who works only at AfD for example could be left unaware of the implications for their use of Twinkle. Surely the message needs to be extended, for example to "Permission groups for New Pages Patrolers and limits to all users' access to the Twinkle tools for initiating CSD, PROD and AfD are being discussed at Patroler Right Proposal"? AllyD (talk) 17:55, 28 August 2016 (UTC)[reply]
Jumping on the leave-twinkle-alone bandwagon, I want to point that out that it's not just a useful for high-volume maintenance jobs. It also means that people like me who don't do a lot of that stuff normally can do properly formatted maintenance tagging without having to look up a bunch of templates and criteria you don't quite remember. I think I once created an AfD in the pre-Twinkle days. I don't want to do it again... Joe Roe (talk) 18:42, 28 August 2016 (UTC)[reply]
I do not use Twinckle and create AfDs on a regular basis (the last one, I believe, yesterday).--Ymblanter (talk) 20:27, 28 August 2016 (UTC)[reply]
That's is fine for some people. For the rest of us, forcing people to do things manually or get this right is a negative for the project as a whole. I've listed one article for AfD manually, I will never do it again and if forced to do so for images I would rather just not tag images for deletion anymore. --Majora (talk) 20:48, 28 August 2016 (UTC)[reply]
As one of the people who cleans it up when someone screws up an AfD Nomination, twinkle avoids a ton of issues. We have at least one bot dedicated to fixing the more common problems, but there are still ways to screw up a nomination in a way that requires human intervention. We recently had an AfD open for 10+ months as a result of such an issue. See exampleMonty845 22:24, 28 August 2016 (UTC)[reply]
Something to consider is whether this right should be requested or automatically conferred based on time/edits. Debresser (talk) 22:35, 28 August 2016 (UTC)[reply]
In that case just bundle it with EC. Twinkle can be restricted to that level as well. It is already restricted to (auto)confirmed people so I would assume it would just take a quick tweak in the code. --Majora (talk) 22:40, 28 August 2016 (UTC)[reply]
How would this (especially the TW changes) affect the File namespace? That's where I do most of my work, and not having Twinkle to DI, XfD, and CSD things would severely inhibit that work. AntiCompositeNumber (Leave a message) 23:18, 28 August 2016 (UTC)[reply]
On a completely separate note. Twinkle doesn't even need to be used at NPP to begin with. The page curation module can be used to CSD articles. To bring Twinkle into this discussion when it is used on every aspect of the project, not just NPP, is insanity and there is nothing stopping people from placing the Twinkle code directly into their own .js scripts. Restricting Twinkle with this proposal is ridiculous. --Majora (talk) 23:43, 28 August 2016 (UTC)[reply]
Agreed. Furthermore, it simply makes something individual accounts with no special rights would still be all allowed to do, harder. Starting a discussion to disallow such users to make such nominations, however much I'd disagree with it, would be reasonable. The restrictions in this form are not.—Godsy(TALKCONT) 00:00, 29 August 2016 (UTC)[reply]
This proposal focuses on patrolling newly created articles. It conflates the process we've established for patrolling pages in the article namespace and patrolling itself. A page in any namespace can be patrolled. Would it be possible to separate the patrol ability based on namespace? If so: I think a better way of implementing this would be to remove patrolling articles from the 'patrol' right, thus leaving the ability to patrol other namespaces with autoconfirmed and confirmed users, while creating an "'article patrol'" right to be granted with the user right by the name suggested here. This would allow new users to gain familiarity with patrolling without the negative affects it currently has on the the encyclopedia proper. Pages in other namespaces aren't as actively patrolled.—Godsy(TALKCONT) 00:45, 29 August 2016 (UTC)[reply]
Not for discussion here (in a future implementation RfC, possibly), but a possible compromise regarding Twinkle is to instead setup two edit filters every time a new user places a deletion template, one disallowing very new users (≤200 total edits) from using deletion templates, and one warning other new users (≤1000 total edits/90 days) about the caution required in using them. The former filter should not discourage most new users, as if a very new user uses a deletion template around their 100th edit, then they are likely a sockpuppet or hat collector. The latter filter would direct most newbies to doing simple maintenance tasks until they reach the threshold (over-eager newbies would likely find the way to bypass Twinkle). The same functions can be built into Twinkle (deletion is greyed out for very new users, and other newbies are warned in the same way). — Esquivalience (talk) 01:25, 29 August 2016 (UTC)[reply]
An edit filter of that magnitude would probably be rejected due to the resources required to use it. There is a reason why we switched from an edit filter to a user right to enforce ECP. Filters take up a lot of server resources and they are avoided, or worked around, if possible because of that. --Majora (talk) 03:55, 29 August 2016 (UTC)[reply]
and in particular the number of edit filters that can be applied without seriously affecting response time is limited; many existing filters are not deployed because of this reason--only the minimum number are used. This is, however, not a discussion on how best to program the restriction, but on having the restriction. DGG ( talk ) 04:23, 29 August 2016 (UTC)[reply]
The suggestion to restrict parts of Twinkle is not only wildly unpopular but also unenforceable. Since Twinkle is freely licensed by virtue of being legitimately posted on-wiki, anybody with a bit of JS knowledge could make an unrestricted version of the Twinkle CSD/AFD/PROD modules, if not write a new unrestricted script altogether. Now you could manoeuvre it out of gadget-space, but anybody can import anybody else's .js files, so to restrict these functions from users without the user right you would have to make it a wiki-crime for anybody to have a non-Twinkle CSD/PROD/AFD script. This was a terribly thought out suggestion. BethNaught (talk) 08:32, 29 August 2016 (UTC)[reply]
In real life, I've previously encountered complex retrofitting of user rights management tooling being advocated rather than looking at the checks and balances already inherent in processes. Regarding NPP, I count 5 possible end-points, listed here with their possible problems: <1> page marked reviewed (possibly missing significant problems with the article in the encyclopaedia), <2> page marked reviewed and tagged (possible detriment to new editor's experience from over-tagging - another experienced editor once objected to my Unreferenced tag on one of the many "X is a village on the Indian sub-continent" one-line articles as excessive for an obvious stub), <3> speedy deletion tag (possible detriment to new editor's experience from over-tagging even if subsequent rescinded by the checking administrator), <4> Prod tag (possible detriment to new editor's experience from over-tagging even if removed by another user or the checking administrator), <5> AfD tag (possible detriment to new editor's experience from over-tagging even if subsequent rescinded as Speedy-Keep or as the AfD decision).
While <3>, <4> and <5> can provide negative experience to the individual editor who contributed the article, these scenarios are already under 100% scrutiny. Guidance can and should be provided to a problematic tagger, escalating to WP:NPPN or WP:ANI on repeat conduct. Hence there are already adequate process review steps in place as to make the Twinkle aspect of this proposal unnecessary (as well as overkill to its use in other processes).
That leaves scenarios <1> and <2>. Again, an identifiable pattern of poor or malign review is susceptible to advice (including cease-and-desist) and then WP:NPPN or WP:ANI, so the question is whether trust is enough aside from that exceptional action. I'd like to think that trust and advice suffice, but also appreciate that the present RFC is based on real concerns that known poor review may be the tip of an iceberg. If a rights-management remedy is needed, it should be specific to the "Mark page as patrolled" function. AllyD (talk) 08:37, 29 August 2016 (UTC)[reply]
Well, there is end-point 6 - article improved by the reviewer and can be patrolled without any additional tags. It is unfortunate that most Wikipedia users are apparently not aware of the existence option. I guess it is also not listed in Twinkle.--Ymblanter (talk) 11:24, 29 August 2016 (UTC)[reply]
It seems like the creators of this proposal were thinking "NEW PAGE PATROL IS THE MOST IMPORTANT THING ON WP AND NOBODY SHOULD WORK THERE UNLESS THEY ARE PERFECT!". Seriously. NPP also fails to catch many things, and that's one of the reasons that Twinkle is vital: placing deletion tags on stuff that was missed by NPP. (For reference, look at My CSD log. I don't work on NPP, so all the red-linked articles there were missed by it, or I got to it first.) ThePlatypusofDoom(talk) 11:29, 29 August 2016 (UTC)[reply]
I have been autopatrolled for ages (meaning articles I created do not even show in NPP log), and still on a regular basis I get my articles bullshit tagged within hours of creation (like adding a stub tag during the period I edit every twenty minutes). I wish people could use their time instead helping me to expand article. I have only seen this happening once or twice.--Ymblanter (talk) 11:37, 29 August 2016 (UTC)[reply]
Also, (as Obapina noted) they seem to think that if "Not many experienced editors are patrolling NPP", the solution is "Make it harder for editors to patrol NPP"? ThePlatypusofDoom(talk) 11:40, 29 August 2016 (UTC)[reply]