Wikipedia talk:New pages patrol/RfC for patroller qualifications

Suggestion: central basis of criteria should be qualitative, not quantitative

Objective criteria are important, maybe even totally necessary, but I think the core criteria should based on the performance objectives and not raw edits/days experience. This isn't a generalist permission like extended confirmed, but a specialist role.

How about:

Alternate proposal #1

Proposal

Requests for the patroller right will be made at WP:PERM. Editors receiving the patroller right should have an editing history that demonstrates the ability and demeanor suitable for new page patrolling, particularly:

A thorough understanding of deletion policy and speedy deletion,
An understanding of key policies such as WP:BLP, WP:COPYVIO, and WP:VANDALISM,
The ability to communicate and avoid biting the newcomers, and
An understanding of categorization.

Based on the analogous requirement for review of Articles for Creation submissions, an entry threshold of 90 days of active account use and 500 nontrivial edits to mainspace is suggested.

I'm also not how important it is to spell out the behavioral/3RR block exclusion in the proposal (or the other "Guidelines for granting" currently in the proposal, for that matter). They seem like things that the admin reviewing WP:PERM could evaluate case-by-case. VQuakr (talk) 00:13, 6 October 2016 (UTC)[reply]

We want this project to succeed. We have escalated the issue to the level of CEO of the WMF, let's not now do anything that's going to become another toilet-roll long RfC for something clear and simple and more bulling the proposer. I don't own the project, but as the only one who is constantly taking the initiative I don't want my time wasted. Kudpung กุดผึ้ง (talk) 01:09, 6 October 2016 (UTC)[reply]

No one wants their time wasted, but I'm having trouble understanding how your response matches up with the proposal. You feel that the above proposal is more likely to rathole the RfC somehow? VQuakr (talk) 01:16, 6 October 2016 (UTC)[reply]

Quite so. I don't feel it, I know it. People will try to re-debate the whole thing anyway - they always do. Getting consensus for anything obvious on Wikipedia through our RfC system is a nightmare. And I thought you were supposed to be on vacation ;) Kudpung กุดผึ้ง (talk) 01:22, 6 October 2016 (UTC)[reply]

Document everything

This should clearly document all the changes being made at once (not up for debate - but to have a solid documentation for the phab request)

Create patrollers groups
Add patrol permission to patrollers group
Localize the name of the patrollers group to "New page reviewers" (done locally in mediawiki space)
Remove the patrol permission from the following groups: autoconfirmed; confirmed; pending changes reviewers

Anything I'm missing here Kudpung ? — xaosflux ^Talk 00:55, 6 October 2016 (UTC)[reply]

I don't think it's really necessary to add to crats (practically we're not going to be getting any non-admin 'crats) or stewards. — xaosflux ^Talk 00:56, 6 October 2016 (UTC)[reply]

This mentions a new user "right" I think it should be a new user "permission group" - the group gets rights, users get groups. The "right" (patrol) isn't actually new at all. — xaosflux ^Talk 01:04, 6 October 2016 (UTC)[reply]

@Xaosflux: Does removing the patrol permission confined to the group you've mentioned? What about other user groups? For example, Template editors and Mass message senders are no way connected to the reviewing experience. Please ping me while you reply. Regards, Krishna Chaitanya Velaga (talk • mail) 01:15, 6 October 2016 (UTC)[reply]

@Krishna Chaitanya Velaga: those groups don't have this permission today. The (patrol) permission is only included in the groups:autoconfirmed, confirmed, pending changes reviewers, and administrators. It is important to note that you can be a member of multiple groups at a time. It is technically possible to be a template editor today, and not be confirmed or autoconfirmed - in which case they could not "patrol". The prior RfC pretty much said this should be its own group, if someone like you (who is a member of Extended confirmed users, Page movers, Mass message senders and Pending changes reviewers, Autoconfirmed users) wants to patrol after this change you would also need to be in the patrol group. — xaosflux ^Talk 02:02, 6 October 2016 (UTC)[reply]

Xaosflux I see we're splitting hairs over vocabulary again. You appear to have forgotten the very long (and time consuming) discussion you drew out of me on my talk page.

Kudpung Just to clarify, being a member of the new usergroup is necessary to perform the following (technically separate) actions: patrol pages via clicking "Mark this page as patrolled" on the right bottom corner, and use the Page Curation tool to mark pages reviewed and apply deletion tags, is that right? Thanks, — Andy W. (talk · ctb) 01:37, 6 October 2016 (UTC)[reply]

Kudpung I think we are 100% in agreement for "what" is trying to be done - and these terms do actually mean different things from an implementation point of view - not from a "practical" point of view. Unless I'm grossly missing something here I can't see any reason why we can't use the accurate terminology. That it is going to happen is not up for debate anymore. — xaosflux ^Talk 02:08, 6 October 2016 (UTC)[reply]

And I do very much remember Special:PermaLink/736428600#NPP_Part2 and my points above match points 1,2,3 that we seemed to be in agreement with back then. — xaosflux ^Talk 02:34, 6 October 2016 (UTC)[reply]

That is absolutely correct Andy M. Wang. And due to the fact that there is nobody patrolling pages at the moment excepta handfull of people who are getting it very wrong, we now have a complete team of engineers at the WMF working to improve the tools and a user right will be required. Nothing here will affect you personally if you ave established yourself already as a regular page patroller. And if you haven't it will take you 30 seconds to apply for it. Did you participate in the previous RfC? Kudpung กุดผึ้ง (talk) 01:49, 6 October 2016 (UTC)[reply]

Krishna Chaitanya Velaga I don't see what this has to do with holders of user rights who are not in any way connected in new article reviewing. Did you participate in the previous RfC? Kudpung กุดผึ้ง (talk) 01:39, 6 October 2016 (UTC)[reply]

@Kudpung: Got the point, thank you. No, I did not participate. Does that mean I should not participate now? Actually I was unaware of the RfC then. Regards, Krishna Chaitanya Velaga (talk • mail) 01:41, 6 October 2016 (UTC)[reply]

@Krishna Chaitanya Velaga: of course you can participate, but as this is an extension RfC it would be very good if you would please find out what it's all about. That's why there's a link on the very top of this RfC. Thanks.Kudpung กุดผึ้ง (talk) 01:51, 6 October 2016 (UTC)[reply]

I added the technical summary, collapsed to the main page - if anything is factually inaccurate - please discuss here. — xaosflux ^Talk 12:23, 6 October 2016 (UTC)[reply]

@NgYShung: You mentioned something might be wrong in the Summary of under the covers technical changes section? If there is something technically wrong - can you elaborate? If it just needs copyedits, style changes, etc - go for it :D — xaosflux ^Talk 16:31, 6 October 2016 (UTC)[reply]

@Xaosflux: Yes, as I mention in the discussion there, there is a little bit of contradiction at that section. For example, if a user meets the grandfathered right to patrol, but it is in the autoconfirmed or reviewer group, according to the technical changes, the patrol right will be removed. And another one is that new user can patrol new pages, since there is no mention in the technical changes that it will be removed (Small disclaimer: I didn't know that if new user can patrol new pages since there is no mention in WP:NPP). It just need more context for the technical changes section so someone (like me) does not misunderstood the meaning of the new patroller rights. Cheers! NgYShung ^huh? 03:51, 7 October 2016 (UTC)[reply]

NgYShung with the technical change alone, the ability to patrol pages will be removed from someone in your groups - the proposal is that if you qualify a process will be enable to add you to the patrol group - if you don't "qualify" for automatic (which does not look like it will be automatic by the software but by the implementers actually click buttons) you would have to request the group if you wanted it. I'll see if this can be cleaned up a bit. — xaosflux ^Talk 13:01, 7 October 2016 (UTC)[reply]

NgYShung also to be clear, you do not currently have patrol access by way of the groups you mentioned, you have it because you are in the autoconfirmed group, which is listed. — xaosflux ^Talk 13:06, 7 October 2016 (UTC)[reply]

@Xaosflux: Thanks for your explanation. I "sort of" get it now. Still need a bit of re-reading afterwards. NgYShung ^huh? 15:24, 7 October 2016 (UTC)[reply]

Question Does the (patrol) permission grants to every user originally? Since there is no specification at NPP, I supposed it would. NgYShung ^huh? 15:24, 7 October 2016 (UTC)[reply]
For the complete information please see Special:ListGroupRights. — xaosflux ^Talk 18:32, 7 October 2016 (UTC)[reply]

Automatically?

The proposal has a granting line to be done "automatically" are we expecting this to be done by mediawiki software, or assisted via reports and admins? — xaosflux ^Talk 01:02, 6 October 2016 (UTC)[reply]

That is irrelevant, but the way other people take initiative here, I'll probably end up doing it myself manually. That said, it can easily be done by a script and I have someone on hand who can do it. Let's not please clog the issue up with minor technicalities at this stage. --Kudpung กุดผึ้ง (talk) 01:15, 6 October 2016 (UTC)[reply]

I'm assuming this can be determined manually by the the sum of entries in the curation, deletion tag, and patrol logs for each user. My hunch is that it's infeasible for the software to determine the number of uncontested/reverted entries in these. — Andy W. (talk · ctb) 01:56, 6 October 2016 (UTC)[reply]

Like I said above, Andy M. Wang, with the amount of actual help that comes from other members of the community except for nit picking, I'll proably end up doing it my self manually any way, I usually do. But there are ways of semi-automating it. But don't expect me to writ e the script and show you how it's going to be done; unless of course you're volunteering... Kudpung กุดผึ้ง (talk) 02:02, 6 October 2016 (UTC)[reply]

My question was only to determine if this was going to require a software request to developers on closing - do we have a "rough" idea (in 100's or 1000's) of editors this needs to be applied to? — xaosflux ^Talk 02:06, 6 October 2016 (UTC)[reply]

Mostly asking because complex autopromotion schemes in the software have been very buggy (for example the autoreview group on trwiki). — xaosflux ^Talk 02:16, 6 October 2016 (UTC)[reply]

Thanks, I understand the outlook of the clause, no worries. Folks will surely find a way to make the transition as smooth as possible if the RfC passes. I'm sure as a community we'll be acting on the spirit of the grandfathering clause on the RfC in any case, whether automated or not. — Andy W. (talk · ctb) 02:13, 6 October 2016 (UTC)[reply]

Xaosflux, there are probably no more that about ten or 20 users who fall into the grandfathering parameters. If you've been following WP:NPPAFC you'll see the current state of affairs and why I already have a team of WMF devs working for us on this. I have made it clear to them that we as a community do not think it appropriate to rely on, or even expect, the community volunteers to write critical core software just because we might happen to know a bit about software programming - after all, our main job is supposed to be building an encyclopedia and controlling its content for quality, and making sure that the editors behave themselves. That's why I always play ignorant and give the impression that i haven't a clue. 15 hours a day initiating and managing these projects on behalf of our en.Wiki community is already enough. It's 9am now, I've worked all night on this and I'm now out of town for the rest of the day for a hospital appointment. Kudpung กุดผึ้ง (talk) 02:59, 6 October 2016 (UTC)[reply]
Thanks, we would not really have a need for this to be done by the software for such a low number. — xaosflux ^Talk 11:56, 6 October 2016 (UTC)[reply]

Good sample: Page movers

Wikipedia:Page_mover#Guidelines_for_granting is a fairly good, recent, sample of some criteria for granting - and also criteria for removal -- this may be good to model part on that are not yet included. — xaosflux ^Talk 01:07, 6 October 2016 (UTC)[reply]

I don't intend including it. It was included in the precursor RfC and I see no need to drag everything through the mill again. Wikipedia editors will just jump at he opportunity to re-debate the whole thing - they always do. Kudpung กุดผึ้ง (talk) 01:11, 6 October 2016 (UTC)[reply]

Query on numbers

In the discussions on this and the main page, I am seeing it said that only tiny numbers of people are currently patrolling new pages. Aside from this proposal being more likely to result in a diminution than an increase in that number, the assertion doesn't seem to match what I am seeing. Yes, there is a massive backlog but I also see (a) significant volatility in Special:NewPagesFeed with pages appearing then being quickly picked off and (b) a range of users involved in the consequent CSDs (for example, when the originator removes the tags). Are there solid figures on the actual number of editors patrolling? (And to be clear, I am meaning the broader type=patrol rather than type=pagetriage-curation which captures only the subset using one tool.) AllyD (talk) 16:09, 6 October 2016 (UTC)[reply]

While we're looking for numbers, an actual number of editors that would be grandfathered in would be nice too. It would help determine how many people that this RFC would actually affect immediately. -- AntiCompositeNumber (Leave a message) 01:42, 11 October 2016 (UTC)[reply]

Did we ever get anywhere on this? As they have to be done "manually" is a list being formulated somewhere? — xaosflux ^Talk 23:30, 19 October 2016 (UTC)[reply]

The RFC has been closed, and there is still no visible list of editors that are eligible for threshold 2. -- AntiCompositeNumber (Leave a message) 23:19, 24 October 2016 (UTC)[reply]

Will this require Twinkle re-engineering?

Following from the consensus on the earlier RfD, the present proposal says "Access to Twinkle is not affected by this new user right." However, when one uses Twinkle to mark an article for speedy-deletion, the message sequence is:

Tagging page: completed (Blah)

Marking page as patrolled: done

Opening page "Blah": Retrieving page creator information

Notifying initial contributor (User_foo): completed (User talk:User_foo)

Adding entry to userspace log: Saving page...

What is the consequence in the post-RfD scenario where the Twinkle user does not have this new Patroller right? Will the Twinkle CSD function fall over at the second step? Will a re-engineering change to Twinkle need to be initiated to introduce conditional logic interrogating the user right so that it gracefully moves on to complete steps 3-5 but leaves the article unpatrolled? AllyD (talk) 07:22, 11 October 2016 (UTC)[reply]

AllyD Access to Twinkle is not affected by this new user right. Pages can be tagged but they will remain unpatrolled until patrolled through Page Curation by an authorised patroller. This provides a double (or even triple) control which should help reject the rampant incorrect tagging - or letting disallowed pages through into the encyclopedia. Only when correctly patrolled will they be able to be indexed by Google.--Kudpung กุดผึ้ง (talk) 09:38, 11 October 2016 (UTC)[reply]

I understand that. But my question is one of consequences for any editor who is not an authorised patrollers. I would be comfortable that their functional capabilities would be unaffected if Twinkle has existing inbuilt resilience to cope with the highlighted 2nd step in my example being incompatible with the editor's rights. But if there is a risk that Twinkle will be unable to proceed in that circumstance and in particular would not inform the article creator, then that becomes an unplanned bad outcome consequent on the introduction of the new right. AllyD (talk) 10:11, 11 October 2016 (UTC)[reply]

@Kudpung: On a related topic (while not wanting to detract from my question), thinking about the interaction of the CSD tools and your plans to make wider indexing dependent on patrolled status: Should the tools be adjusted to cease to flag "patrolled" when tagging an article for CSD? The CSD is not always accepted, for example, if content was added after it was tagged A3. This looks like an exploitable loophole, unless the admin reviewing the A3 is expected to also complete an NPP of the extended article (which adds to their workload). It could be better to break the link, so that both Page Curation and Twinkle tools leave a CSDed article unpatrolled? AllyD (talk) 10:43, 11 October 2016 (UTC)[reply]

You need to decide whether you want the current situation where all and sundry are allowed to patrol new pages without any clue, letting the paid spammers in and biting the good faith editors who are victims of the Foundation's refusal to provide them with a start page. What we are proposing here might not be perfect but it's a step in the right direction. Kudpung กุดผึ้ง (talk) 11:52, 11 October 2016 (UTC)[reply]

The twinkle devs should review they have fall-forward error handling in the event a step fails, alternately skip steps that are impossible with the existing access - this can be programmed now without impacting anything. — xaosflux ^Talk 14:52, 15 October 2016 (UTC)[reply]

While looking at WP:TW/PREF for something else, I notice that Mark page as patrolled when tagging is qualified with (if possible), indicating an existing conditionality. And as it is a Tick box, those without the new right will be able to untick that preference so that Twinkle will not even evaluate the Patrol status, which seems ok. AllyD (talk) 15:29, 16 October 2016 (UTC)[reply]

Thanks AllyD! Seems like this is a non-issue. — xaosflux ^Talk 15:57, 16 October 2016 (UTC)[reply]

"until a clear consensus is obvious"

@Callanecc and L235: Does this seem like clear consensus is obvious? It's an 89% leaning support, and voting/attempting to reach consensus seems to have died down. Dat Guy^Talk_Contribs 15:49, 19 October 2016 (UTC)[reply]

If consensus doesn't substantially change, per the "This RfC will run for 30 days or until a clear consensus is obvious", I'll be glad to close on 24 Oct 2016 (three weeks after opening the RfC). Any objections, Callanecc? Kevin (aka L235 · t · c) 02:06, 20 October 2016 (UTC)[reply]

It looks as if the proposer was quite clear with This RfC will run for 30 days or until a clear consensus is obvious, and will be closed by any uninvolved established user.. I wouldn't have thought that a vote on the validity of that statement would be necessary. --Kudpung กุดผึ้ง (talk) 05:57, 20 October 2016 (UTC)[reply]

If it had died down to no comments I wouldn't have a big problem. Given that there's still discussion on going I'm not so sure. Also, running the RfC for only half the advertised time might mean that others who were planning to comment later on in the process aren't able to do so. Callanecc (talk • contribs • logs) 07:22, 20 October 2016 (UTC)[reply]

Hey Callanecc: I am now prepared to close this as consensus to implement the proposed standards. Would you like to co-close? (I'm OK either way.) Kevin (aka L235 · t · c) 21:56, 23 October 2016 (UTC)[reply]

I've actually gone ahead and closed the RfC as it's now the promised 24 October and there is an "obvious", "clear consensus". Please feel free to join if you'd like. Kevin (aka L235 · t · c) 20:31, 24 October 2016 (UTC)[reply]