Wikipedia:New pages patrol/RfC for patroller right
The following discussion 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.
RfC for New Page Reviewer
[edit]- This RfC (request for comments) 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 (new page patrol). Policy dictates how Twinkle is used - Twinkle does not stipulate how policy will be interpreted.] - 11:42, 29 August 2016 (UTC)
- 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. This page is not for discussing personal disagreements with other contributors.
Introduction
[edit]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.
- Compare: AfC requires users to have a 90/500 threshold plus appropriate experience to use the helper script. (see WikiProject Articles for creation/Participants)
- Compare: WP:Stiki for vandal patrollers requires a 1,000 edit threshold or the rollback right for its use. (see: Wikipedia:STiki#Using STiki)
- Compare: Page mover, something new page reviewers sometimes need to do (move to Draft), requires 3,000 edits and 6 months of editing history
14:58, 28 August 2016 (UTC)
Proposal: New Page Reviewer user right
[edit]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
[edit]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 little interest 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 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:
Additionally, the right may be removed immediately at the request of the editor. |
Recent patroller statistics, backlogs
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Current backlogs[edit]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:
March 2015 - March 2016[edit]
Summary[edit]This means in effect that:
|
Summary of technical changes
|
|---|
|
- Note: Wikipedia talk:Twinkle has been notified of this discussion.—Godsy(TALKCONT) 23:46, 28 August 2016 (UTC)
Support
[edit]- 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)
- 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 JethroBT drop me a line 07:49, 28 August 2016 (UTC)
- Speaking of which, I'm going to patrol some of that crazy backlog; anyone else want to help? I JethroBT drop me a line 07:58, 28 August 2016 (UTC)
- 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)
- Speaking of which, I'm going to patrol some of that crazy backlog; anyone else want to help? I JethroBT drop me a line 07:58, 28 August 2016 (UTC)
- 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)- 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)
- 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)
- 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)
- (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. - Yellow Dingo (talk) 08:55, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- To clarify, I oppose the changes to Twinkle. MER-C 07:37, 29 August 2016 (UTC)
- 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)
- Support, long overdue.--Ymblanter (talk) 13:43, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- Ay, Jbhunley, I'm glad you mentioned that; I think it's gotta be a bug. For instance, I personally have 19 pages in that queue--I'm certainly not an old hand, but I am at least extended confirmed, so I strongly suspect the filter's marking everyone as new right now. I'll mention it at Page Curation talk; if anyone else has a better place to direct this query, please do. Innisfree987 (talk) 00:15, 4 September 2016 (UTC)
- Support WP:CIR for NPP, and new users doing this quite often aren't. Lugnuts Dick Laurent is dead 14:28, 28 August 2016 (UTC)
- Support As per above. Emir of Wikipedia (talk) 15:08, 28 August 2016 (UTC)
- 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)
- 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)
- 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. FoCuS contribs; talk to me! 16:11, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- (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)
- 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)
- 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)
- 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)
- 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)
- <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)
- 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)
- <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)
- 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)
- 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)
- Support - this is a good one. —Oluwa2Chainz »» (talk to me) 22:03, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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. — Music1201 talk 03:49, 29 August 2016 (UTC)
- @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)
- 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)
- 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)
- 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)
- Conditional support. Without the Twinkle part I'm fine with it. --Pgallert (talk) 08:26, 29 August 2016 (UTC)
- Weak support (with the expectation that Twinkle will be left alone): Some minimum cut off appears sane, and the jump in unreviewed pages is indicative of a serious problem. I'm not at all convinced, however, that this is the right first step to manage the flow, or that by adding friction to the process, particularly if the right has to be applied for rather than being granted automatically at some point, you're going to get higher total quality participation rather than lower (which is why the friction should be on page creations). On the other hand, you could lose all casual NPP-ers and it wouldn't make that much difference because the distribution is very much geometric:
- For the entire complement of patrollers, the top ten had more than everyone else combined, and the first (with 61420 patrols total [PT]) had more than the next nine combined (49724 PT). The second and third combined (25864 PT) had more than the fourth to tenth combined. Of the top ten patrollers, four had patrol/edits of > 0.4, and 9 had patrol/edits of > 0.15. Two of those started patrolling within 2 months of their first edit.
- The #1 patroller started during the period. Of the other 715 members (70185 PT; 77 with more than 200 patrols [>200]) who started patrolling during the period, 425 had more than 500 edits (62079 PT; 71 >200), 339 had more than 1000 edits (52663 PT; 55 >200), and 200 had more than 3000 edits (40185 PT; 40 >200)
- ~Hydronium~Hydroxide~(Talk)~ 12:59, 29 August 2016 (UTC)
- Weak support There is a problem with biteyness and driving off new editors, but perhaps until AfC and NPP are integrated or some other blue sky thinking proposal is adopted- as you point out , there are major differences in a new editor's experience depending on whether they publish their article in Draft (first contact AfC reviewers) or straight onto the mainspace (first contact NPP patroller)- but until that happens, or there's a major reversal in the Foundation's stance towards ACTRIAL, I think that this proposal might work- but I strongly disagree with any restrictions to Twinkle, especially restricting deletion tools. I'd much rather leave Twinkle as it is- from my experiences over zealous Twinkle tagging from inexperienced editors is actually quite quickly discovered and they are talked to at the appropriate venues; and restricting Twinkle to try and stop that would stop the useful editors that nominate articles for deletion using Twinkle. I understand that this RfC is definitely not about Twinkle, but I think it does play a significant part in whether this proposal is adopted or not. jcc (tea and biscuits) 14:38, 29 August 2016 (UTC)
Conditionalsupport -I agree that experienced users should be the ones patrolling new pages. However, I vehemently disagree with rolling Twinkle CSD/PROD/XfD access in with this right/group. Admins have to review any CSD, expired PROD, and XfD discussion, so there is your safeguard. There is a header at WP:Twinkle which explicitly states that all editors "take full responsibility for any edits [they] perform using Twinkle." Penalties for misuse and abuse include the threat of being blocked – blocking happens to be among the penalties for all users who abuse the encyclopedia. I have never tried to create an AFD manually because the process is too damn complicated, and I don't understand why I should have to apply for the right to patrol new pages in order to nominate old articles for deletion. If, however, the Twinkle changes will not be removed from this RfC, you can count this as a vehemently oppose. — Jkudlick • t • c • s 14:44, 29 August 2016 (UTC)I missed the hidden section where it was stated that any modifications to Twinkle would take place in a separate RFC. I will readdress my concerns there if/when it occurs. — Jkudlick • t • c • s 15:01, 29 August 2016 (UTC)- Support the basic concept of restricting the "patrolled" checkbox to users who demonstrate a certain threshold of competence. That said, I have qualms about almost everything else about this proposal. I have never used Twinkle, so I have no opinion about that, but the fact that so many people who do use it are having conniptions tells me this proposal was poorly-thought out. Moreover, many parts of the proposal are vague and abstract, with a "we'll figure it out later" vibe. This RFC seems to be aiming for a consensus on the basic idea, which I support, but it might have been a better idea to come forth with a more through plan to alleviate confusion. ~ ONUnicorn(Talk|Contribs)problem solving 14:59, 29 August 2016 (UTC)
- Support the idea that NPPrs should have some minimum qualifications. Obviously admins could confer or rescind the right to do that. Withhold support for any particular implementation. Withhold support for any particular set of qualifications, but would support automatic right for EC users.Constant314 (talk) 15:48, 29 August 2016 (UTC)
- Support NPP is one of our most important functions, and yet we currently allow anyone to do it, without any qualifications, without any training, without any supervision. My only hesitation would be to ask if enough people will apply for the new user right and actually do new page patrolling? If not, the backlog could go from bad to overwhelming. Still, I think incompetent patrolling is worse than no patrolling at all, so I support this proposal. --MelanieN (talk) 16:10, 29 August 2016 (UTC)
- P.S. Do I understand that the Twinkle proposal would make it impossible to tag articles for CSD or PROD, or nominate them for deletion, unless the tagger has the New Page Patroller right? Or that it would still be possible, but only manually (without using Twinkle)? In either case I oppose that change. We come across articles all the time, outside of the NPP process, that should be deleted. People need to be able to do that without having a special permission. (I assume that admins like me would automatically be granted the right, but I am speaking for the thousands of competent regular editors, who may not want to bother applying for a new user right just so they can nominate articles for deletion.) --MelanieN (talk) 16:17, 29 August 2016 (UTC)
- In answer to your question, Twinkle does not allow a user to do anything they couldn't do manually. Manual CSD is easy, prod is pretty easy, AfD is a bit of a pain, and something newer users may screw up, but is totally possible as well if you can follow the directions. Monty845 19:19, 29 August 2016 (UTC)
- I have done all of the above manually, but it is a pain in the you-know-what. Forcing everyone who doesn't apply for this new user right to go back to manual tagging - that is pretty much a non-starter in my view. --MelanieN (talk) 17:54, 30 August 2016 (UTC)
- In answer to your question, Twinkle does not allow a user to do anything they couldn't do manually. Manual CSD is easy, prod is pretty easy, AfD is a bit of a pain, and something newer users may screw up, but is totally possible as well if you can follow the directions. Monty845 19:19, 29 August 2016 (UTC)
- P.S. Do I understand that the Twinkle proposal would make it impossible to tag articles for CSD or PROD, or nominate them for deletion, unless the tagger has the New Page Patroller right? Or that it would still be possible, but only manually (without using Twinkle)? In either case I oppose that change. We come across articles all the time, outside of the NPP process, that should be deleted. People need to be able to do that without having a special permission. (I assume that admins like me would automatically be granted the right, but I am speaking for the thousands of competent regular editors, who may not want to bother applying for a new user right just so they can nominate articles for deletion.) --MelanieN (talk) 16:17, 29 August 2016 (UTC)
- support Jianhui67 T★C 18:04, 29 August 2016 (UTC)
- Strongly support the first part (Tech. changes 1–4); oppose the second part (Tech. changes 5–8). The first part of this – requiring a minimum level of competence/time-on-the-project for NPP is of vital importance. I do this acknowledging some of Opabinia regalis' points; but even if she's correct with her #4, so what? – bad NPP'ers are still maiming this process, and even if experienced editors don't rush to fill the void of kicking the no0bs to the curb, this proposal is still worth doing... However, I join nearly everyone else in opposing the Twinkle part of the proposal – that part needs to be dropped from the proposal/RfA, posthaste, and either reformulated as a later separate, add-on proposal, or just dropped in its entirety. Frankly, converting Twinkle access to something like AWB access (i.e. requiring permission to use them) would be a better idea than what is proposed here... --IJBall (contribs • talk) 19:05, 29 August 2016 (UTC)
- Weak Support– I think the Foundation severely overestimated any chilling effect ACTRIAL would have had on new editor retention, and I don't think their research supported their estimation. Obviously, page creation is where the main problem lies, not page patrol, but at the very least this proposal will prevent sockfarms from patrolling their own articles. I'm not convinced of the rationale in its entirely, per OR below, but I think this is a positive step to take. Even I can see that there's consensus here to leave Twinkle alone so I won't include that as a condition to my support. Are extendedconfirmed users automatically granted the patrol right? I think applying for it is a bit much. If this proposal fails, can we transclude the entire text (or at least the scary templates and lead paragraph) of WP:NPP to the top of Special:NewPages? I think most newbie patrollers, for all their incompetence, are acting in good faith, and might not be seeing those warnings. Snuge purveyor (talk) 20:10, 29 August 2016 (UTC)
- Support. I only have AfC experience, not NPP experience, but I've seen what happens when an inexperienced reviewer gets in a dialogue with a new author (at one point, I was even that inexperienced reviewer). Enterprisey (talk!) (formerly APerson) 20:13, 29 August 2016 (UTC)
- Weak support: I like the idea of a 90/500 requirement, but I don't think that Twinkle should be restricted only to people with the userright. I think the userright could come with a new button or allowing the "mark as patrolled" link turn up. In concept, I sometimes wonder if a small bundled toolset could be automatic at 90/500 or 90/1000, of which this could be part. Montanabw(talk) 22:30, 29 August 2016 (UTC)
- Very weak support: I like this idea in general of having a requirement, but users should be automatically added into this userright if they reach this boundary, instead of making people applying to them. I do not support restrictions on Twinkle if users are not automatically added, however. Ueutyi (talk) 01:02, 30 August 2016 (UTC)
- Strong support for creating a Patroller user right restricting the ability to mark an article as patrolled. This is a hard need to protect the integrity of the encyclopedia. The reservations many of the opposers have regarding bundling CSD are heard, and seem reasonable. I recommend striking that portion of the proposal as a related, but less critical, issue. VQuakr (talk) 04:30, 30 August 2016 (UTC)
- Support Some articles never get far past NPP, be it through authors being scared off by biters, or pages being deleted for various reasons. Yes there are tons of legitimate things that don't belong on Wikipedia that NPP finds, but newer editors looking to contribute to the project may not necessarily understand AGF and the like yet, so this is why we need this check. As to the Twinkle bits, I will wait for that RFC. RegistryKey(RegEdit) 05:57, 30 August 2016 (UTC)
- Support, along with desire for Twinkle to be able to UNpatrol pages, and seeing some overlap (grandfathering?) with Autopatrolled. Generally supportive of Kudpung's longstanding efforts to improve NPP. Cabayi (talk) 13:54, 30 August 2016 (UTC)
- Support I have been occassionally patrolling pages recently, and the its been really sad to see a number of potentially good articles and contributors get bitten by folks who don't understand the growth of articles, and their potentiality. This is not a place to be drawing inexperienced editors in, and is as Orangemoody demonstrates, actually could have very detrimental effects on the community. I am against restricting how Twinkle is used for deletion tagging, however -- it makes the processes much, much, much more reasonable for folks who don't want to dive into template gobbly gook, Sadads (talk) 14:59, 30 August 2016 (UTC)
- Support due to both the BITE potential and the potential to let slip in content that should not be here, NPP requires a certain level of experience/competence. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 19:49, 30 August 2016 (UTC)
- Support understanding that there will be further discussion of specifics. - Reidgreg (talk) 20:38, 30 August 2016 (UTC)
- Support - This sounds like a very reasonable proposal indeed. There needs to be a balance between removing inappropriate new content on Wikipedia and biting any honest newbies. Note: I have never used Twinkle (or really much of any other automated editing programs beyond ones that specifically help with reference formatting), so I can't comment on the potential impacts to those kind of tools by this proposal. Guy1890 (talk) 20:59, 30 August 2016 (UTC)
- Support This proposal is an improvement over where we currently stand. I'm sure it can be improved further but we need to start somewhere. I don't assume this will help NPP backlog problems. I'd rather have a bunch of pages marked as unpatrolled than have a few pages incorrectly marked as patrolled. ~Kvng (talk) 21:19, 30 August 2016 (UTC)
Supportchanging vote to oppose as I no longer believe this is the right means of creating a revocable user right, though I still support that aspect Innisfree987 (talk) 20:28, 17 September 2016 (UTC) as to the establishment of revocable user right; neutral on Twinkle as I have zero experience with it. On the user right, the fact is I don't quite share the perception that new users are wreaking so much havoc (I understand how they could, I just haven't witnessed it particularly), but I have seen users at a variety of levels of experience recurrently conducting patrols in an unconstructive way, and I think it'd be very helpful to have an simple manner of putting a stop to that. That there were 40 people removed from AfC this year but none could be removed from NPP seems like something to be rectified. Innisfree987 (talk) 23:39, 30 August 2016 (UTC)- Support with the exception perhaps of any immediate changes to Twinkle - there appear to be some valid explanations why this might possibly not be such a good suggestions; indeed, as DGG states: 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. The opposition appears (at least on first sight) to come possibly from users who would easily get the right if they asked for it or who are admins or even highly influential members of Arbcom, who are possibly not fully aware of the full extent that uncontrolled patrolling is damaging the reputation of Wikipedia on the one hand, and discouraging good-faith new editors on the other. WP:AfC which, as those who have taken trouble to read the RfC preamble, demands at least 90/500 plus demonstrable experience and the performance of the reviewers is heavily monitored by their peers. I fail to see why NPP should require any less competence and/or would not need to be controlled. .Kudpung กุดผึ้ง (talk) 02:59, 31 August 2016 (UTC)
- To this point, I'll add I was actually surprised to learn via the preamble that NPP didn't already require 90/500; the instructions refer to 90/500 and make the comparison to AfC, and have for more than a year without drawing any controversy I could locate (if someone knows otherwise please correct me). Doesn't seem especially radical (and by contrast, rather helpful) to formalize that benchmark. Innisfree987 (talk) 04:53, 31 August 2016 (UTC)
- Support Numerous articles I've created have been patrolled by completely inexperienced editors who shouldn't be involved in NPP without a certain level of understanding re. policies; potential for problematic patrolling. Cloudchased (talk) 03:00, 31 August 2016 (UTC)
- Support as per above at least this will stop misuse of NPP. I also want to add that newly created pages become patrolled automatically when we add any tag using Page Curation so it will be great if we can fix that as well. GSS (talk) 11:37, 31 August 2016 (UTC)
- Qualified support I generally think it would be a good idea to have some basic requirements for editors doing new page patrol. However, I worry that these requirements will be too strict. I also absolutely oppose limiting the functionality of Twinke. It has many uses outside NPP. Happy Squirrel (talk) 17:15, 31 August 2016 (UTC)
- Support - this is an obvious control mechanism that has been sorely missing from the project, and is present on most other similarly important tools whose proper use requires relatively experienced users. ‑Scottywong| yak _ 21:28, 31 August 2016 (UTC)
- Strong Support We can't keep letting incompetent editors to let incorrect material pass by. It defeats the whole purpose of having a New Pages Patrol in the first place! FiendYT ★ 03:13, 1 September 2016 (UTC)
- Support. I understand the concerns around the proposed Twinkle restrictions, and perhaps that should be a separate discussion. But there is a strong case for NPP being a user right and I support that proposal. WaggersTALK 14:40, 1 September 2016 (UTC)
- Support This makes a lot of sense to me. NPP requires knowledge of a lot of different WP policies and is an important feature that protects the project from a wide variety of inappropriate pages. I've come a cross a few approved pages that should have been tagged or marked for deletion. Most reviewers do a great job so this only would affect a relatively minor subset of users, so I don't anticipate this hurting the backlog, which anyways is a less important concern than protecting from other issues inherent in new articles. FuriouslySerene (talk) 14:56, 1 September 2016 (UTC)
- Support w/ comment (agree with editors #12, 23, + 36 above) - This is one solution to a problem that is difficult to control. I don't know if it's the best possible one, but it seems viable and I've never come across something better. My only concern is that it might actually allow more inappropriate pages to be created, since fewer editors will be able to do anything about them. I wholeheartedly agree with the underlying idea, though: making sure thinking editors dedicated to making Wikipedia a better encyclopedia are the ones performing edits, at every step of the process. Perhaps there could be some sort of mentorship program for new editors wishing to get this right, but with little experience? -- 2ReinreB2 (talk) 21:50, 1 September 2016 (UTC)
- Support, but I have a comment to make. Rather than making people request this right like they have to request Autopatrolled or whatever, could it automatically be given to all editors with say, 5,000 edits or more? Surely somebody with that many contribs would be reliable enough to use it. That would also hopefully keep the backlog from getting too huge. White Arabian Filly Neigh 01:13, 2 September 2016 (UTC)
- The existing rights system supports that, just like how extended-confirmed is set up (automatically on 500/30; may be revoked by admins, may be granted by admins) - so it could be by application and by automatic criteria (need to be defined in terms of #of edits and/or length of account) if there were support for such a setting. — xaosflux Talk 02:36, 3 September 2016 (UTC)
- Support. I've seen some crazy-ass new-page patrolling. Softlavender (talk) 10:17, 2 September 2016 (UTC)
- Support per Esquivalience. Yintan 22:30, 2 September 2016 (UTC)
- Support although most NPP are very hardworking and do a great job there are a few who seem to be on a power–trip and like to bully new editors for example bombtagging, inappropriate csd and replacing prods that have been removed by the creators, removing cited content and even removing all references ( including reliable sources) before asking for deletion. I think this proposal will hopefully reduce those sort of antics. Atlantic306 (talk) 03:39, 3 September 2016 (UTC)
- Support. Inexperienced editors that harass experienced editors is the main Wikipedia problem. --Chris.urs-o (talk) 18:06, 4 September 2016 (UTC)
- Support — I am somewhat inexperienced in policy matters and don't look at many new pages, despite how Wiki-old (if that's a word) I am. I'm astonished new editors are allowed to serve as gatekeepers for new pages. That makes no sense. Skeptical of the Twinkle restrictions idea, but I only just started using Twinkle (!), so I don't have much to say on that. — Eru·tuon 06:45, 5 September 2016 (UTC)
- Support — I've done a bit of this and it can be hard work. Stuartyeates (talk) 08:16, 5 September 2016 (UTC)
- Support — per the above. (I do not support removing any Twinkle functionality as that tool is used in a broader context than just NPP.) Etamni | ✉ | ✓ 13:50, 5 September 2016 (UTC)
- Support This addresses a gaping hole that too many problematic patrollers have found or fallen into. Meters (talk) 18:57, 5 September 2016 (UTC)
- Support New Page Patrol requires skill, familiarity with Wikipedia policy, and good judgement. New page patrolling requires enough self awareness to skip pages outside the patrollers competency. At a minimum, New Page Patrolling should be a right granted only after a certain level of experience on Wikipedia is reached. (I just tried new page patrolling for the first time, over the past week. I read over two hundred new pages, but felt comfortable in marking only a few dozen; a handful with speedy tags, a dozen with clean-up tags...) — Neonorange (talk) 10:09, 6 September 2016 (UTC)
- A good point about knowing-when-to-be-silent. It is also an area where enhancing the Page Curation tool could assist, for example allowing the reader who declines to Patrol (as for example I do for articles I see are about Baseball or Idol Band people) to allocate the article to a pull-down of WikiProjects, thus structuring the backlog data to allow a second person with area knowledge to complete the Patrol. AllyD (talk) 18:32, 6 September 2016 (UTC)
- Support sloppy deletion tagging is a huge problem and loses us a lot of newbies. Re the lapsing of the userright, 24 months rather than 12 would bring it into line with adminship ϢereSpielChequers 18:04, 6 September 2016 (UTC)
- Support with conditions 1) Don't touch Twinkle (for reasons already stated by many); 2) Must be automatic at a reasonable threshold (90/500). re my #2, the last thing we want to do is have people apply for this right (unless they don't yet meet the threshold) as this would unnecessarily restrict the pool of folks doing the work. If someone can't do NPP after 90/500, something is wrong. But certainly, an admin should be able to grant the right to anyone before they reach the threshold, given their presumed good judgment on an editor who has demonstrated proper experience. Also, certainly, users misusing this right can have it stripped per the proposal. Overall this is a sound proposal. Stevie is the man! Talk • Work 18:35, 6 September 2016 (UTC)
- Also, 3) No lapsing. If one has editing knowledge in the Wikipedia, how does that go away just because someone has taken a long break? Stevie is the man! Talk • Work 18:49, 6 September 2016 (UTC)
- Support I don't really think of myself as a new pages patroller as I am not very experienced, but I look at new pages and sometimes fix small errors. However, I will agree with many above that changing Twinkle doesn't seem like a good idea to me, mainly because it seems to mostly serve as a convenience tool (removing the features from the tool wouldn't stop someone from placing tags or otherwise making changes, it would just make it more difficult), and it has many applications outside of New Page Patrolling. Otherwise, I have personally tried to make edits to new pages in something similar to a patrol capacity, but found out that it takes more experience to do it effectively, so I think that this is a good idea. Gluons12 talk 19:40, 6 September 2016 (UTC).
- I've tagged over 6000 pages for CSD. I've closely followed the development of this and have offered some of my own data-driven findings and proposals. I can't disagree with anything and I'm glad that at last we're seeing some sorely needed change. →Σσς. (Sigma) 01:28, 10 September 2016 (UTC)
- Support to prevent occasional chaos made from mispatrols. However, since one can also tag CSD, AfD, and PROD manually, Twinkle restrictions should not be established. The only restriction that should be applied to TW is that it will not automatically patrol pages unless you have the (patrol) right. NasssaNser 08:10, 17 September 2016 (UTC)
- Strong Support This is sorely needed. Inexperienced users need to be prevented from patrolling pages so that new articles with issues are properly deleted or tagged for improvement. Inexperienced users are more likely to incorrectly tag new pages, which can be harmful to new editors who we need to retain, especially with respect to incorrect CSDs. It will also put up a barrier to paid editors like Orangemoody. No, it won't be able to entirely contain the problem, but it is better than what we have now – nothing. Yes, the backlog could increase even more, but it is better to have articles properly patrolled than to have a smaller backlog. NPP is our front-line defense against articles that don't meet our content requirements, so it needs to be done by editors with experience. I've seen some comments about an automatic user group versus one that will get admin review at PERM. I think admin review at PERM is necessary or it will be more likely that paid editors and inexperienced users who meet the required number of edits and account age requirements but are not sufficiently versed in our policies and guidelines end up patrolling new articles, which is what we don't want. While I don't agree with the proposed Twinkle restrictions, that isn't important in this RFC. Some Twinkle restrictions may be needed, but that is a discussion for another time. If Twinkle functionality is restricted, I'm sure it will be forked. — JJMC89 (T·C) 18:24, 18 September 2016 (UTC)
- Support - This seems like a good one. I gotta admit that I also have NPP problem before because I was lack of NPP experience that time, leading me to "not-very-good-faith" edits. But I don't really think changing the Twinkle options is a good idea. Per some others, the user can just add in the template easily. And also Twinkle is only for autoconfirmed users only, so no worries about it too much. NgYShung huh? 15:59, 27 September 2016 (UTC)
Oppose
[edit]- 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)
- 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!" KGirlTrucker81 talk what I'm been doing 14:56, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- @AllyD: Yeah, then you would have to CSD, PROD, AFD it by manually taging it which also a waste of my time. KGirlTrucker81 talk what I'm been doing 17:53, 28 August 2016 (UTC)
- 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)
- For clarification, I am against restricting Twinkle. Won't help at all. Peridon (talk) 09:17, 29 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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))
- 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)
- For lack of a better place to put it, just adding a link here to a thread on my talk page that has grown out of this comment, involving batting some other ideas around on better new-article management. Opabinia regalis (talk) 01:32, 8 September 2016 (UTC)
- I'd like to understand how you get to strong oppose just by poking holes in someone else's good-faith proposal to fix a perceived problem. You've offered no compelling evidence that a/ the problem doesn't exist or b/ the proposal would not be an improvement over where we now stand. Your statement sounds well reasoned but it seems to boil down to WP:IDONTLIKEIT. ~Kvng (talk) 21:14, 30 August 2016 (UTC)
- Their !vote clearly doesn't fall into that category. Your support !vote is much closer to an WP:ILIKEIT than theirs is to the converse.—Godsy(TALKCONT) 21:38, 30 August 2016 (UTC)
- Fair enough but I'd still like to see a reason for opposing the idea, not just a deconstruction of the proposal. ~Kvng (talk) 23:09, 30 August 2016 (UTC)
- Everyone is entitled to their opinion on an RfC, provided of course in the best case scenario, that theit comments are objctive and based on an understanding of the mater under discussion. I am therefore at a loss to understand Opabinia regalis who while recognising that 'this identifies a serious issue facing the project does not feel it personally to be so, criticises the research and preparation of proposals being carried out by small groups, particularly where most of her work on Wikipedia is carried out in utmost secrecy and reaches decisions over which we less privileged editors are not allowed to exert any influence. Perhps she simply regrets not having been specifically invited to be part of the NPP reform team - she could have been of course and her amazing talents for rapidly compiling statitics and charts would have been highly appreciated. Kudpung กุดผึ้ง (talk) 01:28, 31 August 2016 (UTC)
- "Something must be done; this is something; therefore this must be done." ;)
- Poking holes in arguments (including my own) and finding which parts are in need of better evidence is a major component of my real-life work. It's not personal criticism. The fact that there are serious issues that need to be addressed is not an argument in favor of this specific approach to addressing them. If I were in your shoes, I'd go back to the drawing board and start by gathering the relevant evidence - from the current proposal I get the sense that you had an idea, decided it was a good idea, and then went to look for evidence in support of it. That tends to lead to untested assumptions making their way into the final product. For example, as I posted somewhere below, I think the people here talking about Twinkle are somewhat missing the point of your proposal, but I also think it's clear from their reactions that you need to do some more thinking about implementation and workflow. If you look at the "influx" to each deletion process, how many of those articles are recent enough to have been nominated by a dedicated new page patroller and how many were identified some other way? As another example, there are plenty of kinks to be worked out in the new ORES system, but perhaps a similar classification could be applied to new articles in order to prioritize the high-risk ones for review.)
- As for the "NPP reform team", I would've said no thanks, I'm already short on time as it is :) But then, I can't seem to find anything about this "team" on-wiki, and I think I remember comments about meeting in person - at Wikimania, maybe? - which isn't really my thing, since I prefer to keep my internet hobbies mostly on the internet. (But I could be wrong - is the "team" the group of people you notified? That's not really such a small group...) Opabinia regalis (talk) 20:27, 31 August 2016 (UTC)
- I was notified (accidentally, after I already gave my opinion here) but have no relation to the team (I am not even sure it exists). I guess I was notified because I am doing NPP on a regular basis and understand typical problems with NPP - in contrast to some other voters here.--Ymblanter (talk) 07:58, 1 September 2016 (UTC)
- Everyone is entitled to their opinion on an RfC, provided of course in the best case scenario, that theit comments are objctive and based on an understanding of the mater under discussion. I am therefore at a loss to understand Opabinia regalis who while recognising that 'this identifies a serious issue facing the project does not feel it personally to be so, criticises the research and preparation of proposals being carried out by small groups, particularly where most of her work on Wikipedia is carried out in utmost secrecy and reaches decisions over which we less privileged editors are not allowed to exert any influence. Perhps she simply regrets not having been specifically invited to be part of the NPP reform team - she could have been of course and her amazing talents for rapidly compiling statitics and charts would have been highly appreciated. Kudpung กุดผึ้ง (talk) 01:28, 31 August 2016 (UTC)
- Fair enough but I'd still like to see a reason for opposing the idea, not just a deconstruction of the proposal. ~Kvng (talk) 23:09, 30 August 2016 (UTC)
- Their !vote clearly doesn't fall into that category. Your support !vote is much closer to an WP:ILIKEIT than theirs is to the converse.—Godsy(TALKCONT) 21:38, 30 August 2016 (UTC)
- Oppose per Opabinia regalis. I will write more about Twinkle in the comments section. BethNaught (talk) 08:23, 29 August 2016 (UTC)
- Oppose per Majora. --Wario-Man (talk) 08:35, 29 August 2016 (UTC)
- 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. --Begoon talk 09:00, 29 August 2016 (UTC)
- 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)
- Oppose All nominations for speedy are reviewed by an admin anyway, and I expect that erroneously nominating and having the error explained by the rejecting admin is likely an important initiation ceremony for patrollers. So there's no problem there.
- Conversely, erroneously reviewing an article that is grossly out-of-line with policy is a different and more serious issue, and seemingly the particular one this is intended to address. A simpler and less burdensome solution, if we're trying to think outside the box, would seem to be the creation of an auto-confirmed reviewer group, dividing patrollers into two groups based number of correctly reviewed articles (ignoring CSD nominated ones as irrelevant) .
- New reviewer group: New patrollers do not review articles; instead they semi-review them. That review is then confirmed by an experienced user (not necessarily an admin). Users with X number of correctly reviewed articles are auto-confirmed into the next group.
- Auto-confirmed reviewer: These users wouldn't necessarily need to see any change in functionality. Some of the articles they review will have been previously semi-reviewed by newbies. If they agree, it adds to the newbie's "good job" count toward auto-confirmation. If they disagree and nominate for speedy, a notification would also be automatically posted on the newbie's talk, so they can try to adjust their reviewing accordingly.
- This would add no additional burden on admins. It would add some level of hidden burden to reviewers (articles which now have to be systematically reviewed twice), but would ensure that 100% of decisions made by a new reviewers would be vetted, either by an admin (CSD nomination) or by an experienced patroller (semi-reviewed). It would also ensure that the reliability of patrollers is based on the most important metric: how reliable they actually are in their patrolling, rather than somewhat more subjective assessment of their experience level by the permission granting admin.
- Alternatively, a full semi-reviewed icon/status could be added (say, a yellow semi-reviewed check box in curation). This could notify auto-confirmed reveiwers that additional guidance may be needed if they find a gross error. This could also make possible a semi-reviewed filter, for those who only want to see, or do not want to see new articles that have been semi-reviewed. TimothyJosephWood
- @Timothyjosephwood: how would these alternatives protect against future Orangemoody-type attacks? VQuakr (talk) 04:58, 30 August 2016 (UTC)
- Any solution offered is going to be a balance between ratcheting up the inconvenience of gaming the system, against the inconvenience of good faith editors. Anyone who wants to engage in malicious incognito reviewing is at least going to have to go through the trouble of 1) achieving the requirement for semi-review (be that auto-confirmed or 30/500), and then 2) achieving the requirement for auto-confirmed-reviewer (X number of correct reviewing decisions).
- We could also, I'm sure, add in some requirement for overall accuracy, and not just amassing correct decisions, for example, so that one could not simply review 300 articles, with the expectation that 100 of them would be confirmed, thus reaching the threshold. Instead one would have to reach X number of correct decisions, along with Y accuracy measured in some way. Alternatively, or in concert, we could add a longevity requirement similar to 30/500.
- Obviously someone who is determined to game the system could satisfy these requirements given enough effort. But, like a locking door with a window, the medium level deterrent may likely be enough to dissuade the majority of would-be nefarious actors. TimothyJosephWood 12:09, 30 August 2016 (UTC)
- @Timothyjosephwood: how would these alternatives protect against future Orangemoody-type attacks? VQuakr (talk) 04:58, 30 August 2016 (UTC)
- Conversely, erroneously reviewing an article that is grossly out-of-line with policy is a different and more serious issue, and seemingly the particular one this is intended to address. A simpler and less burdensome solution, if we're trying to think outside the box, would seem to be the creation of an auto-confirmed reviewer group, dividing patrollers into two groups based number of correctly reviewed articles (ignoring CSD nominated ones as irrelevant) .
- Oppose per OR. shoy (reactions) 14:34, 29 August 2016 (UTC)
- Per OR's point 2, I haven't seen the RFC presenters offer any evidence that this proposal would address the problem of WP:BITE. shoy (reactions) 16:56, 29 August 2016 (UTC)
- For what it's worth, BITE is why I like at least the concept of a revocable user right
my main reason for supporting my mainly favorable view of this proposal(adding reservation in comments Innisfree987 (talk) 17:26, 1 September 2016 (UTC) and as oppose vote Innisfree987 (talk) 15:29, 18 September 2016 (UTC) ); it seems to me that the revocation criteria (specifically item #2) for any admin to remove a reviewer from the NPP user right group will would make it much, much easier to address any such problems. Have read a bunch of related ANIs lately (including the ones OR cited in point 2) and things really seem to be breaking down in terms of resolving such issues promptly and constructively through that mechanism. This portion seems like a very welcome alternative. Innisfree987 (talk) 04:24, 1 September 2016 (UTC)
- For what it's worth, BITE is why I like at least the concept of a revocable user right
- Per OR's point 2, I haven't seen the RFC presenters offer any evidence that this proposal would address the problem of WP:BITE. shoy (reactions) 16:56, 29 August 2016 (UTC)
- Oppose but only because of the Twinkle restrictions. The only restrictions required is access to new pages feed and the mark as patrolled button. We don't need to restrict anything else.
- Oppose I use Twinkle for CSD, etc. and I sometimes do NPP as well. I don't think Twinkle has anything to do with NPP and people who use Twinkle for CSD,AFD, will be left in the lurch. I am also curious about the terms required for NPP. I don't have a clean block log but that is to be expected with being here for over 10 years. Does that mean I can't patrol? Sir Joseph (talk) 17:35, 29 August 2016 (UTC)
- Oppose in the strongest possible way until the Twinkle restrictions are entirely dropped. I don't want to pave the way for removing these options from non-reviewers. I would support without the Twinkle restrictions. ~ Rob13Talk 17:43, 29 August 2016 (UTC)
- Oppose. What a stupid proposal! Just to prevent all users except a small number of patrollers from using any automation when nominating pages for deletion? Are you serious? Moreover no attempt has been made to notify all users (possibly thousands) that currently utilize these scripts. It seems that the authors of the proposal just want to perform a fait accompli before any users have a chance to understand what they going to lose. Ruslik_Zero 18:35, 29 August 2016 (UTC)
- Strong Oppose NPP is difficult, thankless volunteer work. It's certainly hard enough without them another hoop to have to jump through. Andrew Lenahan - Starblind 19:06, 29 August 2016 (UTC)
- Oppose Fully explaining my POV would take a couple of days so I'll just vote per Starblind. (((The Quixotic Potato))) (talk) 22:13, 29 August 2016 (UTC)
- Oppose As proposed, this doesn't seem workable. If access to Twinkle is restricted, then people will just start constructing workarounds. Andrew D. (talk) 22:44, 29 August 2016 (UTC)
- Oppose no reason why use of Twinkle should be restricted. Do any new page patrollers actually use Page Curation anyway? SSTflyer 03:58, 30 August 2016 (UTC)
- Yes, they do. IMO since it came in, the standard of patrolling has dropped, but I can't produce any statistics to prove it. Could be personal bias, as I found it quite horrible when I tried it. Once again IMO. PC's use of db-significance rather than db-a7 or another specific criterion is misleading. It seems to imply lack of significance applies to anything. Peridon (talk) 08:21, 30 August 2016 (UTC)
- I agree that PageCuration is under-featured, both if one wants to maintain a CSD log and in explaining to the contributor on why their page has been tagged for speedy-deletion. Coincidentally, I CSDed with Twinkle at the same time as another user with PageCuration this morning: this User Talk page shows significantly different levels of information, with Twinkle much superior. So I use Twinkle rather than PageCuration for Patrol+CSD, which activity is missing from the RFC data, significantly understating NPP activity by longstanding users, as I've commented below. AllyD (talk) 08:43, 30 August 2016 (UTC)
- Yes, they do. IMO since it came in, the standard of patrolling has dropped, but I can't produce any statistics to prove it. Could be personal bias, as I found it quite horrible when I tried it. Once again IMO. PC's use of db-significance rather than db-a7 or another specific criterion is misleading. It seems to imply lack of significance applies to anything. Peridon (talk) 08:21, 30 August 2016 (UTC)
- Oppose per Opabinia regalis. I'm most concerned about the biting of NPP, and I don't see this as being particularly solvent for that. The Twinkle restrictions, as others have said, are throwing the baby out with the bath water, and this whole proposal advocates for an added level of bureaucracy that it doesn't really justify. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 15:02, 30 August 2016 (UTC)
- Oppose At a time when Wikipedia struggles with attracting active editors (File:Highly_active_editor_graph.png) it seems baffling we'd try to push people away. Despite the amount of people who maybe make bad reviews imposing a restriction would be a net negative. Same goes for restricting Twinkle. Pinguinn 🐧 16:15, 30 August 2016 (UTC)
- I see on WT:NPP the backlog now stands at an all time high of 13,158 unreviewed pages but yet not more than a couple sentences down is the urging that NPP should be restricted to a small subset of editors only. So the solution to a growing backlog is less editors handling it? To quote Charles Babbage, "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question". Pinguinn 🐧 16:56, 30 August 2016 (UTC)
- An incompetent or malicious patrol is worse than one not yet done and sitting in the queue. VQuakr (talk) 19:23, 30 August 2016 (UTC)
- @Pinguinn: A backlog does not mean that we delegate the work to newer editors. Quality is what matters. See Orangemoody, where hundreds of accounts, due to our granting of patrol rights to every Tweedledee and Tweedledum, held businesses' articles for ransom. And we still grant the right to patrol articles to editors with ten edits! What's worse than a growing backlog is a proliferation of irredeemable articles into mainspace—our readers rightfully give no whits about whatever backlog we have and the few thousand bad but obscure articles there may be; they care about the quality of our content and patrolling. — Esquivalience (talk) 19:44, 30 August 2016 (UTC)
- I see on WT:NPP the backlog now stands at an all time high of 13,158 unreviewed pages but yet not more than a couple sentences down is the urging that NPP should be restricted to a small subset of editors only. So the solution to a growing backlog is less editors handling it? To quote Charles Babbage, "I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question". Pinguinn 🐧 16:56, 30 August 2016 (UTC)
- Oppose - With all of the bureaucratic scope creep and increasing amount of restrictions you want to put on users, why don't you just get rid of the volunteer aspect of Wikipedia and hire professional editors? Supposedly Wikipedia is dying because not enough people are willing to do tedious tasks, but you want to make it even more difficult. This proposal flies in the face of the open-editing and volunteer ideal and seeing as how Wikipedia has existed just fine for 10+ years without making NPP a special "user right" (in other words, a hat for a Wiki politician to collect). GigglesnortHotel (talk) 20:14, 30 August 2016 (UTC)
- Strong Oppose Why is it that every time that some crisis of our own design comes up on this site the immediate reaction is to make it even harder to address by levying new restrictions, creating new rights, disallowing editor and contributor participation, etc? Wikipedia is a dying project, dying precisely due to the fact that it is no longer free and open for anyone to edit, and decisions of this nature only severe to exacerbate the issue by adding quality fuel to an already eternally burning flame. For God's sake just let us voluntarily contribute like we did on the old days, otherwise your going to subdivide everyone so much that each person is going to be island nation unto themselves. TomStar81 (Talk) 22:08, 30 August 2016 (UTC)
- Oppose. I do NPP once in a while, but I use Twinkle routinely for AfD/CSD/templating purposes. There's no reason to jack up Twinkle for this purpose. Niteshift36 (talk) 00:48, 31 August 2016 (UTC)
- oppose NPP was one of the first activities I participated in when I started to contribute more frequently, recently I have began to focus on it, and I was just made aware of this RfC, thanks to my watchlist. I was accused of biting the newcomers when I began doing it, but now I understand the consequences, so 1: I believe that new contributors should be given a chance to participate in NPP, this was a great learning experience for me 4 years ago. 2: The modifications to Twinkle will be a problem for regulars at XfD like me, even if we need another RfC for that. I would not support it without the Twinkle restrictions. Best regards, - Champion (talk) (contribs) (Formerly TheChampionMan1234) 11:53, 30 August 2016 (UTC)
- I know I'm not going to say now anything that adds to the discussion, but I simply can't resist wondering if you realise that your
great learning experience
might have resulted in many potential contributors being turned away from the project. Uanfala (talk) 14:00, 30 August 2016 (UTC)- @Champion: You might want to move this up to the oppose section. Best Regards,—Godsy(TALKCONT) 20:46, 30 August 2016 (UTC)
- @Godsy:
Done - Champion (talk) (contribs) (Formerly TheChampionMan1234) 05:31, 31 August 2016 (UTC)
- Adjusted —Godsy(TALKCONT) 05:44, 31 August 2016 (UTC)
- @Godsy:
- @Champion: You might want to move this up to the oppose section. Best Regards,—Godsy(TALKCONT) 20:46, 30 August 2016 (UTC)
- I know I'm not going to say now anything that adds to the discussion, but I simply can't resist wondering if you realise that your
- Oppose. As someone who has recently started NPP, I have made the occasional bad judgment call, and have been advised accordingly. The way to help newbies like myself is NOT to give us hoops to jump through before we're allowed to volunteer our time and efforts. Apart from anything else, I don't see that this will stop anyone who wants to from adding tags etc. manually. Killer Moff (talk) 12:18, 31 August 2016 (UTC)
- Killer Moff, for many newbie content contributors, a patroller is the gatekeeper to wikipedia and one ill-advised placement of a CSD tag, for example, creates pointless hoops for this newbie to jump through and leaves the impression that the environment here is incompetent, arbitrary and hostile. And this does drive people away. The stakes are simply too high to allow NPP to be a learning area. Uanfala (talk) 13:00, 31 August 2016 (UTC)
- Uanfala, perhaps I misspoke or wasn't clear. I was referring to newbie patrollers, not contributors. How can we learn to patrol without patrolling? And if anything, I've had more hostility from new contributors demanding I remove CSD tags from unreferenced BLPs and Company articles than other patrollers. Killer Moff (talk) 13:15, 31 August 2016 (UTC)
- You were perfectly clear, Killer Moff. My point was that for any single newbie patroller that we give free reign to learn as she goes, we are letting down a large number of newbie contributors. As for the hostility on part of editors who want their page here at all costs, I know that very well (I still receive death threats by email because of an AfD I started). But I was referring to something else: the inadvertent impression of hostility that newbie contributors are left with if a page of theirs is inappropriately tagged for deletion.
How can we learn to patrol without patrolling?
I don't think there is so much a specific skillset rather than a broad awareness of how aspects of wikipedia work, and that is learnt through contributing content, improving the encyclopedia in various ways, learning about what projects there are, participating in discussions (particularly at XfD's) etc. Of course, patrolling will inevitably involve learning on the go, but that should happen against an already existing background of experience. Uanfala (talk) 13:36, 31 August 2016 (UTC)
- You were perfectly clear, Killer Moff. My point was that for any single newbie patroller that we give free reign to learn as she goes, we are letting down a large number of newbie contributors. As for the hostility on part of editors who want their page here at all costs, I know that very well (I still receive death threats by email because of an AfD I started). But I was referring to something else: the inadvertent impression of hostility that newbie contributors are left with if a page of theirs is inappropriately tagged for deletion.
- Uanfala, perhaps I misspoke or wasn't clear. I was referring to newbie patrollers, not contributors. How can we learn to patrol without patrolling? And if anything, I've had more hostility from new contributors demanding I remove CSD tags from unreferenced BLPs and Company articles than other patrollers. Killer Moff (talk) 13:15, 31 August 2016 (UTC)
- Killer Moff, for many newbie content contributors, a patroller is the gatekeeper to wikipedia and one ill-advised placement of a CSD tag, for example, creates pointless hoops for this newbie to jump through and leaves the impression that the environment here is incompetent, arbitrary and hostile. And this does drive people away. The stakes are simply too high to allow NPP to be a learning area. Uanfala (talk) 13:00, 31 August 2016 (UTC)
- Oppose, as currently written, for two reasons. I do sympathize with the intent of the proposal, but I have two issues with it. The first one concerns the proposed restrictions to Twinkle, much discussed above. Second, I believe that if a "new page patroller" right is created, users should not have to apply for it, but rather the right should be granted automatically upon reaching a certain threshold (which can be set appropriately high). Otherwise you would be placing too much burden on many experienced editors who only perform NPP occasionally. Making them jump through extra bureaucratic hoops to get the new user-right is likely to discourage them from doing NPP altogether. Nsk92 (talk) 16:23, 2 September 2016 (UTC)
- Oppose per Opabinia regalis. Can't let this become something for hat collectors. JAGUAR 16:25, 2 September 2016 (UTC)
- Oppose - The idea is meritorious, but I have some issues with the specifics. First, the grandfather clause: Editors such as myself who use Twinkle and the new page feed, but not use the page curation tool, and who have reviewed thousands of pages would not be not be grandfathered in. As someone else mentioned, a user who has already made 5000+ edits probably be should grandfathered in as well. I don't see the utility in requiring users to have a clean block log, unless they were blocked for some reason related to new page patrol. I'm not in favor of restricting Twinkle as proposed, but I would not opposed to restricting it for users who have not met a certain threshold of main space edits. My observation is that if we simply prevented inexperienced new users from jumping into NPP, many of the problems would go away. Something along the lines of of requiring 'extended confirmed user' rights for page patrollers could address many of the issues, and be easier to implement and maintain.- MrX 19:02, 2 September 2016 (UTC)
- Oppose although I support in principle the idea of a bare minimum of competence for this task, I am against the proposed solution. Really if established editors are not interested in new page patrolling, implementing this will not lead to them taking up the task. If the only source of new blood interested in doing this job, are relative newbies, then any proposal should not be about dissauding them from patrolling but about building up their ability and competence. Write a better tutorial as to how to patrol, create a wizard, checklist or flowchart to guide them through the process. Choose an article to act as a standard to compare against, archive some failed articles to serve as negative examples of what an article should not be. Maybe someone could create a bot to part patrol a new article:- so many points for pages created by editors with a history of problem free article creation, more points for articles with incomimng and outgoing wikilinks (less likely to be a neologism}, more points if the title produces lots of ghits, negative points if blocks of text show up in google (likely copyvio}, compare blocks of text against any references given, present the bot results as ticks and crosses to help patrollers make up their minds. For longer articles allow the patrolling of sections by different patrollers, we expect and accept article creation as a community, why not article petrolling. If someone is willing to sign off on one section but is unsure of the others let them sign off on the section they are happy about, allow the article to pass once the majority of sections have passed. To get established editors to patrol would it be possible to use the new article bots o break the list into categories, for example new film article, aviation or train articles etc, could the bot then look for editors who have an interest in a particular subject and send them a message "Hi User:abcdef, there's a new ....... article, that you might be interested in patrolling" Please before erecting what will look like a wall to exclude new editors from participating please consider inclusive solutions.--KTo288 (talk) 00:16, 3 September 2016 (UTC)
- I strongly agree that established editors are more likely to get involved if patrolling is subject-specific. I'm wondering if this couldn't go hand in hand with the system for new article alerts (see User:InceptionBot). Uanfala (talk) 07:42, 3 September 2016 (UTC)
- I'm opposed to general restrictions on Twinkle. People might still do this without the NPP, and it makes sense to at least let them do it properly. -- Ajraddatz (talk) 15:33, 3 September 2016 (UTC)
- @Ajraddatz: that is not correct. Under this proposal, it would be impossible for editors lacking the patrol permission to mark a page as patrolled. VQuakr (talk) 19:55, 3 September 2016 (UTC)
- It is not possible for them to mark the page as patrolled, but they could still tag pages for deletion and such. If they are going to do that, better let them have the appropriate tools to ensure it is done properly instead. -- Ajraddatz (talk) 20:20, 5 September 2016 (UTC)
- @Ajraddatz: that is not correct. Under this proposal, it would be impossible for editors lacking the patrol permission to mark a page as patrolled. VQuakr (talk) 19:55, 3 September 2016 (UTC)
- Strong Oppose: Only users with a clean block log will be grandfathered in? How many users will be excluded because of a block from over five years ago? People should have "experience with moving pages"? What if you've just never encountered a page in need of moving? Even if requests for the patroller right didn't give much weight to that, the fact is excellent editors who have only moved a few pages will be unlikely to even make a request if they see that listed as a guideline for granting. With respect to #4 what exactly is a "behavioral block"? #1 states "Edits and/or user status on other Foundation projects are not taken into consideration", so an admin from the German Wikipedia who has been editing for eight years won't have that taken into consideration? And a criteria for revocation is "inactive for 12 months"? What changes so much after 12 months to warrant losing the ability to patrol pages?
Admins keep their tools after being inactive for 12 years.With respect to #4, no experienced editor does "blatant vandalism" except on April 1st, so all this criteria does is potentially give us a headache every April 1st. I don't see how someone could use the patroller right to "to gain the upper hand in disputes", and I don't see how the ability to patrol pages (which currently everyone possesses) is so sensitive as to warrant losing it for neglecting account security practices. Fundamentally though I'm opposed to this because there is no evidence that any of these granting criteria will weed out problematic patrollers, it seems as though it will just make the problematic patrollers wait longer until they can problematically patrol. I think a better solution would be having a bot locate potential problematic patrollers, put them on an a list visible only to admins for review, and allow admins to indef topic ban them from page patrolling if they violate certain criteria (with the ability to contest this topic ban). M. A. Bruhn (talk) 07:51, 6 September 2016 (UTC)- Re your "Admins keep their tools after being inactive for 12 years." Nowadays that's "Admins keep their tools after being inactive for up to 2 years." We have desysopped hundreds of admins under that rule since 2011. ϢereSpielChequers 08:14, 6 September 2016 (UTC)
- Thank you for the correction :) M. A. Bruhn (talk) 08:27, 6 September 2016 (UTC)
- Re your "Admins keep their tools after being inactive for 12 years." Nowadays that's "Admins keep their tools after being inactive for up to 2 years." We have desysopped hundreds of admins under that rule since 2011. ϢereSpielChequers 08:14, 6 September 2016 (UTC)
- Oppose. We do not need yet another user right. This is adding a new layer of bureaucracy and hoop-jumping. If there are people who are patrolling new pages in a problematic manner, they should be asked to stop. If they persist, they should be blocked for disruption. I accept that we need to improve the quality of new page patrolling, particularly to avoid biting well meaning new editors, but I don't think this is the solution. WJBscribe (talk) 22:36, 6 September 2016 (UTC)
- Oppose broadly along the lines of Opabinia regalis. Let me first off say that the problem Kudpung describes is very real and I have seen it myself enough times to know the poor communication with new users is a problem. However, in a voluntary project, people only flock to what is interesting or fun, and while I don't mind caretaking the odd new article (examples), I can't possibly do that for the flood of pages coming into NPP. The reason we have inexperienced / incompetent reviewers there is because those of us who do understand policy (I'll assume that since I have the tools that people assume I understand policy a bit) also, to paraphrase Donald Rumsfeld, know what we don't know and leave articles alone, leaving others to pick them up. We see this problem all over the place - it happens at AfC, DYK, GAN, ANI (unnecessary closing of ANI threads gets my goat in particular), everywhere outside the basic encyclopedia writing tasks. So while I fully appreciate that something must be done, I really don't think what's proposed on the table here is going to make much difference; in fact I'm sceptical enough to think nothing except paid customer service staff will make a serious dent in the problem. Consider the events at User talk:Ritchie333#IP editing experiment, I'm certain the editor who I was complaining about would be first in the queue for the new user right, yet equally be the sort of person we don't want on patrol (at least, not yet). Ritchie333 (talk) (cont) 09:30, 7 September 2016 (UTC)
- Strong Oppose. Generally I'm in favor of new user rights. They usually exist to make sure that the people who need a right have it, even if they are not cut out to be full admins. This seems more like it is intended to restrict things. I see why we need all the bureaucracy we have, but this goes to far. Not to mention the fact that it creates a bunch of new work for the admins. I'd be a lot more likely to consider it if you were talking about granting it automatically at some reasonably sized (500 edits-ish) threshold. The points that are made about needing certain privileges are probably valid, but that needs simplification and streamlining, not this... over-complication. Tamwin (talk) 00:23, 8 September 2016 (UTC)
- Oppose I've done thousands of speedy taggings patrolling new pages, and I've had literally a handful of declined nominations since I started years ago when I was new. Many of these pages are obvious spam, vandalism, A7, and test pages. Even the newest user could tag most of this stuff, and many do so properly. If they screw up, admins can decline the speedy and notify them. In the few cases where a new editor doing patrolling work is really doing it badly, an admin can pretty easily give guidance or even a warning/block if necessary. I don't see a real need for a new right. A good number of the newbies that're bitten are no loss for Wikipedia from what I've seen. They're usually here to spam or write about some tiny company that started up last week, or about themselves, or some guy who was a local big-shot, not to mention vandals and kids with too much time on their hands. INeverCry 03:35, 8 September 2016 (UTC)
- I would say it is far more likely than you might think that somebody writing "spam" about a company or "some guy" are simply seeing that other stuff exists on Wikipedia and think that following suit is acceptable as they have no reason to believe otherwise. Ritchie333 (talk) (cont) 12:45, 8 September 2016 (UTC)
- INeverCry, you're not the only one who has patrolled literally thousands of new pages - and it hasn't gone unnoticed. However, today's spammer is a professional PR person with an Ivy League degree in marketing or communication, and just like the SEO specialists will get your web site to Google's first page, takes big bucks for getting Wiki pages through the controls, creates dozens of socks to be able to patrol their own pages, and their creations are so perfect that newbie patrollers will think: 'Hey this ought to be a GA already'. I see these ussues every day. Realy every day. Perhaps you missed out on the Orangemoody fiasco - see, it even has its own Wiki article ! Kudpung กุดผึ้ง (talk) 15:21, 15 September 2016 (UTC)
- Kudpung I'm dealing with their Commons counterparts at the moment. We're currently getting a steady influx of spam services and spambots that upload images and spam the descriptions in order to get by our spam filters for pages in User and Gallery space. Spam blacklisting hasn't stopped them at all. They started up a couple years ago and are mainly coming from dirty webhosts in India, the US, etc, or from scraped public proxies. It takes somebody with a lot of experience to deal with what you're talking about. Why not let the newer patrollers pick the low-hanging fruit in the meantime? There's plenty of it to go around. INeverCry 22:02, 15 September 2016 (UTC)
- Because newbie Page patrollers are basically messing the whole thing up. Why is it so awful to demand minimum competence from anyone around here who wants to do more than simple editing?! --IJBall (contribs • talk) 23:55, 15 September 2016 (UTC)
- Perhaps a new Patroller right is needed if new patrollers are doing that poor of a job. Maybe things are worse off than I realize. INeverCry 00:30, 16 September 2016 (UTC)
- @INeverCry: because letting the fox guard the henhouse doesn't work. We aren't just trying to filter out "newer patrollers"; we are trying to reduce the number of sockpuppets patrolling their own spam/blackmail/etc. VQuakr (talk) 00:04, 16 September 2016 (UTC)
- People who're sophisticated and dedicated enough to use socks/sockfarms for spam and promotion will probably figure out how to get themselves the patroller right quick enough. Spammers have figured out how to get their spambot-created pattern accounts around our filters at Commons well enough. These people get payed to figure out how to get results for clients. INeverCry 00:30, 16 September 2016 (UTC)
- So because any barrier could potentially be circumvented we should have no barrier at all? VQuakr (talk) 04:07, 16 September 2016 (UTC)
- People who're sophisticated and dedicated enough to use socks/sockfarms for spam and promotion will probably figure out how to get themselves the patroller right quick enough. Spammers have figured out how to get their spambot-created pattern accounts around our filters at Commons well enough. These people get payed to figure out how to get results for clients. INeverCry 00:30, 16 September 2016 (UTC)
- Because newbie Page patrollers are basically messing the whole thing up. Why is it so awful to demand minimum competence from anyone around here who wants to do more than simple editing?! --IJBall (contribs • talk) 23:55, 15 September 2016 (UTC)
- Kudpung I'm dealing with their Commons counterparts at the moment. We're currently getting a steady influx of spam services and spambots that upload images and spam the descriptions in order to get by our spam filters for pages in User and Gallery space. Spam blacklisting hasn't stopped them at all. They started up a couple years ago and are mainly coming from dirty webhosts in India, the US, etc, or from scraped public proxies. It takes somebody with a lot of experience to deal with what you're talking about. Why not let the newer patrollers pick the low-hanging fruit in the meantime? There's plenty of it to go around. INeverCry 22:02, 15 September 2016 (UTC)
- INeverCry, you're not the only one who has patrolled literally thousands of new pages - and it hasn't gone unnoticed. However, today's spammer is a professional PR person with an Ivy League degree in marketing or communication, and just like the SEO specialists will get your web site to Google's first page, takes big bucks for getting Wiki pages through the controls, creates dozens of socks to be able to patrol their own pages, and their creations are so perfect that newbie patrollers will think: 'Hey this ought to be a GA already'. I see these ussues every day. Realy every day. Perhaps you missed out on the Orangemoody fiasco - see, it even has its own Wiki article ! Kudpung กุดผึ้ง (talk) 15:21, 15 September 2016 (UTC)
- I would say it is far more likely than you might think that somebody writing "spam" about a company or "some guy" are simply seeing that other stuff exists on Wikipedia and think that following suit is acceptable as they have no reason to believe otherwise. Ritchie333 (talk) (cont) 12:45, 8 September 2016 (UTC)
Would support without Twinkle restrictions
[edit]Those opposing, would you support this proposal without Twinkle restrictions. Vote Support w/o TR or Still opposed. pinging opposers so far: User:Monty845User:KGirlTrucker81User:MajoraUser:Mr rnddudeUser:AllyDUser:PeridonUser:RebbingUser:AntiCompositeNumberUser:GodsyUser:This, that and the otherUser:Mz7User:BethNaughtUser:Wario-ManUser:BegoonUser:ThePlatypusofDoomUser:TimothyjosephwoodUser:Shoy Oiyarbepsy (talk) 16:49, 29 August 2016 (UTC)
Support without Twinkle restrictions
[edit]- Support w/o TR Aside from the fatal flaw of disabling an important tool, this proposal is a good one. Oiyarbepsy (talk) 16:52, 29 August 2016 (UTC)
- Support w/o - I'm in support of adding more capabilities to the page curation tool, and of splitting the patrol right to a new user group. I don't think requiring changes to twinkle is necessary-deletion tagging is useful for much more than NPP. — xaosflux Talk 17:17, 29 August 2016 (UTC)
- I already stated this in my oppose !vote. Leave my Twinkle alone. Beyond that, I don't have a problem with the user right besides the obvious issue of backlogs. If you can't get people to do it now what makes you think a shiny new hat will make people go do it? --Majora (talk) 20:41, 29 August 2016 (UTC)
- I have a(n unproven) theory that "hat collecting" is actually a mild incentive for editors to do work/additional work on the project. For every editor like me who won't do vandal fighting work to get Rollback (as one example), I think there are several more that will focus on vandal fighting just to get Rollback. In general, I find the reflexive antipathy towards "hat collecting" around here puzzling... So making NPP a "user right" with definable qualifications might actually encourage a not-insignificant subset of editors to focus on improving their NPP-type skills just to qualify for the user right – that's actually a good thing, and is as it should be... --IJBall (contribs • talk) 21:26, 29 August 2016 (UTC)
- Until the restrictions on Twinkle are removed. I remember when I joined here I was overwhelmed by what does what almost to a point where I considered leaving. Luckily, Twinkle came to my rescue. Everyone makes mistakes initially and it can be corrected with proper guidance and understanding. And Twinkle isn't one of those tools holding the possibility of mass damage if not used thoughtfully. I'm not saying issues won't rise, it will, but to a fixable extent. I'm pretty sure without Twinkle, new editors will be left in the wild. Twinkle is the baby walker of Wikipedia in my opinion. I also believe that removing Twinkle would weigh heavily on editor retention. I'll back this right once the restrictions on Twinkle are withdrawn. Best—UY Scuti Talk 07:43, 30 August 2016 (UTC)
- Support without Twinkle restrictions (I haven't !voted yet, I hope this is the right place.) It makes absolutely no sense to restrict Twinkle. Socks and such can still apply the templates manually, and CSD and PROD and still reviewed by admins or more experienced editors, and an AfD will have even more eyes, so it's not really like they can do as much damage as patrolling a bad article. nyuszika7h (talk) 13:53, 30 August 2016 (UTC)
- Support This would make three new user groups added to enwiki within the same six months... Yet another WP:PERM page, update to User:MusikBot, User:MusikAnimal/userRightsManager.js, and whatever other work I have to do... but seriously, this user group does actually make sense. Just remember Special:NewPages and Special:NewPagesFeed are two separate things.
A page that has been reviewed by clicking "Mark this page as patrolled" isn't going to go anywhere with the current state of the proposal, and any autoconfirmed user is still going to be able to click it. That doesn't mean it won't show up in Special:NewPagesFeed, however. My point is there are two systems and we're only addressing one of them, which fortunately is the most popular.Also just FYI,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.
– it is my humble opinion technicalities should be discussed first. If it's not possible to do in the way you want it to, than consensus doesn't matter. The proposal should revolve around what we are able to do technically. Also mw:Extension:PageTriage is an extension, notcore MediaWiki software
. Finally, I agree that while many new-ish users are trigger-happy with the speedy tagging, it's important they still be able to do it, and Twinkle does not provide this functionality, it merely makes that easier — MusikAnimal talk 20:45, 30 August 2016 (UTC)- To most of us, MusikAnimal (with a 'k'), who are qualified creative writers and/or book authors, or who are concerned with the quality of Wikipedia articles, whether Page Curation is core MediaWiki or an 'extension' is of no more interest than the pitot tube of an airplane to an average passenger who needs to go somwhere. And if the analogy is not understood, lets put it it this way: do commuters at a subway line ('tube train' for readers from my side of the pond) need to know how the doors of a new model train will work before they will use the subway again? I appreciate your work enormously, especially your efforts to clean up WP:PERM the 'clerking' of which was a magnet to newbies (just like NPP) and a headache to admins until you came along with your bot. I do understand however that you will naturally be looking at the issue through the eyes of a software engineer in the same way that I as a PPL holder worry about every change of tone of the engines on a routine long haul flight. Kudpung กุดผึ้ง (talk) 01:12, 31 August 2016 (UTC)
- Hehe, totally get the analogies! I actually failed to notice the "Summary of technical changes" which answers some of my concerns... As I understood it, Special:NewPagesFeed actually "triages" pages, not patrols them, when in fact it does both. E.g. when redirects become articles they appear in Special:NewPagesFeed, but not Special:NewPages. This means both systems are covered by the proposal, which is excellent. Sorry for not doing some rudimentary homework before !voting, but the same !vote remains :) I am also very curious what the missing features are of the Page Curation tool that exist in Twinkle, but I understand all that is for another discussion — MusikAnimal talk 04:32, 31 August 2016 (UTC)
- To most of us, MusikAnimal (with a 'k'), who are qualified creative writers and/or book authors, or who are concerned with the quality of Wikipedia articles, whether Page Curation is core MediaWiki or an 'extension' is of no more interest than the pitot tube of an airplane to an average passenger who needs to go somwhere. And if the analogy is not understood, lets put it it this way: do commuters at a subway line ('tube train' for readers from my side of the pond) need to know how the doors of a new model train will work before they will use the subway again? I appreciate your work enormously, especially your efforts to clean up WP:PERM the 'clerking' of which was a magnet to newbies (just like NPP) and a headache to admins until you came along with your bot. I do understand however that you will naturally be looking at the issue through the eyes of a software engineer in the same way that I as a PPL holder worry about every change of tone of the engines on a routine long haul flight. Kudpung กุดผึ้ง (talk) 01:12, 31 August 2016 (UTC)
- Support w/o Twinkle restrictions I think the barrier to entry for reviewing new pages should be kept relatively low, if only to shrink the backlog, but should have a review process to get rid of obviously inexperienced people, socks, or COIs. Jjjjjjdddddd (talk) 21:06, 30 August 2016 (UTC)
- Support w/o TR Something needs to be done about NPP, but restricting Twinkle is not the solution. Mattlore (talk) 07:30, 1 September 2016 (UTC)
- Support w/o TR Restricting the ability to
(patrol)pages to a new user group is something I can tolerate, to enforce greater quality control at NPP, but restricting Twinkle isn't going to help and may be detrimental in many cases. If someone can't mark pages as patrolled, at least let them make a decision on whether to CSD, PROD, or AFD it so that if they do apply for the new page reviewer user right, admins can see their CSD and PROD logs (which are automatically generated by Twinkle) and make a judgement. Forcing users to manually do the tagging and manually do the logging may keep out inexperienced new users, but it will also keep out inexperienced new users that are actively trying to learn. Also, there's nothing about Twinkle that you can't already do manually; restricting Twinkle isn't going to stop the user that really tries to bork the NPP process and is going to stop the user that wants to help out. —k6ka 🍁 (Talk · Contributions) 13:32, 1 September 2016 (UTC)- @K6ka: Note that Twinkle's CSD/PROD logs are disabled by default and need to be enabled manually, but most of them can be found from the history of automatic notices sent to authors for CSD/PROD. nyuszika7h (talk) 12:58, 4 September 2016 (UTC)
- That doesn't address my concern that logs will still need to be manually kept to no benefit of the tagger. As for the point about perusing automatic notices, searching through a user's contributions for CSD and PROD nominations is many times more difficult than if they were all neatly kept on one page, not to mention that not all CSD criteria have notices for the author of the page (G7 for example). —k6ka 🍁 (Talk · Contributions) 17:20, 4 September 2016 (UTC)
- @K6ka: Note that Twinkle's CSD/PROD logs are disabled by default and need to be enabled manually, but most of them can be found from the history of automatic notices sent to authors for CSD/PROD. nyuszika7h (talk) 12:58, 4 September 2016 (UTC)
- Support w/o TR: I support this proposal after seeing so many new editors patrolling new pages right away. But please, don't restrict twinkle because it's pointless because tags can also be put manually. Twinkle is a tool which gives us convenience in tagging pages. Ayub407talk 12:52, 2 September 2016 (UTC)
- Support w/o TR - I am in support of the basic tenets of this proposal; I think they are needed and overdue. The Twinkle restrictions, however, are a deal breaker; my support is conditionally dependent on this reservation.--John Cline (talk) 03:13, 5 September 2016 (UTC)
- Support w/o Twinkle restrictions per K6ka. Restricting Twinkle for this could cause problems because many users will have no other choice but to manually tag pages for cleanup, speedy deletion, proposed deletion, or articles for deletion. —MRD2014 (talk) (contribs) 16:54, 5 September 2016 (UTC)
- Support w/o TR As with the above users, I support the basic proposal, but the Twinkle Restrictions are an absolute deal breaker for me. Only way I can support this proposal is if the Twinkle Restrictions are deleted. Safiel (talk) 02:20, 7 September 2016 (UTC)
- Support w/o TR – The underlying basis for this proposal – to restrict access to the "mark as patrolled" button – makes sense. I think I understand what TimothyJosephWood's alternative proposal is trying to do, but this proposal, if I am reading it correctly, has a built-in mechanism that addresses his concerns (given that we forgo the proposed Twinkle modifications): Newer users can still learn the ropes of new page patrolling by tagging and improving pages, nominating for deletion, and respectfully communicating with page creators – as a new page patroller would now – but by restricting the "mark as patrolled" button, a more experienced user with the NPP user right would have to review the article a second time, checking the initial review. There is no need to create a "semi-patrol this page" button, and I fear that might unnecessarily complicate things. As long as we forgo the Twinkle restrictions, I think this proposal would increase the quality of new page patrolling. It's worth a shot. Mz7 (talk) 21:53, 7 September 2016 (UTC)
- Support w/o TR - Something that is so useful and so easy to use and access should not be limited unless you're misusing the gadget.CatcherStorm talk 21:41, 11 September 2016 (UTC)
Still opposed without Twinkle restrictions
[edit]- Still opposed See thought experiment above on a possible alternative way to approach the issue, that I think would be less burdensome. Additionally, number of edits on WP as a whole is not necessarily any indication that the person understands CSD. I think a lot that a person needs to know about NPP, they are going to get through patrolling, and not through any other way. I don't think restricting access per se is the answer. We should be finding a way to improve quality while still utilizing the motivation of those who volunteer to patrol. TimothyJosephWood 17:13, 29 August 2016 (UTC)
- Still opposed per Timothyjoesphwood. This is just going to keep more editors away from NPP, which is doing less and less to help the encyclopedia. ThePlatypusofDoom (talk) 17:38, 29 August 2016 (UTC)
- Still opposed. We should have a less straightjacketed discussion about the article creation process with (per Opabinia regalis) better data. BethNaught (talk) 18:53, 29 August 2016 (UTC)
- Strong oppose per above and leave our Twinkle alone. KGirlTrucker81 talk what I'm been doing 20:50, 29 August 2016 (UTC)
- Still Oppose per Timothyjoesphwood as well as not knowing if this change would effect patrolling on the File namespace. AntiCompositeNumber (Leave a message) 23:13, 29 August 2016 (UTC)
- Still opposed per BethNaught. This RFC was very poorly planned: the "Proposal" section outlines Twinkle functions to be restricted, but the "Summary of technical changes" section, while repeating these, says that they will be discussed at a future RFC. If script changes aren't intended to be considered here, why are they mentioned in the proposal? If they were meant merely as possible future ideas, they should have been listed under a "Possible future considerations" heading or, best, left out entirely.I am also surprised, dismayed, and offended by the suggestion from one of the proposers that many of the "oppose" votes were cast solely on the basis of personal animosity, something I do not see in any of the votes. I look forward to a more open discussion about these important issues at a later date. Rebbing 11:22, 30 August 2016 (UTC)
- Still opposed per TJW and OR's point #2 above. shoy (reactions) 12:58, 30 August 2016 (UTC)
- Still oppose. Niteshift36 (talk) 00:48, 31 August 2016 (UTC)
- @Niteshift36: out of curiosity, why? You only mentioned Twinkle in your !vote above. VQuakr (talk) 00:55, 31 August 2016 (UTC)
- Yes, because Twinkle was my primary objection above. Removing the Twinkle restrictions still doesn't make me like this set of additional hoops to jump through. Niteshift36 (talk) 01:05, 31 August 2016 (UTC)
- The goal of this proposal isn't to create hoops to jump through. It is to close an open loophole in our quality system that is known to be causing real-world harm. VQuakr (talk) 01:49, 31 August 2016 (UTC)
- The goal and the effect aren't always the same thing. We view this differently. I stand by my vote. Niteshift36 (talk) 03:40, 31 August 2016 (UTC)
- @Niteshift36: out of curiosity, why? You only mentioned Twinkle in your !vote above. VQuakr (talk) 00:55, 31 August 2016 (UTC)
- Still Oppose - My initial vote was targeting Twinkle and was my only concern at the time. However, my opinion of this proposal has further reduced. I agree with much of what Opabinia Regalis said, in essence, I think this is a malformed proposal that lacks the substance to back the proposed changes. The simple approach that should have been taken was to prevent editors without the user rights to "mark this page as patrolled" (other ideas can absolutely be implemented alongside this), instead the proposal seeks to address the problem by using gap filler to cover the walls and leave the gaping hole alone (best shown by the Twinkle part of the proposal). I dislike this approach and fail to see how it will actually work to solve the issue of sub-par page patrolling. Some of the ideas are quite good, some however, I can only describe as being duct-taped to the wall in the hope that it will stick when rammed by a mob. Not good. I want to make this clear, the most crucial aspect of this proposal, which is (or should be) how to implement such a system, has been summarily ignored in the RfC. I'm not going to support any proposal that lacks a foundation on which to stand. The first step should have been to suggest the technical implementation of such a system; 1. How to prevent user's without the right to perform NPP, 2. How to allow people with the right to perform NPP, 3. What considerations need to be taken into account to achieve this (Twinkle, "Mark this page as patrolled", Special:New Pages Feed, Special:New Pages, etc, etc, etc) and then finally 4. Who should have this right. Not the complete opposite. Agreeing to implement a rights system does not to actually implement a system. The inaptness of the current proposal is highlighted by the brute force approach to Twinkle and the wide sprung affects it would have that weren't even considered. Mr rnddude (talk) 04:38, 31 August 2016 (UTC)
- Oppose - Both the comments by OR and the restrictions on twinkle are sufficient to earn my oppose, with the restrictions on twinkle being a particularly dumb idea. Tazerdadog (talk) 08:23, 31 August 2016 (UTC)
- Oppose. I strongly oppose changes to Twinkle (with largely the same rationale as those who've already posted) and less strongly oppose this in general. I don't think this is the sort of thing that barriers should be put in front of. 331dot (talk) 19:10, 31 August 2016 (UTC)
- Oppose: Firstly, I oppose any Twinkle restrictions, which is a bad idea. Assuming no restrictions, it is still a bad idea. It is fundamentally incoherent to bemoan the backlog at NPP while also wanting to increase the bar for participation at NPP. As for the comment about criticizing people for coming up with the proposal, I have only one thing to say. "Nothing's so bad that it can't be made worse". Kingsindian ♝ ♚ 11:16, 1 September 2016 (UTC)
- Oppose - You will not find anybody with a stronger sentiment about the negative side of the New Page Patrol than myself, where I've been bitten hard and even tried to get consensus on policies regarding those performing this mostly thankless task. It is something that needs some fresh ideas, so I will give credit to the proposer of this to at least come up with something to try and combat the problems associated with wayward PRODs and other efforts to cull Wikipedia. I just don't see this as a proposal that will in the long run work out so far as adding hoops for those who really want to be useful to Wikipedia to step in and perform tasks. The only possible compromise I might suggest is that if this is made into a user right, it should be automatically granted to all users after some standard conditions are met (so many edits, having an account for a certain length of time) and for it to be revoked only when users show signs of abuse. You should not need to go crawling to an admin or bureaucrat to receive this ability to perform this task, but admins and other very experienced users ought to perform regular reviews of those who are active in the new page patrol process and have the ability to perform restrictions on those who are abusive. --Robert Horning (talk) 22:22, 1 September 2016 (UTC)
- I'd prefer a focus on education, rather than proactive removal of bad reviewers. If there are issues with specific people, then it would probably be best to write more documentation and give those people a helping hand. NPP is incredibly boring and tedious, and often times there are very borderline cases, so I think we should be encouraging more participation rather than adding a barrier to helping out. And the hat collectors have more than enough extra little permissions as-is. -- Ajraddatz (talk) 15:31, 3 September 2016 (UTC)
- Oppose - notably per TimothyJosephWood, Eridon etc. 's comments.
- If we consider NPP as a diagnosis for deletable pages, a single false positive (incorrect deletion tagging, be it speedy or AfD) is very benign compared to a single false negative (incorrect patrol approval, which will let junk articles survive for a looong time). I see none complaining about too many incorrect CSD or AfD nominations (at least, not in the sense that those issues are severely backlogged), so I would venture that the false negatives as a whole are not a significant issue either. I would gladly support a solution that lets "newbies" patrol and send to deletion while requiring a "veteran" to press the "approval" button.
- The reason is, a false positive is bad, but an unclearable backlog is just as bad. It is fairly clear that the proposal, if implemented, will lead to a much decreased NPP input; I am ready to listen to a contrary argument, but frankly it seems common sense. Even if the veteran input was increased (and I share Opabinia regalis' doubts on that point, see step #4 in their comment), the raw amount of input will fall sharply, and unless the newbies are particularly incompetent at AfD-tagging (i.e. they have a 90%+ rate of false positives), it will not be compensated. TigraanClick here to contact me 16:50, 6 September 2016 (UTC)
- @Tigraan: In its most basic form this RFC is only asking whether a Patroler right should be implemented or not all of the other stuff is dependent on other RFCs. The essence of this right is that only those with it can mark an article Patrolled it has no effect on who can nominate stuff for deletion or place tags - those things are, Ultimatly, templates which can be placed by anyone.
The backlog will increase by virtue of the newbie patrollers not being able to remove articles from the queue - that is the whole point of the exercise, to keep articles from being removed from the queue before someone competent can look at them. Personally I care less about allowing editors to tag articles, that is how they learn, than I do about that tagging resulting in removing the article from the queue by marking it patrolled. JbhTalk 20:36, 6 September 2016 (UTC)
- @Jbhunley: Excluding Twinkle issues, I can see two parts in the page patrol thing: (1) the ability to tick the green check and mark the page as "patrolled" in the logs, removing it from the queue, and (2) the ability to access Special:NewPagesFeed (i.e. the queue) and the PP tool. I was under impression, reading the proposal and comments, that access to both would be conditioned on the "patrol" right, though now that I read the proposal again it is not written. That is IMO a crucial question and not merely a "technical implementation" problem. I am okay with restrictions to (1) (if reasonable) but strongly opposed to pretty much any restriction to (2). TigraanClick here to contact me 07:32, 7 September 2016 (UTC)
- @Tigraan: In its most basic form this RFC is only asking whether a Patroler right should be implemented or not all of the other stuff is dependent on other RFCs. The essence of this right is that only those with it can mark an article Patrolled it has no effect on who can nominate stuff for deletion or place tags - those things are, Ultimatly, templates which can be placed by anyone.
- Still oppose. My reasons for opposing (set out above) are unrelated to Twinkle. WJBscribe (talk) 22:36, 6 September 2016 (UTC)
- Is it okay that a 4 day old account with 10 edits (auto-confirmed) can click Mark this page as patrolled and use Twinkle for CSD, XFD, Prod.? --Marvellous Spider-Man 01:24, 7 September 2016 (UTC)
- @Marvellous Spider-Man: It is absolutely okay for "a 4 day old account with 10 edits (auto-confirmed)" to "use Twinkle for CSD, XFD, Prod.", because disallowing them from using it would simply make it harder for them to make nominations, and the nomination itself more likely to have errors (which others have to fix). If you want to propose an edit and account age threshold for making deletion nominations themselves, you can make a much better case for that. It makes much less sense to simply make it harder in an attempt to discourage new users from doing something they're allowed to do. Making users less efficient is pointless, unless their edits are malignant, in which case we have a better solution to decrease it. That aside, users could just implement a similar functionality using a user script, which someone would probably write and make available.— Godsy (TALKCONT) 03:36, 7 September 2016 (UTC)
- @Marvellous Spider-Man: Regrettably, we have users of lengthy tenure with thousands of edits who make a mess of new page patrol. Time served and edit count ≠ competence. The solution is to engage with people who aren't doing it right, and teach them to do it better. If that doesn't work, they should be told to stop and sanctioned if they persist. There is however in my view no need for a new user class, particularly one that risks empowering people to feel "above" those whose contributions they will be reviewing. If anything I worry that this new right would make WP:BITE issues greater... WJBscribe (talk) 15:11, 7 September 2016 (UTC)
- WJBscribe, I definitely agree with that. I've seen a few editors who make thousands of incompetent edits (but not so blatantly incompetent to earn them a block) and I've seen them get any extra tool they asked for except the mop. So the current proposal for a new user right isn't going to do much about these folks. But I'm not sure anything else is going to do anything.
The solution is to engage with people who aren't doing it right, and teach them to do it better.
My experience so far has been that this works with editors who are either already experienced enough, or inexperienced but willing to learn. There are editors that just won't listen. To paraphrase John Haiman, talk is so inconsequential that humankind has come up with so many ways of "anchoring" it to reality. Now, if there's a new user right, the ability for it to be revoked is one such method for anchoring talk to reality and giving substance to all these endless and otherwise futile talk-page explanations. Uanfala (talk) 21:15, 7 September 2016 (UTC)
- WJBscribe, I definitely agree with that. I've seen a few editors who make thousands of incompetent edits (but not so blatantly incompetent to earn them a block) and I've seen them get any extra tool they asked for except the mop. So the current proposal for a new user right isn't going to do much about these folks. But I'm not sure anything else is going to do anything.
- Is it okay that a 4 day old account with 10 edits (auto-confirmed) can click Mark this page as patrolled and use Twinkle for CSD, XFD, Prod.? --Marvellous Spider-Man 01:24, 7 September 2016 (UTC)
- I seem to be a minority with this, but am opposing because of no Twinkle restrictions. Twinkle makes it easy to hit and run tag, bite a newbie and cause widespread competence-related destruction. A long time ago, when I learned ATL COM programming, I was told to "do everything manually first, then use the wizards and the templates to save time". Doing the code manually forced me to understand what was going on under the hood, so by the time I made a mistake on wizard-generated code, I knew how to fix it. It's kind of the same here. Ritchie333 (talk) (cont) 15:19, 7 September 2016 (UTC)
- @Ritchie333: I disagree that we should restrict Twinkle (as I express above). I agree that learning the manual route is beneficial, but I don't think it is a necessity for those simply wanting to make the occasional deletion or discussion nomination easily. However, I'd love to see a proposal to restrict VisualEditor in a way similar to that what is suggested for Twinkle in this proposal (if only as a symbolic gesture to show further community disapproval of it), based on your line of reasoning. I believe editing in wiki-markup is a necessity for everything but extremely basic editing.— Godsy (TALKCONT) 05:46, 8 September 2016 (UTC)
- Godsy, I'm all for efficiency but I'm wondering if reducing Twinkle access won't be a good of and by itself. The time it takes to manually add a template to two pages is nothing compared to the time it takes to look for references and figure out notability. If single-click deletion nominations are restricted, I bet we'll see much fewer of those two-word-long AfD nominations by editors seemingly oblivious to WP:BEFORE. Uanfala (talk) 07:54, 8 September 2016 (UTC)
- @Uanfala: That argument can be made for XfDs, but this proposal would also restrict CSDs and PRODs, which are simply declined if they're unreasonable. That aside, as I said before, someone could just write and publicize a user script with the same functionality to get around the restriction. I agree that it would be beneficial if users put more thought into nominations, but it would take much more than restricting Twinkle to force them to do so. If a user is continuously making poor nominations, generally someone will point it out to them, and take the issue to the proper venue if it persists.— Godsy (TALKCONT) 23:41, 8 September 2016 (UTC)
- Godsy, I'm all for efficiency but I'm wondering if reducing Twinkle access won't be a good of and by itself. The time it takes to manually add a template to two pages is nothing compared to the time it takes to look for references and figure out notability. If single-click deletion nominations are restricted, I bet we'll see much fewer of those two-word-long AfD nominations by editors seemingly oblivious to WP:BEFORE. Uanfala (talk) 07:54, 8 September 2016 (UTC)
- @Ritchie333: I disagree that we should restrict Twinkle (as I express above). I agree that learning the manual route is beneficial, but I don't think it is a necessity for those simply wanting to make the occasional deletion or discussion nomination easily. However, I'd love to see a proposal to restrict VisualEditor in a way similar to that what is suggested for Twinkle in this proposal (if only as a symbolic gesture to show further community disapproval of it), based on your line of reasoning. I believe editing in wiki-markup is a necessity for everything but extremely basic editing.— Godsy (TALKCONT) 05:46, 8 September 2016 (UTC)
- Oppose. No need for a new user right, and we should be making it simpler for users to patrol new pages, not more difficult. Coretheapple (talk) 18:24, 7 September 2016 (UTC)
- @Coretheapple: how will the approach you describe protect against further attacks that take advantage of our existing open patrol system? VQuakr (talk) 19:29, 7 September 2016 (UTC)
- @VQuakr:I understand the concern with respect to Orangemoody. However, this would not address that situation, for then all a paid editor would have to do is to create accounts that do sufficient innocuous edits to meet the NPP user right requirement. No, I fear that this would simply reduce the number of non-corrupt new page patrollers. It would throw the baby out with the bath water. Coretheapple (talk) 13:27, 8 September 2016 (UTC)
- @Coretheapple: that's not really an accurate assessment or an applicable analogy. Per granting criterion #2 in the proposal, the edits would have to show competence in the skills required for patrolling. That is a massively higher bar than the status quo of autoconfirmed. The humans reviewing WP:PERM are also far better at detecting role accounts than an arbitrary criterion with no man-in-the-loop, which is trivial to game. The motivation for Orangemoody-type attacks is financial gain through blackmail: if the effort required to circumvent our patrols is greater than the potential payoff, the attack method is no longer viable. Meanwhile, experienced patrollers already routinely scan recently-created articles to check for obviously objectionable material such as attack pages, so while the backlog may be in the tens of thousands (it has been much higher in the past), the queue has already been filtered of the highest-priority violations. We want the actual patrol to be done correctly; that is much, much more important than whether it is done immediately. Once the article is marked patrolled, it becomes one in 5.2 million instead of one in 10 (or 50) thousand and finding problematic content becomes proportionally more difficult. But even if I am incorrect and in the future we find NPP hopelessly backlogged, we will have the flexibility to loosen the restrictions on the patrol permission as necessary. That is what, at its core, this RfC is proposing and what is desperately needed - the technical ability to control access to the "patrolled" flag. VQuakr (talk) 23:28, 8 September 2016 (UTC)
- Granting criteria two is "The editor should have made edits (to be determined above) to mainspace of a kind that clearly demonstrate knowledge of page quality control." One, it's about as vague as can be, which raises the possibility of worthy editors being excluded. Two, it's so easy to surmount by a determined paid editor that it's ridiculous. Coretheapple (talk) 13:26, 9 September 2016 (UTC)
- @Coretheapple: that's not really an accurate assessment or an applicable analogy. Per granting criterion #2 in the proposal, the edits would have to show competence in the skills required for patrolling. That is a massively higher bar than the status quo of autoconfirmed. The humans reviewing WP:PERM are also far better at detecting role accounts than an arbitrary criterion with no man-in-the-loop, which is trivial to game. The motivation for Orangemoody-type attacks is financial gain through blackmail: if the effort required to circumvent our patrols is greater than the potential payoff, the attack method is no longer viable. Meanwhile, experienced patrollers already routinely scan recently-created articles to check for obviously objectionable material such as attack pages, so while the backlog may be in the tens of thousands (it has been much higher in the past), the queue has already been filtered of the highest-priority violations. We want the actual patrol to be done correctly; that is much, much more important than whether it is done immediately. Once the article is marked patrolled, it becomes one in 5.2 million instead of one in 10 (or 50) thousand and finding problematic content becomes proportionally more difficult. But even if I am incorrect and in the future we find NPP hopelessly backlogged, we will have the flexibility to loosen the restrictions on the patrol permission as necessary. That is what, at its core, this RfC is proposing and what is desperately needed - the technical ability to control access to the "patrolled" flag. VQuakr (talk) 23:28, 8 September 2016 (UTC)
- @VQuakr:I understand the concern with respect to Orangemoody. However, this would not address that situation, for then all a paid editor would have to do is to create accounts that do sufficient innocuous edits to meet the NPP user right requirement. No, I fear that this would simply reduce the number of non-corrupt new page patrollers. It would throw the baby out with the bath water. Coretheapple (talk) 13:27, 8 September 2016 (UTC)
- @Coretheapple: how will the approach you describe protect against further attacks that take advantage of our existing open patrol system? VQuakr (talk) 19:29, 7 September 2016 (UTC)
- Oppose. I won't support something which only adds more red tape and bureaucracy to an area when what we need to be doing is encouraging editors to have a go at tackling the problems and backlogs that are omnipresent around here, NPP being one of them. More requirements and hoops (and hats) is not going to achieve this. If somebody isn't doing it very well, or needs some extra help or training, I feel sure that an experienced editor or admin will take them aside and give them the guidance to develop their NPP abilities. That way, more people are doing the work, the backlog reduces faster, and we don't need a load of people managing an unnecessary process for gaining this proposed user right. Rcsprinter123 (interface) 20:54, 7 September 2016 (UTC)
- Oppose Twinkle isn't a significant factor in my above oppose, so I'll oppose here too. No need for a new restriction/right. INeverCry 03:39, 8 September 2016 (UTC)
- Oppose, I would support, except for the proposed method of implementation (having to request the new right rather than having it automatically granted, as the default option). To me this is an important point that deserves serious discussion. I feel that the proposed method of implementation will cut off a large pool of experienced users from ever performing NPP, either occasionally or regularly. There are many experienced users, such as myself, who in the past only did NPP rarely, once in a blue moon. I must admit that until recently I never even used the curation tool when I did NPP, and I just worked directly with Special:NewPages. If NPP becomes a user-right that one has to request, then experienced users who don't already perform NPP on regular basis and don't consider NPP a significant part of their editing on Wikipedia are likely to never request this right. I know that I personally never would in this situation. Why exactly should I ask for a right that I don't think I need and for a task that I don't think I plan to perform? The only real way to get into NPP is by trying. Over the last two weeks I did just that, on a few occasions. I played with the curation tool a bit and understood a bit more what NPP really means (although I am by no means an expert). Now, having done that, I can in fact imagine getting involved in NPP more seriously. But asking experienced users to request this right before they acquire any actual NPP experience is rather like putting the cart before the horse in this case, IMO. So my strong preference would be that the New Page Reviewer right be grated, as the default option, automatically, provided that the bar is set really high. Let's say something like at least 5000 edits and at least 6 months of editing. Hopefully, that would serve as sufficient filter against both overeager school-kids who may want to feel like having a "hall-monitor" type arm-band, and against various commercial outfits trying to get some promotional material under the radar. Nsk92 (talk) 00:49, 16 September 2016 (UTC)
- Nsk92 The community could decide to do "both" (e.g. allow anyone to request at WP:PERM, while also allowing an auto-promote-once process at some threshold (even "big" ones like a year and 5000 edits). This is very easy to implement from a technical level if it were supported (it is how extended confirmed works today). — xaosflux Talk 01:06, 16 September 2016 (UTC)
- You are right, of course, but right now the proposal is formulated in rather specific terms, and this aspect seems to me to be a non-minor detail that really matters. Nsk92 (talk) 01:22, 16 September 2016 (UTC)
- That, Nsk92 is clearly a strawman oppose. When you have had a bit more experience in how our RfCs work, you'll notice that ironically they are opposed by !voters who contend there is too little detail, and you want this to fail because there is too much rather than supporting the parts that you might have understood. Kudpung กุดผึ้ง (talk) 07:04, 16 September 2016 (UTC)
- I am opposing because there is an important part of the proposal, as the proposal is currently presented, that I disagree with. I would also have supported a shorter and less detailed proposal, which would have proposed a new user-right and said that the actual implementation mechanism of how that right is to be granted will be determined by a subsequent RfC. Nsk92 (talk) 09:01, 16 September 2016 (UTC)
- That, Nsk92 is clearly a strawman oppose. When you have had a bit more experience in how our RfCs work, you'll notice that ironically they are opposed by !voters who contend there is too little detail, and you want this to fail because there is too much rather than supporting the parts that you might have understood. Kudpung กุดผึ้ง (talk) 07:04, 16 September 2016 (UTC)
- You are right, of course, but right now the proposal is formulated in rather specific terms, and this aspect seems to me to be a non-minor detail that really matters. Nsk92 (talk) 01:22, 16 September 2016 (UTC)
- Nsk92 The community could decide to do "both" (e.g. allow anyone to request at WP:PERM, while also allowing an auto-promote-once process at some threshold (even "big" ones like a year and 5000 edits). This is very easy to implement from a technical level if it were supported (it is how extended confirmed works today). — xaosflux Talk 01:06, 16 September 2016 (UTC)
- Oppose somewhat regretfully. I think incoming articles do need to be handled differently, particularly to diminish biting. I think a revocable user right would probably help with that, and I even like the revocation standards proposed here. But I'm decreasingly inclined to believe an experience cutoff would help (inexperience has almost never been the cause of the biting I've encountered), and I think making the user right a permission that must be requested from an admin--explicitly so as to make it a hat to wear (not to say, collect)--may actually make biting worse. I don't believe that mechanism will raise the proportion of participants temperamentally suited to or even necessarily interested in obligations that come with being many new editors' first interlocutors in the community. That said, please ping me if I have misunderstood and enacting this as, for instance, opt-in (as at AfC) remains an option for implementation of this RfC (as currently phrased). I do see several support ivoters suggesting things along these lines so perhaps this RfC wouldn't necessarily lock us into a PERM, but I haven't been able to get confirmation one way or another when I asked in the comments, and I notice that the discussion just above this comment is also struggling to pin this down. Innisfree987 (talk) 00:10, 18 September 2016 (UTC)
- Oppose I have only been patrolling new articles for a short period of time, but there appears to be a backlog going back to June 2016. Reducing the number of people who can patrol articles would presumably make this worse. Yadáyiⁿga (talk) 02:16, 18 September 2016 (UTC)
#Oppose - Rationale is in the "still opposed without twinkle restrictions" section, putting my name here for an accurate count. Tazerdadog (talk) 05:11, 3 October 2016 (UTC) Striking unintentional duplicate vote - mea culpa. 21:33, 10 October 2016 (UTC)
General comments
[edit]- For clarity, I'm neutral on the remainder of the proposal, only opposing the restrictions on Twinkle (for reasons I stated above). — This, that and the other (talk) 23:45, 29 August 2016 (UTC)
- I hope that this is appropriate: I organized the !votes in this section by support/oppose/general so that the numbering makes more sense. Feel free to revert me if this is ill-advised. Mz7 (talk) 02:04, 2 September 2016 (UTC)
Comments
[edit]- Consider me parked at
Neutralfor 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) - 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)
- 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. — xaosflux Talk 17:31, 28 August 2016 (UTC)
- 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 -- samtar talk or stalk 16:34, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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) - (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)
- 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)
- 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)
- One, how would you effect this? and two, that is not what the proposal suggests;
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 example Monty845 22:24, 28 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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 feasible 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)
- @Godsy: I think it makes sense, so long as the patrolling mechanism works on titles, not pages, which I believe is correct...? If that's not the case, then a user could move an article to another namespace, patrol it there, and move it back. If it is the case, the scenario I just mentioned can't happen as far as I know (since the article title is not patrollable) — Andy W. (talk · ctb) 20:00, 29 August 2016 (UTC)
- @Godsy: I think it makes sense, so long as the patrolling mechanism works on titles, not pages, which I believe is correct...? If that's not the case, then a user could move an article to another namespace, patrol it there, and move it back. If it is the case, the scenario I just mentioned can't happen as far as I know (since the article title is not patrollable) — Andy W. (talk · ctb) 20:00, 29 August 2016 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- True, and seeking/adding more text and references to new pages is where I spend much of my editing time. My <1> to <5> was looking to where bad outcomes can result from NPP, but restricting NPP participation could have the unintended consequence of reducing the number of editors seeking to improve new articles. AllyD (talk) 11:55, 29 August 2016 (UTC)
- 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)
- I do not get an impression your "replies" have any relation to my points. Sorry for that. I am also not sure whom you mean by "creators of this proposal".--Ymblanter (talk) 11:43, 29 August 2016 (UTC)
- I'll move my comments to a different section. By "creators of this proposal", I mean the people who came up with the idea for this proposal, and wrote it. ThePlatypusofDoom (talk) 11:47, 29 August 2016 (UTC)
- 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)
- 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)
- 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)
- Of the "Guidelines for granting" the new permission, items 1, 2, 4 make sense, but I not sure that item 3 "editor should have experience with moving pages" is necessary. The content of the new pages is obviously important, but is the title of the new article so important? If it's wrong, it can be fixed later; in most cases I wouldn't have thought an incorrect article title would be likely to cause a major problem. Do we have a big problem with defamatory or excessively promotional titles? Or inexperienced editors incorrectly moving new articles (from a "correct" to an "incorrect" title)? Mitch Ames (talk) 11:49, 29 August 2016 (UTC)
- Actually, we have a lot of problems with cut-and-paste moves, which result in the return of old articles to the unpatrolled queue, but I am not sure whether this is this point which was meant.--Ymblanter (talk) 11:54, 29 August 2016 (UTC)
- I'm not really sure that adding disclaimers to the RFC at this stage, with 55 !votes already, and many comments already added, is a particularly good idea. Will someone go back and ask all those folks how the new wording would have affected their opinion, or is it just aimed at newer participants? Either way seems inadvisable to me, honestly. --Begoon talk 11:57, 29 August 2016 (UTC)
- That edit seems to simply be reinforcing the Summary of Technical Changes section people have been ignoring for the last day
Technical Permission Changes - not for discussion at this RfC. If necessary, will be discussed if a consensus is reached.
- 1 Remove the (patrol) permission from the Autoconfirmed group, the Confirmed group, and the Pending changes reviewers group.
- 2 Create a new user group Patrollers (localization name: "New Page Reviewers")
- 3 Give the new New Page Reviewers group the (patrol) permission
- 4 Give administrators the ability to add or remove membership for users to the New Page Reviewers group
- Script and Tool Changes - not for discussion at this RfC. If necessary, will be discussed if a consensus is reached. (emp added)
- 5 Adjust Twinkle to make some options only available for New Page Reviewers
- 6 Some missing features of Twinkle which were forgotten by the developers will be added to the Page Curation tool, along with some new ones.
- 7 Add some features from the "Articles for creation helper script" to the "Page Curation tool" that would be useful to New Page reviewers.
- 8 Expand the number of filters in the New Pages Feed to enable Reviewers to be more selective in their patrolling
- Admitedly it is hidden in with all of the other nitty gritty like criteria for granting and revocation and the other section on Twinkle makes it confusing but the new caveat makes no material change to the RFC. It just puts it at the top for editors who comment without reading the whole thing. JbhTalk 12:22, 29 August 2016 (UTC)
- Perhaps you're right. I've never been in favour of any wording changes to an ongoing RFC, particularly when they seem to attempt to address the biggest oppose reason to date by offering a more prominent disclaimer. I feel this discussion section exists for that sort of thing, and if the initial wording was poorly laid out, with important points in collapsed sections, then that's unfortunate, but not something that should be tinkered with as we go along, after many have commented - more something to learn from next time a draft is prepared. Just my opinion - others may differ. --Begoon talk 12:37, 29 August 2016 (UTC)
- (edit conflict) I agree it probably would have been better to not mention possible tool changes in the RFC material if they were not supposed to be discussed. I suppose the writers wanted to give some 'look ahead' but the benefit of having people think ahead being far outweighed by derailing the thrust of the RFC. Oh well... JbhTalk 12:53, 29 August 2016 (UTC)
- Before voting, I did read the statement in § Summary of technical changes that this RFC doesn't cover Twinkle, but, since the plain wording of the proposal says that it does, I chose to take the RFC at its word. It would have been helpful if the RFC proponents had figured out what they wanted to ask and straightened out the proposal's contradictions before putting it up for a site-wide vote, but that's not my business. They wanted a straight vote on their proposal ("Please start your own RfC rather than detracting from this one to make your point."), and that's what I gave. Rebbing 19:08, 29 August 2016 (UTC)
- I also read the technical changes blurb, but I don't read that text in quite the same way - I think the authors of the RfC have conceptualized this as a generic "NPP user group" and simply expect to be able to direct the Twinkle developers (and the developers of any other user scripts) to implement the result at a later stage. The new addition here, which says that "policy dictates how Twinkle is used", supports that interpretation. I suspect that the people saying "I support except for the Twinkle part" and the RfC authors are talking past each other a bit. Opabinia regalis (talk) 21:24, 29 August 2016 (UTC)
- I had the same interpretation. Of course, the obvious flaw in this logic is that altering user scripts in such a way that they prevent "untargetted" users from simplified access to tasks which they are perfectly entitled to perform manually is both wrong and unenforceable. Does the RFC propose that if I wrote my own script to continue adding (in a simplified manner, instead of manually) the CSD tags and image deletion tags which I do add, rather than applying for this NPP right (in which I have little interest, as I don't wish to "patrol" new pages), then I (or others) should be prevented from using it? Of course not. This, in addition to the pointless inconvenience it would cause to hundreds of editors who have and want no connection to NPP, is why it was ill-considered to include such a proposal. --Begoon talk 02:41, 30 August 2016 (UTC)
- I also read the technical changes blurb, but I don't read that text in quite the same way - I think the authors of the RfC have conceptualized this as a generic "NPP user group" and simply expect to be able to direct the Twinkle developers (and the developers of any other user scripts) to implement the result at a later stage. The new addition here, which says that "policy dictates how Twinkle is used", supports that interpretation. I suspect that the people saying "I support except for the Twinkle part" and the RfC authors are talking past each other a bit. Opabinia regalis (talk) 21:24, 29 August 2016 (UTC)
- Perhaps you're right. I've never been in favour of any wording changes to an ongoing RFC, particularly when they seem to attempt to address the biggest oppose reason to date by offering a more prominent disclaimer. I feel this discussion section exists for that sort of thing, and if the initial wording was poorly laid out, with important points in collapsed sections, then that's unfortunate, but not something that should be tinkered with as we go along, after many have commented - more something to learn from next time a draft is prepared. Just my opinion - others may differ. --Begoon talk 12:37, 29 August 2016 (UTC)
- Just one question here: will autopatrolled be given
(patrol)as well or will they still need this new user right? —k6ka 🍁 (Talk · Contributions) 13:21, 29 August 2016 (UTC)- It seems to me that the right should be added to the reviewer and especially autopatrolled groups since they require at least as much competence and assiduousness. Rebbing 18:52, 29 August 2016 (UTC)
- Unfortunately, "reviewer" (i.e. PC reviewer) rights are handed out far too easily, currently, to be useful. Until the requirements for reviewer are strengthened, I would oppose including them in this NPP proposal. (And, fortunately, the current proposal does exclude reviewer...) --IJBall (contribs • talk) 19:08, 29 August 2016 (UTC)
- Yes, curious as well. (A counterargument is that while an editor's own new pages meet a decent standard, the editor is unable to evaluate the works of others...?) — Andy W. (talk · ctb) 18:58, 29 August 2016 (UTC)
- For the record, I'm not exactly against excluding patrol in autopatrolled though, but here's another possible counter: folks might rather go directly for the autopatrolled right and gain
(patrol)indirectly that just go for the "patroller" user group. — Andy W. (talk · ctb) 19:40, 29 August 2016 (UTC)- But, to get WP:Autopatrolled they'd need to write 25–30 valid (mainspace) articles, properly sourced, with few-to-no maintenance tags, and with few-to-no deleted articles in their histories – that's actually a far higher hurdle than what is likely to result for NPP rights from this proposal... --IJBall (contribs • talk) 21:36, 29 August 2016 (UTC)
- For the record, I'm not exactly against excluding patrol in autopatrolled though, but here's another possible counter: folks might rather go directly for the autopatrolled right and gain
- It seems to me that the right should be added to the reviewer and especially autopatrolled groups since they require at least as much competence and assiduousness. Rebbing 18:52, 29 August 2016 (UTC)
- Query on the statistics: The presented table appears to show that I curated 50 articles in the year March 2015-16. This looks seriously out of line with, for example, my CSD Log which had 293 articles in Feb 2016 alone. Now, I use Twinkle for CSD rather than the more limited Page Curation toolbox; does this indicate that the activity analysis only picked up those logged under "pagetriage-curation" and omitted a swathe of NPP activity? AllyD (talk) 14:49, 29 August 2016 (UTC) Extending on this: The tabular stats presented above to underpin this RFC have missed more than 96% of my activity in the period. Presumably it is the same for other longstanding NPP editors who continued to use Twinkle rather than the "new" Page Curation tool to initiate CSD. Are the statistics then showing merely that new editors adopt Page Curation as have an unquantified proportion of longstanding editors? If the data is significantly understating the level of activity by longstanding editors at NPP by omitting Twinkle-based CSDs, is it fit for purpose here (both in terms of this discussion and any subsequent rights allocation)? AllyD (talk) 19:00, 29 August 2016 (UTC)
- @AllyD: Correct me if I'm wrong, but I believe the presented table is counting how many times you marked a page patrolled. When a page is created, it is not marked as patrolled. People not using the page curation software will see a little button on the bottom right hand corner of the page that says, "[Mark this page as patrolled]". If you click that, you've patrolled a page. If you are using the page curation toolbar, there's a big green checkmark to mark it patrolled, or doing any action using the toolbar (including tagging for lack of sources, nominating for deletion, etc.) marks it as patrolled. Nominating for deletion manually or using anything but the toolbar doesn't mark the page as patrolled. ~ ONUnicorn(Talk|Contribs)problem solving 19:58, 29 August 2016 (UTC)
- AllyD, one of the very reasons why NPP is in such a mess is because there are no mechanisms for contolling it. We actually have no inkling over who is doing it, when, and how often, and how competent they are, We have tools that tell us all this data for AfC, RfA, AfD participation and other areas, and logs of admin actions, etc., but for NPP (Page Curation or Twinkle), nothing, absolutely nothing. Just a few logs which can't be sensibly used by anyone trying to piece all this together. Kudpung กุดผึ้ง (talk) 05:50, 31 August 2016 (UTC)
- I thought the little button is only for pages outside of the article space but I might be wrong.--Ymblanter (talk) 20:24, 29 August 2016 (UTC)
- Twinkle will mark a page as patrolled if you put it up for CSD, but it does not seem to do so if you PROD or AFD it. PGWG (talk) 20:40, 29 August 2016 (UTC)
- Yes, as it did for a page I just put to CSD, so it is no longer showing in special:newpages; but my reading is that this Patrol transaction will be missed by the query used for the stats here. AllyD (talk) 20:54, 29 August 2016 (UTC)
- I had hoped to check more, but the Quarry WMFLabs function has been unavailable. However my missing CSDs alone amount to a 0.7% omission in the total data above. Numerically that is almost large enough to be significant, but all the more problematic if it indicates a missed NPP activity pattern whose omission makes conclusions untenable. (Analogy: If a shopping mall's use was analysed by tallying people entering its street doors but not those from its car park, the results would over-assess its proportionate use by teenagers, for example, and could not be extrapolated to support statements about overall usage.) AllyD (talk) 12:22, 30 August 2016 (UTC)
- FWIW, apparently I haven't patrolled a single article ever. TimothyJosephWood 12:28, 30 August 2016 (UTC)
- I think a better information source is available for analysing new page patrol activity. If you compare (1) My Page Curation Log vs (2) My Patrol Log, they have vastly different numbers, but more importantly, (2) is inclusive of (1)'s patrol lines. @Marvellous Spider-Man and Kudpung: a query based on type=patrol rather than type=pagetriage-curation would give a more realistic view of patrol quantities per person doing NPP (albeit with User Talk pages that will need to be filtered out and without the Page Curation Log's additional lines for deletion tagging). AllyD (talk) 20:10, 30 August 2016 (UTC)
- Does NPP backlog come into this discussion? It seems like it will be more difficult to address the backlog if we restrict who is allowed to work on it. ~Kvng (talk) 14:53, 29 August 2016 (UTC)
- The RFC appears to assume that once "bad" patrollers have been eliminated (which it assumes the right will achieve), more experienced editors will be "encouraged" to apply for the new user right and participate, and will be "better". It's up to you whether you go along with that chain of assumptions. Whilst acknowledging that the quality and methodology of NPP is a real concern that needs to be properly addressed, and inexperienced patrollers is a big factor, I mostly agree with the concerns expressed about this particular proposal by Opabinia in her oppose vote. --Begoon talk 03:47, 30 August 2016 (UTC)
- I don't see a credible scenario where the new requirement would increase NPP participation. I do think I would prefer we had a larger backlog to having the work done poorly. ~Kvng (talk) 21:00, 30 August 2016 (UTC)
- I largely agree. Of course, the problem with much of the 'backlog' in this area is that, unlike AFC, it's not stuff waiting for approval before it gets 'published', but rather stuff waiting to be approved, cleaned up or rejected that is already 'live' and maybe shouldn't be here at all. Not all of it, obviously, or maybe even most, but it's an important distinction in the way the 2 areas operate. That's a separate discussion, and harks back to WP:ACTRIAL etc, but worth a mention, I feel. --Begoon talk 09:33, 31 August 2016 (UTC)
- I don't see a credible scenario where the new requirement would increase NPP participation. I do think I would prefer we had a larger backlog to having the work done poorly. ~Kvng (talk) 21:00, 30 August 2016 (UTC)
- The RFC appears to assume that once "bad" patrollers have been eliminated (which it assumes the right will achieve), more experienced editors will be "encouraged" to apply for the new user right and participate, and will be "better". It's up to you whether you go along with that chain of assumptions. Whilst acknowledging that the quality and methodology of NPP is a real concern that needs to be properly addressed, and inexperienced patrollers is a big factor, I mostly agree with the concerns expressed about this particular proposal by Opabinia in her oppose vote. --Begoon talk 03:47, 30 August 2016 (UTC)
- Consider me Neutral. I haven't used Page Curation myself, but I have patrolled a number of pages. I'm not familiar with the new pages landscape too well, except for the occasional page that has an incongruent DISPLAYTITLE, and the article generally almost always meets CSD somehow. The intent to get more competent editors reviewing pages is very good, and I could mildly support some technical implementation to get this happening. A concern for me is if this results in slower progress reviewing articles though, the group will have failed. The proposed Twinkle changes are questionable in my opinion. — Andy W. (talk · ctb) 18:58, 29 August 2016 (UTC)
- As a start, why don't we just bump patrol up from confirmed to extended confirmed and see how that works? At best, it solves the problem and we don't need the bureaucracy of an additional user right. At worst, it locks the newest and least experienced people out of new page patrolling, something we appear to want to do anyway. ~ Rob13Talk 23:03, 29 August 2016 (UTC)
- I agree that that would be a good start (though I might want even higher standards than EC). But that would at least cut down on the ridiculousness of editors being able to NPP after just 4 days on the project. --IJBall (contribs • talk) 23:25, 29 August 2016 (UTC)
- I personally think it's a great idea, but I'm doubtful whether the rest of the community thinks that, whether it's an extension of the scope of ECP beyond what it was intended for initially. — Andy W. (talk · ctb) 02:20, 30 August 2016 (UTC)
- Just thought I would mention that ECP has already expanded far beyond what it was originally intended for. We have this new user level. Why not use it? --Majora (talk) 02:24, 30 August 2016 (UTC)
Possibly heretical comments IMO incorrect tagging is a problem, but one that's not too hard to deal with if admins (and experienced others...) will take a few minutes to explain things. (Some may not wish to bump up their 'talk page' to 'creative edit' ratio. I don't care about mine as it's beyond help anyway...) The real problem is the incorrect application of the patrolled button. A possible answer to this would be to scrap the button altogether. This would, I presume, leave everything in place in the list for someone else to review again. Time wasting? Yes, in a way. But so is cleaning up an OrangeMoody type operation. As to locking out the most inexperienced - yes, but... With a driving licence test in the UK there is a practical test and a theory test, and prior to the practical test one may only drive in public places when accompanied. That would be very hard to do here. But without exposure to the nitty-gritty of CSD, how will the most inexperienced become experienced? Would-be admins are preferred to have experience on the fringes of admin work, and there is the new admin school, which I found quite instructive. Would it be possible for an NPP school similar to that to be created? Or again, would it be possible for a two level patrolled button, where things marked by newbies to the area can be separated into another list for a quick review by a smaller number of rather more experienced patrollers with a 'right' granted to them? This could reveal patterns in the use of the patrolled button, and enable alarm bells to be sounded (as well as giving the chance to educate those making errors in the case of genuine good faith mistakes). I'm just throwing these thoughts out to stir people up. But I will reiterate that I think restricting Twinkle is a non-starter - it wouldn't have stopped me doing all I did manually, and PC would have to be restricted too (so they say - open to correction there as I never looked that far into it). Peridon (talk) 08:59, 30 August 2016 (UTC)
- Peridon: A two tiered system is basically what I proposed above, with the addition that I would try to make it an auto-confirmation process so as to avoid the addition of a persistent burden on admins. TimothyJosephWood 12:13, 30 August 2016 (UTC)
- In response to the "but it will cause a worse backlog!" comments, let's be clear that we're just either pushing a backlog down the road or actively reducing the quality of new articles when we allow bad reviews to happen. The fastest way to clear the backlog would be to abolish new page patrolling altogether, but that's clearly not a viable option because the whole point is to perform quality control on new articles. The same is true here; yes, we have less of a backlog if we allow everyone to patrol new pages, but no, we don't get the same quality control as we normally would have. Whether or not this is the particular solution we're looking for is possibly questionable, but let's not try to oppose the idea of restricting new page patrol entirely to "reduce the backlog" for reducing the backlog's sake. ~ Rob13Talk 16:54, 30 August 2016 (UTC)
- An addition has been made to the proposal, Special:Diff/736719900. Concrete changes were proposed to Twinkle. That doesn't fall under illustrative purposes.—Godsy(TALKCONT) 22:39, 30 August 2016 (UTC)
- Backlog: Kvng, Begoon While this RfC is not aimed at reducing the backlog - which clearly demonstrates the lack of real interest in the quality of Wikipedia by many of the participants at this RfC - what a lot of people are missing is the very fact that having a hat to collect (i.e. a user right) literally gets people clambouring to do a rights-limited maintenance task. But again, I wouldn't expect anyone who has never worked at WP:PERM or who is not a teacher or social scientist, to understand that. Quite undeniably, for a great many people, as evidenced by their user pages, Wikipedia is a game where the object is to get to the next level.
- Ironically, when recruiting for New Page Patrollers, that's not a bad thing - as long as the admins who accord theright also take into consideration the user's editing history beyond simple numerical statustics. Kudpung กุดผึ้ง (talk) 23:33, 30 August 2016 (UTC)
- Gee, Kudpung, do you think you could be any more condescending? I share your concern that inexperienced patrollers damage the project. I, and others who have commented, do not support the proposals as expressed in this RFC, partly because it relies on a chain of unproven assumptions, and partly because there are options it does not explore. Instead of suggesting that editors who are not as instinctively infallible in their intuition as you feel you are could not possibly understand your great wisdom, you might serve your cause better by, ermm, not doing that. The point you make about "hat-collecting" adding to the appeal is a good one, but the tone of your delivery almost caused me to skip over it. I support efforts to address this issue, and the fact that I don't feel this RFC does so in a way I can go along with does not diminish that. I understand that you are disappointed that the formulation of the RFC led to so many opposing on the "Twinkle" aspect, but that is really not a fault in the opposers... Incidentally, pings like this won't work. From Wikipedia:Notifications#Triggering events
But I wouldn't expect a teacher or social scientist to understand that... (See how well that works?) --Begoon talk 04:11, 31 August 2016 (UTC)Note that the post containing a link to a user page must be signed; if the mention is not on a completely new line with a new signature, no notification will be sent.
- Gee, Kudpung, do you think you could be any more condescending? I share your concern that inexperienced patrollers damage the project. I, and others who have commented, do not support the proposals as expressed in this RFC, partly because it relies on a chain of unproven assumptions, and partly because there are options it does not explore. Instead of suggesting that editors who are not as instinctively infallible in their intuition as you feel you are could not possibly understand your great wisdom, you might serve your cause better by, ermm, not doing that. The point you make about "hat-collecting" adding to the appeal is a good one, but the tone of your delivery almost caused me to skip over it. I support efforts to address this issue, and the fact that I don't feel this RFC does so in a way I can go along with does not diminish that. I understand that you are disappointed that the formulation of the RFC led to so many opposing on the "Twinkle" aspect, but that is really not a fault in the opposers... Incidentally, pings like this won't work. From Wikipedia:Notifications#Triggering events
- Comment 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. In other words: Over a series of off-wiki discussions in which you were not invited, we were able to convince ourselves that we will diminish the page patrol backlog by preventing the majority of editors from patrolling pages. Sure you will. Geogene (talk) 23:45, 30 August 2016 (UTC)
- In other words, Geogene, taking comments out of context is not conducive to reaching any conclusions. Based on your contributions I'm not wholly convinced that you are aware of the function of NPP; I may of course be wrong. Apologies if I am. What may come to a surprise to you however, is that a great deal of the preparatory work by volunteers on serious Wiki developments and all outreach takes place in work groups anfd public meetings with those who understand that the electronic part of Wikipedia is merely its public face. There is absolutely no rule at all that absolutely every word of the running of en.Wiki should take place on talk pages here. You will never be invited, no one ever is - the onus is on users to get actively involved. --Kudpung กุดผึ้ง (talk) 00:47, 31 August 2016 (UTC)
- Nothing was taken out of context, a group of influential users merely believes, counter-intuitively, that this is a better option than attempting to teach less experienced users. And they want to keep the unwashed off their turf. You are correct that I know little of NPP, and once this becomes a user right-I will not be grandfathered-my ignorance of it will be made into a permanent condition. That is not going to help your backlog in the long term. Geogene (talk) 01:06, 31 August 2016 (UTC)
- In other words, Geogene, taking comments out of context is not conducive to reaching any conclusions. Based on your contributions I'm not wholly convinced that you are aware of the function of NPP; I may of course be wrong. Apologies if I am. What may come to a surprise to you however, is that a great deal of the preparatory work by volunteers on serious Wiki developments and all outreach takes place in work groups anfd public meetings with those who understand that the electronic part of Wikipedia is merely its public face. There is absolutely no rule at all that absolutely every word of the running of en.Wiki should take place on talk pages here. You will never be invited, no one ever is - the onus is on users to get actively involved. --Kudpung กุดผึ้ง (talk) 00:47, 31 August 2016 (UTC)
- School? Would it be possible for an NPP school similar to that to be created? Well Peridon, Opabinia Regalis, that school was created on October 7, 2012 at Wikipedia:New pages patrol/School following, for consistency, the format of our other schools. It was never used. Such is the interest of wannabe patrollers, and the editors commenting in this RfC. What stands out most with NPP is that its tutorials are the best and most comprehensive among all the maintenance tasks, but empirical evidence drawn by those who take a regular interest in NPP and the quality of what arrives here up to 1,500 times a day, is that nobody bothers to read it until they are told to refrain fro patrolling until they have. Even then, the response from 2-week, 200-edit wonders is often words to the effect (diffs available) 'Mind your own business, don't tell me what to do, Wikipedia is the encyclopedia anyone can edit.' That very, much deliberately misused maxim, is what will ultimately destroy what little is left of Wikipedia's reputation for quality. Kudpung กุดผึ้ง (talk) 00:18, 31 August 2016 (UTC)
- Question To clarify on the Request for permissions aspect. If this RfC passes, will this necessarily be something that requires a proactive request on the part of an editor (other than those grandfathered in), or is it possible that the subsequent implementation RfC could still decide that, say, extended confirms are automatically included and the only requests would need to be for those who want an exemption or, I don't know, are reapplying after a removal? Studying this closely, I've started to worry that making it a requested permission might deter participation by some qualified people who'd be temperamentally very well-suited to the work, like those specifically not enticed by the perception of achieving a "higher" right. This would obviously be bad for backlogs, but I even wonder if it might perversely be at odds with goal of reducing biting, by taking some of the most low-key editors out of the mix (and meanwhile rather explicitly trying to attract ego-motivated editors? It seems, unless I am misreading?) Innisfree987 (talk) 17:46, 1 September 2016 (UTC)
- This is fully covered in the itroduction, Innisfree987, but to recap, it is proposed that permission will be granted at WP:PERM (take a look there if you are not familiar with it) based on a recommended set of numercial criteria, plus a review of the applicant's editing (see also - just as an example: Wikipedia:WikiProject Articles for creation/Participants). Users who have already demonstrated recent competent patrolling would be grandfathered into he right. The right would be subsumed into that of Admin. There is a school of thought that in spite of occasional peaks of backlogs, it is better to let articles stay unpatrolled for a while rather than to bite good-faith newcomers and/or let totally inappropriate articles into he encyclopedia for ever more. Indeed, the earlier system of NPP allowed just that: any unpatrolled articles older than 30 days became de facto patrolled - there must be hundreds of thousands of them. With the extremely low current participation at NPP, it is hardly likely that the new requirement would make the situation worse. Indeed, the way users clambour for other minor rights suggests that with a hat to wear, NPP might even get a boost.Kudpung กุดผึ้ง (talk) 23:17, 1 September 2016 (UTC)
- I think I must not be making myself clear because this still doesn't confirm the information I'm trying to pin down. To come at it from a different angle: I'm wondering if I understand this RfC correctly for the way the proposed mechanism differs from AfC, where you do not have to submit a request to PERM--you need only achieve the 90/500 threshold (by which time you're automatically extended confirmed and don't have to ask for anything), then you can add yourself, and after that quality control is done by admins removing editors who are unsuitable. (Basically, you can join at will but might be bounced, instead of having to ask to join in the first place.) What I'm asking here is, 1, do I understand correctly that this RfC is meant to preclude that approach (and instead require an explicit request) as a possibility at a subsequent implementation RfC, and 2, if so, why? Innisfree987 (talk) 01:10, 2 September 2016 (UTC)
- Innisfree987, The answers are clear to anyone who has taken the time to read the preamble. In a nutshell, this RfC is not about AfC (which also suffers fron the same ailments)) but the comparison is made for those commenting on this RfC who may not even be fully familiar with either process, to help them understand that NPP is an official process, which is even embedded in the MediaWiki software as some kind of extension, API, (or whatever the MediaWiki engineers care to call it) while AfC is a local, volunteer run process, whose Helper Script was a good faith, free contribution by an unpaid volunteer, which incidentally works quite well, but like Page Curation, is only any good when in the hands of an experienced user who has a good knowledge of policies and guidelines. Unlike NPP however, it does not have a detailed tutorial, and reviewers' error rates are arguably higher than those of regular New Page Patrollers.[citation needed]. Kudpung กุดผึ้ง (talk) 15:38, 15 September 2016 (UTC)
- I think I must not be making myself clear because this still doesn't confirm the information I'm trying to pin down. To come at it from a different angle: I'm wondering if I understand this RfC correctly for the way the proposed mechanism differs from AfC, where you do not have to submit a request to PERM--you need only achieve the 90/500 threshold (by which time you're automatically extended confirmed and don't have to ask for anything), then you can add yourself, and after that quality control is done by admins removing editors who are unsuitable. (Basically, you can join at will but might be bounced, instead of having to ask to join in the first place.) What I'm asking here is, 1, do I understand correctly that this RfC is meant to preclude that approach (and instead require an explicit request) as a possibility at a subsequent implementation RfC, and 2, if so, why? Innisfree987 (talk) 01:10, 2 September 2016 (UTC)
- This is fully covered in the itroduction, Innisfree987, but to recap, it is proposed that permission will be granted at WP:PERM (take a look there if you are not familiar with it) based on a recommended set of numercial criteria, plus a review of the applicant's editing (see also - just as an example: Wikipedia:WikiProject Articles for creation/Participants). Users who have already demonstrated recent competent patrolling would be grandfathered into he right. The right would be subsumed into that of Admin. There is a school of thought that in spite of occasional peaks of backlogs, it is better to let articles stay unpatrolled for a while rather than to bite good-faith newcomers and/or let totally inappropriate articles into he encyclopedia for ever more. Indeed, the earlier system of NPP allowed just that: any unpatrolled articles older than 30 days became de facto patrolled - there must be hundreds of thousands of them. With the extremely low current participation at NPP, it is hardly likely that the new requirement would make the situation worse. Indeed, the way users clambour for other minor rights suggests that with a hat to wear, NPP might even get a boost.Kudpung กุดผึ้ง (talk) 23:17, 1 September 2016 (UTC)
- I support the idea of creating a two tiered system as has been described by a couple of people already. Not only will it put an extra layer of protection on the new page patrol process, it will also be useful to newbies learning how to patrol pages by looking at the ones that have been 'approved' by a senior patroller. --ABF99 (talk) 00:46, 2 September 2016 (UTC)
- I think we can safely declare consensus against the twinkle restrictions. Jjjjjjdddddd (talk) 04:18, 6 September 2016 (UTC)
- "Compare: Page mover, something new page reviewers sometimes need to do (move to Draft), requires 3,000 edits and 6 months of editing history." It isn't a need. WP:CSD#R3 suffices, which anyone can apply a tag for, even those who choose to edit without an account.— Godsy (TALKCONT) 09:59, 15 September 2016 (UTC)
- Having thought about this, would it be easier if we simply removed the autopatrol from Twinkle and page curation. At the moment, I notice that if I tag a page as potentially not notable, it comes up as patrolled, when there's clearly still work to be done on it. I suspect that this may be the source of much incorrect patrolling. If we simply altered the software so that you could tag, nominate for deletion, etc, without saying it's patrolled, would that work?Killer Moff (talk) 12:39, 16 September 2016 (UTC)
- Killer Moff, I think the answer to your question is to ask what you think patrolling is, what it's for. If you tag a page as potentially not notable, that means that you have seen the article, recognized that it has an issue, flagged the issue, but did not feel the issue was bad enough to merit deletion. In other words - the article has been patrolled. Why should it remain on the list for other people to look at when the list is full of articles no one has seen? You have tagged it, and now if someone wants to review articles tagged for notability because they feel like they can specialize in that, it's in a list for them. ~ ONUnicorn(Talk|Contribs)problem solving 16:44, 16 September 2016 (UTC)
- ONUnicorn, do you think there are many people doing that, going through the templated articles according to their interests and nominating for delete as necessary? Because that would be a good system! I just worry it doesn't happen, so I've actually stopped tagging NPP articles now that I have autopatrol--because if I don't nominate for deletion, I really don't necessarily mean I think an article isn't so terrible; I often only mean I don't want the responsibility of being the AfD nominator. (Because AfD feels so battleground to me, but that's a different conversation.) If I thought I could count on someone else seeing it once I've tagged it, then I'd be happy to help sort like that (in fact, I'd probably do a lot of it), but right now I don't think that's in fact what's taking place, so I worry my tagging something takes it out of NPP and means no one will check what are often still seriously flawed entries. But maybe what we need an effort to invigorate the approach you describe. Innisfree987 (talk) 02:42, 18 September 2016 (UTC)
- Innisfree987, I don't think there are many people doing that, and I think there needs to be more. Back in 2006/2007 I was part of Wikiproject Unreferenced articles which was attempting to systematically clear out unreferenced articles by searching for references for them and either adding references or deleting them as appropriate. Like many Wikiprojects it's largely inactive, and has been working on clearing out Category:Articles lacking sources from October 2006 since February 2010. That category still has 74 pages in it.
- I think part of what Wikipedia lacks is organization. We should have organized drives to clear out the maintenace categories. Something like the Wikipedia:Stub Contest, only for unreferenced articles might be fun and have a good result. Points could be awarded for each article taken from 0 sources to at least 5 sources, each article deleted if sufficient sources could not be found, each unsourced article fully sourced and achieving at least a B quality, oldest unsourced sourced, etc. The same could be done for the articles lacking notability categories, the articles needing copyediting, rough translations, etc. Someone just needs to take the initiative.
- Part of the problem with the mainteance categories is that working on them is a lot of work. It's way more work to verify and add sources to a totally unsourced article that you know little or nothing about than it is to write an article from scratch on something that may be of more interest to you, that you already have sources for. Also, there's more "glory" in writing new articles. If you watch WP:RFA people are always looking for "content creators," not "content improvers." If one takes an article that someone else has written and spend hours finding sources for it and copyediting it and restructuring it and basically doing the whole thing over, but it's not good enough to take to GA or FA, what do they gain? It's not eligable for DYK, if they were to run for RFA they would not be considered a "content creator". But if they were to write a similar quality article from scratch the article could be featured on the main page, and they would be lauded as a "content creator" at RFA, and the process is easier.
- At any rate, I'm getting off topic here. The topic is supposed to be about improving new page patrol; not improving workflows and motivating people on Wikipedia more generally. Suffice to say that I have noticed people occasionally nominating articles long tagged with notability concerns or lacking references for deletion, and I have noticed myself and others occasionally adding sources and trying to address tagged issues without nominating for deletion, but like with everything else in Wikipedia the process is disorganized and ad hoc, and people do what they want. ~ ONUnicorn(Talk|Contribs)problem solving 14:17, 19 September 2016 (UTC)
- ONUnicorn, do you think there are many people doing that, going through the templated articles according to their interests and nominating for delete as necessary? Because that would be a good system! I just worry it doesn't happen, so I've actually stopped tagging NPP articles now that I have autopatrol--because if I don't nominate for deletion, I really don't necessarily mean I think an article isn't so terrible; I often only mean I don't want the responsibility of being the AfD nominator. (Because AfD feels so battleground to me, but that's a different conversation.) If I thought I could count on someone else seeing it once I've tagged it, then I'd be happy to help sort like that (in fact, I'd probably do a lot of it), but right now I don't think that's in fact what's taking place, so I worry my tagging something takes it out of NPP and means no one will check what are often still seriously flawed entries. But maybe what we need an effort to invigorate the approach you describe. Innisfree987 (talk) 02:42, 18 September 2016 (UTC)
- Killer Moff, I think the answer to your question is to ask what you think patrolling is, what it's for. If you tag a page as potentially not notable, that means that you have seen the article, recognized that it has an issue, flagged the issue, but did not feel the issue was bad enough to merit deletion. In other words - the article has been patrolled. Why should it remain on the list for other people to look at when the list is full of articles no one has seen? You have tagged it, and now if someone wants to review articles tagged for notability because they feel like they can specialize in that, it's in a list for them. ~ ONUnicorn(Talk|Contribs)problem solving 16:44, 16 September 2016 (UTC)
- ONUnicorn, ok, that makes sense. I suggested it largely owing to the number of people saying that the current system is broken and there's too many problem patrollers. Maybe there would be a way to return it to unpatrolled if the tags are removed without any substantial changes? Killer Moff (talk) 13:39, 17 September 2016 (UTC)
- Killer Moff If you tag an article and you don't want it to be marked as patrolled, you can manually unmark it while leaving the tags, but I don't think it automatically returns to unpatrolled if the tags are manually removed by the creator. Annoyingly, articles are returned to unpatrolled status if they are converted to redirects and then back to an article. So sometimes very old articles show up on NPP as a result of redirect vandalism. ~ ONUnicorn(Talk|Contribs)problem solving 14:17, 19 September 2016 (UTC)
- ONUnicorn, ok, that makes sense. I suggested it largely owing to the number of people saying that the current system is broken and there's too many problem patrollers. Maybe there would be a way to return it to unpatrolled if the tags are removed without any substantial changes? Killer Moff (talk) 13:39, 17 September 2016 (UTC)
Closure requested
[edit]Since 30 days have elapsed, I have requested that this discussion be closed at Wikipedia:Administrators' noticeboard/Requests for closure. Mz7 (talk) 14:03, 30 September 2016 (UTC)
- There is an additional post about this on the main noticeboard as well. Jo-Jo Eumerus (talk, contributions) 16:38, 30 September 2016 (UTC)
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.