Wikipedia:Protecting BLP articles feeler survey/Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages (Opt

Add links
From Wikipedia, the free encyclopedia

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Implement Flagged Revisions for blps and Flagged revisions with expiration for all non-blp articles / content pages (Opt#4)[edit]

Support (Opt#4)[edit]

Supports (Opt#4) 1–[edit]

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]

Note that I don't support this for all articles and all blps, only where it is most needed and not exactly the classic way Flaggedrevs works. I'd prefer a semi-automatic, non-obtrusive way for other articles. (more on this later, this poll is quite old, there are other places to discuss) Cenarium (Talk) 16:48, 24 January 2009 (UTC)[reply]
Having since developed other solutions, I won't to indicate my lack of support for this. This is an excessively harsh measure. Cenarium (talk) 18:08, 28 February 2009 (UTC)[reply]
  1. Best option, since the "backlog" issue becomes moot. rootology (C)(T) 14:11, 20 December 2008 (UTC)[reply]
  2. Agreed (rather like what I supported before). Obviates all concerns about manpower. Collect (talk) 14:25, 20 December 2008 (UTC)[reply]
  3. 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]
  4. 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]
    This would be useless with such configs. Better keep it short, a few hours at most, and make it longer or indefinite where needed. Cenarium (Talk) 14:42, 26 December 2008 (UTC)[reply]
  5. I support doing this and/or semi-protection. Bubba73 (talk), 21:55, 23 December 2008 (UTC) [reply]
  6. Support. Avoids backlog and still keeps BLP's safe. Padillah (talk) 20:39, 24 December 2008 (UTC)[reply]
  7. Wow, I think this is the best idea out there. --NickPenguin(contribs) 08:21, 26 December 2008 (UTC)[reply]
  8. Support per the reasons I mentioned in my other comments on this page[1][2][3][4]. —Snigbrook 14:15, 26 December 2008 (UTC)[reply]
  9. Neutral: Good idea but why not expire all flags at least until we see if non-expiring flags are needed? If you auto-expire all flags after an hour or a day, it will be pointless to vandalize high-traffic articles. If there's still a problem after a trial period, lengthen the expire time on BLPs or make it indefinite/no expire. davidwr/(talk)/(contribs)/(e-mail) 22:31, 26 December 2008 (UTC)[reply]
    Agree. It is clear that a progressive implementation is needed, so middle-term delays for blps, then longer or indefinite ones on a case by case basis, then per subcategories for example, could work well. Cenarium (Talk) 23:10, 26 December 2008 (UTC)[reply]
  10. Support Whilst Kotra makes good points, I do not see why this measure should not be supported. Extending flagged revisions is a logical step, however I think as it's new and some established editors may not like change or may be skeptical that it's wise to go this way and use expirations. Then when things are going well the expirations could be dropped completely or revised as needed depending on user experience. Nja247 (talk • contribs) 12:54, 29 December 2008 (UTC)[reply]
  11. Support, with an expiry time of 72 hours or so. -- Army1987 – Deeds, not words. 14:47, 29 December 2008 (UTC)[reply]
  12. Weak support I like the 72 hours, three days should catch just about everything. Timmccloud (talk) 17:17, 29 December 2008 (UTC)[reply]
  13. Support conditionally - I think both kinds of articles should have flag expiration dates (the 72 hour limit mentioned upstream sounded good to me). An expiration date has two benefits: (1) Encourages users to register - never a bad thing - since only then will they be fully functioning partners to Wikipedia. However, for them to know this (since they otherwised won't see their changes immediately) there should be a note on the edit page that pops up explaining this when IPs are making edits. (2) IPs do add a lot (we all started out as IPs), so they shouldn't be marginalized and the good information they add should be presented. I can easily see a scenario of a backlog of indefinite flags on raggedy versions of less popular articles that aren't even particulary suffering from vandalism but that could easily be assisted by drive-by editors. I do, however, feel that flagged versions for featured articles (which are already established to be as close to ideal as we can get it) can have much longer expiration dates (like a month).--Esprit15d • talk • contribs 12:45, 1 January 2009 (UTC)[reply]
  14. Potentially support. This seems like a good idea, if a test of flagged revs on BLPs is successful. GDonato (talk) 13:32, 1 January 2009 (UTC)[reply]
  15. Support with Reservations The flagging process seems to be the best method to maintain the "Anyone can edit..." philosophy while ensuring that accurate/worthwhile information is being viewed. My reservations stem from needing to see flagging implemented in a test on Wikipedia (which is planned), since one cannot comment about that one has not had real experience with, and I am concerned about potential backlog troubles from flagging (which is why I support the timed flagging option herein). hornoir (talk) 13:08, 4 January 2009 (UTC)[reply]
  16. Potential Support Requires testing to gauge effectiveness and appropriate default expiration times PLUS the added ability to change the expiration time depending on the article. Grika Ⓣ 15:43, 6 January 2009 (UTC)[reply]
  17. Support Trial first, etc. etc.--Tznkai (talk) 16:05, 8 January 2009 (UTC)[reply]
  18. Support I think this is the best idea but it should be tested first in smaller scale and evaluated.--Jimmy Bergmark (talk) 14:32, 10 January 2009 (UTC)[reply]
  19. Support By far my overall preferred option. -- Cimon Avaro; on a pogostick. (talk) 16:04, 15 January 2009 (UTC)[reply]
  20. Support My preferred option as well, for the reasons suggested principally by Cenarium. I especially prefer this because it eliminates the backlog problem. N2e (talk) 20:17, 22 January 2009 (UTC)[reply]
  21. Support with an expiry time of a week Iccaldwell (talk) 09:39, 30 January 2009 (UTC)[reply]
  22. 'Support best option so far. Donama (talk) 07:18, 2 February 2009 (UTC)[reply]

Oppose (Opt#4)[edit]

Opposes (Opt#4) 1–[edit]

  1. Oppose The German experience proofed that it will drive one in every five users away from the project, a killer tool. Mion (talk) 08:00, 11 January 2009 (UTC)[reply]
  2. Strong oppose. Causes way too much bureaucracy and additional job for administrators. Admiral Norton (talk) 15:32, 13 January 2009 (UTC)[reply]
  3. Oppose. I think that such an option for non-blps should be restricted to DYK articles, main page content, and other high traffic articles. Lithoderm 23:05, 4 January 2009 (UTC)[reply]
  4. Strongly Oppose; I suppose it could be better than the non-expiring alternative, but no. Ngorongoro (talk) 19:37, 1 January 2009 (UTC)[reply]
  5. Strong Oppose Better than non-expiring. However, when I edit, I like the change to be visible immediately. Good faith editors will also want new information they added to be visible - if they have to come back tomorrow to see, why will they edit?Corvus coronoides talk 21:51, 3 January 2009 (UTC)[reply]
  6. Oppose. I'm getting the feeling this would turn out to be a messy, uncontrollable, unworkable idea. ~AH1(TCU) 17:39, 1 January 2009 (UTC)[reply]
  7. Oppose flagged revisions for all BLPs per my rationale above. -kotra (talk) 22:42, 26 December 2008 (UTC)[reply]
  8. Oppose, if something is a good idea, and I think flagged revisions for BLPs is a good idea, limiting it to a short time just means nothing is settled and we postpone the decision to down the road. Tim Vickers (talk) 20:13, 24 December 2008 (UTC)[reply]
    Tim, I don't think this option means the BLP Flags will expire, just the Non-BLP flags. This helps eliminate the backlog that would be created by flagging everything and making certain people review every article revision. Padillah (talk) 20:39, 24 December 2008 (UTC)[reply]
    The technical implementation is not known yet, but note that the distinction with manual flagging will be very clear. Just to correct a previous comment I made, IPs will be initially directed to the so-called 'stable' page, displaying the latest expired revision (old enough and not identified as 'suspect' by the abuse filter), and will be given the possibility to view the latest rev (displayed at the so-called 'draft' page) and the latest flagged. If the latest expired rev is the latest rev, no stable/draft separation appears. I haven't proposed it for blps, them being sensitive 'per default'. Cenarium (Talk) 14:42, 26 December 2008 (UTC)[reply]
  9. Oppose All Hallow's Wraith (talk) 07:34, 21 January 2009 (UTC)[reply]
  10. Oppose flagged revisions - if you cannot edit Wikipedia, then what is the point?--Rumping (talk) 11:10, 21 January 2009 (UTC)[reply]
  11. Oppose What?? -RunningOnBrains 08:55, 23 January 2009 (UTC)[reply]
  12. Oppose Too much work, unmaintainable. -- lucasbfr talk 16:05, 23 January 2009 (UTC)[reply]
  13. Again, Lor no! Please, no second-class anons and no pissing off good anon editors. -Jéské Couriano (v^_^v) 21:16, 24 January 2009 (UTC)[reply]
  14. Oppose. However, if there was a sufficiently short revision period (a few hours), this would be significantly less bad than the other ideas for flagged revisions. It would still be bad, but less so. BecauseWhy? (talk) 03:27, 26 January 2009 (UTC)[reply]
  15. Strong oppose We need to save the freedom of Wikipedia 'n stuff. --Blah2 (talk) 12:06, 26 January 2009 (UTC)[reply]
  16. Strong Oppose - Too much workload, even with expirations. And it takes away the satisfaction of seeing an edit live after making it. Of course, I do support FR on BLPs, as they are especially sensitive. Stevie is the man! Talk • Work 17:18, 26 January 2009 (UTC)[reply]
  17. Strong Oppose Has anyone ever thought how many potential editors will be driven away from Wikipedia because of this Orwellian project? If it takes 3 weeks (German Wiki average) for a new user's edit to be confirmed by someone else (an overlooker with no face), then does anyone think that they will come back? Would you have come back to Wikipedia if that were the case when you started editing? 82.230.24.185 (talk) 21:47, 26 January 2009 (UTC)[reply]
  18. Oppose per my objections to the other Flagged Revision proposals above. -- noosphere 01:08, 27 January 2009 (UTC)[reply]
  19. Oppose - this option expires under its own steam, once the article has it's FR turned off after its expire by date, it will just become attacked again, I understand that there may be a need for this on some BLP, but it may prevent important discovery from being inserted into other pages --Chaosdruid (talk) 02:15, 27 January 2009 (UTC)[reply]
  20. Strong oppose. This undermines the entire purpose of a wiki. --IdiotSavant (talk) 01:27, 28 January 2009 (UTC)[reply]
  21. How about an "Already-sick-of=all-the-choices oppose?" Per similar objections above, and fear that ennui will make something low-profile like this pass while everyone is objecting to everything else. - brenneman 06:31, 28 January 2009 (UTC)[reply]
  22. Oppose Thehalfone (talk) 09:19, 28 January 2009 (UTC)[reply]
  23. Oppose for the reasons brenneman gave at 21 above. Certes (talk) 23:11, 29 January 2009 (UTC)[reply]
  24. Strong Oppose - This flies in the face of the concept of Wikipedia being an encyclopedia that anyone can edit. Flagged revisions are an abomination that flies in the face of the very principles of Wikipedia. Nutiketaiel (talk) 18:44, 30 January 2009 (UTC)[reply]
  25. Oppose as per (Nutiketaiel) RP459 (talk) 18:13, 31 January 2009 (UTC)[reply]
  26. Strong Oppose Killing flies with nuclear weapons? People will stop editing because of the backlogs and edit conflicts. Mervyn Emrys (talk) 18:32, 31 January 2009 (UTC)[reply]
  27. Oppose WP is the encyclopedia anyone can edit, and that means instant results. We can handle petty vandalism just fine. Crum375 (talk) 23:36, 31 January 2009 (UTC)[reply]
  28. Oppose - Too early to try this out; we need more information on the effectiveness of flagged revisions before doing this wide-scale. I'm not opposed to the idea, but this is not yet the time. Anaxial (talk) 11:28, 1 February 2009 (UTC)[reply]
  29. Oppose Would make it hard to attract editors when they can't see what they've done. Narayanese (talk) 17:35, 2 February 2009 (UTC)[reply]
  30. Oppose Premature. Lets try out on a small subset of articles first and see how the system works. Doing this now would be hasty. AndrewRT(Talk) 00:56, 4 February 2009 (UTC)[reply]
  31. Oppose for the same reasons I articulated in my oppose vote on enabling FR on all content pages. -BloodDoll (talk) 06:24, 4 February 2009 (UTC)[reply]
  32. Oppose as it's just an unworkable solution, too open to abuse/misinterpretation. JonStrines (talk) 15:56, 4 February 2009 (UTC)[reply]
  33. Oppose Unworkable. Orderinchaos 00:46, 6 February 2009 (UTC)[reply]
  34. Oppose there is no evidence that expiration is needed. I can't see why we won't be able to keep up with reviews, we manage RC patrol pretty well... If we do get massive backlogs, then we can reconsider. --Tango (talk) 15:05, 6 February 2009 (UTC)[reply]
  35. Oppose The problem outside BLP is fundamentally different from the problem in BLP. Flagged revesions outside BLP, even with an expiry time of 10 minutes would damage WP. Dc76\talk 17:40, 6 February 2009 (UTC)[reply]
  36. Oppose Enough issues with BLP, and there are similar issues with non-BLP, no need for any additional special treatment, there, etc. Is there a way to sign oppose to all of these at one time without repeating oneself? ηoian ‡orever ηew ‡rontiers 06:12, 18 February 2009 (UTC)[reply]

Not yet (Opt#4)[edit]

Not yet (Opt#4) 1–100[edit]

  1. Not yet. We need small scale trials of flagged revisions before using them on such a large scale. —AlanBarrett (talk) 15:11, 3 February 2009 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Protecting_BLP_articles_feeler_survey/Implement_Flagged_Revisions_for_blps_and_Flagged_revisions_with_expiration_for_all_non-blp_articles_/_content_pages_(Opt&oldid=1086347058"