Wikipedia talk:Pending changes/Request for Comment 2016

RfC options

I don't believe you need an RfC to get community opinion whether or not to run an RfC. As proposed at the Village Pump, all you need is a few tips and tweaks from people who know how to run RfCs and whether they believe the RfC has a chance of consensus or if the proposal will be a non-starter.

I think the time is right for another formal discussion on PC2, although the community was getting pretty sick and tired of hearing about it. Your proposal must include the description of PC2 (even I had to look it up just now): Pending-changes protection level 2 means edits by unregistered, new contributors, and autoconfirmed contributors are not visible to readers who are not administrator, until the edits are approved by a reviewer or administrator., because many RfC participant do not follow the links in an RfC preamble and they vote from the hip or 'as per' someone else without really understanding what the RfC is all about. May opponents to such proposals are based on straw-man rationales such as :'gives too much additional power to admins', or 'simply adds more bureaucracy to Wikipedia'.

I don't know how I would vote on another RfC about PC2 or even if I would bother to vote on it. What I do know however, is that it is high time the community really woke up to the urgent need for more and better control over the quality of article content and new articles. Kudpung กุดผึ้ง (talk) 03:39, 22 September 2016 (UTC)

Hi Kudpung, thanks, yes I've been following the patroller RfC. I may cast a !vote if I start to feel more strongly than my current ~neutral comment. Thanks for your comments on this one.

I initially thought that it might not be possible for 1 RfC to establish consensus after such a long time, especially since folks after 2 years may have other ideas now. Thought that giving options like "proposal 1; proposal 2; proposal 7; other; and no" might also more difficult to manage than 2 yes/no questions (roughly). If it started ballooning in options (like the 2014 RfC), I don't think the RfC will pass with consensus. But I'll gladly reformat it perhaps as "prop 1; prop 2; prop 7; other; no" if folks believe it will help speed it up. Added clarification about PC2. Also hope you don't mind my sectioning this— Andy W. (talk · ctb) 04:27, 22 September 2016 (UTC)

In my experience, RFCs on the lines of "proposal 1; proposal 2; proposal 7; other; and so on' are a sure-fire recipe for failure. The paradix is, however, that on the best worded RfC there will always be users who will state, on the same RfC, 'this RfC offers too much detail at this stage', or 'there is no scope on this RfC for alternative suggestions', or even 'the proposal (and/ornit options) do not provide sufficient detail'. There are also those who deliberately attempt to derail the RfC by saying that the coding (if it concerns new features) should be discussed there and then, which of course is frankly ridiculous - you dont't built a railroad before you've invented the locomotive. There are also genuinely plenty of people who vote on RfCs without having the slightest clue what it's all about, and there are also plenty of trolls (run your mouse over the user names and see in the popups just how many have been blocked}, and some who are just plain arrogant and nasty.

You can please some of the people all of the time, and all of the people some of the time, but you cannot please all of the people all of the time. Kudpung กุดผึ้ง (talk) 14:07, 22 September 2016 (UTC)

September 25 thoughts

Becoming inclined to archive this RfC draft without too much feedback despite a VP post. In the spirit of WP:IAR and WP:BOLD, and as the writer of this draft, I might withdraw. I was not intending on !voting support for PC2 actually, had been mostly neutral, but the more I think about this, the more I feel that technical issues have not been addressed properly. Several spring to mind:

1. The very nature of PC2 allows valid combinations with other protections levels and be a distinct prot/pending changes setting, i.e. PC2+ECP or PC2+TPROT are distinct and its implications are largely unknown to the community and have largely been undiscussed. The way I phrased this RfC makes it difficult to discuss this and be extremely visible I think
2. Undiscussed whether it makes sense to set autoaccept=extendedconfirmed or a different group other than reviewer. (not as of 05:50, 25 September 2016 (UTC))
3. Bots are not reviewers (don't have review?), so I believe that helpful bot edits on a PC2 page will need explicit review by others
4. Reviewers might not be qualified to take the PC2 task on, and folks granted the right have not be granted based on the fact that PC2 is policy.

If anyone had comments on possibly rephrasing this RfC, I'm not opposed to it in the slightest. — Andy W. (talk · ctb) 05:46, 25 September 2016 (UTC)

Comments on Andy's points:

1. PC+TPROT could be used, but using it doesn't make sense. Transclusions will use the top revision, reviewed or not. Also reviewers that are not template editors cannot revert and may not have sufficient understanding of templates/modules to review edits to them.
2. Any usergroup with review should also have autoreview. autoreview could also be granted to others.
3. Bots have autoreview, so the edits don't need review unless there are unreviewed edits when the bot makes its edit.
4. This is the biggest issue with implementing PC2. The requirements for granting reviewer would need to be revised and the those not meeting the new requirements removed from the group. If PC2 becomes common, many experienced reviewers would be needed.

— JJMC89 (T·C) 08:37, 25 September 2016 (UTC) (strike 05:41, 26 September 2016 (UTC))

Hi JJMC89, thanks. Though several things:

1. I tried PC2+TPROT at the test wiki and determined that non-TE reviewers are unable to review the page, which alleviates the template expertise issue, which is good. (Behavior seems similar to how the ability to move depends on the ability to edit, i.e. if an admin intentionally goes out of his/her way and sets only edit protection to full and move protection to none, non-admins cannot move the page) The question might be whether there should be an explicit "sign-off" or rejection from the community for these combos.
2. If autoreview is granted to other usergroups other than the 5 autoconfirmed groups, that affects only PC1, doesn't it, not PC2? I mentioned a potential currently-nonexisting PC setting (autoaccept=extendedconfirmed) because it may have fewer logistical/technical issues than the autoaccept=reviewer topic of this RfC and may gain support more easily (but I might want to refrain from bringing up other ideas prior to this particular RfC, not sure)
3. Re Bots have autoreview: but still certain that bot edits don't go live with PC2 set. Non-reviewer (Auto)confirmed editors have autoreview, but their edits surely do not go live when PC2 is set. From Wikipedia:PC2012/RfC 2, it's unclear whether there's an existing bot that accepts other bots' edits. Xaosflux?
4. Perhaps this draft RfC should mention Proposal 15 from the 2014 RfC?

I'm becoming certain that this RfC is not ready... — Andy W. (talk · ctb) 00:27, 26 September 2016 (UTC)

Bots do not have the (review) permissions by default, so do not mark other edits as reviewed. There are a very few (5) bots that have pending changes reviewed access - if PC2 gains wide use we may need to evaluate what is expected for bots that will edit PC2 pages with pending edits - for the most part it is likely best that their edit stay pending as well - as they likely won't be expected to be able to review the prior versions. — xaosflux ^Talk 02:05, 26 September 2016 (UTC)

@Xaosflux and JJMC89: Agree that bot edits after unreviewed changes should remain unreviewed in both PC1 and PC2. If a PC2 page has no pending revisions and a non-reviewer bot makes an edit, the single bot edit needs review by others. I think it would be a reasonable reviewer bot task to review bot-only pending changes (a situation that occurs only when PC2 and not possible in PC1). — Andy W. (talk · ctb) 02:27, 26 September 2016 (UTC)

Replies

1. That makes sense that non-TE reviewers cannot review TPROT pages. PC2+TPROT isn't more effective than TPROT unless the configuration is changed, so I don't think explicit approval is necessary. PC2+ECP maybe.
2. You're correct. I don't think FlaggedRevs supports configuration for this.
3. I was mistaken about this – the bot edits I check were from a reviewer bot. review could be added to the bot user group so that bot edits would be automatically accepted if there aren't any unreviewed edits. Alternately, a reviewer bot that automatically accepts unreviewed bot edits where those edits are the only unreviewd ones would be useful.
4. Probably. Current reviewers weren't appointed with PC2 in mind.

As an aside, does anyone know what validate is used for? Anything in the current enwiki configuration? — JJMC89 (T·C) 05:41, 26 September 2016 (UTC)

Curious too. Ping VPT? Possibly a remnant of Wikipedia:Flagged revisions#Unsuccessful proposals — Andy W. (talk · ctb) 06:07, 26 September 2016 (UTC) 23:16, 29 September 2016 (UTC)

'Validate' is a userright that exists in the default config of FlaggedRevs and simply wasn't removed. It does nothing here. Cenarium (talk) 00:22, 26 October 2016 (UTC)

Draft 2

The old draft is here. I've re-drafted the RfC on potentially redefining the threshold for automatically accepting edits from "reviewer" to "extendedconfirmed". I think the page as it stands possibly deserves some needed copyediting, and possibly some minor elaborations or clarifications, or possibly more importantly, some tasteful trimming? Aiming for approx. Nov. 1 for opening at this point. — Andy W. (talk) 02:12, 27 October 2016 (UTC)

The table is probably too complex and difficult to read. It's a particular concern as one of the main objections to PC2 is that it adds too much complexity. But in practice many of those combinations won't occur. We could do without the templateeditor level, which should IMO not be combined with extendedconfirmed protections. Broadly speaking, EC is for mainspace while TE is for template-space, they shouldn't mix. (If anything, for the future, a templateeditor-pending changes protection would make more sense, it would be to TPROT as EC-PC2 is to EC-protection). We could also do without the admin level, which isn't interesting, to further simplify. Cenarium (talk) 04:55, 27 October 2016 (UTC)

@Cenarium: I'd strongly agree that TPROT and PC don't mix well in general, especially when it comes to transclusions and unreviewed changes. I'm planning on trimming and making the RfC a bit leaner soon. (Reluctant about trimming the table, but it makes sense. If someone asks for what the full prot/pc table looks like, I may refer a permalink.) — Andy W. (talk) 05:16, 27 October 2016 (UTC)

It'd be nice though if pending changes worked with template protection. That would make it easier to operate a kind of code review on templates and modules, something developers have asked for for JavaScript. Something worth asking on Phabricator? Jo-Jo Eumerus (talk, contributions) 06:03, 27 October 2016 (UTC)

Hi Jo-Jo Eumerus, don't know how tricky it is to get unreviewed edits on transcluded pages not showing up. I believe this is tracked with phab:T61102. Cenarium might be working on it — Andy W. (talk) 06:15, 27 October 2016 (UTC)

Yes, I'm interested in working on it, but first I'd like to know if there is consensus for use. This would only address templates (and files) though, not javascript (it would be way harder to develop a system to review common.js). I've started a rough draft of an RFC, but this isn't for anytime soon. Cenarium (talk) 02:46, 29 October 2016 (UTC)

Discussing who and how to close this RfC

Looking at this RFC, it will be tricky to close. Two reasons:

1. As with many PC related things over the years, there is a majority for change, but not an overwhelming one. If it was purely a matter of numbers, this would be 'no consensus', but it isn't purely a matter of numbers.
2. I think some of the heat has gone out of the PC discussions since 2014, but I still think there is potential for drama, whichever way the RfC is closed.

Therefore, I think it is important that the closer look very carefully at the arguments presented and is prepared to show that they have done this in the closing statement.

I am willing to do the close, but thought I should put that idea forward here first, in case anyone objects. I haven't commented on this RfC. I have made comments on some of the previous PC RfCs, but these have *mostly* been to clarify things and summarise things, rather than arguing for one 'side' or the other.

So...

1. Does anyone have any comments on what I've said about the nature of the close?
2. Does anyone object to me closing this RFC?

Yaris678 (talk) 00:27, 2 January 2017 (UTC)

Yaris678 and Cenarium, if another relisting is unnecessary, how is this RfC trickier to close than previous RFCs on PC2? Would welcoming more comments improve the consensus? George Ho (talk) 01:36, 2 January 2017 (UTC)

I have no objection to any uninvolved editor closing this, so long as they're aware that the standard here (per WP:PGCHANGE) is widespread consensus and are prepared to defend their close against that standard. ~ Rob₁₃^Talk 01:43, 2 January 2017 (UTC)

I can't speak for Cenarium, but in my opinion this is no more tricky than previous PC-related RfCs. My point is that, like previous PC-related RfCs, the closer must pay a lot of attention to the many arguments made and so justify the decision. This is definitely true if closing for a change, per WP:PGCHANGE, as Rob points out. I would argue that a justification is also very useful, if closing for no change, if only to reduce drama, given that there is a majority for change. In practice, that justification may come down to 'the arguments are balanced and so there is no consensus for change', but I would hope that the closing admin is prepared to show (or give a well-supported argument that) the arguments are balanced, rather than just stating it. Yaris678 (talk) 10:26, 2 January 2017 (UTC)

While I agree that this RfC is no more tricky, perhaps even less tricky, than previous PC RfCs, some previous RfCs had a team of closers. For the present RfC, I don't think a team is necessary, but it may be helpful. I'm happy to have Yaris678 close, either solo or as part of team.

I am anxious to have a detailed justification. Community consensus in this RfC, if there is one, is not obvious to me. Plus, there are people on both sides who are passionate about the issue.

In the meantime, would it be possible to mark the discussion as being finished? Occasionally someone adds or modifies their !vote, but if the discussion is being closed then it's really too late to be doing that. Ozob (talk) 20:18, 2 January 2017 (UTC)

Kevin said that he was working on the draft for the closing rationale. George Ho (talk) 20:46, 2 January 2017 (UTC)

I'd begun writing up a close on Dec 26. I see there has been more discussion since then, but they don't appear to change the outcome. I certainly have no attachment to closing; if Yaris678 or anyone else wants to close on their own or on a team with me, I'd be glad to cooperate. If not, I will hopefully have a detailed close ready within a few days. Yaris, if you do want to close with me, can you shoot me an email or a ping on IRC? Kevin (aka L235 · t · c) 21:17, 2 January 2017 (UTC)

OK. I have asked for no more comments on the RFC and emailed Kevin. Yaris678 (talk) 22:52, 2 January 2017 (UTC)

One week later, still not closed ... Pppery 22:55, 9 January 2017 (UTC)

 Done. Yaris678 (talk) 11:54, 13 January 2017 (UTC)