Wikipedia:Protecting BLP articles feeler survey: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Bushytails (talk | contribs)
Bushytails (talk | contribs)
Line 315: Line 315:
#'''Oppose'''. An even more terrible idea than flagging all BLPs. [[User:Nsk92|Nsk92]] ([[User talk:Nsk92|talk]]) 23:31, 23 December 2008 (UTC)
#'''Oppose'''. An even more terrible idea than flagging all BLPs. [[User:Nsk92|Nsk92]] ([[User talk:Nsk92|talk]]) 23:31, 23 December 2008 (UTC)
#I oppose flaggedrevs period. --[[User:penubag|'''<span style="background:#00CCFF;color:#0066FF;font-size:84%">&nbsp;penubag&nbsp;</span>''']] ([[User talk:penubag|talk]]) 23:50, 23 December 2008 (UTC)
#I oppose flaggedrevs period. --[[User:penubag|'''<span style="background:#00CCFF;color:#0066FF;font-size:84%">&nbsp;penubag&nbsp;</span>''']] ([[User talk:penubag|talk]]) 23:50, 23 December 2008 (UTC)
#'''STRONG oppose'''. All users should see the latest version of all pages. Anything else is not acceptable for a site like this. And do we really want a "decide what people get to see" cabal? I sure hope not. [[User:Bushytails|Bushytails]] ([[User talk:Bushytails|talk]]) 23:52, 23 December 2008 (UTC)


== Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages ==
== Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages ==

Revision as of 23:52, 23 December 2008

This is a simple survey to see if there is any support for, and what people think of, the ideas of enhancing the protection of BLP articles on Wikipedia, the articles about living people. THIS IS NOT A POLL TO CHANGE ANYTHING TODAY. Rather, it is just a survey to get a general idea of what people think, and feel, of the ideas to address the outstanding problems with biographical informations on living people. The two ideas that are floated most often are to use one of the following by default on all biographies:

  • Semi-protection: locking articles so that only those with accounts more than a few days old can edit them, or
  • Wikipedia:Flagged revisions: periodic tagging of the most recent good version, which is then the version visible to the public.

This spawned from this conversation on User:Jimbo Wales's talk page.

Two example studies that were compiled of vandalism in general, and vandalism to high profile BLPs, are:

It may be worth reading some user essays on the subject: Category:User essays on BLP

Again: This survey is not to change anything today but to just see what if any options are popular, and to see if there is support to later work further on one, the other, both, or none.

What does Jimmy Wales think?

This is what Jimmy had to say about this:

"I would be thrilled with the implementation of flagged revs on all BLPs as a test. I don't think I should force it through, but I strongly support that we experiment with it. What I will do is this: I will gladly serve as a formal point of contact to ask the Foundation directly to implement whatever we decide on. What I recommend is a timed test, i.e. turn on flagged revs for all BLPs for 3 months, and have a poll in the last two weeks of that period to determine whether we want to keep it. I feel confident that we will.

I would also support us simply copying what the Germans have done with it. I know there are concerns about volume, but the Germans are able to deal with it just fine as I understand it. Yes, we have more edits, but we have more community members. So I reckon we can deal with it quite well. However, I'm *thrilled* about it for BLPs and merely *supportive* for all articles.--Jimbo Wales (talk) 23:24, 19 December 2008 (UTC)"

Implement Semi-protection for all BLPs

  1. Have always supported this. I'd also support a proposal made by Greg Kohs (comment on the proposal not the proposer…) to experimentally semiprotect a subset of BLPs (for example, all those beginning with "A") and after a couple of months compare the vandalism & editwarring stats with the unprotected control group. – iridescent 19:28, 19 December 2008 (UTC)[reply]
  2. I find no compelling reason to not use a tool we already have, semi-protection, to protect the reputations of living people on whom our project contains articles. If an IP wants to edit a BLP, create an account. One of the main reasons I first created an account back in early 2007 was that I was sick of being shut out of editing semi-protected articles. It's not a big deal to place semi-protection, and the reward (less vandalism and general junk on BLPs) far outweighs the risk (less IP editing generally). SDJ 19:29, 19 December 2008 (UTC)[reply]
  3. 2nd, but I think Flagged is better. rootology (C)(T) 19:31, 19 December 2008 (UTC)[reply]
  4. I agree. Tired of people coming in and trashing BLPs and I have to clean it up, especially when I don't look carefully enough for a few weeks and bad and good edits get mixed up. Frankly, I think you should give IPs maybe 50 to 100 "free" edits and after that they have to register. It's not like they are protecting anything being anonymous or giving anything away being registered. (Or maybe it is, but I think most of them don't know what it is any more than I do.) CarolMooreDC (talk) 19:53, 19 December 2008 (UTC)[reply]
  5. The only risk is that article subjects who see defamation will not be able to fix it without registering. As long as we do this via a template or some such that also includes, in the sitenotice text, links to the OTRS email address and BLP noticeboard, there is no real reason not to at least test the idea. I know a lot of people make much of anons providing a lot of our content, but I think that is less true now than it was and should be balanced against the fact that they also provide rather a lot of vandalism. In the case of BLPs, vandalism is a more pressing problem than it is in, say, articles on Pokémon. Guy (Help!) 20:02, 19 December 2008 (UTC)[reply]
    Your answer is more backlogs? Seriously? --MZMcBride (talk) 21:43, 21 December 2008 (UTC)[reply]
  6. Agree per CarolMooreDC. Willking1979 (talk) 20:14, 19 December 2008 (UTC)[reply]
  7. BLP's should be semi protected, I have always supported thus, but again, it won't happen, Wikipedia and "change" do not mix well. — Realist2 20:15, 19 December 2008 (UTC)[reply]
  8. Absolutely, but as a second choice. I would favor doing this if it can be implimented more quickly. It shouldn't be required once flagged revisions are implemented, however. Cool Hand Luke 20:31, 19 December 2008 (UTC)[reply]
  9. I agree. I have frequently called for indefinite semi-protection of BLPs suffering from inordinate vandalism -- Ilan Pappé, Norman Finkelstein, Vladimir Lenin and several more. This would prevent not only anon ISP vandalism, but also the constant vandalism by one-off throw-away acocunts that has characterised these and other BLP articles. This peoposal would contribute significantly to reducing this problem. RolandR (talk) 20:55, 19 December 2008 (UTC)[reply]
    Just want to point out that one of those three articles is not a BLP... Everyking (talk) 05:51, 23 December 2008 (UTC)[reply]
  10. First choice. shoy (reactions) 21:21, 19 December 2008 (UTC)[reply]
  11. Second choice, or step on the way where we need to be (Semi and flagged for all BLP, flagged for everything in article space) ++Lar: t/c 21:39, 19 December 2008 (UTC)[reply]
  12. Second choice. Actually choice 2.5, as the optimum would be stricter than just flagging. Collect (talk) 22:00, 19 December 2008 (UTC)[reply]
  13. Second choice. FloNight♥♥♥ 22:09, 19 December 2008 (UTC)[reply]
  14. . Thanks, SqueakBox 23:17, 19 December 2008 (UTC)Support this option. Thanks, SqueakBox 23:17, 19 December 2008 (UTC)[reply]
  15. . Keep it simple. I prefer this marginally over introducing yet another layer (flagged revisions), but both have merit. Cheers, Casliber (talk · contribs) 23:44, 19 December 2008 (UTC)[reply]
  16. Obviously I support something I have been saying for months should occur. MBisanz talk 03:47, 20 December 2008 (UTC)[reply]
  17. This is the least radical of possible steps, and it should be tried first. It will certainly help the situation somewhat, and then we can judge what to do further. If we do try flagged revisions, we should try it for a very small subset first, as proposed by Cenarium and others in the section on General Comments. (I'd suggest US Presidents)DGG (talk) 17:10, 20 December 2008 (UTC)[reply]
    Fundamentally changing the nature of a very, very large portion of our site is the "least radical of possible steps"? What on Earth? --MZMcBride (talk) 21:43, 21 December 2008 (UTC)[reply]
  18. Support. BLP issues are among the most significant facing this project, and reducing or eliminating vandalism on those articles - particularly on lower profile BLPs - is part of the responsibility the project has to its article subjects. If this means indef semi-protection on those articles, so be it. Pfainuk talk 00:51, 21 December 2008 (UTC)[reply]
  19. First choice. It's simple without adding an unreasonable amount of extra work. EconomicsGuy (talk) 09:34, 21 December 2008 (UTC)[reply]
  20. Support this or some reasonable variation (there may be a subset of BLPs that are lower-risk, for example). I'm closely following the discussion on this page, which is developing some nuances I had not previously considered; further thoughts to follow. But I've become convinced that the status quo is not acceptable. Newyorkbrad (talk) 21:16, 21 December 2008 (UTC)[reply]
  21. This would do nicely. First choice. Stifle (talk) 10:54, 22 December 2008 (UTC)[reply]
  22. Preventing real-world harm is crucial. Everyone can still edit, though they must create an account first, so I can't see why the open-edit brigade have too many worries GTD 21:56, 22 December 2008 (UTC)[reply]
  23. OK for a start as long as it does not preempt even stronger measures in the future – such as far more stringent standards for inclusion, default-to-delete for AfDs on bios, and opt-out for marginally notable people. All these little-watched BLPs are legal and ethical time bombs, out there ticking away. Short Brigade Harvester Boris (talk) 22:53, 22 December 2008 (UTC)[reply]
  24. At minimum. Plus, all BLPs need a little transcluded wikibox: "Are YOU the subject of this article? HERE is what you need to do, to edit it" Followed by simple autoconfirm directions for newbie IPs who find themselves bio'ed, plus a link to OTRS and [1].SBHarris 00:20, 23 December 2008 (UTC)[reply]
  25. Much needed. Everyking (talk) 05:46, 23 December 2008 (UTC)[reply]
  26. I think this is a good idea. WP needs much higher standards of protection for living people. Lawsuits aside, this is something often mentioned in critical articles about WP. Remember the person whose article said he was the real killer of JFK? It makes WP look bad when that kind of thing is reported. Redddogg (talk) 19:42, 23 December 2008 (UTC)[reply]
    You're recalling the Seigenthaler incident. Like the vast majority of problems, it came from an IP address. WilyD 21:10, 23 December 2008 (UTC)[reply]
  27. 1st - I think this is an excellent idea. I would like to see it expanded to heavily-vandalised articles in general. That is, all BLPs, and an easy way to semi-protect an article without going through an RfA... and yes I reallize that may be impractical or a bad idea.sinneed (talk) 21:13, 23 December 2008 (UTC)[reply]
  28. I think that some form of protection is a good idea, and I support this instead of flagged revisions due to the concerns expressed by User:Jéské Couriano. SU Linguist (talk) 21:15, 23 December 2008 (UTC)[reply]
  29. Agree. Actually, I wouldn't mind having semi-protection be the default article state. But I guess I'm still in the minority on that. --Alvestrand (talk) 22:11, 23 December 2008 (UTC)[reply]
  30. I agree, although I would also support the idea of testing it on a random subset of articles for a few months first to see if it really does have the beneficial effect that I would predict. Anaxial (talk) 22:35, 23 December 2008 (UTC)[reply]
  31. This makes sense. How many BLP issues are really caused by established editors? Jclemens (talk)
  32. Weak Support, especially if this can calm down the unfounded BLP paranoia that seems to be propelling this entire survey. I think this option is in fact more democratic and inclusionary than the flagging option. It takes very little effort to register and get a Wikipedia account, so I don't think that this option is really antithetic to the "everyone can edit principle". On the other hand, it is an established fact that most vandalism, especially of the barnyard childish kind, comes from IPs and it would certainly be reduced by permanent semi-protection. Nsk92 (talk) 23:48, 23 December 2008 (UTC)[reply]

Oppose Semi-Protection for all BLPs

  1. Object. It's a cost-benefit thing. A fair number of people who want to exploit BLPs are sloppy and edit from static IP addresses. This would cut down on abuse somewhat, but it would also reduce accountability. Think how useful the Wikiscanner was at sniffing out trouble. Why would we want to make BLPs marginally less difficult to exploit, while shutting down Wikiscanner capabilities completely? DurovaCharge! 19:45, 19 December 2008 (UTC)[reply]
  2. Oppose strongly, this would be a clear break with the ability of anybody to edit. Flagged revisions are far superior for the reasons I have commented in the flagged revision section above below. Davewild (talk) 20:58, 19 December 2008 (UTC)[reply]
  3. Oppose in the strongest possible terms. This would only
    1. Create a false "don't need to watch this page anymore" sense of security.
    2. Make determined BLP attackers more difficult to identify at a glance, because they have to build up a certain number of meaningless edits before doing deliberate damage.
    3. Funnel drive-by BLP violations to tangentially related non-BLP articles which are unprotected and probably unwatched.
    4. Leave good-faith newcomers unable to edit at all when their favorite baseball players (or whoever they're interested in) are s-protected and they don't know how to game the "autoconfirmed" criteria. Then if they figure out how to ask for help, we do what? Ask them to "just go edit asteroids or pokémon for a week"? Forget that! — CharlotteWebb 21:18, 19 December 2008 (UTC)[reply]
  4. Oppose More BLP paranoia. We have a functioning and strict BLP policy. We just need to enforce it and edit accordingly. We don't need to invent these contrivances to "solve" this non-problem. And I oppose flagged revisions generally. Protonk (talk) 21:20, 19 December 2008 (UTC)[reply]
  5. Not only "No" but... While we need to be responsible in our treatment of BLPs, a default position of semi-protect is antithetical to the basic premise of Wikipedia. It is obvious that a great deal of vandalism comes from IPs, but so do a tremendous number of constructive edits. In addition, I suspect that the overwhelming majority of us here first contributed as IPs before becoming sufficiently hooked to register an account. It is foolish to create an impediment to the contributions of those who would join this community. And consider, in many cases the way we find out that there's a problem on a BLP is when an IP (probably the subject or someone close to them) repeatedly tries to fix a problem and gets reverted. The need to protect the subjects of thisthese articles would be addressed in a far superior way through the use of flagged revisions on problematic articles.Xymmax So let it be written So let it be done 21:42, 19 December 2008 (UTC)[reply]
  6. Oppose Could serve to lock in vandalism, such that the subject who found something untrue in the article can't just fix it, while the benefits from doing this are largely obsoleted by flagged revisions. -Steve Sanbeg (talk) 21:44, 19 December 2008 (UTC)[reply]
  7. CharlotteWebb put it nicely. Let's not forget the point of Wikipedia. John Reaves 21:49, 19 December 2008 (UTC)[reply]
    Building a stable and reliable encyclopedia? Cool Hand Luke 22:02, 19 December 2008 (UTC)[reply]
    So why not semi-protect the whole mess? Protonk (talk) 22:35, 19 December 2008 (UTC)[reply]
    Why not? Still the site anyone can edit, but no longer the site anyone can drive-by vandalize. BLPs just happen to be the most potentially damaging class of articles. Cool Hand Luke 00:50, 20 December 2008 (UTC)[reply]
    Because it betrays one of the fundamental purposes of wikipedia: that editing be as open as possible. No one promised that these purposes were going to be concordant--the meat of good policy debates comes from situations where guiding principles conflict or are mute. WP:NFC is a compromise between our goal to be a free encyclopedia and to be a comprehensive encyclopedia. It would be unacceptable to betray either pillar through inaction or immoderation. Likewise we have here two competing principles, we need to satisfy both partially. Semi-protecting BLP's preemptively and indefinitely doesn't do that. It's lazy, it won't stop determined vandals, it will not stop real threats to BLPs (no one really believes obvious vandalism on a page but they can believe misinformation inserted by dogged SPAs), and it turns away too many productive edits and prospective editors. Protonk (talk) 01:28, 20 December 2008 (UTC)[reply]
    The fundamental purpose of Wikipedia is building and maintaining an encyclopedia. If any supposed principle gets in the way of that, we should ignore it. Cool Hand Luke 01:34, 20 December 2008 (UTC)[reply]
    No, its not just an encyclopedia, its a free encyclopedia that anyone can edit. We can't toss away "free" or "anyone can edit" because it gets in the way of "encyclopedia" in some cases. Any idiot can see that you would get a stable encyclopedia by restricting who can edit it. Paper and other electronic encyclopedias have been doing it for years by restricting editing to their staff members. "Anyone can edit" is why Wikipedia is successful, and why we have 10 million articles in 250 languages. If you disagree with that principle, I hear Citizendium is recruiting. Mr.Z-man 04:01, 20 December 2008 (UTC)[reply]
    Clearly I don't. You don't need to lecture me; I have a passing familiarity with the success of Wikipedia. Cool Hand Luke 05:30, 20 December 2008 (UTC)[reply]
    Sorry, I was confused by your comments suggesting we abandon the "anyone can edit" principle in favor of more stable content. Mr.Z-man 06:06, 20 December 2008 (UTC)[reply]
    I'm sure you do. I voted for you. I don't think he was intending to lecture you, just make clear the point that the foundation issue of a free encyclopedia is in contest with the implementation of semi-protection for a class of articles. Further, since you alluded to IAR, he was probably hoping to show that this was an ends based argument, not some position taken merely out of advocacy or inertia. The real point is we can all go back and forth appropriating "what wikipedia is" for our end of the argument because the definition is too fluid and vague to serve as a decision rule here. I accept that wikipedia faces a tradeoff in anonymous editing. We may disagree on the magnitude of that tradeoff, but we agree that there is one. Protonk (talk) 06:12, 20 December 2008 (UTC)[reply]
    We absolutely agree. There's always a trade off. My first edit was to start a new article that was redlinked. We haven't allowed IPs to do that in a long time, and we've certainly lost some contributors who would have begun like I did. In this case, I just think we have particular editorial obligations to BLP subjects which trump volunteer recruiting.
    Incidentally, if anyone wants to move some of this thread to the currently-redlinked talk page, I wouldn't mind at all. Cool Hand Luke 06:39, 20 December 2008 (UTC)[reply]
  8. Pointless when you can have flaggedrevs. Semiprotection can and should be used liberally but only when there has been a problem: pre-emptive protection of all BLPs is just overkill. Moreschi (talk) 22:18, 19 December 2008 (UTC)[reply]
  9. No - flagged revisions are OK, even necessary, for BLPs, but stopping all anonymous or non-autoconfirmed users from editing them at all is far too extreme. Dendodge TalkContribs 23:27, 19 December 2008 (UTC)[reply]
  10. Oppose per the very good reasons outlined by CharlotteWebb and Xymmax. This is throwing the baby out with the bathwater. Mr.Z-man 00:16, 20 December 2008 (UTC)[reply]
  11. Oppose; flagged revisions offer a much less intrusive way of protecting articles. — Coren (talk) 00:39, 20 December 2008 (UTC)[reply]
  12. oppose per Charlotte, Xymmax and Coren. JoshuaZ (talk) 01:00, 20 December 2008 (UTC)[reply]
  13. Strong oppose - This chucks the baby out with the bathwater. IPs do work too, you know. - NuclearWarfare contact meMy work 01:19, 20 December 2008 (UTC)[reply]
  14. Oppose Many useful contributors to BLPs are anons - protection should be on a case-by-case basis. --Philosopher Let us reason together. 01:41, 20 December 2008 (UTC)[reply]
  15. Support a compromise solution. Any BLP should be automatically semi-protected for a period of time on a request from any established user if an IP is making reverts in the article.Biophys (talk) 05:21, 20 December 2008 (UTC)[reply]
  16. Cost-benefit. Most BLPs do not ever attract disruption. Those that do can already be made subject to some sort of protection.  Sandstein  07:50, 20 December 2008 (UTC)[reply]
  17. Oppose; this essentially and eventually becomes disallowing anons to edit and thus a Foundation issue, not a community one. It's too slippery of a slope towards Citizendium. -Jéské Couriano (v^_^v) 07:51, 20 December 2008 (UTC)[reply]
  18. Oppose this is overkill. It would reduce the amount of vandalism on BLPs, but we have to weight this against the huge adverse effects. Hut 8.5 10:12, 20 December 2008 (UTC)[reply]
  19. Oppose, it would not cost wikipedia just the anon edits, but also a number of contributors, who started out as anons and got hooked on Wikipedia. bogdan (talk) 11:30, 20 December 2008 (UTC)[reply]
  20. Strong oppose another kick in the face for anonymous editing. Antithetical. Skomorokh 13:11, 20 December 2008 (UTC)[reply]
  21. Strong oppose. Studies have shown that the anon edits make up a significant amount of vandal reversions. Making it harder for anons to fix errors in BLPs is not beneficial to the project. It also goes against the whole idea of being an encyclopedia anyone can edit when the majority of BLPs pose no problems. - Mgm|(talk) 14:24, 20 December 2008 (UTC)[reply]
  22. Oppose Unnecessary. --Tango (talk) 14:28, 20 December 2008 (UTC)[reply]
  23. I think a blanket semi-protection of BLPs will probably be more harmful than the vandalism it will prevent. Flagged revisions are a better solution. -- Jitse Niesen (talk) 16:12, 20 December 2008 (UTC)[reply]
  24. Oppose—any systematic protection of pages is effectively a way of categorically denying people the right to edit that page. That seems to me to be in conflict with one of our core principles, that anyone should be able to edit. While abuse concerns might even justify the use of sighted-revision-by-default FlaggedRevs (which I also intensely dislike), systematic protection of any level is simply unacceptable. {{Nihiltres|talk|log}} 16:47, 20 December 2008 (UTC)[reply]
  25. Oppose the autoconfirm barrier is way too high. -- lucasbfr talk 17:19, 20 December 2008 (UTC)[reply]
  26. not strongly opposed - but not for this solution either. --Rocksanddirt (talk) 20:16, 20 December 2008 (UTC)[reply]
  27. Weak oppose Too easy to bypass, too much collateral damage. Whacka-redlink isn't productive.--Tznkai (talk) 21:14, 20 December 2008 (UTC)[reply]
  28. No, do it only on those that have problematic IP edits on them. There are lots that don't --Enric Naval (talk) 22:05, 20 December 2008 (UTC)[reply]
  29. Oppose: Per the valid reasons above. This is a wiki. There are many, many valid edits to BLPs from IP users. - Rjd0060 (talk) 03:12, 21 December 2008 (UTC)[reply]
  30. Oppose - Per Rjd, many valid BLP edits come from IP users. VegaDark (talk) 04:06, 21 December 2008 (UTC)[reply]
  31. I haven't seen any real convincing evidence to support a measure this drastic. Is there evidence of anonymous users or brand new users causing significantly more harm to BLPs than autoconfirmed users? And if so, does anyone have a link? --MZMcBride (talk) 16:46, 20 December 2008 (UTC)[reply]
    Gurch had some stats somewhere based on what was being reverted by Huggle, I believe – iridescent 18:52, 20 December 2008 (UTC)[reply]
  32. Would be a net negative. There are less crude ways of resolving the BLP problem without denying a substantial proportion of our contributors the right to edit a sizable group of articles. AGK 16:09, 21 December 2008 (UTC)[reply]
    There are ways of "resolving the BLP problem"??? I'd love to hear them, please.--Scott Mac (Doc) 16:11, 21 December 2008 (UTC)[reply]
    [Points downwards.]
    FlaggedRevs being one.
    AGK 13:27, 23 December 2008 (UTC)[reply]
  33. Strong oppose What ever happened to the "encyclopedia than anyone can edit"? I know that semi-protection is a necessary evil, but BY DEFAULT on BLPs is utterly ridiculous. ~the editorofthewiki (talk/contribs/editor review)~ 16:24, 21 December 2008 (UTC)[reply]
  34. Oppose A policy of this sort could far too easily evolve into semi protection throughout article space. Furthermore, I'm not convinced that IP editors do more harm than good in BLPs. —/Mendaliv//Δ's/ 18:08, 21 December 2008 (UTC)[reply]
  35. New Main page greeting: Welcome to Wikipedia,the free encyclopedia that anyone can edit. Just don't try it one BLP's, even if its a legit edit. Synergy 19:00, 21 December 2008 (UTC)[reply]
  36. Oppose some good edits to BLPs come from IP editors. If the concern is people adding incorrect or slanderous information, I think a better answer is to have more editors closely watching BLP articles and have them be more hard-line about reverting unsourced or defamatory edits. —Politizer talk/contribs 19:23, 21 December 2008 (UTC)[reply]
  37. Not so long as there's a chance that the flagged revisions idea will work. Wikipedia will succeed in the coming years only if we can (1) keep recruiting new editors -- who get interested in Wikipedia by discovering they can edit it, and are discouraged when they cannot; and (2) steadily improve in reliability. Obviously this points to a need to balance monitoring of edits with openness, but if we're capable of handling the work of monitoring edits, aided by flagged revisions, then I would strongly prefer that we do that and forgo as little openness as possible. — Dan | talk 21:57, 21 December 2008 (UTC)[reply]
  38. Oppose. This is just as effective at keeping vandalism in the BLP as it is at keeping vandalism out. Some BLP violations are discovered by the subject of the article, and I can imagine that they would be hopping mad if they find that the libel is protected. Sjakkalle (Check!) 15:07, 22 December 2008 (UTC)[reply]
  39. Strongest possible oppose. Are we so quick to compromise our foundation issues? TotientDragooned (talk) 23:24, 22 December 2008 (UTC)[reply]
  40. Welcome to Wikipedia, the encyclopedia anyone can edit Oppose --Dweller (talk) 13:02, 23 December 2008 (UTC)[reply]
  41. Oppose Dweller says it best. SoWhy 21:25, 23 December 2008 (UTC)[reply]
  42. OpposeAnyone can edit wiki that is the theory in anyway and we should stick with that. BigDuncTalk 22:13, 23 December 2008 (UTC)[reply]
  43. Oppose I don't feel this is the right solution. This won't help, it's however going to stop positive contributions from ip's. Just because some ip's are doing it does not mean we should block them from editing BLP's. --Kanonkas :  Talk  22:14, 23 December 2008 (UTC)[reply]
  44. Oppose for many of the reasons highlighted above. Page protection should be the exception, not the rule. --Explodicle (T/C) 22:51, 23 December 2008 (UTC)[reply]
  45. No. This is an encyclopaedia that anyone can edit. I strongly oppose anything which will take that away. Sure, semi-protection is needed often by default is ridiculous in my honest opinion. —Cyclonenim (talk · contribs · email) 22:55, 23 December 2008 (UTC)[reply]
  46. Strongly oppose per above comments. It won't change anything. Majorly talk 23:20, 23 December 2008 (UTC)[reply]
  47. Oppose - It's all said above. - Peregrine Fisher (talk) (contribs) 23:34, 23 December 2008 (UTC)[reply]
  48. Strong oppose - I originally supported this idea, since, being a vandal-fighter, flagged revisions seemed practical. Then, the thought of Wikipedia's freedom, the singular "you-can-edit-this-right-now" quickly changed my mind. And speaking practically, I can't begin to mention the dramaz this would start. —La Pianista (TCS) 23:36, 23 December 2008 (UTC)[reply]
  49. Oppose - all users should be able to edit all pages. Bushytails (talk) 23:50, 23 December 2008 (UTC)[reply]

Implement Flagged Revisions for all BLPs

  1. My choice. rootology (C)(T) 19:21, 19 December 2008 (UTC)[reply]
  2. Choice. But, of course, there are a number of highly divergent ways that flagged revisions could be implemented. CIreland (talk) 19:37, 19 December 2008 (UTC)[reply]
  3. I have a dream that one day Wikipedia will be a respectable source of quality information, and not the punchline of hack comedians. WilyD 19:40, 19 December 2008 (UTC)[reply]
  4. Makes sense. DurovaCharge! 19:41, 19 December 2008 (UTC)[reply]
  5. First choice. Flagged revisions make semiprotection largely unnecessary. Eventually I'd like to see everything in article space using flagged revisions but this is good for now. Also has the advantage that IPs can actually make substantial edits and changes to BLPs they just need to get approved. Also removes the issue of someone starting an article that they can then not edit which occurs if we semiprotect. JoshuaZ (talk) 19:43, 19 December 2008 (UTC)[reply]
  6. Most anonymous edits to BLPs are good and we don't want to lose those. Flagged revisions is a reasonable way to protect biographies from the bad anonymous edits. -- Ed (Edgar181) 20:02, 19 December 2008 (UTC)[reply]
  7. We should really be pushing towards this for all articles, actually. The question is whether it will scale to the size of enWP, or even just enWP's biographies, but the deWP experience seems to indicate that it should. Guy (Help!) 20:03, 19 December 2008 (UTC)[reply]
  8. Yes, yes, yes. If it can be activated on articles selectively, I would personally spread it to all the BLPs I could, and I'm certain that others would help pitch in. Cool Hand Luke 20:31, 19 December 2008 (UTC)[reply]
  9. Definitely. Vastly preferable to semiprotection - David Gerard (talk) 20:45, 19 December 2008 (UTC)[reply]
  10. Absolutely, I have long supported this, far better than semi protection (which I would strongly oppose) for the strong reason that it preserves the ability of anybody to edit, while preventing the casual reader from seeing vandalism/libel. Semi protection would either lead to BLPs being hopelessly out of date, a impossible surge in requests for edits and the moving of vandalism to talk pages and other articles. Flagged revisions enables the reader to update/make corrections as necessary which is the great strength of wikipedia and I am confident (and would help ensure) we could keep BLPs flagged quickly. Davewild (talk) 20:49, 19 December 2008 (UTC)[reply]
  11. Flagged Revisions would be a big step forward. Semi-protecting a substantial portion of our articles is just too antithetical to Wikipedia. --Alecmconroy (talk) 20:50, 19 December 2008 (UTC)[reply]
  12. Second choice. Much preferred to protection. NonvocalScream (talk) 21:16, 19 December 2008 (UTC)[reply]
  13. Second choice. shoy (reactions) 21:21, 19 December 2008 (UTC)[reply]
  14. Second choice, or step on the way to where we need to get. ++Lar: t/c 21:37, 19 December 2008 (UTC)[reply]
  15. Prepared to endorse this. Reasonable balance between dealing with BLPs in a responsible way and encouraging free anonymous participation. Would prefer some selectivity in which BLPs are flagged, but not a deal breaker. Xymmax So let it be written So let it be done 21:46, 19 December 2008 (UTC)[reply]
    This is just to gauge general feelings, the nitty-gritty details could include partial or selective activation of flagged revs on BLPs. (If this isn't yet technically possible, we could buy Brion something nice for Christmas). WilyD 21:53, 19 December 2008 (UTC)[reply]
    OK, but the section header said "implement on ALL BLPs" ... Xymmax So let it be written So let it be done 22:20, 19 December 2008 (UTC)[reply]
    Basically, we needed to finally have THIS discussion, rather than pointless little "What if this? What if that?" chats under FLAGGED and the protection policy and 100 other places, to see who actually supports what in general--is all-semi-BLP a good/dumb idea? Is all-flagged-BLP a good dumb/idea? And based on this, the appropriate next steps can then be looked at, and shaped up. The specifics--"Protect all via a transclusion of a widget under the positron matrix"; "Flag rev all via the MacGuffin's inverse matrix", and so on, can be hashed out later and doesn't require 1,000 people to say Yay! or Nay! This is just to see if the ideas even have legs. rootology (C)(T) 22:34, 19 December 2008 (UTC)[reply]
  16. I don't see how this is technically possible without some sort of BLP namespace, but, yes, do it. John Reaves 21:51, 19 December 2008 (UTC)[reply]
  17. Probably the best bet. We need to do something about the fact that BLPs of relatively obscure people (which in many cases will be their first Google hit) can be targeted with vandalism that stays for long periods of time. The Siegenthaler incident is probably the most notorious case, but such incidents can and will happen again if nothing is done. At the same time, cutting off all anonymous BLP edits seems to go too far. *** Crotalus *** 21:54, 19 December 2008 (UTC)[reply]
  18. I was leaning towards semiprotection as the best approach, but Crotalus' response made me think it over a bit. Our biggest problem for BLPs is when a little-watched article is dinged, often by someone with a grudge against said person; these are the ones that come back to bite us in the collective ass most often. Flagged revisions would provide a level of oversight to the process, and ensure that we don't have an issue where the first anyone here hears about a problem is when it's being frothed about in the media. Tony Fox (arf!) 21:59, 19 December 2008 (UTC)[reply]
    I sort of started an initiative to watch unwatched pages from Special:Unwatchedpages (pretty much dead now due to technical problems with the page), if we could do that on a more massive or potentially semi-automated scale, that would help a lot. John Reaves 10:36, 22 December 2008 (UTC)[reply]
  19. Support -- actually I would like it stricter than the current German implementation. Currently "affiliated editors" seem to stake out notable BLPs or groups thereof, and we would need to make sure that the person accepting the flagged revisions was aware of this. Collect (talk) 22:06, 19 December 2008 (UTC)[reply]
  20. Support. Even short term vandalism or poorly sourced edits can be harmful. We can do better and should. FloNight♥♥♥ 22:12, 19 December 2008 (UTC)[reply]
  21. I like this option too. — Realist2 23:01, 19 December 2008 (UTC)[reply]
  22. Support, first choice. We try it first on BLP's, then if it helps stabilize content and reduce the amber waves of crap that some of our high-profile BLP articles are hit with throughout their time of notoriety, we expand the flagging to ALL articles.GJC 23:10, 19 December 2008 (UTC)[reply]
  23. Semiprotecting them all is a bit extreme, but this seems an ideal compromise. IPs aren't stopped from editing, their edits just have to be processed by, say, a rollbacker. I presume we can tweak the settings on a per article basis so it applies to, say, all non-admins for some articles, or so only admins can 'sight' the revisions or something? Dendodge TalkContribs 23:24, 19 December 2008 (UTC)[reply]
  24. It's worth a try. This may be better than semi-protection because of the essential problem with banning editing by IPs: barriers to editing tends to favor editors with stronger POVs. Flagged revisions could change the POV balance less than semi-protection while still reducing vandalism. ·:· Will Beback ·:· 23:29, 19 December 2008 (UTC)[reply]
  25. Weak support I am concerned this will be unwieldy in terms of time used up implementing it, but certainly more owrthwhile trialling with BLPs than with FAs or GAs. Cheers, Casliber (talk · contribs) 23:46, 19 December 2008 (UTC)[reply]
  26. Second choice, prefer flaggedrevs on all pages. Mr.Z-man 00:17, 20 December 2008 (UTC)[reply]
  27. Support evolutionary step as a reliable encyclopedia. Docku: What up? 00:30, 20 December 2008 (UTC)[reply]
  28. Support in the alternative; I don't think singling out BLP is that useful, but if we have a choice between flagged revisions on all pages and only on BLPs then I'd rather have at least the BLPs protected. — Coren (talk) 00:31, 20 December 2008 (UTC)[reply]
  29. Agree with Coren above. I'd prefer indefinite semiprotection of BLPs and flagged revisions of all articles, but better this than nothing. – iridescent 00:40, 20 December 2008 (UTC)[reply]
  30. This seems ideal to me, if technically feasible. Deli nk (talk) 03:07, 20 December 2008 (UTC)[reply]
  31. I could support some 3-month or 6-month trial of this to see what happens. I would prefer this to semi-protection for all BLPs. As of right now, Category:Living people has 324,956 articles in it. About 1 in 8 articles on the English Wikipedia is a BLP. Looking at the recent changes to BLPs, it looks like a BLP is edited about 12 times per minute, or once every 5 seconds. I would prefer we try out FlaggedRevs on BLPs first, before we even think of enabling it on all articles — to see how out of date the 'sighted' BLPs get and what kind of backlog results. But I think there needs to be a clear plan in place (how someone gets/loses 'reviewer' status, how many 'reviewers', when and when not to 'sight'/'unsight' a page) before it goes into effect. Vandals could still game the system, but I guess if you make it a real chore for them you could dissuade most of them. But once FlaggedRevs is enabled on all BLPs, will all BLPs be 'sighted' as is, or will 'reviewers' have to review them all one by one? If they need to first be reviewed one by one (which I think is the case), how long will it take to do the first sweep ('sight' some revision of all 324,956 BLPs), and who's going to do it? --Pixelface (talk) 03:43, 20 December 2008 (UTC)[reply]
  32. Second choice, some improvement, but a little clunky. MBisanz talk 03:49, 20 December 2008 (UTC)[reply]
  33. My first choice. As mentioned above, semi-protection may inadvertently encourage editors with a stronger POV (i.e.: the barrier to edit is higher); and affect the neutrality of our articles. I hope that we move to try this solution before semi-protection. Lazulilasher (talk) 04:17, 20 December 2008 (UTC)[reply]
  34. Seems to be the best course of action, keeping the "anybody can edit!" philosophy intact, while also affording more protection to the subjects of BLP articles. Definitely worth a trial, if nothing else. Lankiveil (speak to me) 05:00, 20 December 2008 (UTC).[reply]
  35. This is the best alternative over two extremely unsatisfactory situations: semi-protection on all blps that would be an extraordinary break in our open-editing wiki spirit, and a situation where blps are largely unmonitored and prone to vandalism and wp:blp violations. I think it's manageable, but we'll still probably face huge backlogs. Cenarium (Talk) 14:12, 20 December 2008 (UTC)[reply]
  36. Support. This is the perfect middle ground. It allows editing, but at the same time builds in a safeguard against vandalism. The only possible problem is scaling, but we can't dismiss it before a trial has been done. - Mgm|(talk) 14:26, 20 December 2008 (UTC)[reply]
  37. Support There is a lot to discuss regarding the details, but some form of FR for BLPs seems like the best option to me. --Tango (talk) 14:30, 20 December 2008 (UTC)[reply]
  38. Second choice.Peacock (talk) 15:22, 20 December 2008 (UTC)[reply]
  39. Flagged revisions are very promising, but it is a big change so we need to go slowly and carefully. There are real concerns about backlogs which need to be addressed and trials are probably the only way to find out. And of course there are many details to be filled in. -- Jitse Niesen (talk) 16:16, 20 December 2008 (UTC)[reply]
    It's known that the details need to be filled in. What we want to find out is whether it's worth trying to fill in those details, by seeing how people feel about flagged revisions, whether it's likely the community will give a mandate to implement them once the details are worked out. WilyD 16:41, 20 December 2008 (UTC)[reply]
  40. Conditional Support -- I think flagged revisions are a wonderful idea, but should be strictly kept to featured articles (helps us look good) and biographies of living people (legal reasons). I am strongly opposed to them going farther than that, I think it would break the spirit of wikipedia and turn it into a cool kids club of people who can commit revisions. --ScWizard (talk) 08:10, 20 December 2008 (UTC)[reply]
  41. Support I completely agree with ScWizard above. -- lucasbfr talk 17:19, 20 December 2008 (UTC)[reply]
  42. Support; appears to be an excellent idea, and if it turns out to be unworkable we can turn it off. It's worth a try. I also think we should only try one thing at a time: this would be a good preliminary test for flagged revisions in general on en:. Antandrus (talk) 17:25, 20 December 2008 (UTC)[reply]
  43. Weak and qualified support—while on the one hand I strongly support the general use of FlaggedRevs, it is my impression that its use here implies a sighted-revisions-visible-by-default implementation of FlaggedRevs, which I strongly oppose. FlaggedRevs would be helpful in combatting vandalism, but I can't shake the feeling that a sighted-revisions-visible-by-default implementation constitutes effectively denying editing to those not allowed to sight edits (in other words, most people). I'd accept sighted-by-default FlaggedRevs to any more extreme protecting-BLPs proposal, however, as it's got many advantages over other schemes. I must note that BLPs are one of the few areas where sighted-by-default FlaggedRevs would be acceptable to me: I don't want any implementation on BLPs to be used as an excuse to enable sighted-by-default FlaggedRevs elsewhere. My preferred implementation of FlaggedRevs would make the "sighted" or "unsighted" status visible as a means to aid more basic BLP-monitoring efforts. Sighted-by-default FlaggedRevs would be preferable to semi-protection, in any event. {{Nihiltres|talk|log}} 18:10, 20 December 2008 (UTC)[reply]
  44. Support I generally support, but I think it may be impractical to implement FR over all BLP articles at the first stage. It is better to select several thousands most vandalized BLP articles and enable FR over them. Ruslik (talk) 19:56, 20 December 2008 (UTC)[reply]
  45. support - I like this as a test certainly, one that we will find reduces both the blp-vandalism, and complaints about it from blp subjects. Not sure about full article implementation of it though. --Rocksanddirt (talk) 20:20, 20 December 2008 (UTC)[reply]
  46. Support Do this, do it now - we have other things we need to work on.--Tznkai (talk) 21:11, 20 December 2008 (UTC)[reply]
  47. Support It's well past time to at least try this idea. Gnome de plume (talk) 21:30, 20 December 2008 (UTC)[reply]
  48. Support without question, per my previous comment above. We must do what we can to protect BLP subjects from harm - particularly those that are lower profile - and this seems to be a very good way of doing this. So a few anons and newer users have to click another link to see their changes (until they are sighted) - that seems a small price to pay given the potential for harm to BLP subjects. Pfainuk talk 00:57, 21 December 2008 (UTC)[reply]
  49. Do it - Dan Dank55 (send/receive) 01:34, 21 December 2008 (UTC)[reply]
  50. Support TimBuck2 (talk) 02:36, 21 December 2008 (UTC)[reply]
  51. Support Second choice per my concerns about how much time this will consume. EconomicsGuy (talk) 09:36, 21 December 2008 (UTC)[reply]
  52. Distant second choice. If we must let IPs edit BLPs, at least have the revisions be flagged. SDJ 15:24, 21 December 2008 (UTC)[reply]
  53. Yes, so long as we take things slowly and organize the resources needed to make FlaggedRevs work. My first choice: seems to be the best option. AGK 16:11, 21 December 2008 (UTC)[reply]
  54. Very weak support - I think this would be a good way to see how flagged revisions work, but I am concerned that it would disenfranchise any editor without reviewing rights. 18:52, 21 December 2008 (UTC) [That was User:J.delanoy - Dank55]
  55. Support - this is a good idea, certainly worth trying. --Aude (talk) 20:57, 21 December 2008 (UTC)[reply]
  56. By all means. — Dan | talk 21:57, 21 December 2008 (UTC)[reply]
  57. I have no objection to them wholesale either, but BLP's provide a useful test to discover any major issues. Eluchil404 (talk) 08:26, 22 December 2008 (UTC)[reply]
  58. Good idea, the only question is how. Foxy Loxy Pounce! 13:02, 22 December 2008 (UTC)[reply]
    If there is a widespread feeling that this is a good idea in general, "How?" is the next question to ask. But "Is this worth pursuing?" is the logical place to start. WilyD 15:02, 22 December 2008 (UTC)[reply]
  59. Certainly, though I'd rather create a class of "BLP editors" who have to openly declare their identities and be of an age to be legally accountable in a court of law GTD 21:59, 22 December 2008 (UTC)[reply]
  60. Yes. And add sprotection also to reduce antivandal-load (as noted above). If we lack manpower for promotion, then that's a sign our notability criteria are too low and we have too many BLPs. Finally, although it's true IPs add a significant fraction of good content, nobody knows the answer to what would happen if they were forced to register. You can guess that they will; you can guess they won't. The truth is: nobody knows. So try the experiment. SBHarris 00:26, 23 December 2008 (UTC)[reply]
  61. Everyking (talk) 05:49, 23 December 2008 (UTC)[reply]
  62. Moondyne 10:43, 23 December 2008 (UTC)[reply]
  63. Support - This will limit the damage caused by BLP violations (including by users who register, wait 4 days and make 10 edits first), while allowing the BLPs to remove false information as needed. עוד מישהו Od Mishehu 13:13, 23 December 2008 (UTC)[reply]
  64. Support, the least damaging option. --Aqwis (talkcontributions) 20:49, 23 December 2008 (UTC)[reply]
  65. 2nd choice for me. I am dubious about how to make this work. There are a LOT of BLP articles. I also fear it would expose Wikipedia to greater liability. Or that it might even expose ME to liability, if I did something that made an article version flagged "good"... and I had missed something that someone found unacceptable. sinneed (talk) 21:15, 23 December 2008 (UTC)[reply]
  66. Support, this is my preferred option. Allowing everybody to edit, but removing the risk of people being harmed by vandalism. A balance of our rights and responsibilities. Tim Vickers (talk) 21:58, 23 December 2008 (UTC)[reply]
  67. Support I like this option. It provides a nice effective degree of oversight on the public face of the encylopedia without preventing continued editing. Mfield (talk) 22:09, 23 December 2008 (UTC)[reply]
  68. Support once enough experience with flagged revisions is gained. --Alvestrand (talk) 22:12, 23 December 2008 (UTC)[reply]
  69. Support This would be my first choice (and would render semi-protection somewhat moot). As with others, I'd like to see this for all of article space, but that's a matter for later debate - BLP seems the obvious place to start if we must do it piecemeal.Anaxial (talk) 22:44, 23 December 2008 (UTC)[reply]
  70. Support. This would help implement some control without turning away potentially useful contributions. – Joe Nutter 22:45, 23 December 2008 (UTC)[reply]
  71. Support It will provide more control over the articles while still allowing anyone to edit. And it will provide a good (large) test case for Flagged Revisions. --Falcorian (talk) 23:21, 23 December 2008 (UTC)[reply]
  72. I'm happy with this. Majorly talk 23:21, 23 December 2008 (UTC)[reply]
  73. Another excellent and pragmatic solution. Jclemens (talk) 23:37, 23 December 2008 (UTC)[reply]

Oppose Flagged Revisions for all BLPs

  1. There is no way for the use of stable/flagged/cabal-approved revisions to be limited to one category, and it wouldn't make any sense to do so as anyone can add or remove a category. This would be a social restriction rather than a technical one, and I see no reason to honor it really. What purpose would be served by writing a policy that says "this feature should only be used for living people, other articles are unworthy"? Oppose in favor of explicitly allowing edit-flagging on any and all content pages. — CharlotteWebb 23:03, 19 December 2008 (UTC)[reply]
    Do we know for a fact this technical limitation can't be changed? rootology (C)(T) 23:07, 19 December 2008 (UTC)[reply]
    I just found out we can indeed do this from a technical standpoint. People can certainly remove a BLP category, but thats sort of a red-flag action in and of itself that would also be limited by the flagging process. rootology (C)(T) 23:10, 19 December 2008 (UTC)[reply]
    It would be a technical restriction if the 'surveyors' agreed to only enable FlaggedRevs on articles in Category:Living people, or if you had a bot with 'surveyor' status do it. --Pixelface (talk) 03:48, 20 December 2008 (UTC)[reply]
    I must have confused the hell out of somebody. Let me make this clear. I will support this only if there are no technical or social restrictions against using flaggedrevs for other pages (some of which will need it more badly than the average BLP). — CharlotteWebb 15:52, 21 December 2008 (UTC)[reply]
  2. Strong oppose as someone who is continuously vigilant of a conservative reading of our blp policy, as both going against our "anyone can edit policy" and making it harder to actually deal with random blp vios. I often spot blp vios reading an article on somebody I have just read about elsewhere and the idea that I and others could not do this kind of blp removal IMMEDIATELY just seems completely counter-productive. Plus its a huge time waster. Thanks, SqueakBox 23:24, 19 December 2008 (UTC)[reply]
  3. Strong oppose, but I will not be opposed to an X month trial so we can see how bad backlogs really get. I suspect this will go the same way as the New Page Patrolling backlog (ie, dies). - NuclearWarfare contact meMy work 01:21, 20 December 2008 (UTC)[reply]
    Followup: After thinking about this more, I feel that I would not even support a multimonth trial, not for a group as large as BLPs. There 327k articles in the Living People's category. That's far too high of a number to start a trial at; I'd prefer it if say, currently featured or semi-protected articles were trialed (both have 2-3k articles). Even something with 100k articles would be more preferable as a trial. - NuclearWarfare contact meMy work 16:57, 21 December 2008 (UTC)[reply]
  4. Oppose - unless an exception was granted for high-edit and/or articles tagged with a "recent event/death/whatever" tag. --Philosopher Let us reason together. 01:46, 20 December 2008 (UTC)[reply]
  5. Oppose; I do not see what flagging revisions will do except for irritate vandals and provoke them to become more egregious in their vandalism. This is especially of concern with BLPs, and flagged revisions more like than not will not affect vandal pagemoves (a common JA/G tactic). We need to be able to see and remove vandalism on sight, registered account or otherwise, and this would firmly plant anons in a second-class citizen situation. Flagged revisions at present are too double-edged - good anons cannot reverse the actions of their crueler counterparts unless they access and read the history (which a lot of anons likely do not know how to do), and good anons updating an article will constantly repeat their edit or become a vandal when they find that the good edit they've just made doesn't show up, even after server-side delay is factored in. -Jéské Couriano (v^_^v) 03:42, 20 December 2008 (UTC)[reply]
  6. Oppose I'm irritated by the invocation of the Wales at the top of this page, but that isn't the reason. Flagged revisions, when they come to wikipedia, should be trialed in a much smaller and more controlled area than BLPs. Further, if we don't have the willingness or editor resources to revert vandalism to these articles (ostensibly the reason we are pursuing this), how the hell are we going to flag all of these revisions as sighted? I'm not going to. If I see an article edit on the RC feed I won't give it a second thought unless it is obviously vandalism, then I will revert it. That's basically how Huggle stops most vandalism and it does so very quickly. The stuff that doesn't get caught is plausible info that upon deeper reflection, is vandalism. No technical process will make those edits more scrutable. What we will find ourselves with will be hundreds to thousands of articles with revisions in the sighting queue and no motivation to review them. Those edits will never make it into mainspace without being sighted so the motivation to pay some cursory look at them for the sake of keeping obvious vandalism out is gone as well. Aside from the effectiveness issue, I still don't understand how this notion of sighted revisions helps us gain new adherents or live up to our guiding principles. We can bullshit ourselves into thinking "sighted revisions means we can unprotect George W. Bush", but the same number of anonymous edits to that page will stick with protection as without. And in return we will have blocked off anonymous access to every MLB, NFL and NHL player page (or, placed that access behind the gatekeeper of a revision sighter). Great. Protonk (talk) 05:30, 20 December 2008 (UTC)[reply]
  7. Oppose again this is overkill. We are the encyclopedia anyone can edit. Hut 8.5 10:18, 20 December 2008 (UTC)[reply]
  8. Oppose Not yet. We should try semi-protection first. And then perhaps we wil still thik we need ths--and if we do, it should first be implemented on a vulnerable subset so we can see how practical it is.DGG (talk) 18:49, 20 December 2008 (UTC)[reply]
  9. Too much management needed. Stifle (talk) 10:55, 22 December 2008 (UTC)[reply]
  10. Oppose Flagged revisions are a stupid idea, it creates a false sense of security and much work. Determined vandals proved time and time again that they are willing to create masses of socks to circumvent such measures. Think of it, they just need to manage to mark a bunch of BLPs as flagged with vandalism and most people will ignore checking the page because of the "flagged"-state. Regards SoWhy 21:30, 23 December 2008 (UTC)[reply]
    So we should avoid a solution that would only fix the vast majority of the problem because some problems would remain uncorrected? WilyD 22:20, 23 December 2008 (UTC)[reply]
  11. Oppose As I said above wiki is the encyclopedia anyone can edit. BigDuncTalk 22:17, 23 December 2008 (UTC)[reply]
  12. Oppose. First it is a tremendous overkill and an overreaction. The great majority of BLPs are quiet, noncontroversial articles where nothing much ever happens and in the few cases where there genuine BLP issues, there is usually enough attention to fix them. Second, the flagged system is inconsistent with the basic philosphy and the basic model of how Wikipedia operates and would certainly interfere with the normal editing process that involves incremental changes by multiple editors. Untangling "good" edits from "bad" ones would become a real mess. All sorts of new types of edit wars could ensue. Who will have the right to flag what and when? Are we about to introduce a new stratification of "trusted" users, something intermediate between an admin and the average Joe Shmoe? If yes, the very nature of how content discussions and disputes are handled will change dramatically, with users being divided into several classes of citizenship. It will be very easy to abuse and misuse the system by pursuing editorial agendas that have nothing to do with BLP. Imagine, for example, the effect of flagging on AfD discussions. It will be rather easy to prevent improvements to an article listed for deletion being made by refusing to flag them or by simply not getting around to flagging them. Also, presumably, a brand new kind of content dispute will arise, regarding whether or not a particular version deserves to be flagged. We have enough disputes and acrimony already. No thanks. Nsk92 (talk) 22:54, 23 December 2008 (UTC)[reply]
  13. Per my above reasoning against semi-protection. Anyone should be able to edit this encyclopaedia. —Cyclonenim (talk · contribs · email) 22:59, 23 December 2008 (UTC)[reply]
  14. Oppose flagged revisions in general. Other projects like Veropedia are better suited for deciding which versions are "good". Wikipedia is and should always be the live, you-can-edit-this-page-AND-see-it-right-now project. --Explodicle (T/C) 23:02, 23 December 2008 (UTC)[reply]
  15. Oppose flagging revisions. I don't think people understand how big Wikipedia is. This would create an enormous backlog and waste the time of Wikipedia's active users. Shii (tock) 23:29, 23 December 2008 (UTC)[reply]
  16. Oppose flagged revisions. Not worth the effort. - Peregrine Fisher (talk) (contribs) 23:36, 23 December 2008 (UTC)[reply]

Implement Flagged Revisions for all articles / content pages

  1. This would include templates, images, categories, and anything else that might somehow be part of the dependency tree of any article or portal page, etc. — CharlotteWebb 20:33, 19 December 2008 (UTC)[reply]
  2. An important move to make in making this an encyclopedia. Has worked well on de:wp - David Gerard (talk) 20:46, 19 December 2008 (UTC)[reply]
  3. I would support but doubt consensus would be reached without first seeing it implemented in some articles such as BLPs. Davewild (talk) 20:50, 19 December 2008 (UTC)[reply]
  4. If it were possibly to do this and get it through, it would be a good thing, but not on Wikipedia space, please (at least at first). rootology (C)(T) 20:56, 19 December 2008 (UTC)[reply]
  5. This is where we need to get. Maybe this isn't the first step, but this is the destination, in my view. ++Lar: t/c 21:21, 19 December 2008 (UTC)[reply]
  6. I'm prepared to be persuaded, but I'm going to have to see how this functions in the wild first. Let's start with problematic BLPs and see how it goes. Xymmax So let it be written So let it be done 21:50, 19 December 2008 (UTC)[reply]
  7. Third. I do not know how readily it could be implemented with the large number of minor edits on non-controversial topics. Perhaps the limit should not be on the "topic" but on the activity therein -- if an article gets more than (say) ten edits a day that it goes into "flagged" status? Collect (talk) 22:09, 19 December 2008 (UTC)[reply]
  8. To move the emphasis to the quality of all content. FloNight♥♥♥ 22:16, 19 December 2008 (UTC)[reply]
  9. Moreschi (talk) 22:17, 19 December 2008 (UTC)[reply]
  10. bibliomaniac15 22:54, 19 December 2008 (UTC)[reply]
  11. Prefer this, though I support implementing flaggedrevs in pretty much any way. Mr.Z-man 00:18, 20 December 2008 (UTC)[reply]
  12. Support; this will allow stability without sacrificing the ability to edit as semi protection schemes necessarily must; it will also greatly reduce the number of times we have to protect at all. — Coren (talk) 00:33, 20 December 2008 (UTC)[reply]
  13. Yes. It has worked well on .de and on the English wikinews as well as a variety of other projects. JoshuaZ (talk) 03:24, 20 December 2008 (UTC)[reply]
  14. Third choice, weakly, we don't have the manpower to implement this idea, but if it will help the BLP issue, we must adapt. MBisanz talk 03:50, 20 December 2008 (UTC)[reply]
    Essentially to get rid of vandalism, libel, most blp issues, etc. Not too soon though, I am afraid that we might rush things and ultimately screw up. But only with an expiration system to prevent inevitable backlogs. Cenarium (Talk) 04:00, 20 December 2008 (UTC)[reply]
    Indent, as explained, I prefer the option to #Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages. Cenarium (Talk) 14:16, 20 December 2008 (UTC)[reply]
  15. Support Possibly with a different implementation for BLP vs non-BLP articles, but we can discuss that later. --Tango (talk) 14:31, 20 December 2008 (UTC)[reply]
  16. First choice. Peacock (talk) 15:23, 20 December 2008 (UTC)[reply]
  17. Support iff the implementation is not sighted-revision-viewed-by-default, for all users and all pages. While I think that flagging revisions is probably a good idea, making sighted revisions what's visible by default effectively denies editing to those without the ability to sight edits. Even if we could handle the backlog of unsighted revisions (our ability to do so is dubious), the disincentive to editing for anonymous users would definitely be a bad thing. It's been shown by academic studies that anonymous and infrequent users contribute a significant amount of our content, and I think that sighted-by-default FlaggedRevs project-wide would disrupt that positive influence. For all that it would effectively destroy vandalism, we could do that any number of ways which would be obviously unacceptable by our foundation principles, and I think that this is one of those ways.

    That being said, I do think that FlaggedRevs has potential, for BLPs and elsewhere. Showing, to some extent, what's been reviewed and what could be vandalism—that is, the status of being sighted or not—would be a good step in the direction of visible quality without sacrificing the ability of most people to effectively edit. I find that being able to selectively, but not systematically enable sighted-by-default for particular pages liable to much vandalism or libel might be worthwhile, as a different form of protection which could be applied to articles, such as BLPs, for example, as an alternative to semi-protection. {{Nihiltres|talk|log}} 18:39, 20 December 2008 (UTC)[reply]

    Please do not advocate this— Without 'by default' flagging is little different than the ill-fated page patrolling feature which no one put enough effort into using simply because it didn't do anything except update a little note about each revision. Some people argue that flagging will be a massive failure because no one will update the flags, but that prophecy becomes potentially self-fulfilling when its used to argue that flagging should be castrated to non-default viewing. In terms of mitigating harm a link to some "blessed" version is little different than the availability of the history tab.
    With the right configuration flagging can be setup so that the new-editor would be largely unaware that his edit is only visible to himself, other editors, and people who have chosen to see the latest draft: He edits, he sees his edit and continues to see his edit every time he visits the site unless it is reverted, based on the existence of an editing cookie. The whole flagging and visibility to millions of people vs visibility to thousands of Wikipedia editors would then just be sausage making details that most new users would be completely unaware of… With that in mind your whole causal chain falls apart. In fact, life would be much easier on the new editor since we wouldn't need to be as overagressive with vandalism patrol. I edit logged out a lot and have too frequently found that my perfectly good edit is reverted seconds later by a fly-by "vandal fighter" with little hope of recovery unless I redo it. So, in fact your doomsday situation where new users are effectively unable to edit happens already to anons and careful use of revision flagging can actually be a way to escape that problem. --Gmaxwell (talk) 19:26, 20 December 2008 (UTC)[reply]
    1. I differ on the point that "a link to some "blessed" version is little different than the availability of the history tab". Unless a vandal leaves an obscene, descriptive, or automatic edit summary (and it is my experience that vandals don't generally bother with edit summaries), it requires active work for the average reader to discern quality revisions with only the page history. I think that 'a link to some "blessed" version' is precisely what would help many users easily avoid vandalism and other nonsense. We can get that without making any restrictions on dynamic updates, so I think that's what we should do.
    2. Transparency in the editing process is important, and we need to be transparent about how things work and what editing is going on. I think that it would be a big problem if we have to make a big distinction between "thousands of Wikipedia editors" and "millions of [readers]". I don't think it would be healthy to cement or expand any gap between readers and our preexisting editors. Besides, technical fake-outs to show the newbie editor the draft (as you seem to suggest would work well) will fail at some point: if Anonymous user A refers a good faith correction to a friend and the friend can't see it, how long is it until he complains that his edits aren't showing up?
    3. Can you please provide examples of areas where you, or another editor, have had their edits reverted solely on the basis of their being made by an anonymous user? Even assuming that there are several valid examples, how could we acknowledge that random anon-reverting is a problem while condoning a more effective measure to prevent their effective participation? Certainly the answer here would be to address any problem with arbitrarily reverting anons, rather than introduce a more serious barrier to entry.
    I think that the above points are valid concerns. At the very least, please consider that it is a valid opinion—I think that non-default flagging is a good thing, and I am free to advocate my opinion, within reason. Besides, I do not advocate a hard limit: one of the things that I say is "not default" (emphasis added), and it might just be possible to recognize that my position is not black and white on the issue… all this ignoring the point that this is explicitly a "feeler survey" on which our opinions are being asked. {{Nihiltres|talk|log}} 21:05, 21 December 2008 (UTC)[reply]
  18. I think the common wisdom about BLPs is wrong: BLPs are not subject to greatly increased risk of total harm —rather, BLPs are subject to greatly increased risk of complaint about harm. In other words: BLPs are more sensitive indicators of our overall performance than other types of articles, but by themselves are probably only somewhat more risky than average. In a great many non-BLP articles there is a risk of vandalism causing extreme harm: consider a statistics article vandalized in an unfortunate way at an unfortunate time which results in an engineer miscalculating the safety of his design. In that case there is no singular obviously wronged person to notice and complain that his article is incorrect—so we may not feel the pain of the vandalism but a great many people may be harmed. Moreover, the impact of significant harm caused by problems in BLP articles is generally limited to a few people (the subject and his close associates), while errors in other areas can impact more people. I've witnessed firsthand an error from Wikipedia making its way into a software design document. While not itself a safety-impacting error, it was enough to make me sure that safety-impacting errors do occur. Even to those of us who care only or mostly about BLPs, flagging only BLP articles is clearly insufficient to protect the subjects: if a vandal changes Bomis to call it a child porn site, the actual harm to Jimmy would be just about equal to the harm caused by the same claim placed directly in the article on Jimmy himself. I think it's unfortunate that we continue to special-case BLPs, since when we do that we're killing our best indicator of potential harm throughout the project while only making a fairly limited improvement. All that said, if people wanted to flag only BLPs as a testing point, I wouldn't oppose it, since we do need to start learning about the impacts of flagging. I do oppose flagging+semi at this time, but only because I think we should make one change at a time in order to measure the results. --Gmaxwell (talk) 01:01, 20 December 2008 (UTC)[reply]
    I think you're wrong about potential harm. When people want to know about Jimmy Wales (or any individual), they do not type "Bomis" into a search engine. They type the person's name. If there's something harmful in their biography, it is much, much more likely to reach the eyes of people curious about that person, thereby causing harm. That said, thank you very much for not being opposed to BLP flagged revisions as an experiment. Cool Hand Luke 01:20, 20 December 2008 (UTC)[reply]
    And yet… the Bomis article still gets more traffic than most of our BLPs. --Gmaxwell (talk) 19:08, 20 December 2008 (UTC)[reply]
    At ~300 hits per day, it gets more traffic than most of our non-BLPs too. I'm not sure which way that cuts; low hits also lengthen the period of time that errors might persist. Jimbo has many more hits than Bomis in this case, but I'm more interested in the mechanism of serving articles than the hits.
    When someone wants to know about an individual, they type the name of that individual, and google retrieves their Wikipedia biography because of the page name and the inlinks. So sure, Nike, Inc. gets much more traffic that CEO Mark Parker, but when one searches for "Mark Parker," only the biography comes up, not the company. Every BLP is a high-ranking magnet for potential defamation on particular individuals. It's not that there's no potential for harm from non-BLPs (there certainly is), its that BLP articles are a good place to start—to test whether or not we can handle flagged revisions. Cool Hand Luke 19:25, 20 December 2008 (UTC)[reply]
  19. I think this is our destination, and editors are certainly free to focus on BLPs if they wish. I would. Cool Hand Luke 19:34, 20 December 2008 (UTC)[reply]
  20. Flagged revisions have far more upsides than downsides - the upsides are practical and ethical, the downsides are philosophical or extremely hypothetical.--Tznkai (talk) 21:10, 20 December 2008 (UTC)[reply]
  21. I don't see any practical downsides to this. The German Wikipedia seems to manage just fine, and I don't see why we wouldn't do just as well. Pfainuk talk 00:45, 21 December 2008 (UTC)[reply]
  22. This is definitely the way forward for en Wikipedia. dougweller (talk) 16:30, 21 December 2008 (UTC)[reply]
  23. Absolutely. Reduces the reward for vandals, provides higher-quality content, still leaves editing open to all comers. What's not to like? Seraphimblade Talk to me 22:05, 21 December 2008 (UTC)[reply]
  24. Anything that would improve Wikipedia's credibility is to be welcomed 21:57, 22 December 2008 (UTC) <-- This is User:George The Dragon.
  25. Everyking (talk) 05:53, 23 December 2008 (UTC)[reply]
  26. I support doing this and/or semi-protection for all articles. I've seen firt-time IP users do things like change a birthdate by one year. I can't check out everything like that. Bubba73 (talk), 22:07, 23 December 2008 (UTC)[reply]
  27. A very attractive idea. I'd like to see how it unfolds once actually put into use. —La Pianista (TCS) 23:26, 23 December 2008 (UTC) Changed to oppose upon further thought. Reasons below. —La Pianista (TCS) 23:28, 23 December 2008 (UTC)[reply]
  28. Another fine, workable idea. The departure from the ideals of infant Wikipedia is more than made up for by the usefulness in building an encyclopedia. Jclemens (talk) 23:39, 23 December 2008 (UTC)[reply]

Oppose Flagged Revisions for all articles / content pages

  1. Strong oppose, ludicrous idea that would be unworkable and make wikipedia the website not to edit. Thanks, SqueakBox 23:25, 19 December 2008 (UTC)[reply]
Flagged revisions do not restrict the ability to edit the page. - Mgm|(talk) 13:35, 20 December 2008 (UTC)[reply]
  1. Oppose: It would make us more reliable, at the cost of being less informative. We'd get massive backlogs, which no-one will want to tackle. Because of these massive backlogs, newbies will complain that their edits aren't being processed and then leave us. Then we have even less editors to handle the growing backlog. Rinse, lather and repeat. Dendodge TalkContribs 00:04, 20 December 2008 (UTC)[reply]
    Thanks for that, a cogent explanation of the problem this would cause. Thanks, SqueakBox 00:25, 20 December 2008 (UTC)[reply]
    Except that it's hand-waving speculation which is unsupported by the experiences of other projects who have enabled flagged revisions. I expect there is consensus that those outcomes would be bad and would justify further changes to the configuration. --Gmaxwell (talk) 19:11, 20 December 2008 (UTC)[reply]
  2. Crazy strong oppose Yeah, lets increase the existing backlog by a factor of 12. I'm not sure how many articles we miss at NPP, but I'd estimate 150/day, at least, translating to 4500/month. At least those articles are still allowed through. I shudder to think of the backlogs that have to be gone through before edits from, say two months ago are let through. - NuclearWarfare contact meMy work 01:26, 20 December 2008 (UTC)[reply]
  3. Oppose without some kind of trial first. This could either be a small-number-of-pages trial, or a "flag but show most recent version" type test as I proposed elsewhere on this page. davidwr/(talk)/(contribs)/(e-mail) 01:34, 20 December 2008 (UTC)[reply]
    ...and does absolutely nothing to help the BLP issue. Many readers don't even notice the edit tabs, why would they notice a "prior flagged revision available" note? Why would anyone even care to flag such articles? What is the purpose, exactly? Cool Hand Luke 01:43, 20 December 2008 (UTC)[reply]
  4. Templates Only, see above for BLP thoughts--Philosopher Let us reason together. 01:47, 20 December 2008 (UTC)[reply]
  5. Oppose for now, see how it works on BLPs first. About 1 in 8 articles is a BLP, and a BLP is edited about once every 5 seconds. 156,430 users have made at least one edit in the last 30 days. Even if you made all of them 'reviewers', is that enough people to 'sight' all 2,665,657 articles? --Pixelface (talk) 03:19, 20 December 2008 (UTC)[reply]
  6. Lor no; see my opposition to flagging BLP's above. Flagged revisions are too much stick and too little carrot. -Jéské Couriano (v^_^v) 03:43, 20 December 2008 (UTC)[reply]
  7. ABSOLUTELY NOT. Yeah I used caps. I really do think this would be a very bad idea, for many reasons, most of which have been said again and again. Wizardman 04:27, 20 December 2008 (UTC)[reply]
  8. Strong Oppose - the backlogs would probably explode... VX!~~~ 05:04, 20 December 2008 (UTC)[reply]
  9. Uhhh How many permutations are there going to be? I guess I'll note here that I'm opposed to implementing flagged revisions elsewhere but my rationale is at one of the various "Whatever it is, I'm against it" sections above. This is confusing. Protonk (talk) 05:32, 20 December 2008 (UTC)[reply]
  10. Oppose Disaster waiting to happen. Let's not go there. PeterSymonds (talk) 09:50, 20 December 2008 (UTC)[reply]
  11. Oppose this will prevent huge numbers of constructive editors from contributing and is directly opposed to the spirit of Wikipedia. Hut 8.5 10:22, 20 December 2008 (UTC)[reply]
  12. oppposeWe simply don't have the rescources.Geni 13:10, 20 December 2008 (UTC)[reply]
  13. Oppose until a trial has been run and there's evidence we actually have the resources to handle it. - Mgm|(talk) 14:28, 20 December 2008 (UTC)[reply]
  14. Strong Oppose - Would the site still be wikipedia after such a monumental change? I mean last I checked the front page said: "Welcome to Wikipedia, the free encyclopedia that anyone can edit." --ScWizard (talk) 17:06, 20 December 2008 (UTC)[reply]
  15. Oppose Quite apart from the merits, I don't think we're well enough organized to do this--unlike some other wps. We would need to try a subset first. I may be wrong, but we need to find out before we go ahead with something this drastic. DGG (talk) 18:55, 20 December 2008 (UTC)[reply]
  16. Support or oppose depending on what exactly is meant. See my comment in the support section above. To summarize: I think FlaggedRevs is a good thing, but making sighted revisions what's visible by default is a bad thing (and this opinion is not self-contradictory! :) ). I suspect that many oppose FlaggedRevs primarily because of the idea that sighted revisions will be visible by default. {{Nihiltres|talk|log}} 19:03, 20 December 2008 (UTC)[reply]
  17. Oppose: As I opposed the trial proposal for flagged revisions. The backlogs would likely be unmanagable. - Rjd0060 (talk) 03:12, 21 December 2008 (UTC)[reply]
  18. Oppose Something needs to be done about BLPs and this effort is only a partial solution but implementing this across all articles is against the spirit of Wikipedia. We manage vandalism very well I think so this is overkill. Also, as others have stated we don't have the manpower for this and it would consume the time needed to address other serious problems such as POV pushing that this does not solve. EconomicsGuy (talk) 09:30, 21 December 2008 (UTC)[reply]
  19. I do not have sufficient obscenities in my vocabulary to express how strongly I oppose this suggestion, and I take pride in my vocabulary. DS (talk) 18:44, 21 December 2008 (UTC)[reply]
  20. DS above pretty much sums up my sentiments. J.delanoygabsadds 18:54, 21 December 2008 (UTC)[reply]
  21. J.delanoy above, sums it up for me. Synergy 19:07, 21 December 2008 (UTC)[reply]
  22. Goodness no. Stifle (talk) 10:55, 22 December 2008 (UTC)[reply]
  23. Oppose I think it would be simpler to semiprotect all articles, which is in effect what is being done from the casual ip editors point of view ("your edit won't appear until one of us checks it", really takes away from the instant gratification) Cheers, Casliber (talk · contribs) 06:23, 23 December 2008 (UTC)[reply]
  24. Oppose. This would require us to manually approve each and every edit. RC patrol is loaded enough dealing with the bad edits. Forcing them to take action on good edits will triple their workload at least. Flagged revisions are a good idea on a few articles, but it is a bad idea for universal implementation. Sjakkalle (Check!) 14:59, 22 December 2008 (UTC)[reply]
  25. Oppose Premature without a trial. --Dweller (talk) 13:03, 23 December 2008 (UTC)[reply]
    If people are opposed to the idea of flagged revisions, as you're indicating you are, there won't be a trial. WilyD 13:57, 23 December 2008 (UTC)[reply]
  26. Strong Oppose - A trial with BLPs, yes, this? No.sinneed (talk) 21:16, 23 December 2008 (UTC)[reply]
  27. Oppose I cannot think of something more absurd to import from de-wiki. I am a "sighter" there, I could run around flagging stuff as "flagged" and I could surely mark vandalism as such if I were a determined vandal and people would probably be tricked by it. SoWhy 21:34, 23 December 2008 (UTC)[reply]
  28. Per my above reasoning that this is an encyclopaedia which anyone should be able to edit. Also per NuclearWarfare that this would increase the backlog further. —Cyclonenim (talk · contribs · email) 23:01, 23 December 2008 (UTC)[reply]
  29. Oppose flagged revisions in general. Other projects like Veropedia are better suited for deciding which versions are "good". Wikipedia is and should always be the live, you-can-edit-this-page-AND-see-it-right-now project. --Explodicle (T/C) 23:03, 23 December 2008 (UTC)[reply]
  30. Oppose. An even more terrible idea than flagging all BLPs. Nsk92 (talk) 23:31, 23 December 2008 (UTC)[reply]
  31. I oppose flaggedrevs period. -- penubag  (talk) 23:50, 23 December 2008 (UTC)[reply]
  32. STRONG oppose. All users should see the latest version of all pages. Anything else is not acceptable for a site like this. And do we really want a "decide what people get to see" cabal? I sure hope not. Bushytails (talk) 23:52, 23 December 2008 (UTC)[reply]

Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages

  1. This is the best course of action: it will avoid harmful backlogs by automatically making visible to IPs revisions that are old enough on non-blps. While blps require more scrutiny, most articles comparatively don't and applying flagged revs without expiration on all would certainly create huge backlogs and prevent a mass of edits from going live. This would still allow to get rid of the quasi-totality of vandalism and other disruption, since most is reverted within a few hours. With the understanding that this is very flexible: it can be deactivated on certain pages, be prevented by the abuse filter, etc. Cenarium (Talk) 13:49, 20 December 2008 (UTC)[reply]
  2. Best option, since the "backlog" issue becomes moot. rootology (C)(T) 14:11, 20 December 2008 (UTC)[reply]
  3. Agreed (rather like what I supported before). Obviates all concerns about manpower. Collect (talk) 14:25, 20 December 2008 (UTC)[reply]
  4. This is my new favourite, as long as the expiry is no longer than 24 hours. This would allow us to prevent many of the bad edits from even happening, without creating massive backlogs. The one problem is whether or not it is possible. Dendodge TalkContribs 17:20, 20 December 2008 (UTC)[reply]
  5. Support (as a rather poor alternative to others) as long as the auto expiration was at least 6 months, preferably a year. One day, for example, is far too short. ++Lar: t/c 07:06, 22 December 2008 (UTC)[reply]
  6. I support doing this and/or semi-protection. Bubba73 (talk), 21:55, 23 December 2008 (UTC) [reply]

Comments

This section is silly. This is basically just a "preliminary" discussion. Throwing in more options similar to existing options is just going to split people up even more, make consensus look even more fuzzy, and decrease the chance we get anything decided here. These are the kind of details that should be worked out if/when we decide we want flaggedrevs at all. AFAIK, "expiration" isn't even an option yet in flaggedrevs. Mr.Z-man 17:06, 20 December 2008 (UTC)[reply]

I hear you, and you're right. But people like to add options. Just support everything (with a lukewarm/secondchoice/meh sort of comment) that is a step in the right direction, and oppose everything that isn't. That's what I'm doing. My personal destination is:
All BLPs semiprotected, with flagged revisions, and their existance subject to opt out for marginally notable subjects, use of dead tree standard for judging who is not marginally notable, default to delete for no consensus XfDs. All other articles (and anything else in article space or embedded by it or reached from it, to include (but not necessarily limited to) templates, portals, lists, image descriptions, etc... ANYTHING that someone not concerned with the underpinnings of content production might see) using flagged revisions with no automated default to flagged for any of it.
ANYTHING that moves us in that direction from where we are now, gets at least my lukewarm support, so any proposal that flags BLPs in whatever form, any proposal that semiprotects BLPs in whatever form... gets something positive from me. All journeys begin with a single step. ++Lar: t/c 07:14, 22 December 2008 (UTC)[reply]
I and others would oppose to flagged revisions without expiration on all articles because of backlogs, so this allows to make more specific choices. Cenarium (Talk) 12:24, 22 December 2008 (UTC)[reply]

Implement both Semi-Protection and Flagged Revisions for all BLPs

  • Comment. Is this not redundant? As I understand them, Flagged Revs are only placed for IPs, so if it's semi-protected, what's the need for FRs? SDJ 19:31, 19 December 2008 (UTC)[reply]
  1. See my objection to semiprotection. DurovaCharge! 19:46, 19 December 2008 (UTC)[reply]
  2. Isn't the above a comment, Durova? WHO sees flagged revisions first is an option, it could be set to "everyone" so it is possible to have and need both SP and FR. ... suppor this. ++Lar: t/c 21:23, 19 December 2008 (UTC)[reply]
  3. Lar makes a very good point. The two are not mutually exclusive; one is presentation, the other control. Support (which I didn't think I would, even though I added this section header myself!). rootology (C)(T) 21:33, 19 December 2008 (UTC)[reply]
    I consider myself progressive on this issue, but doesn't FR make semi-protection redundant (assuming that the flagged version is the reader default)? Cool Hand Luke 21:46, 19 December 2008 (UTC)[reply]
    I took it to mean that... BLPs are semi'd--the drive-by vandalism by IPs is a thing of the past. That still leaves sneaky vandals on usernames that are past the semi-limit, but wouldn't have the "Flagger" ability or whatever we'll end up calling it. So, it would be a double layer of protection, like an Oreo, with the BLP as the creamy center. The benefit of this is casual readers (our real userbase, not us) will only ever hopefully see a "good" version, without the chance of any crap snuck in by untrusted users OR anons. If I've butchered the technical aspects of this, someone please correct me. rootology (C)(T) 21:51, 19 December 2008 (UTC)[reply]
    I think it is fairly redundant, unless it's taken to mean "Semi today, Flagged when we work out the details". WilyD 21:54, 19 December 2008 (UTC)[reply]
    I'm with WilyD here. I support semi as a stop-gap to work out the details of flagging. I suspect that most sneaky vandalism actually comes from savvy throw-away accounts (flaggers would probably be more comfortable approving edits from a blue-link user), such that using both protections is redundant. Cool Hand Luke 22:07, 19 December 2008 (UTC)[reply]
    Lemme clarify that I'm not exactly endorsing that position, just explaining it. I'm conflicted about semi-prot. On the one hand, we clearly need to do a lot more than we're doing. But the barrier to entry is high. It's a tricky cost-benefit. Flagged is just soo much cleaner. Semi-protting is worth exploring, but I'm tepid. WilyD 22:18, 19 December 2008 (UTC)[reply]

Wait... why is this an option? The whole point of the flagged revisions extension was as a more open alternative to semi-protection, to make articles editable by anyone without any inappropriate revisions being visible to readers (too bad it didn't work). Semi-protecting the page and using the extension defeats the point of it -- Gurch (talk) 23:07, 23 December 2008 (UTC)[reply]

I don't like any of these options but something has to be done for BLPs

Leave your alternate idea here
  1. For all articles, show the current version but have a link at the top to the last-flagged version. This would alert users immediately that the version they are looking at has not been reviewed and give them an opportunity to go to the last reviewed version. davidwr/(talk)/(contribs)/(e-mail) 20:35, 19 December 2008 (UTC)[reply]
  2. Spread the word that Special:RecentChangesLinked&target=Category%3ALiving_people and other patrols exist. If that doesn't work to reduce the time vandalism stays on biography articles, then look at more severe actions like making BLP articles flagged-revision or semi-protect by default. "Use a light touch first, use more pressure only if necessary." davidwr/(talk)/(contribs)/(e-mail) 20:35, 19 December 2008 (UTC)[reply]
  3. I don't like the idea of semi protecting anything until such time as is demonstrably required. I don't like the idea of not allowing anonymous editors in, automatically. As a suggestion, perhaps categorize all BLP as a BLP and then place a noticebot in a public IRC channel. That would be a suggestion, but as for protection, I don't think I like the idea. NonvocalScream (talk) 21:15, 19 December 2008 (UTC)[reply]
  4. We just need to enforce a conservative interpretation of blp, its only cos loads of editors don't want to that we see this problem. Thanks, SqueakBox 23:26, 19 December 2008 (UTC)[reply]
    Keep in mind that the problem of vandalism is completely distinct from the problem of what material should actually be in an article when that material is well-sourced. Let's not confuse them. JoshuaZ (talk) 02:06, 20 December 2008 (UTC)[reply]
  5. Endorse Davidwr's idea. --Philosopher Let us reason together. 01:48, 20 December 2008 (UTC)[reply]
  6. A while ago I did a survey of how long it took to revert some vandal edits (see User:Hut 8.5/vandals). The vast majority of edits were reverted extremely quickly. However a handful of edits were missed by RC patrol and survived for much longer, and presumably it is these which pose the biggest risk since there is a much greater chance that someone will see them. In order to catch these edits we need some way of marking an edit as "patrolled", which I understand is already done on some wikis. Alternatively we could use flagged revisions while still giving all users the most recent version to read. Hut 8.5 10:30, 20 December 2008 (UTC)[reply]
  7. Alternate idea - If you have the capability to edit semi protected articles, your edit goes straight though. If you do not then your edit gets flagged. Kind of a cross between "flagged revisions for BLPs" and "semiprotect BLPs." --ScWizard (talk) 17:10, 20 December 2008 (UTC)[reply]
  8. improve patrolling A follow up on what Hut said a little above--organize RC patrol so we can catch what gets missed. If we can implement semi-protection of NLPs, we could alternatively establish a separate RC patrol for BLPs. DGG (talk) 18:59, 20 December 2008 (UTC)[reply]
    I agree with this and davidwr's idea above. Keeping a close eye on BLP articles, and having editors be more hard-line about reverting unsourced or inappropriate edits, seems to be a better solution than semi-protecting them. —Politizer talk/contribs 19:26, 21 December 2008 (UTC)[reply]
  9. I think we have all the policies here to address problems, we just have to priortise dealing with them. Cheers, Casliber (talk · contribs) 11:00, 22 December 2008 (UTC)[reply]
  10. On the few times I have been on RC patrol recently I have generally allowed very little tolerance on blatant vandalism to BLPs. While newbie testing on BLPs, such as adding "Hello" or "LOL" at the end of the article is dealt with in the usual, kind, {{test}} manner, I have been much harsher with people who use the bio as a medium to launch attacks. If I'm in a good mood, I can go with {{test4im}}, but if the vandalism is particularly vicious, I have no compulsions against instant-blocking without warning. I don't believe that anyone would be surprised, or righteously upset, at being blocked as a response to lies and slander to someone's bio. Perhaps standards are that way already with some admins, but if not I have no trouble in implementing tougher practices on vandalism like this. If a non-admin sees an anon making libel and slander on a BLP, they should be able to take them to WP:AIV immediately, without seeing the report rejected with "user hasn't been warned". Sjakkalle (Check!) 15:16, 22 December 2008 (UTC)[reply]
  11. Improve access to reporting functions, admins, and OFFICE Need I point out that the administrators' noticeboard is usually a 300kb, ad-hoc mess of a discussion page? Is it really so difficult to implement a simple forum on Wikipedia? If there were a "Problem!" tab before the "Talk" tab that took readers to a report form or admin forum, problems would get solved much more quickly. Shii (tock) 23:34, 23 December 2008 (UTC)[reply]

Leave BLPs exactly as they are

  1. Since this is the closest thing to a "both options are bad" section, let me just say that (absent context), both options (semiprotection and flagged revisions) are bad. Semiprotection would prevent anonymous users from just casually removing obvious BLP violations whenever they see them, which would make such violations harder to fix, and keep them on the article longer. Flagged revisions would mean that when an IP acted to remove BLP-violating information, we would nonetheless continue to display the bad content until some approved user allowed the article to be fixed. Either one implies that you must be authorized to remove libel - that's Bad Bad Bad Bad. I realize that this badness isn't the poller's intention; it's only what will actually happen. We shouldn't stop IPs from fixing things. Gavia immer (talk) 19:50, 19 December 2008 (UTC)[reply]
    How do you propose we stop IPs from breaking things? IPs are more likely to add violations than remove them. Cool Hand Luke 20:34, 19 December 2008 (UTC)[reply]
    The same way we do it now, which mostly works (ANI/AIV reports are not a representative sample of all IP edits). My experience is that most IP edits are generally trival (neither especially good nor especially bad), with an admittedly visible volume of test edits. My further experience is that most bad IP edits are either spam/SEO crud or experienced users attempting to avoid scrutiny. Restricting casual editing of BLPs because of a (very visible) minority of edits is the wrong way to do things. I do think there are addressable deficiencies in our monitoring BLP-sensitive articles; I just don't think these proposals are the way to go. Gavia immer (talk) 20:55, 19 December 2008 (UTC)[reply]
    From my experience, with the exception of highly visible pages (Governors, cabinet members) where vandalism is reverted quickly, IP editors are actually more constructive than destructive, hence (of course) the idea that Wikipedia is the encyclopedia that anyone can edit. --Philosopher Let us reason together. 01:51, 20 December 2008 (UTC)[reply]
    I hadn't thought of that, but flagged revisions would mean that if an IP saw BLP-violating information, then a 'reviewer' made a bad 'sight' (which is bound to happen I suppose). --Pixelface (talk) 05:13, 20 December 2008 (UTC)[reply]
    Right - there would be mistakes, oversights, approvals made too speedily, etc. I myself have accidentally rollbacked an article to a heavily vandalized version because I didn't notice another editor squeezing in a rollback before me. There would also be the problem that today's puppetmaster with carefully autoconfirmed accounts can be tomorrow's puppetmaster with carefully aged accounts and approval to make revisions sighted - if someone wants to get this, they'll get it, however slowly. Gavia immer (talk) 15:41, 20 December 2008 (UTC)[reply]
  2. Gavia has said it really well. - NuclearWarfare contact meMy work 01:33, 20 December 2008 (UTC)[reply]
  3. I agree with Gavia's concerns. This is a problem I hadn't considered, and I originally came here with the intention of endorsing semi-protection, but this argument has changed my mind. JulesH (talk) 10:46, 20 December 2008 (UTC)[reply]
  4. A BLP that meets WP:V, WP:NPOV, and WP:OR is not defamatory; a BLP which is defamatory doesn't meet one of WP:V, WP:NPOV, or WP:OR. Trying to use semi-protection or flagged revisions to fix policy violations is absurd on its face, because neither of them address the issue at hand. The only solution is to require strict adherence to policy—just as WP:BLP already does. Ozob (talk) 22:40, 23 December 2008 (UTC)[reply]
  5. (i) Protecting >500,000 articles would make "the encyclopedia that anyone can edit" essentially incorrect. (ii) "Flagged revisions" does not scale to wikis that see more than a few thousand edits per day; the German Wikipedia has already proven this, so there is no reason this projects needs to -- Gurch (talk) 22:54, 23 December 2008 (UTC)[reply]
  6. Gavia said it better than I can. —Cyclonenim (talk · contribs · email) 23:03, 23 December 2008 (UTC)[reply]
  7. Damn right. Wikipedia should be as open and free as possible - if American libel laws require that we change that, we should move the servers to a different country. --Explodicle (T/C) 23:14, 23 December 2008 (UTC)[reply]
  8. Exactly. I have seen no compelling evidence that some sort of drastic changes regarding BLPs are needed, and the harm done by the proposed changes looks much more significant than whatever problems do exist. Nsk92 (talk) 23:34, 23 December 2008 (UTC)[reply]
  9. In the sense that I don't think we're taking full advantage of the tools we already have available. My experience having watchlisted Anna Wintour after improving it to A-class has shown me that a vigilant regular editor is all that is needed for one high-profile BLP (and there are periodic attacks on that one from both PETA types and angry fashionistas); see the article's edit history. I was going to support flagged revisions until I read the opposes; they have concerns there that lead me to believe it could actually make problems worse by preventing anons from making good edits. I also think either measure may actually increase our legal exposure since it will be harder to claim that we aren't a common carrier.

    There are some ways we could improve this; I'll put them in the above section later. Daniel Case (talk) 23:49, 23 December 2008 (UTC)[reply]

Polls are evil

Keeping in mind that this isn't a poll, it's a survey to see which ideas are most popular, and worth looking more at later, and keeping in mind there isn't a more practical way to get a wide cross-section of users to simply sound off
  1. Dogmatically: "All polls are evil", but some are more evil than others. This is among the least evil ever :) ++Lar: t/c 21:24, 19 December 2008 (UTC)[reply]
    What makes this poll especially evil? We've discussed this matter for over a year, and a poll seems like a good way of assessing community support of moving forward with implementation of one of these proposals. How should we decide? More inconclusive threads at the Village Pump? A fiat from Jimbo? If there's a better way please suggest it. ·:· Will Beback ·:· 23:51, 19 December 2008 (UTC)[reply]
    It's traditional to have "All polls are evil".... somebody had to vote for it. :) (Note I've voted in several of the other categories too) Personally I think (as I said before) it's about as unevil of a poll as you can get. Because, maybe this time it would be the start of actually implementing some very needed changes. Hope that helps. ++Lar: t/c 00:53, 20 December 2008 (UTC) (PS I don't actually think all polls are evil, myself)[reply]
  2. All polls are [evil], but some polls are more [evil] than others. This one is just fine. :) - NuclearWarfare contact meMy work 01:34, 20 December 2008 (UTC)[reply]
  3. Why no to have an open discussion without the dreadful oppose/support? The result of these so called "polls" is that they die sooner or later and nothing happens. Why? Because they polarize views rather than build consensus. Show me a poll that ever worked. ≈ jossi ≈ (talk) 18:50, 20 December 2008 (UTC)[reply]
    1, 2, and probably a lot more. Big site-wide stuff needs a big site-wide review and you can't get hundreds of people in a discussion realistically without senior/power users unfairly dominating it. Besides, Jimmy already said he will act on the outcome of this. rootology (C)(T) 18:59, 20 December 2008 (UTC)[reply]
    The examples you give are actually votes, not polls. The section below is what was needed in the first place. Then, maybe later, when we have had the chance to discuss and explore, a poll could be constructed and announced to gauge consensus. ≈ jossi ≈ (talk) 19:05, 20 December 2008 (UTC)[reply]
    And as I wrote when I made this page, this is explicitly not a poll but a survey. Apples and oranges; lets kill internal systemic bias of frequently posting power users dominating any discussion that will affect the whole site, which is a better idea. All opinions are of value here but no one user is more more valuable in their opinion than another. Thats the neat thing about this format. rootology (C)(T) 19:08, 20 December 2008 (UTC)[reply]
    Self-serving comments aside, an open discussion rather than a support/oppose format is a much better way to build consensus. ≈ jossi ≈ (talk) 21:36, 20 December 2008 (UTC)[reply]
    There is no way to fairly accurately gauge consensus for something of this scale on some tucked away 2004-style discussion for a realistic discussion, without given unearned and undeserved weight to the wikipolitical crowd that loiter on those pages. As this affects everyone, rather than just any of the various "in-crowds", this is how it has to reasonably be. Traditional, potentially outdated discussion formats have never scaled for site-wide matters in all the years I've been following this website. I would argue that this method (same as RFA, same as RFAR elections, same as Board elections) breaks the power that any group or lone people try to claim for themselves. No one user(s) are entitled to any undue weight on a matter of this magnitude. This is an even more important change, for that matter, if it happens than any silly RFA, AC election, or even board election. Self-appointing regulars, to be blunt, have no right to more say in a matter like this than those that don't religiousy, regularly, or too frequently haunt the Wikipedia discussion space. rootology (C)(T) 21:51, 20 December 2008 (UTC)[reply]
    The reason for this should be explicit, so I'll note it: We've been having open discussion for a long time, and have very little idea how people actually feel about these things. This actually is illuminating - it suggests if a concrete proposal for a flagged revision system for BLPs was developed, a consensus could probably be developed to implement it, and then once we saw how it was running, we might revisit the issue of whether it was the right choice, whether we want to extend or retract the system or whatever. We could've continued the open discussion until it had been running for a hubble time and not figured out what to do or what people felt and thought. WilyD 07:25, 21 December 2008 (UTC)[reply]
  4. Polls aren't evil, pollsters are evil., this is a good way of determining how the AN reading and otherwise "hooked in" wikipolity feels about the BLP problems.--Tznkai (talk) 21:24, 20 December 2008 (UTC)[reply]
    Support (lol) ≈ jossi ≈ (talk) 21:34, 20 December 2008 (UTC)[reply]
  5. The community is good at a lot of things but having polls is evidently not one of them per prior experiences. This should be a threaded discussion and should be advertised on watchlistes. EconomicsGuy (talk) 09:46, 21 December 2008 (UTC)[reply]
    The community does fine at polls; the niche crowd that assumes they're in charge of Wikipedia because they loiter more on some pages dislikes it because polls enable anyone who posts to even standing if they say something that makes sense, even non Wikipedia space regulars, as detailed to Jossi by me in painful detail above. In any event, this is already a threaded discussion page. Old-school consensus chat does not and will not ever scale for major site-wide things like this, and will less and less each year. It's not 2004 anymore. But the Watchlist thing is a good idea, and I'll suggest it on WP:AN! rootology (C)(T) 16:16, 21 December 2008 (UTC)[reply]
  6. This poll isn't so much evil as premature. We haven't even garnered consensus for a flagged revs trial yet, let alone implemented such a trial, let alone seen it successful, let alone found consensus for rolling it out. Not so much premature then, as still in the first trimester. --Dweller (talk) 13:06, 23 December 2008 (UTC)[reply]
    Maybe you misunderstand what we're doing here. We're trying to glean whether there's likely to be a consensus for a trial or implementation. If garnering a consensus is the first trimester, we're scheduling an appointment with a fertility doctor. WilyD 13:55, 23 December 2008 (UTC)[reply]

General discussion

Comment Just to break the monotony of the structure of this poll/survey/whatever that do not allow discussion or the arguments/counter arguments cycle. As you may be aware, there is a proposed trial of flagged revs on featured articles. The class of BLPs is too huge for a trial and it would certainly be impossible to handle without a first experience and a phase of analysis and resolution of problems. So indeed, sighted revs on all articles, and especially blps, is to be considered and planned, but before we need a trial and a substantive reflexion on flagged revisions. The primary problem with flagged revs on the English Wikipedia is that due to its size and the very high number of editors, backlogs will become excessively large and so edits, good ones, won't be flagged for extensive periods. Allowing someone to edit and then not displaying the revision in a timely manner on a huge number of articles is actually worse than not allowing to edit on a limited number of articles. Very likely, it will discourage IPs and new users from editing Wikipedia, and prevent addition of good material. Now, there is a solution: automatically flagging revisions after a certain period of time, for example 18 hours, with a possibility to adjust the delay depending on the backlog, deactivate it on certain pages, for example on blps that have proved problematic, make the delay longer for blps, create a special page listing only blps, allowing the abuse filter to prevent automatic sighting for certain edits that are very likely to be vandalism, etc. We could also create a higher level of flagged revisions (like semi protection and full protection), with a smaller usergroup able to flag with this level on articles where it is enabled, for articles with serious problems. A comment on newly created blps too: those can't be handled by sighted revs before being sighted for the first time, if ever. So we still need to filter at Special:Newpages. When a blp is identified as such, for example through categories, that can be detected by the software, and has been sighted, it can then be monitored by flagged revisions in a specific manner. Cenarium (Talk) 23:44, 19 December 2008 (UTC)[reply]

For the purposes of a test, it could always be done first just on one letter--flag all the "T" BLPs, or the "As", for a week or a month, to see how it goes. rootology (C)(T) 00:50, 20 December 2008 (UTC)[reply]
No. The most damaging sort of edits are the ones that survive RC patrol, so I don't think any kind of automatic flagging is a good idea. I'm unclear why everyone claims that backlogs will be huge (an untested assumption, honestly). Isn't flagging a user right that can be distributed like rollback? Cool Hand Luke 00:55, 20 December 2008 (UTC)[reply]
German Wikipedian backlogs are huge, I've heard. As of a few months ago, I believe they were at a 100,000 articles that still needed to be checked[citation needed] though. I like the system put forth here though. If the most recent version is showed, but with an icon noting that it hasn't been checked yet, that might be far more useful. - NuclearWarfare contact meMy work 01:41, 20 December 2008 (UTC)[reply]
This page seems to say that 98.91% of all sighted articles are on currently reviewed. It appears that some articles have never been sighted, but for over 775,000 articles they are more-or-less up-to-date. Cool Hand Luke 01:57, 20 December 2008 (UTC)[reply]
The first sighting of each article takes special care, as it explains here. This page shows that all of the articles are getting sighted. Once sighted, they go on a worklist, and they appear to be kept up-to-date. The column on the far right shows articles previously sighted that are not up to date. Note that this isn't increasing, even as all the pages are getting sighted; it never goes above 8000 or so. Anyhow, the German experience shows diminishing backlogs, not increasing ones. Cool Hand Luke 02:20, 20 December 2008 (UTC)[reply]
Even so, 8000 old-reviewed articles, with unreviewed edits, most of them being days-old and some weeks-old, preventing revisions from going live, is far from negligible. The English Wikipedia has a much quicker editing rate, especially from IPs, and not a lot of 'regulars' in comparison, so it's likely the backlog will grow much higher. The usergroup can be distributed, but it's also a reason we need, not only a trial, but a progressive implementation: at the beginning, we'll only have rollbackers and admins to flag edits, largely insufficient for all blps. If you are referring to sort of edits that led to the Seigenthaler incident, then having an 'expiration' (automatic flagging) system or not won't change anything: new unreviewed articles will be listed at Special: Newpages when filtering out reviewed pages. While blps are more sensitive and require more oversight, most articles don't, so if we intend to use flagged revisions on all articles, an expiration system is a necessity. For blps, it may be delayed longer, or deactivated if necessary. Expired revisions would also be dealt with differently than usual sighted versions:with distinguishable signs, a specific special page to list them, etc. We could also make a special page specific to blps. And Huggle could have an option to sight a revision when the previous one is sighted, but it would still be insufficient for all blps. Cenarium (Talk) 03:30, 20 December 2008 (UTC)[reply]
There are 400,000 BLPs, perhaps (probably less). German Wikipedia is already successfully sighting 775,000 articles with less users than we have. I don't think there's a bottleneck here; it's at least worth a trial run. Cool Hand Luke 03:33, 20 December 2008 (UTC)[reply]
However, you are missing the fact that articles on en are edited much more often. We can't only consider numbers anyway, we need to implement to see how it will turn out, and prudence demands a progressive implementation, otherwise we will be flooded, and a trial before that. I have already worked intensively on flagged revisions and I am not opposed to it, but try to find ways to adapt it to Wikipedia, in a pragmatic manner and respecting our wiki nature. Cenarium (Talk) 04:07, 20 December 2008 (UTC)[reply]
We can also just try for one letter to see how it goes. A went smooth? Lets add B? Still good? C and D, etc. rootology (C)(T) 03:37, 20 December 2008 (UTC)[reply]
Yes, the implementation needs to be progressive to give the time to grant reviewer rights and adapt, the alphabetical order looks acceptable, with the occasional exception. Cenarium (Talk) 04:07, 20 December 2008 (UTC)[reply]
Implementation would be inherently progressive as articles wouldn't be flagged to begin with. That is, for articles where there is no flagged revision yet, the most recent one would be shown, and edits would take effect immediately. As BLPs would begin to be flagged, those BLPs that are would show the most recent flagged version first. That's how the German Wikipedia managed to scale the system.
In addition, depending on the mechanism being used to implement BLP protection, it could be applied incrementally. FlaggedRevs already supports per-page configuration of the default viewing level. Essentially the "show most recent flagged version first" setting can be seen as an alternative to semi-protection, and can be used as such on a per-page basis.
I'm writing some notes on the German experience at m:FlaggedRevs Report December 2008.--Eloquence* 04:16, 20 December 2008 (UTC)[reply]
Excellent; I look forward to your thoughts. Yes, I like the German system of incrementally reviewing new articles into flagged revisions. Cool Hand Luke 05:19, 20 December 2008 (UTC)[reply]
This is interesting, thanks. Some useful and significant data has been gathered, but it seems still too soon to see the impact on user contributions. I do not believe that 10000 articles is a reasonable number though.
Indeed the implementation would be progressive in that sense. At the very beginning of the implementation, admins should be allowed to enable flagged revs on blps, essentially to be used on high-visibility or problematic ones. Then in a second step, we could enable Flaggedrevs by default, either massively or incrementally. The advantage of an incremental implementation, for example following the alphabetical order, is that, since most blps are likely to be sighted randomly, it'll relatively keep things 'under control', avoid dispersion, and focus the attention of users for feedback purposes (in anticipation to an extension to all articles, in particular). Of course, a trial prior to the implementation would provide sample analysis.
The backlog is the primary problem, especially in the event of an extension to all articles. I believe that a system of expired revisions could precisely resolve it: if the backlog is huge, we reduce the delay to expiration (for non-blps), if it becomes less important, we can augment the delay. Expired revisions can still be flagged like any other, the only effect is that it becomes the stable version (the version showed to IPs). Cenarium (Talk) 05:56, 20 December 2008 (UTC)[reply]
No, revisions should not be sighted randomly. In the German Wikipedia, articles are not sighted at all until someone flags them for the first time (after an extra-thorough review). By this method, 775,000 articles have been flagged. That's how we should tackle BLP flagging. I strongly oppose any expiration for flagged revisions. On the German Wikipedia, 98%+ of flagged articles are up-to-date. Cool Hand Luke 06:50, 20 December 2008 (UTC)[reply]
Revisions will be sighted randomly. Articles are seen by a user randomly, either through recent changes, viewing of an article, etc, and then the user decides to flag a revision of not. This is completely random, with a tendency for most viewed and most edited pages. You'd have to create a process to organize the flagging of blps and it won't be up and working in the beginning, and the random factor will still be there. Of course an article is not sighted until someone does (or automatically from the beginning if the creator is a reviewer), this is always true, it's the way flaggedrevs work, not only on de. Your numbers are not meaningful at all, we can't compare the situation with de, due to our size, our ratio regulars/all editors that is much weaker, etc. Have you considered the opposition to flagged revisions above ? Wouldn't you prefer flagged revs with expiration for non-blps rather than nothing ? You'll never get a consensus for flaggedrevs on all articles without an expiration for non-blps and for other content pages (templates, images, etc). Cenarium (Talk) 13:29, 20 December 2008 (UTC)[reply]
Absolutely not. Expiration is worse than the status quo because it has the ability to lock in edits that no one has ever examined. See also Davewild's comment below. We would cope with backlogs by not biting off more than we can chew, and the BLP articles are a good place to start. Cool Hand Luke 19:40, 20 December 2008 (UTC)[reply]
Not at all. It won't lock edits: the time between an edit and the next one won't increase. Cenarium (Talk) 12:19, 22 December 2008 (UTC)[reply]
I disagree with any automatic flagging of revisions. I think automatic flagging brings the worst of both the current situation and flagged revisions. Not only does the person who makes the edit have to wait for a period of time for his edit to be flagged but we do not have the benefit of flagging - the stopping of vandalism/libel from entering the flagged article. Imagine the situation where news organisations pick up on articles where vandalism/libel has been flagged automatically as good edits. If we cannot cope with the amount of edits to flagged articles then we should scale down the number of articles to be flagged, equally if we are coping well then we can scale up the number of articles flagged. I believe we will be able to cope with flagged revisions on BLPs but I see no benefit to introducing flagged revisions that are automatically flagged on other articles. Davewild (talk) 15:56, 20 December 2008 (UTC)[reply]
This is not a form of automatic flagging in the strict sense at all, and I would disagree with that too. Expiring is meant in the sense that it'll redirect IPs to the "draft" page instead of the "stable" page. Edits are not locked, the page can be edited and edits are added as normal, the delay between edits is not increased, revisions can still be flagged, IPs can access the stable page by one click. Think about all the vandalism that could be reverted before being viewed if edits were delayed by only one hour ... almost all of it. We could keep the delay quite short for all articles, a few hours at most, and allowing to augment it (up to indefinite) on the members of a specific category, and on specific pages as needed. Edits will still have to be flagged, but it will avoid the negative consequences of backlogs. Cenarium (Talk) 12:19, 22 December 2008 (UTC)[reply]


I'm not sure we should be giving special technical (e.g., restricting editing through the software) treatment to BLPs. While we can reduce edits to these pages (by implementing semi-protection) or monitor additions more carefully (and we really should be doing that better), I think removing unsourced statements that currently sit in BLPs for months or years is perhaps more important than anything else. So I'm spamming Wikipedia:Database reports/Biographies of living persons containing unsourced statements. That list contains 500 out of about 17,000 similar pages. --MZMcBride (talk) 16:54, 20 December 2008 (UTC)[reply]

Flagged revisions: who will flag? --Apoc2400 (talk) 22:59, 20 December 2008 (UTC)[reply]

I'd guess it would be hashed out after the decision to flag or not to flag is hashed out. Other projects have extra groups like we do with Rollbackers. I think this is the Wikinews one. I'd point out the German one but I can't read German. I'd guess it would be as easy as giving out Rollbacker here, for trusted users. rootology (C)(T) 23:05, 20 December 2008 (UTC)[reply]
I would like to know this before forming an opinion on flagged revisions. If there are not enough flaggers it would make Wikipedia stagnate. --Apoc2400 (talk) 00:08, 21 December 2008 (UTC)[reply]
This isn't a binding poll. Look at the top; it's meant to get some ideas for how to proceed. Instead, suggest in your replies how flagging should be distributed; indicate that you would find it unacceptable without those conditions. On German Wikipedia, everyone with 300 edits and several months experience automatically sights revisions with their edits, and the ability to sight edits can be granted by permission like rollback. I think those rules are reasonable. Cool Hand Luke 00:21, 21 December 2008 (UTC)[reply]
  • A three month exploration is a good idea. We should be able to assess if it works or if does not work, and undo the implementation if the latter. ≈ jossi ≈ (talk) 18:56, 20 December 2008 (UTC)[reply]

Some comments from Scott (Doc)

A few comments. Sorry, I come to this late, so most of these will have been made already. I'm not a fan of polling, since people tend to jump in dependent on prejudices and preconceptions. It might be better to create a list of pros and cons, that people might weigh up - then indeed some people might change there mind either way.

I am of the opinion that semi-protecting BLPs will have only limited utility. If you review my longer essay at User:Doc glasgow/The BLP problem, you will note that my opinion is that passing vandalism and IPs adding in defamations is not the real problem. Most of this crap gets quickly reverted, and of that which does not a high proportion is obvious crap that's embarrassing for wikipedia rather than damaging to the subject. The biggest problem we have is that of the motivated biased user with an axe to grind, inserting libels or bias that looks OK to an uninformed reviewer, and may even be apparently sourced. These people will log in and wait. I'd support semi-protection as it might help a bit with some of the lesser problems - but I'm not that enthusiastic about semi-protecting all BLPs.

Further, the BLP problem exists not so much on high profile articles, where there are sufficient informed eyes to recognised biased or hatchet-job edits and revert. Even a sophisticated libel, with apparently good sourcing, will be investigated on George Bush, Sarah Palin, Michael Jackson. The problem emerges with less obvious libels on low notability BLPs - because no one care enough or knows enough to spot them if they are not obvious vandalism. So, if we were going to semi-protect BLPs as a class, I'd suggest:

  • Any admin may permanently semi-protect any BLP where there have been BLP violations inserted that have remained uncorrected for over 48 hours, or where there been a justifiable complaint to OTRS. Such semi-protection must only be undone if there is a consensus on RfPP.

As for flagged revisions, I'm again unconvinced that this will solve the problem. Will the person flagging really check all the sources and discover the hatchet job that looks OK on first reading? However, I do think this is worth trying, simply because it might help, and it might be a better check on the patient POV pusher. Again, if we don't want to go the whole way, we could start with problematic BLPs.

  • Any admin may switch flagged revisions on for any article (not just BLPs!) where there have been harmful BLP violations that have not been immediately reverted, or where there been a justifiable complaint to OTRS. Such flagging should only be undone if there is a consensus to do so.

Anyway, that's my initial thoughts.--Scott Mac (Doc) 01:31, 21 December 2008 (UTC)[reply]

OK, would it be worth adding something to this essay as a first up? Cheers, Casliber (talk · contribs) 13:24, 21 December 2008 (UTC)[reply]

OK, how about carrots instead of sticks?

A contest like ---> ta-daaaa this one. Cheers, Casliber (talk · contribs) 13:32, 23 December 2008 (UTC)[reply]