Wikipedia

Wikipedia:Requests for comment/Pending Changes expansion RfC

< Wikipedia:Requests for comment
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Although I still very much support the idea, as a practical matter there is no point in wasting more time on this. Biblio (talk) Reform project. 05:22, 7 November 2016 (UTC)[reply]

This Pending Changes expansion RfC consists of several proposals regarding pending changes protection.

The first two proposals concern the expansion of Level 1 PC protection to either all articles or only ones of the highest quality and/or importance. PC1 protection requires that a reviewer approve any revision by an anonymous or non-autoconfirmed user before it becomes visible to the general public. The aim of these proposals is to ensure that the general public does not see vandalism, inaccurate/unsourced statements, or poorly-written content. In this way, Wikipedia's quality could hopefully be stabilized somewhat, allowing editors to eliminate backlogs without worrying about the backlog increasing yet again.

The third proposal would help PC reviewers deal with the increased backlog by means of more efficient reviewing systems.

As with all other RfCs, this RfC will run for thirty days.

21:14, 6 November 2016 (UTC)

Proposals

edit

A: PC1 protection for all articles

edit

Implement Level 1 Pending Changes protection for all articles. The protection itself would be performed by a bot created for this purpose.

This solution would keep the general public from seeing vandalism or statements that are unsourced/poorly-written, perhaps saving Wikipedia the periodic public embarrassment it has to deal with whenever hoaxes and vandalism are viewed by readers (consider the widespread media attention that Wikipedia recently received after Hillary Clinton's article was replaced with an obscene image).

It is important to recognize that PC1 protection would not keep anyone from actually editing any page. It would simply require that a reviewer approve article edits by an anonymous or non-autoconfirmed user.

Support A

edit
  1. Strong Support. Long overdue. Globally, Wikipedia is the seventh most popular website. Millions upon millions of people rely on it every day for basic information. But yet we continue with a policy of letting any random person add anything they want on almost any article (even our most highly-viewed or highly-prized ones) without even reviewing most of those edits or requiring sources for them. We have no way of knowing how many inaccurate statements may exist on Wikipedia already, due to our laissez-faire quality requirements, and spreading potentially inaccurate or biased information to millions of people is no laughing matter, especially in subjects such as medicine. Such misinformation can have dangerous real-life effects, and it is our moral responsibility to take action to prevent such things.

    Wikipedia has been publicly embarrassed many times, such as when a highly-visible article is grossly vandalized, or when hoaxes or inaccurate information are discovered to have existed for a long time on some articles. Wikipedia itself has a list of such incidents. It is long past time that this endless cycle stop. Why do we keep letting this happen? There's an old saying which says that "insanity is doing is the same thing over and over again and expecting different results." No one person is to blame for this, but what is to blame is the general anti-change environment.

    So these problems are very much fixable, if we simply become willing to try new things and wake up to the need for common-sense changes. And this proposal is one of the simplest, low-impact, most common-sense way to start. An ounce of prevention is worth a pound of cure. Biblio (talk) Reform project. 21:13, 6 November 2016 (UTC)[reply]

  2. Support. Vandalism is too easy, reverting it uses the time of productive editors. Xxanthippe (talk) 22:02, 6 November 2016 (UTC).[reply]
    You know that you will still have to revert the vandalism under this proposal right? --Majora (talk) 22:06, 6 November 2016 (UTC)[reply]
    No that's incorrect. The vandalism will not be allowed to become an edit. Akld guy (talk) 23:29, 6 November 2016 (UTC)[reply]
    You don't seem to understand what pending changes actually does. The edit is still made. Just hidden from view. Inappropriate edits still have to be reverted to remove them from the queue. --Majora (talk) 23:31, 6 November 2016 (UTC)[reply]
    OK, so how is that bad? Catching it before it goes live is far better than allowing readers to see it, perhaps for days before anyone acts, right? Akld guy (talk) 23:58, 6 November 2016 (UTC)[reply]
    It's bad because good edits from IPs will get caught in this too. Possibly getting stuck in unreviewed limbo for a very long time. Baby and bathwater? SpinningSpark 00:05, 7 November 2016 (UTC)[reply]
  3. Strong support. Virtually no other online group allows unmoderated posts, yet here is Wikipedia with a huge reputation to maintain allowing its integrity to be compromised by any anonymous pest. An 'Oppose' editor suggests below that moderation of edits by IP's would lead to a huge backlog. His/her belief is based on the faulty premise that nothing will change after implementation of this proposal, but what will happen is that vandalism and disruptive editing will fall dramatically when IP's find that their attempted edits are being discarded. Most of the problem will vanish abruptly. And there are far too many editors with accounts who want to be able to sneak around in IP mode changing and reverting stuff without revealing the username by which they are known to others who watch the articles, so some of them are sure to oppose. Good editors are being driven away because they see that attempting to stop vandalism and disruption by IP's is futile and time consuming at WP:ANI, and some become so disgruntled that they give up their usernames and resort to that very same disruptive IP editing in order to try to force the solution put forward here. Akld guy (talk) 23:50, 6 November 2016 (UTC)[reply]

Oppose A

edit
  1. Strong Oppose any such implementation should be made server side, creating a protection bot to individually apply protection to over 5 million pages, plus each article as it is created is a recipe for trouble. — xaosflux Talk 21:26, 6 November 2016 (UTC)[reply]
  2. Strongest Possible Oppose: This is essentially what dewiki has and they are literally drowning in pending changes waiting to be reviewed. This is against the very foundation of Wikipedia. An encyclopedia that anyone can edit. Sure a reviewer could just approve every single IP edit made across the project (think about the sheer size of that request for a second) but time and time again studies have shown that the vast majority of IP edits are not vandalism. We might as well just force everyone to make an account at this point. --Majora (talk) 21:34, 6 November 2016 (UTC)[reply]
    The majority of IP edits might not be vandalism, but well over 90% of vandalism is from IPs. And since non-autoconfirmed edits would be reviewed as well, that would prevent someone from just quickly registering an account and vandalizing a page. Therefore, this solution would keep virtually 100% of vandalism from ever being seen. Biblio (talk) Reform project. 21:51, 6 November 2016 (UTC)[reply]
    And it will stop productive editors as well. Or have you forgotten that PC blocks even autoconfirmed edits from being displayed if there is a pending change waiting to be reviewed on the same page? This past year Wikipedia has systematically reduced the editing abilities of normal editors unless they want to jump through the hoops of WP:PERM. This will only further degrade the ability of productive editors who just want to edit. --Majora (talk) 22:11, 6 November 2016 (UTC)[reply]
    If an editor is truly productive, they should have no difficulty acquiring the reviewer right, which they could then use to quickly clear pending edits on any page they want to improve. It's that simple. Biblio (talk) Reform project. 22:28, 6 November 2016 (UTC)[reply]
    Difficulty is irrelevant to the point. And framing it around the "if an editor is truly productive" is insulting. There are those of us who don't want extra hats. Forcing them on people is contrary to the spirit of Wikipedia. --Majora (talk) 22:32, 6 November 2016 (UTC)[reply]
  3. (edit conflict) Oppose – Hardly low impact at all. Imagine the backlog. If you've ever used Huggle, imagine having to accept or revert every single edit that you see pop up in the queue. There's one almost every second. We simply do not have enough volunteers to make the benefits of this proposal outweigh the costs. I envision the backlog going back months, maybe years. We've done pretty well over the past fifteen years without needing this. As for vandalism, the open-editing nature of Wikipedia is both what creates and solves the problem. If any random passerby catches a piece of misinformation in an article, currently they are able to go in and correct the mistake themselves. If this proposal passes, attempts to correct misinformation would get caught in the backlog of edits awaiting review too! Mz7 (talk) 21:38, 6 November 2016 (UTC)[reply]
    Do recall, Mz7, that PC1 protection applies only to non-registered and non-autoconfirmed users, so it would not cover all edits. And as for "doing well," I hardly regard a long record of embarrassments and misleading statements as "doing well." Biblio (talk) Reform project. 21:51, 6 November 2016 (UTC)[reply]
    Every now and then a reporter thinks it a good idea to publish a story about something that was reverted within a few minutes, which is what happened with the Hillary Clinton case you linked above. (Hillary Clinton is semi-protected, so PC1 wouldn't have prevented that instance anyway.) I understand the frustration when this happens, and it certainly forces us to ask how we could do better in the future. I do not think this is better. I understand that PC1 applies only to non-registered and non-autoconfirmed users. Huggle also tends to filter out edits from established users, leaving mostly non-registered and non-autoconfirmed users, and even then, there's about one a second. Mz7 (talk) 22:05, 6 November 2016 (UTC)[reply]
    Addendum: I do also understand the frustration when a long-lasting hoax is discovered. However, these hoaxes are often subtle, which is why they are left undetected for so long. Having to review all edits from unregistered or non-autoconfirmed users might catch some of these hoaxes, but more often than not, with the large backlog, they will get accepted along with the rest of the edits that aren't obvious vandalism. Perhaps your proposal is to have editors fact-check every single edit from unregistered and non-autoconfirmed users to Wikipedia, which would be even less feasible than merely applying our current reviewing criteria, which explicitly does not require reviewers to check edits for V, NPOV, or NOR compliance. At some point, we have to trust that most users want to help the project, not hurt it. Mz7 (talk) 22:18, 6 November 2016 (UTC)[reply]
  5. Oppose Although this seems like a good idea at first glance, the fact is that 32% of edits made on Wikipedia are made by unregistered users.[1] Unless the proposal were to also make the reviewer userright be granted automatically after a certain number edits, The backlog would be unimaginably long. Wikipedia is edited about 3,442,815 times every month[2] (although this includes other namespaces, the vast majority of bad-faith editors are focused on the article namespace), which means its edited around 78 times a minute. This means that 25 edits would be added to the list of edits to review every minute, 1500 every hour, 36000 every day, and there are only about 8000 people who can review these edits, and none of these people dedicate every editing moment to refreshing Special:PendingChanges. This means that every pending changes reviewer would have to review edits at least 4-5 times every day, or else a few people would have to dedicate their work on Wikipedia to doing this and little else. A small (a week or two long) slump in reviewing could lead to a huge backlog that could take months or weeks to be resolved. Applying to a smaller subset of articles might work, but I'm hesitant to support proposal B for many of the same reasons I state here. Gluons12 ☢|☕ 21:52, 6 November 2016 (UTC).[reply]
    6. Hi Gluon12. I considered adding a proposal for auto-granting the reviewer right, but at the time I thought it would be best to handle that separately. Such a thing could be added here, I suppose. Biblio (talk) Reform project. 21:57, 6 November 2016 (UTC)[reply]
    Such a change might make this proposal a bit more viable, but I still don't think that such a change would get me out of the oppose section, simply because many editors it would be granted to wouldn't know what to do with it, and would continue with their normal editing habits, leaving the issue of the backlog intact. Perhaps I spoke a bit too soon in the statement made to that affect above, so I have struck through it. Gluons12 ☢|☕ 22:12, 6 November 2016 (UTC).[reply]
    Obviously, the right would not be granted to any editor who has made a few dozen edits and has managed to avoid being blocked. They would have to have a somewhat substantial track record of being productive. Biblio (talk) Reform project. 22:30, 6 November 2016 (UTC)[reply]
    How would any automated process be able to tell if a user's edits were productive or not, and even if it could, if you don't have to apply for the right, even experienced editors in the content realm might not be sure why it was given to them or what it is for. Furthermore, most experienced editors have their editing habits firmly established (i.e., content creation), and wouldn't want to get involved in reviewing these changes in any case, as it would be very dull work. I also agree with the sentiment expressed by A2soup that "this would be the end of the encyclopedia that anyone can edit." Gluons12 ☢|☕ 22:41, 6 November 2016 (UTC).[reply]
  6. Strong Oppose No, the backlog would be immense, it would only introduce problems. Iazyges Consermonor Opus meum 22:15, 6 November 2016 (UTC)[reply]
  7. Strong oppose - This would be the end of the encyclopedia anyone can edit. Wikipedia should have no gatekeepers. Vandalism-fighting tools have continually improved (edit filters, STiki), and there is less need for this measure than ever. Wikipedia's content declines because there are not enough editors to curate it, not because there are too many editors damaging it. The focus needs to be on involving new editors, not putting up more walls to their involvement. A2soup (talk) 22:21, 6 November 2016 (UTC)[reply]
  8. Oppose: Wikipedia is doing just fine as an encyclopedia that anyone can edit. Please don't "fix" something that isn't broken. --Guy Macon (talk) 22:28, 6 November 2016 (UTC)[reply]
    With all due respect, I'm afraid Wikipedia isn't "just fine" for people who are misled by inaccurate information, forced to stumble through poorly-written content, or have an obscene image put right in their face on a website they thought was safe. Biblio (talk) Reform project. 22:34, 6 November 2016 (UTC)[reply]
  9. Oppose any form of pre-emptive page protection. Hasn't this been discussed (and rejected) several times already? SpinningSpark 22:30, 6 November 2016 (UTC)[reply]
  10. Oppose We simply don't have the editor numbers to check every single edit made, and I suspect this would only help to reduce the number of new good faith editors, who cease to be able to observe their changes to the "encyclopedia anyone can edit" until approved. Sam Walton (talk) 22:35, 6 November 2016 (UTC)[reply]
  11. Strong Oppose: We don't preemptively protect all articles that can discourge newbies and IPs. KGirlTrucker81 huh? what I'm been doing 22:58, 6 November 2016 (UTC)[reply]
  12. Oppose - this would cover way too many edits! Although I would like to see more protection to stop vandals especially ip/non-confirmed this is over the top and would cause a huge backlog of work. From working on Huggle the number of edits this would cover seams huge! I would suggest a more sensible proposal would be automated temporary protection only when an article is considered 'under attack' (i.e. x reverts in a given time period). KylieTastic (talk) 23:20, 6 November 2016 (UTC)[reply]
  13. (edit conflict) No, no no! The backlog this would create would be impossible to handle, discourage our largest contributor group, and would harm content, as articles couldn't be changed by non-reviewers if a non-autoconfirmed edited the page. deferring changes based on edit filters and neural networks is specific enough to not cause harm, but PC1 for everything? It wouldn't work. -- AntiCompositeNumber (Leave a message) 23:22, 6 November 2016 (UTC)[reply]
  14. Oppose This would mean consolidating this encyclopedia; like saying that it is good as it is. It s not yet so, and I sincerely hope it will always remain a work in progress. Also backlog issues would be insurmountable. Debresser (talk) 23:43, 6 November 2016 (UTC)[reply]
  15. Oppose. I am opposed to Pending Changes in any form for any reason, as an undue burden for volunteers on this project and a source of new backlogs when we are not keeping up with existing ones. Either protect or semi-protect the article, if necessary, but don't make other editors excavate the edit history of the article and figure out what's what there and take responsibility for other people's actions. We have better things to do with our time. Nsk92 (talk) 23:52, 6 November 2016 (UTC)[reply]
  16. Strongest possible largest uncountably infinite oppose: Backlog, backlog, backlog. Esquivalience (talk) 00:03, 7 November 2016 (UTC)[reply]
  17. Oppose per above. Wikipedia was founded on the basis of being an encyclopedia anybody can edit. -FASTILY 00:46, 7 November 2016 (UTC)[reply]
  18. Absolutely not!!!! - Wikipedia is supposed to be the encyclopedia that anyone can edit. While this doesn't prevent IP or non-autoconfirmed editors from editing, this will create an enormous backlog and discourage not only new editors but veterans as well, since any edits they make after an unreviewed edit are also blocked from going live and must also be reviewed. How is this even an option? — Jkudlick • t • c • s 01:19, 7 November 2016 (UTC)[reply]
  19. Oppose - The backlog this would create is so ridiculously vast that it would be impossible to maintain. Wikipedia does not have millions of active editors, it has a mere few thousand that cannot keep up with 5 million articles as it is. Now you want to implement PC1 on every single article. No, absolutely not. Mr rnddude (talk) 01:31, 7 November 2016 (UTC)[reply]
    Add; While I like the conclusion Akld has drawn about vandals disappearing if their vandalism doesn't appear. The fact of the matter is that we'd lose both. Vandals would disappear because their vandalism isn't visible, good editors will disappear because their contributions will take days, then weeks, then months, and finally years, to be accepted. We just don't have the resources to maintain this, it would drag Wikipedia to a halt and allow only those of us who are "elites" to truly contribute. We have vandal fighters, high priority pages are on lots of watchlists, this we can survive. Having to meticulously check every non-autoconfirmed edit for accuracy (which is in essence what we're hoping for as misinformation can be disguised to look genuine), this we cannot. Mr rnddude (talk) 01:46, 7 November 2016 (UTC)[reply]
    Days, then weeks, then months, and then finally years? What nonsense! Akld guy (talk) 03:33, 7 November 2016 (UTC)[reply]
    Have you looked at the .de Wiki? Mr rnddude (talk) 03:42, 7 November 2016 (UTC)[reply]
  20. (edit conflict) Oppose – Without being too harsh, I would say it was a good idea at heart, but ideally not a right choice. Like everyone above has stated: backlog on backlog and were free, no need. Adog104 Talk to me 01:45, 7 November 2016 (UTC)[reply]
  21. Strong oppose, as I believe an expansion of PC on this scope will be terribly detrimental to enwiki. Per comments at the ongoing PC2 RfC proposed separately, there are already concerns that the level (despite very limited scope, like ECP) will cause backlogs to increase. There is evidence that despite thousands of reviewers, there are a few who are actually incredibly active reviewing pending changes. This proposal will also render WP:DC2016 somewhat obsolete. And per Majora above: This is essentially what dewiki has and they are literally drowning in pending changes waiting to be reviewed. — Andy W. (talk) 03:52, 7 November 2016 (UTC)[reply]
  22. No way Jose for all the reasons above. We absolutely do not want to clog the servers. I do not know why dewiki has such a policy even on new articles that are hardly even viewed let alone edited or even vandalism. And I think ruwiki is also like this: notice that nearly every edit listed in Recent Changes has been marked as [непров] for needing review. <<< SOME GADGET GEEK >>> (talk) 04:39, 7 November 2016 (UTC)[reply]
  23. Strongest Oppose Possible, to the power of ∞ No, no, no, no. We cannot afford for PCR to get as backlogged as WP:NPP. — Gestrid (talk) 04:45, 7 November 2016 (UTC)[reply]
  24. Oppose - The majority of ip edits are not vandalism. If you think this necessary, mandatory registration makes more sense. EvergreenFir (talk) 05:19, 7 November 2016 (UTC)[reply]

References

  1. ^ "Wikimedia Stats".
  2. ^ "English Wikipedia Stats".

B: PC1 protection for recognized, vital, and BLP articles

edit

Implement Level 1 Pending Changes protection only for good articles, featured articles, vital articles, and biography of living persons articles. As with proposal A, a special bot would be responsible for the actual page protections.

This solution is a scaled-back version of Proposal A. It does not include "less important" articles, only including content of recognized quality, Wikipedia's core articles, and the notoriously sensitive Biographies of Living Persons category. This would ideally protect recognized content from quality degeneration (this sometimes happens when unsourced and poorly-written statements gradually accumulate on GAs and FAs, occasionally leading to their eventual delisting). It would also hopefully protect the integrity of Wikipedia's core articles, as well as prevent defamatory statements and vandalism from publicly appearing on BLPs.

It is important to recognize that PC1 protection would not keep anyone from actually editing any page. It would simply require that a reviewer approve article edits by an anonymous or non-autoconfirmed user.

Support B

edit
  1. Support as second choice, if Proposal A does not pass. Biblio (talk) Reform project. 21:13, 6 November 2016 (UTC)[reply]
  2. Support as above. Xxanthippe (talk) 22:03, 6 November 2016 (UTC).[reply]

Oppose B

edit
  1. Strong Oppose we should not be preemptively protecting any pages. Period. It is against one of the foundations of Wikipedia. The vast majority of IP edits are not vandalism. Even this smaller proposal would increase the workload by thousands of reviews. This is not what Wikipedia should be. --Majora (talk) 21:37, 6 November 2016 (UTC)[reply]
    There is a point to not preemptively keeping people from actually editing a page, but that is not what this does. It simply subjects the page to review, and anyone can still edit as normal. Editors would hardly notice it. And I keep saying that the biggest problem here is the stubborn unwillingness to rethink the way things work, even if a certain system has proven to be troublesome. Biblio (talk) Reform project. 21:55, 6 November 2016 (UTC)[reply]
  2. Strong Oppose We shouldn't preemptively protect pages, the only time I could see it being worth it is if we applied it only to the featured articles of the day. Iazyges Consermonor Opus meum 22:16, 6 November 2016 (UTC)[reply]
  3. Oppose any form of pre-emptive page protection. SpinningSpark 22:31, 6 November 2016 (UTC)[reply]
  4. Oppose: Preemptive page protection goes against our core values. --Guy Macon (talk) 22:33, 6 November 2016 (UTC)[reply]
  5. Oppose per Majora. Sam Walton (talk) 22:36, 6 November 2016 (UTC)[reply]
  6. Oppose per my comments above. KGirlTrucker81 huh? what I'm been doing 23:00, 6 November 2016 (UTC)[reply]
  7. Oppose per my comments in section A and WP:IMPERFECT -- AntiCompositeNumber (Leave a message) 23:26, 6 November 2016 (UTC)[reply]
  8. Oppose better than A as still covers far too many articles and edits. Although I support for "featured articles" (while featured) as they attract vandalism like flies. KylieTastic (talk) 23:29, 6 November 2016 (UTC)[reply]
  9. Oppose I don't think the argument I gave in proposal A is any different here. In addition, I don't think that any article is, from a certain point of view at least, more vital or important than others. Certainly nothing that would justify this level of protection. Debresser (talk) 23:44, 6 November 2016 (UTC)[reply]
  10. Oppose. I am opposed to Pending Changes in any form for any reason, as an undue burden for volunteers on this project and a source of new backlogs when we are not keeping up with existing ones. Either protect or semi-protect the article, if necessary, but don't make other editors excavate the edit history of the article and figure out what's what there and take responsibility for other people's actions. We have better things to do with our time. Nsk92 (talk) 23:52, 6 November 2016 (UTC)[reply]
  11. Strong countably infinite oppose: Better than #1, but still, backlog. Esquivalience (talk) 00:04, 7 November 2016 (UTC)[reply]
  12. Oppose bot implementation plans, there are almost 1 million pages that would have to be individually protected, and then maintaining it will be problematic (e.g. would the bot protect any page that someone put in the living persons category?) — xaosflux Talk 00:08, 7 November 2016 (UTC)[reply]
    @Xaosflux: and then comes the problem of stopping people from putting articles they want protected in the BLP category, rather than having to go through RPP. How would one ever know that it was happening unless they had it on their watchlist, considering as you mentioned it would be one of a million. Iazyges Consermonor Opus meum 00:28, 7 November 2016 (UTC)[reply]
  13. Oppose pre-emptive protection of pages. -FASTILY 00:46, 7 November 2016 (UTC)[reply]
  14. Oppose All forms of pre-emptive page protection blatantly go against WP:AGF. — Jkudlick • t • c • s
  15. Oppose per above, too wide in scope, and don't want to repeat. — Andy W. (talk) 03:54, 7 November 2016 (UTC)[reply]
  16. Oppose per my rationale on Option A. — Gestrid (talk) 04:51, 7 November 2016 (UTC)[reply]
  17. Oppose - Unlike others, I'm not opposed to preemptive protections where vandalism is likely and expected (E.g., sports teams in a finals game; presidential candidates). But a wide scale protection of all blps or top importance pages is too much. EvergreenFir (talk) 05:23, 7 November 2016 (UTC)[reply]

Discussion B

edit
  • I could see this working for BLPs, since the spirit of the BLP policy is that we must get the article right, even if that means setting aside some elements of our standard editing process. However, FAs, GAs, and vitals are still allowed to be imperfect, and they typically have watchful editors that will prevent quality degeneration. Only protect those when necessary after proof of persistent disruption, which is the current practice. Mz7 (talk) 22:50, 6 November 2016 (UTC)[reply]
    Application to BLPs would be a good start, I suppose. Perhaps that can be proposed separately, after these proposals SNOW fail.
    By the way, I hope people don't think I was really so naive and that I actually expected these things to pass. I've certainly been around long enough to know better than to expect that. But I'm the sort of person who believes in trying to improve things regardless of the odds against it happening. I'm very used to people ridiculing my proposals and having them fail, and I really have no issue with being virtually the only person to support or oppose something. I've seen far worse, after all. Someone once compared me to Putin and Kim Jong-Un, just because of an RfA proposal I made. Meanwhile, someone else once called me a "[insert vicious profanity here] troll" and threatened that I had better hope I never cross paths with them. And both of those people got away with it. I could list quite a bit more, but I think my point has been made.
    So anyway, I am not done with proposing improvements in other areas. Biblio (talk) Reform project. 23:44, 6 November 2016 (UTC)[reply]
    Good, don't be! But maybe run through VPI first next time :D As far the above, this will likely SNOW out way before 30 days - but the "WHY" parts of the comments may still be useful. — xaosflux Talk 00:27, 7 November 2016 (UTC)[reply]
    I'll let someone else do the closing, lest I give the false impression that I'm some sort of pouting diva quitter or something. Biblio (talk) Reform project. 00:51, 7 November 2016 (UTC)[reply]
    I too agree with defaulting PC1 to BLPs as there are too many changes being made without providing reliable sources: as soon as someone reverts them that takes care of that individual case and it is not surprising to see BLPs being high vandalism targets too. <<< SOME GADGET GEEK >>> (talk) 04:43, 7 November 2016 (UTC)[reply]

C: Semi-automated tool for pending changes reviewing

edit
Consensus is not necessary to build such a tool.
The following discussion has been closed. Please do not modify it.


Create a semi-automated tool for pending changes reviewers. This tool could be a web interface (such as a special page, or something like Igloo or Lupin). Alternatively, a sort of Approve revision button could be added to pre-existing tools, such as Huggle or Stiki. A tool such as this would hopefully efficiate the reviewing process, and enable reviewers to deal with increased workloads.

Support C

edit
  1. Support. Such a tool would be a great improvement for pending changes reviewers. What is there not to like about it? Biblio (talk) Reform project. 21:13, 6 November 2016 (UTC)[reply]
  2. Support I don't see anything at all wrong with such a change, and it will go from not just being useful to being essential should proposals A or B pass. Gluons12 ☢|☕ 21:20, 6 November 2016 (UTC).[reply]

Oppose C

edit
  1. ...

D: Auto-grant the reviewer right

edit

Automatically grant the reviewer right to users after they have met certain technical requirements. The increased number of reviewers would help deal with the increased backlog that would result from Proposals A and B. The details could be worked out in a separate RfC—only the basic concept should be voted on right now.

Support D

edit
  1. Support This is just another tool. I do think the threshold should be pretty high. Debresser (talk) 23:46, 6 November 2016 (UTC)[reply]
  2. Support: I think extendedconfirmed is enough: if they can fulfill edit requests to our most controversial pages, then they can review pending changes. Esquivalience (talk) 00:05, 7 November 2016 (UTC)[reply]

Oppose D

edit
  1. Strong Oppose Pending changes is an important tool, and shouldn't ever be given automatically, one of the best ideas wikipedia has ever had is for pending changes to be granted by admins when they feel you are ready. Iazyges Consermonor Opus meum 22:14, 6 November 2016 (UTC)[reply]
  2. Oppose: Anything that is granted automatically will be gamed by someone who gives the software whatever it is looking for. --Guy Macon (talk) 22:31, 6 November 2016 (UTC)[reply]
  3. Oppose per the above. Sam Walton (talk) 22:36, 6 November 2016 (UTC)[reply]
  4. Oppose per Iazyges KGirlTrucker81 huh? what I'm been doing 23:04, 6 November 2016 (UTC)[reply]
  5. Oppose, especially with the Deferred Edits RFC going on. It is already not difficult to obtain PC review, and doesn't need to be easier. Besides, I doubt it would help with backlogs anyway (Those who would be reviewing can and will easily get the right). -- AntiCompositeNumber (Leave a message) 23:13, 6 November 2016 (UTC)[reply]
  6. Oppose. I am opposed to Pending Changes in any form for any reason, as an undue burden for volunteers on this project and a source of new backlogs when we are not keeping up with existing ones. Either protect or semi-protect the article, if necessary, but don't make other editors excavate the edit history of the article and figure out what's what there and take responsibility for other people's actions. We have better things to do with our time. Nsk92 (talk) 23:52, 6 November 2016 (UTC)[reply]
  7. Oppose - per above -FASTILY 00:46, 7 November 2016 (UTC)[reply]
  8. Oppose - Only autoconfirmed and extendedconfirmed should be automatic. Everything else should require that an admin or 'crat determine whether the editor should be trusted. — Jkudlick • t • c • s 01:25, 7 November 2016 (UTC)[reply]
  9. Oppose - The increased number of reviewers would help deal with the increased backlog, no they would not. Having more editors with the rights doesn't at all mean they will ever make use of those rights. Even if they do, there is no guarantee that they will use these tools effectively or to the benefit of Wikipedia. Mr rnddude (talk) 01:35, 7 November 2016 (UTC)[reply]
  10. Oppose – per above, and what are these technical requirements? If D is to help the backlog concerns of A and B, they look like they could be SNOWing right now. — Andy W. (talk) 03:56, 7 November 2016 (UTC)[reply]
  11. Oppose Pending Changes Reviewer is given only to certain people for a reason. Just because people meet "certain technical requirements" doesn't mean they understand what PCR is and how to use it responsibly. The reason WP:NPP is being made into a user right is because people didn't understand how to use it responsibly and were marking pages as patrolled that quite obviously needed help of some sort or deletion. — Gestrid (talk) 05:06, 7 November 2016 (UTC)[reply]

Discussion D

edit
  • Were either proposal A or proposal B to pass, I would support this as a necessity for overcoming the backlog. I do not support either proposal A or B at this time, and I do not think auto-granting is necessary under the current application of PC1. Mz7 (talk) 22:37, 6 November 2016 (UTC)[reply]
  • I agree with Mz7 on this, but I definitely don't support this without the passage A or B. I think that this proposal should be reworded to be contingent upon the passage of A or B, as there is very little reason for this otherwise. Gluons12 ☢|☕ 23:52, 6 November 2016 (UTC).[reply]

General discussion

edit

Section "C" doesn't seem to give anyone access to anything they can't already do - this doesn't really require a community consensus to build in general - just go build it - it could be live now, once built then discussion can be had about what existing tools to integrate this in to. Note: even with this section "passing" it will not cause this to come in to being. — xaosflux Talk 21:18, 6 November 2016 (UTC)[reply]

True, but I just thought I would solicit community opinions on it. I suppose I could remove it. Biblio (talk) Reform project. 21:21, 6 November 2016 (UTC)[reply]
I suggest splitting it out to WP:VPI - if someone wants to build it today they should go for it! — xaosflux Talk 21:27, 6 November 2016 (UTC)[reply]
While I cannot support the other three options, I would have supported Option C were it still open. For example, I would definitely prefer a "live-updated" page or at least one that has a "refresh" button like Special:NewPagesFeed has. — Gestrid (talk) 05:09, 7 November 2016 (UTC)[reply]
  • Regarding first 2 options - would this be "cascading" (to apply to all used templates and modules) as well? — xaosflux Talk 21:30, 6 November 2016 (UTC)[reply]
  • I can't help feeling that this is the wrong approach to anti-vandalism. Not all IPs are a problem to deal with. Those editing from fixed IPs are easy to deal with if they turn vandal. They will quickly be blocked. The real problem people are those editing from mobiles who skip to a new IP on every new post. PC will not stop this vandalism happening, and it will take just as much effort to revert (a lot more effort in fact, because there will be far less people with the necessary rights to do it). All that will have been achieved is that vandalism is temporarily hidden from view (along with a bunch of good edits as well). A much better solution to this would be to devize a technical means of requiring IPs from variable ranges to identify the device they are editing from. Administrators would then be able to accurately block offenders without having to protect pages or resort to range blocks which shut everyone out. SpinningSpark 22:41, 6 November 2016 (UTC)[reply]
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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Pending_Changes_expansion_RfC&oldid=1142569682"