User talk:Jimbo Wales/poll

Context: Wikipedia:Flagged revisions (general information page), Poll for all articles, Poll for BLPs, Poll for some trial, Wikipedia:Flagged protection and patrolled revisions (implementation accepted for trial - poll, awaiting implementation)

I'd like us to conduct a poll from now until Saturday, regarding whether we should ask the Foundation to simply turn on flagged revs in the form that the Germans use it, until such time as they finish the version we've reached consensus on here, but which is constantly delayed.

Please just leave it here rather than turning it into a formal RfC or request — this is just a poll to gauge how we feel about it.--Jimbo Wales (talk) 11:24, 2 March 2010 (UTC)

Note: Poll is closed now. I'll be sifting through the results this weekend and doing a new poll next week to refine my and our understanding of where we all stand on this.--Jimbo Wales (talk) 05:39, 6 March 2010 (UTC)

Discussions

• Comment I'm not sure of the details of the proposal. Can we have a link to a summary of the German form proposed, so that we can understand what we're voting for, please. Colonel Warden (talk) 13:00, 2 March 2010 (UTC)

It means that Wikipedia will be (almost) fully protected — only admins and a certain (as yet uncreated) set of other approved users will be able to edit it.--Kotniski (talk) 13:01, 2 March 2010 (UTC)

That is incorrect. Flagged Revs doesn't restrict editing, it however prevents non-reviewed versions of an article from being displayed to normal users by default. They can still access the non-reviewed version by clicking on an icon however. MLauba (talk) 13:05, 2 March 2010 (UTC)

So effectively, it does restrict editing. (You can edit, but your edit won't show up — so "editing" for excluded users is effectively just the same as making an {{editprotected}} request on a fully protected page.) --Kotniski (talk) 13:09, 2 March 2010 (UTC)

It means that a select few veteran editors, many editors who consistently and successfully violate policy without sanction, decide what should and should be on Wikipedia. This will cause more frustration, new editor loss, and fierce arguments because these veteran editors will have more control over content than newer editors. Okip 13:10, 2 March 2010 (UTC)

I got reviewing rights on the German Wikipedia a long time ago, and I still have only 636 edits there. It's a lot less exclusive than adminship. Hans Adler 14:04, 2 March 2010 (UTC)

You have made 12618 edits to the English Wikipedia. As you are German, please explain this discrepancy. Does the German environment have a discouraging effect upon you? Colonel Warden (talk) 14:21, 2 March 2010 (UTC)

I don't consider this question very appropriate, but here is a complete answer: The English Wikipedia is my home wiki. I joined in November 2007, a few weeks after I moved to England and got broadband at home for the first time in my life. My original intent was to work almost exclusively on mathematics articles, on a level of specialisation at which only English articles have a sufficiently wide readership to be worth bothering with. Instead, I got sucked into this multi-player game. While I created my German account a few days after the English one to protect my user name (this was before global accounts), initially my activity on de was extremely limited [4] and wasn't very different from my general interwiki activity in other languages I can read (fr, es, it).

The German environment did have a discouraging effect on me, but the problem was most emphatically not the flagged revisions. Initially they didn't even exist yet, and once they were introduced I felt they were more of an incentive to be more active. The problem was a handful of grumpy German users who go ballistic when another German mentions the English Wikipedia. I only became a bit more active there when I happened upon a German topic here [5] and decided to develop it in German first, hoping for better input. This was very successful, with a German student scanning several important rare sources for me in a library. As a result of those activities I quickly had the 200 article space edits necessary for getting sighting + rollback rights on de. (My account was 20 months old at the time, way over the required 2 months.) Since then I have become a bit more active there, in part because I started occasional work on sighting requests (there is a page where you can ask for a sighting if you feel it takes too long), which increased my watchlist. Hans Adler 07:06, 3 March 2010 (UTC)

This link seems to be the relevant one: Wikipedia:Flagged revisions/Sighted versions. This describes different national flavours: German, Polish and Russian. There's some confusion about terminology — is flagged exactly the same as sighted? The German version has the latter, if it matters. Anyway, the Polish version sounds the most sensible, if we were to rush this in a half-baked way, as it is implemented gradually rather than with a big bang. A sweeping change for all articles does not seem sensible when the details remain to be thrashed out. Colonel Warden (talk) 14:15, 2 March 2010 (UTC)

• Comment I was originally going to cast my vote as "tepid support- I trust Mr. Wales' intentions and judgment". But I was agitated by a comment below, made by an editor whom I have met personally and respect deeply: "The proof that this is a bad idea, is that people are voting for it without knowing the details. " So I spent the last half hour trying to read all our documentation, and I have to say it's just not laid out clearly. Now, I think that a lot of the opposition to this proposal seems to be grounded in distrust, and that this distrust is fed in part by confusion. So I hope that this proposal's supporters will try to clarify the documentation. Especially, I would like WP:Flagged revisions divided into two pages, one for the extension (i.e., what do all configurations of this extension have in common?), another aggregating the specific configurations; the former page should be extremely brief, and should defer discussions of specific configurations to other pages. Andrew Gradman ^talk/_WP:Hornbook 04:27, 3 March 2010 (UTC)
  • • Well, I support the proposal based on my experience with the system on the German Wikipedia. The system is explained in German at de:WP:Gesichtete Versionen. Unfortunately I don't have the time to translate this. By the way, I think it is allowed to wonder what the fact that people who don't know the details are voting against the system, especially when they know it has been successfully used on the second largest Wikipedia since 2008. Hans Adler 07:33, 3 March 2010 (UTC)
      • The answer to your wondering is simple: pig in a poke / Katze im Sack. In addition, in previous discussion the idea was rejected in favour of something much more limited. Rd232 ^talk 07:53, 3 March 2010 (UTC)

(undent) Hopefully once the software is complete wikiprojects will be able to vote to either be included or excluded?Doc James (talk · contribs · email) 12:20, 3 March 2010 (UTC)

No. This proposal includes all articles equally. If you think that your project needs less protection or conversely that BLPs need extra protection, then be aware that this petition applies equally to the whole of Wikipedia. ϢereSpielChequers 13:13, 3 March 2010 (UTC)

• Question. I'm sure this is answered somewhere in one of the myriad of pages about flagged revisions, but what exactly are reviewers to be looking for when they decide whether or not to approve a page? Are they just looking to make sure it's free of obvious vandelism? Do they check for unsourced material? Do they check the quality of sources, and make sure that they say what is asserted in the article? What about copyright issues? I guess what I'm asking is, how OK must an article be to be approved (or whatever the correct term is) for general viewing? Buddy431 (talk) 16:24, 3 March 2010 (UTC)
  • Whilst we're on the subject, was the issue of the legal liability of reviewers ever settled? WMF says it's not responsible for content, it's down to the editors. What about reviewers letting through libel? Rd232 ^talk 18:06, 3 March 2010 (UTC)
  • I don't know about the libel aspect, but we have to be practical here. If we adopt this for all 3.1 million articles without first creating, and recruiting for a new class of "reviewers" who can be trusted to check that information is reliably sourced; and we also replace wp:verifiable with wp:verified, then you can be pretty sure that however this starts, after a week or two all Rollbackers will all be made reviewers and the only thing we will be screening for is blatant vandalism. If however we don't go down the German route but we go for a more nuanced system that targets high risk articles such as ones that are currently semi-protected and others that are contentious or vandalism targets, then we could check that which is checkable. However if we continue to allow people to add unsourced uncontentious material, but not allow such material to be marked as patrolled without the patroller sourcing it, then I fear we could only run this on a small minority of articles. ϢereSpielChequers 18:39, 3 March 2010 (UTC)
    • Commenting on "Whilst we're on the subject, was the issue of the legal liability of reviewers ever settled? WMF says it's not responsible for content, it's down to the editors. What about reviewers letting through libel?" above. WMF may well state that they're not responsible for content as a general stated principle, however that doesn't mean that some court or other is going to agree with them on that. Combine that with some of the astronomical sums awarded for stress etc. , it's basicaly just gambling that a court might agree with that position, very high stakes gambling.Amentet (talk) 19:35, 3 March 2010 (UTC)
      • See Section_230_of_the_Communications_Decency_Act. --JN466 21:15, 3 March 2010 (UTC)
• Who gets to review edits and who gets to appoint reviewers? We currently have just over 1700 admins, though barely half are active. We also have 1200 wp:Autoreviewers and nearly 3,300 Rollbackers and as these are newer systems I suspect that most of these are active. I'm assuming that admins would appoint reviewers and all admins, Autoreviewers and possibly Rollbackers would be reviewers from the start. If we do adopt this in the rushed manner requested by this petition then I think we have to make all three groups reviewers and accept that this is only for screening out blatant vandalism, and that if a vandal alters one part of an article just before a reviewer improves another part of it, that vandalism is liable to stick. If we go for a more targeted measured approach such as introducing this for BLPs only then we could adopt the rule of only marking an edit reviewed if you've verified the source, in which case we might not want all rollbackers to be reviewers. In any event can I suggest that everyone who supports this and wants to make it work, or like me is opposed because it probably won't work, please try to make it a bit less of a trainwreck by persuading some longstanding, civil, clueful editors to run for admin; and if they are good contributors who create lots of legitimate new articles but maybe lack the clean block log, arcane policy knowledge and rampant wp:editcountitis some now expect of admins, please nominate them at Wikipedia:Requests for permissions/Autoreviewer. ϢereSpielChequers 21:06, 3 March 2010 (UTC)
  • Re: if a vandal alters one part of an article just before a reviewer improves another part of it, that vandalism is liable to stick: In the German system, you always get a diff showing you the last sighted version and all changes made since then. It is that diff that you "sight". --JN466 21:15, 3 March 2010 (UTC)
    • OK so far so good. But what happens if an editor with reviewer status fixes a typo on an article that has unsighted changes? Does the system default to assuming they have reviewed all edits since the last sighted edit, or does it require their edit along with all other edits be sighted? ϢereSpielChequers 21:32, 3 March 2010 (UTC)
      • When you edit an article with unsighted changes, you get a diff display with the unsighted changes above your edit window. After you click Save, your new edit is not marked sighted; instead you get another diff display showing your change as well as any previous changes, and you have to explicitly okay all changes since the last sighted version (including your own). It's up to you whether you click on the button to mark all changes sighted, or leave it to someone else (e.g. if you're not sure about the previous edit). --JN466 21:49, 3 March 2010 (UTC)
        • Thanks for that explanation, I've struck that part of my comment as you have answered my concern. ϢereSpielChequers 22:28, 3 March 2010 (UTC)
    • And what happens if an established editor without reviewer status tries to fix a typo on an article that has unsighted changes? Certes (talk) 23:58, 3 March 2010 (UTC)
      • If we use autopromotion criteria such as the ones discussed elsewhere on this page (2 months+200 edits), there will be extremely few established users who won't have reviewer status. Mr.Z-man 01:43, 4 March 2010 (UTC)
        • And it would ruin most of the BLP benefits of the implementation, as most users with a 200 edits/2 months experience will be able to detect obvious vandalism, but not BLP violations. That's essentially why autopromotion had been rejected in prior polls (Wikipedia talk:Reviewers) - in favour of a rollback-like process, and using database reports to detect potential candidates. Cenarium (talk) 14:29, 5 March 2010 (UTC)
  • Sighting rights in the German WP are handed out very liberally: 2 months of being a registered user and a couple of hundred bona-fide edits is all you need. If we are talking about introducing the German system, this is what it is. It is mainly directed at IP and new user/sock vandalism. --JN466 21:20, 3 March 2010 (UTC)
    • OK I will assume from that that this is simply about screening out blatant vandalism. If we wanted to use this to require the use of reliable sources for BLP info we would have to be a bit pickier as to who our reviewers were. ϢereSpielChequers 21:32, 3 March 2010 (UTC)
      • That's exactly right, and it's what the German page explicitly states:
        • "Eine gesichtete Version ist eine speziell gekennzeichnete Version eines Artikels, eines Bildes oder einer Vorlage. Sie sagt aus, dass ein regelmäßiger Autor der Wikipedia den Artikel durchgesehen hat und die Version frei von offensichtlichem Vandalismus ist."
        • "A sighted version is a specially flagged version of an article, image or template. It indicates that a regular Wikipedia editor has looked at the article and that the version in question does not contain any obvious vandalism."
      • It continues,
        • "Das Recht, Versionen auf diese Weise zu kennzeichnen, ist sehr einfach zu erhalten (siehe #Sichterstatus) und die Kennzeichnung erfolgt ohne großen Aufwand (siehe #Markierung einer Artikelversion als „gesichtet“)."
        • "The right to flag versions in this way is very easy to obtain (see #Sighter status) and the process of flagging is very simple (see #Marking an article version "sighted")" --JN466 22:07, 3 March 2010 (UTC)
          • Re Section_230_of_the_Communications_Decency_Act that JN linked. The article does seems to suggest that it's been open to interpretation. It might be possible that the wrong judge might stretch out the process even with that act. Also if Wikipedia as an international site is open to UK Libel law then there is no such act in place, possibly ("The laws of libel and defamation will treat a disseminator of information as having "published" material posted by a user and the onus will then be on a defendant to prove that it did not know the publication was defamatory and was not negligent in failing to know: Goldsmith v Sperrings Ltd (1977) 2 All ER 566; Vizetelly v Mudie's Select Library Ltd (1900) 2 QB 170; Emmens v Pottle & Ors (1885) 16 QBD 354;") could be interpreted by the wrong judge in context of this issue under discussion, ie. failing to implement a safeguard against libellous statements against living people even though there was one available to be implemented.

I have no idea if Wikipedia could be sued in any country other than the US though.Amentet (talk) 02:07, 4 March 2010 (UTC)

• People can just semiprotect whatever article whenever the vandalism gets annoying. From my experience of checking RC on schools cats, about 80% of edits are vandalism or reverts thereof, more than BLPs. In any case, those vandalisms that stay a day or more, I just lock them, it's easy. Whether this passes or fails, slocking everything or doing whatever hardly causes a problem, but trying to legislate does. In the end people shouldn't worry about it too much and just sprot what is. Nowadays every article that Nangparbat (talk · contribs) touches in sprotected, and there are tons of them YellowMonkey (vote in the Southern Stars and White Ferns supermodel photo poll) 02:22, 4 March 2010 (UTC)
• Question: People say this is for obvious vandalism only - does that mean reviewers will be immune from all other claims of against-policy-behavior? Or will reviewers be prone to getting WP:OR, WP:SYNTH, WP:NPOV, and WP:RS-warnings from people who disagree with the "OK-ing"? (This is similar to the above concerns about "liability," but not with regards to a real-world-courts, but rather internally) Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 02:52, 4 March 2010 (UTC)

• Amy reason why the !votes can't be refactored and trhe bulleting turned into numbering so that we have an idea of the numbers on each side? I lost count when both were in the 30s.--Peter cohen (talk) 10:06, 4 March 2010 (UTC)
  • Since it's not clear what people are !voting on it's entirely appropriate to not be clear how many !votes there are. (OK in technical terms it's clear - turn FR German-style on. But policy-wise, no: eg which articles covered, reviewing policy, reviewer selection, failure criteria for turning the thing off as a disaster, criteria for keeping this "stopgap" rather than moving to the long-delayed agreed system which will probably never materialise if this "stopgap" is implemented...)Rd232 ^talk 11:36, 4 March 2010 (UTC)

• The talk about Flagged Revisions, et. al., has obviously been going on for quite some time. Maybe, as a newbie to the whole discussion, I might offer a suggestion. I'm fairly sure that this probably doesn't belongs here so, if someone could tell me where it should be placed, I will transfer it there. It is certainly possible that something similar has been proposed and rejected before; in which case, you can tell me to shut up.

It seems to me that all the talk about "flagged revisions" has gotten too complex. This is a simplified proposal, intended as a stop-gap while you work out the full implementation, however long it takes.

Any time a non-autoconfirmed editor makes a change, it is immediately displayed but with a line (I picture this as a single yellow line with black text at the top of the page) saying:

This version has not been reviewed. To see the latest reviewed version, press here.

If the user does, the yellow banner will display:

This is the latest reviewed version. To see the current, unreviewed version, press here.

At the same time, for both displays, an autoconfirmed user will also see:

You can help by reviewing this article. Press here.

Remember, all of this is displayed on one line, perhaps 15 pixels high.

If the autoconfirmed user clicks-on the second here, he will be presented with a diff between the current, unreviewed version and the latest reviewed version followed by:

Press here if you think that the edits above are acceptable to the general public.

If he does then the current version becomes the latest reviewed version and the banner disappears.

And that's all. No need for a special class of reviewers. No need for any extra, administator-maintained user switches. And it may just be good enough.

There are some details about how to show the reviewer's OK in History and to allow an autoconfirmed editor making changes to either accept the article as reviewed or simply accept his edits without changing the the article's reviewed status.

This is the default for unregistered users but these choices should be maleable in the user preferences. This includes whether or not to see the "This version has not been / This is the latest" banners at all and whether to first view the current version or the latest reviewed version. --RoyGoldsmith (talk) 14:22, 4 March 2010 (UTC)

• Here's an idea. How about we virtually fork Wikipedia? Create a separate extension, say, "flagged-en.wiki.x.io" where you can turn flagged revisions on, running from the same database, but which always displays the last "sighted" version, and you can leave the old en-wiki as it is, and have your trial and your freedom to edit too. We can see if there's any significant divergence b/w the two variants in terms of quality, reputation for reliability, etc., after a period of 6 months or so. Ray^Talk 15:26, 4 March 2010 (UTC)

• With it detailed, I like it even less. Of course we wouldn't need a new permission, because RCP and Rollback exist. For extra-troublesome articles, we have semi-protection. This process encourages any autoconfirmed user to determine what an "okay" edit is? We have enough problems keeping edits acceptable on controversial articles or BLPs and we want to let anyone okay things? We're encouraging people that have no idea what a diff is to okay possibly questionable edits. No. How on earth does that improve article quality? Sounds oddly like the story in the US media about a child being allowed to take control of air traffic control directions. How can we take a specialized all-volunteer ((WP:RCP)) army and claiming it's "better" by handing every citizen a gun? Beans, please! Good grief. I honestly hope I'm wrong, so if there's an actual advantage to improving BLPs in particular and would stop the edit warring that ruins many, I'm all ears. ♪ daTheisen(talk) 16:29, 4 March 2010 (UTC)
  • "We're encouraging people that have no idea what a diff is to okay possibly questionable edits." How about this on the prompt line:

If you are comfortable viewing the edits presented above, press here

if you think that the edits above are acceptable to the general public.

And yes, it does improve quality. If the auto-user is correct, then quality is improved. If the auto-user is wrong, then we are no worse off than the situation now. --RoyGoldsmith (talk) 21:03, 4 March 2010 (UTC)

A panic reaction after management neglect

I am not usually a critic of Wikipedia's management, but this proposal simply does not add up. It is an irresponsible panic reaction to a situation caused largely by management neglect. I don't know whether this has so far been a board-level issue, but if it is not, then the board should now be asking some hard questions.

This reminds me of the routine political equivalent: long-term neglect leads to a crisis, with the negative new headlines piling up. The only way to restore the illusion of political leadership is to propose bold and decisive action, so that the "leader" can be seen to be doing something. The actual quality of the proposed solution doesn't matters: what the politician needs is a simple announcement to say "I'm a decisive leader and I've fixed it", but if the fix falls apart somewhere down the road, it will usually do so with less fanfare. In the UK the classic example of this is the Dangerous Dogs Act 1991, a law which in most key respects was next-to useless, after being rushed through in a panic.

Why does this look like panic? Because the situation was entirely foreseeable. The trigger for this is the "breaching experiment", but the "breaching experiment" is just the sort of thing which should take place regularly to check BLP scrutiny systems; the only real surprise about this one is the fact that anyone was surprised by its occurrence or by its outcome. If the foundation management was not routinely ensuring that this sort of test was conducted, it was asleep on the job.

Why allege neglect? Because a trial of flagged revisions was agreed by the community 11 months ago. If flagged revisions are seen as an essential component of BLP protection, and BLP protection is seen as a high priority of the foundation, then why on earth was the coding not made a top priority? This is a stunning degree of neglect, and the community needs an explanation. (I hope that the board is already demanding one).

However, after 11 months the coding is incomplete, so we are being asked to accept a rushed implementation of a system which the community feels is flawed, without even a time limit on the so-called "trial". Sorry Jimbo, but "no". A management failure to ensure that the agreed trial can happen should not trigger a panic adoption of something which the community has rejected.

(Note that I am assuming good faith here. In politics, a crisis such as this is often used in a cynically opportunistic way to drive through measures which those in power know would otherwise be rejected. I want to continue to believe that Jimbo has better values than that, and that this is just panic after neglect, per the old maxim of never attributing to conspiracy something explicable as a cockup).

Focus on the point of greatest vulnerability. I accept that since the extent of the security hole has now been revealed, something needs to be done to plug it in the short-term. I believe that quick fixes should be as minimal as possible, so let's focus on whether the security breach occurred: at WP:DYK. Without DYK, the breaching experiment would have been an obscure issue; it was DYK which place the hoax in a prominent place. I have been saddened by the criticism hurled at the hard-working editors who run DYK: they are being blamed for failings outside their control (such as untruths being inserted after the article was reviewed), and being criticised for the consequences of a generally lax approach to BLPs. Yes, they missed a trick; but they did so within a flawed system, and I hate seeing individuals castigated for systemic failings.

Temporary fix. Rather than rushing a major change to the whole of wikipedia, let's focus on ways of ensuring that DYK is not abused in this fashion until a wider fix is in place. I can see several temporary fixes which could help: e.g. fully-protecting DYK articles while they are on the front page; banning BLPs from the front page; lengthening the DYK process to allow the hook-checkers to pass their shortlist of articles on to a separate ref-checker team; requiring on-line RS refs for any BLP-related material. Steps such as those, whether singly or in combination, would provide a short-term fix to the weakest point, without rushing into making a big change to the rest of Wikipedia. --BrownHairedGirl (talk) • (contribs) 19:26, 4 March 2010 (UTC)

1. Endorse. Rd232 ^talk 19:51, 4 March 2010 (UTC)
2. I dunno that we want to start a user-generated subpoll here, but for the record I too endorse these sentiments. The problem with DYK is a problem with DYK, and plenty of people already knew about the cultural problem there, because we had to go through a copyright sweep already. You fix DYK by fixing DYK, not by rushing through a do-something change in the whole wiki. — Gavia immer (talk) 01:02, 5 March 2010 (UTC)
3. My comment above was that if Jimbo is proposing this, he should also be resigning from the board as a recognition of failure. BHG puts a little more polish on the turd, so I endorse this statement. Franamax (talk) 01:39, 5 March 2010 (UTC)
4. Endorse. BHG has eloquently expressed my concerns not only about Flagged Revisions (which I could probably live with if it helped to keep out derogatory information about living people), but the entire BLP policy. (The simplest & best solution to the problem would be to have more eyes reviewing articles at all stages of their development/maintenance -- but it seems no one has seriously discussed that solution.) -- llywrch (talk) 21:53, 5 March 2010 (UTC)
5. Endorse. Another good example of panic was disabling anonymous page creation as a sop to the media during the Seigenthaler incident. IIRC, even Jimbo has admitted the disability has done nothing useful. --Gwern (contribs) 02:02 10 March 2010 (GMT)

Alternative explanation (feature creep)

The implementation used by the German Wikipedia would have been suitable for us. However, the fact that a lot of people rejected flagged revisions altogether made it necessary to find a compromise. This compromise consisted in complicated changes to the flagged revisions system, designed by committee. Design by committee is a well-known cause of feature creep in software, often resulting in delayed or buggy delivery or even complete failure of a project. Once a feature creepy specification has failed it makes sense to restart with a conservative implementation without the bloat. Hans Adler 19:35, 4 March 2010 (UTC)

Whether or not the German solution would have been suitable (the consensus was no), there is still a management failing here. If the committee-designed version could not be implemented at reasonable cost or in reasonable time, the foundation or its staff should have returned to the community to say so. Leaving things to drift and then panic-jumping into saying "let's use what you rejected" is not good management. --BrownHairedGirl (talk) • (contribs) 21:09, 4 March 2010 (UTC)

Both of these points sound reasonable. Has there been a discussion somewhere before about the way input of people with necessary technical expertise is fed into community discussions when solutions are proposed that require a technical implementation? If not, then there ought to be. TheGrappler (talk) 22:05, 4 March 2010 (UTC)

None of the proposed revisions were particularly complicated, especially not when compared to the system as a whole. The core of the requested new functionality (the ability to set flagging levels using the protection interface) was working almost a year ago in any case. --Gmaxwell (talk) 00:32, 5 March 2010 (UTC)

So what has happened in the last year to build on that care? Answers, please, Jimbo. --BrownHairedGirl (talk) • (contribs) 02:37, 5 March 2010 (UTC)

See the thread on foundation-l. I really can't make enough sense of the justification given to fairly represent it here. --Gmaxwell (talk) 02:46, 5 March 2010 (UTC)

Mostly adapting the extension to the en.wikipedia environment. The same problems would arise for an implementation of classic FlaggedRevs. That's why there's no guarantee whatsoever that implementing the classic FlaggedRevs would be any faster than implementing the FPPR version now, and it would considerably delay the FPPR implementation considering our lack of developers. Cenarium (talk) 14:20, 5 March 2010 (UTC)

I agree. The existing software has some flexibility through options and policy, and it would certainly serve our needs of flagging a smaller subset of articles. I think that much of the initial opposition confused the software with the policy on de.wp, which we need not adopt. Cool Hand Luke 04:37, 5 March 2010 (UTC)

(re Hans Adler) That's a very unfair and offensive thing to say. FPPR has been adopted as a result of a long and comprehensive consensus building process, in which all the questions raised in this poll had been thoroughly discussed, especially the seemingly incompatible needs in our context of using Flagged Revisions as a form of protection and of monitoring (some supporters in this poll want to use if for the later, some for the former, some for both, but most agree that using it for both would result in huge backlogs); this was in the end the only solution we could find and agree on. It is based on the simple and powerful principle of allowing us to use flagged revisions passively on all articles, and the ability for admins to make it 'active' on a per-article basis. Most of the specifics of the configuration itself are coded since mid 2009, the problem is in adapting FlaggedRevs to en.wikipedia. Cenarium (talk) 14:20, 5 March 2010 (UTC)

It doesn't make much sense to call what I said unfair and offensive when you then go on to say the same thing with different words. You are describing an amplification of the specified features as carried out by a committee.

However, your point that the problem is not the new features but the adaptation to EN is interesting. I'm a bit surprised, because if that's true I would think that the adaptation to DE should have had the same problem. Shouldn't it be easier now that it has been done already? Or do we have additional, incompatible features enabled that make the situation much more complicated than that of DE? Hans Adler 14:55, 5 March 2010 (UTC)

No, I do not believe it's characteristic of design by committee, it's design by consensus to some extent, maybe, but then again it's how we make decisions around here, and many users have worked hard to reach that consensus. The accepted proposal rely on a very simple principle which I expose above and resolved many issues which were previously a barrage to any implementation. That project isn't 'bloated by feature creep'. There may have been one unessential feature, the full flagged protection level, and there's been some discussion about precedence between patrolling and flagged protection reviewing levels, but it's at the implementation level and mostly up to developers.

From reading the mailing list thread, developers have difficulties in setting up a wiki which would reproduce the conditions of en.wp where they could test FlaggedRevs. It seems to be an essential point, you could ask them why, probably because of the higher readership, volume of editing, and all technical specifications of enwiki. Yes, I think we can say it's much more complex to implement any FlaggedRevs configuration on en.wp than on de.wp. In addition to this there's the recently created user experience/usability team who's gotten involved, they make a point of polishing up the implementation before the trial (and improve the extension itself, so their work should affect de.wp too). This all resulted in long delays (the FlaggedRevs specifics have been worked out for the most part a long time ago); and this would have happened too if we had asked for the de.wp implementation, and asking now to implement it would not only further delay the implementation of FPPR, but most certainly take several months before implementation. They'd have to put aside all the work done and restart it with a de.wp implementation, and they would still have to create and test in an environment similar to en.wp... Curiously, when the decision was taken on de.wikipedia to implement ? Cenarium (talk) 17:09, 5 March 2010 (UTC)

How does it work when editing?

Suppose you go to an article to report some well-known fact about someone in perfect innocence. But after the last approved version, someone has added something about his daughter being a lesbian. Now, you don't know if his daughter is notable, if she's really a lesbian, and whether Wikipedia editors' Kafkaesque policy interpretations allow or don't allow that to be mentioned even if it has been published. So if you make an edit to this "unsighted" (?) version, then will your uncontroversial fact ever make it into the article? Or have you wasted your time when someone goes back to a sighted version and adds only a few favorite changes to that forgetting all about yours? I'm worried that what we'll actually see are reviewers or worried editors doing a hatchet job on facts they don't know or care about, just to get what they do care about through the process. It seems like a triumph of the reversionists, and I'd prefer a dozen vandals to any one of these self-important people who run around and deliberately misinterpret policy to explain why your sourced edit can't be in the article, who try to set themselves as your boss and editor who you're supposed to play a guessing game with until your work is finally so reduced and abused that they'll deign to let it pass. Wnt (talk) 05:48, 5 March 2010 (UTC)

At the German Wikipedia, most of the time edits are sighted or reverted before someone else edits. This is because the more active articles are generally on more people's watchlists. When it does happen, an editor with sighting rights has all the normal options. The page history contains all edits, each annotated with "automatically sighted" (if made by a sighter and the previous version was already sighted), "sighted by X" (if made by a non-sighter) or not annotated (if not a sighted version). In the situation you describe – unless very special circumstances make it relevant the statement about the daughter is obviously inappropriate – I would pick out the problematic diff, undo it in the normal way and sight afterwards. Or remove the problematic statement manually from the latest version before sighting, whichever is easier.

The rare occasions when something like this happens and additionally you are not sure whether an intermediate edit was OK or not are quite annoying. I have seen this once or twice and simply left it for someone with an opinion to handle. This obviously results in slightly delayed sighting, but since it is so rare it doesn't affect the overall experience much. Hans Adler 06:15, 5 March 2010 (UTC)

Are BLPs really more dangerous than other articles?

I've seen this BLP frenzy all over Wikipedia, but is it justified? All the really big liability judgments I hear about (like the Food Lion case) are for defaming corporations, or in the case of Oprah Winfrey, for libeling beef. Where people really get into the big money is when they say something that negatively impacts stock price (oddly enough, they never seem to get any credit after the price recovers, nor does the company ever offer to pay them a billion dollars of imaginary money if their false statement drove the price up a bit, but I digress) Maybe Wikipedia focuses on these only as a matter of courtesy or reputation, but what kind of courtesy is it to say that great, your dad just died, now we can vandalize his article! Despite the many comments above, I think this policy is a tumor growing out of control and looking for a place to metastasize to. Wnt (talk) 06:00, 5 March 2010 (UTC)

Frankly, I am personally more worried about destroying someone's life (e.g. someone just switched jobs, new employer googles name during probation period and sacks based on negative misinformation) than about getting Wikimedia into a lawsuit. I guess Wikimedia is somewhat protected against corporations by the fact that such a lawsuit would be extremely bad publicity for them. Hans Adler 06:31, 5 March 2010 (UTC)

This isn't about avoiding legal liability; that's the Foundation's business. Rather, this is about avoiding harm to people because it's the morally right thing to do. BLPs are potentially more harmful because pages titled after a named individual will tend to top their google rankings, and the contents of these biographies will be taken seriously, especially in the case of lower-profile individuals who do not have a lot of other coverage. I believe that we have a moral imperative to avoid real-world harm. Cool Hand Luke 16:10, 5 March 2010 (UTC)

Read this [6] 96.24.231.191 (talk) 18:34, 6 March 2010 (UTC)

These are good points, though the second tends to contradict the first. But when people comment about the damage done to individuals because Wikipedia articles top the Google rankings: That is not our decision. It seems to me that if Google leads employers to the false allegation, knowing that they're favoring a page anyone can edit above pages that may be professional in nature, they are as culpable as anyone else involved. (I'm not saying that they should be legally culpable — an end to libel law, if accompanied by an increase in hoaxes and false rumors, would soon teach employers to stop making such invasive use of hearsay and be of benefit to all)

If we want to stop unsourced or poorly sourced or poorly maintained or newly created or poorly assessed BLPs from having such effects, then we could either work out a deal with Google to rank them lower on the search results, or else use robots.txt to ban their indexing altogether. We have an elaborate system of Wikiprojects and ratings - there must be a way for search engines to use that. Wnt (talk) 00:58, 7 March 2010 (UTC)

A perfect example is the Gilad Atzmon article where despite his filing an OTRS in spring 2009 and admins coming along and deleting all the questionable material, highly partisan editors keep coming back, defaming Atzmon in the talk page and in noticeboards in order to maintain "attack sections" in the article, using guilty-by-association techniques against anyone who tries to comply with BLP policy and wikihounding me when I bring issues to noticeboards using false accusations, poisoning the waters in my trying to get a neutral opinion. There's real partisan tag teaming going on now on a number of BLPs and articles about organizations and WP:ARBPIA has proved ineffective, for reasons you all may understand better than me. I don't know if flagging is the answer, but there is a problem in BLPs where there are a number of highly motivated detractors. CarolMooreDC (talk) 12:29, 10 May 2010 (UTC)

This won't do much anyways

So I checked out the German site while logged out and seriously wonder what this would solve (provided there is a problem). You go to an article that has a small icon in the top corner that sighted "sighted". Next to it, it gives you a button that says "view unsighted" (or something like that). You click and you see whatever potential vandalism or libel took place in full bloom. What gives? Anybody will still be able to read the line "he killed his 10 neighbors in cold blood" or whatever gibberish. The presumably "hidden" version is just one click away. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 19:13, 5 March 2010 (UTC)

Similarly, anybody can read past vandalism in an article's history. The vast majority of users do not, however—they go to the page linked by google. We should strive prevent actual harm to individuals, and not fret that we can't prevent 100% of the harm—preventing any of it is an improvement over the status quo. Cool Hand Luke 20:59, 5 March 2010 (UTC)

Yeah, well... maybe that's true. But reading diffs in a history takes longer to figure out how to do. I'm more trying to make the point that some harsher measures might be needed to actually solve the perceived problems... Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 21:16, 5 March 2010 (UTC)

It's another click, and not one they're likely to make. Ask your non-editor friends if they have ever clicked on the "history" or "discussion" of a Wikipedia article. Not many have, and the few who have do it rarely—even when there's a huge "dispute" template. At any rate, I believe that the "unsighted" message can be customized by editing mediawiki pages. If we want a less prominent note, we can make it. Cool Hand Luke 21:26, 5 March 2010 (UTC)

As I understand it, we can easily tweak the flagged revisions set-up so that our readers cannot view unsighted revisions. So if the configuration that the Germans are using is found to be problematic (although, per CHL, I maintain that it isn't), a developer could easily remedy our concerns. AGK 18:19, 7 March 2010 (UTC)

It seems like this assumes that a vandal will follow the rules. Nobody knows better than a vandal's sock puppet when to review the article and approve the changes. And the more Wikipedia struggles to make it look like no untrue edit can be added, the more damaging a libel will be when it is cleverly inserted. Wnt (talk) 19:28, 8 March 2010 (UTC)

In other words, given enough cunning & malice, any article on Wikipedia can be suborned to contain damaging material. (This is what I see the latest disruptive experiment involving DYK has shown us.) So how do Wikipedia's current practices stack up against all other information media? One of the overlooked discoveries of the Siegenthaler incident was that it is far easier to correct errors on Wikipedia about living people at that time than it was to get newspapers, magazines, or other news media to publish retractions or corrections. I would imagine that with all of the WP:BLP advocates doing the same would be even more easier now.) -- llywrch (talk) 21:57, 8 March 2010 (UTC)

This is precisely my point against flagged revisions. There seems to be a naive assumption that flagged revisions would "just work" to exclude all possible vandalism, and it would certainly exclude crapflood additions that look like "brssjflmpfg [[Media:Example:ogg]]" or similar - but if a vandal gets odious but plausible (or overlookable) vandalism into an article, the mechanisms that propose to keep bad things out will actually conspire to keep them in - if they're in a sighted version, only editors with the ability to sight new revisions can fix things, and they will tend to prefer the "reviewed" sighted version over casual attempts to fix it. — Gavia immer (talk) 22:17, 8 March 2010 (UTC)

I am wondering why some are considering that the time the German WP needs for flagging the articles is unacceptable but not to complain that vandalism like that isn't reverted for 32 days. --Matthiasb (talk) 20:51, 20 March 2010 (UTC)

aggregate statistics vs isolated examples? Rd232 ^talk 21:40, 20 March 2010 (UTC)

Yes. For readers it is better that new informations doesn't show up for a couple of days than having bullshit in an article visible for several hours. (However most articles are flagged within an hour; most of those articles which are not flagged for several days are watched by only one or two wikipedians, sometimes they're totally unwatched. --Matthiasb (talk) 09:32, 21 March 2010 (UTC)

How to get it done faster

In my long and painful experience managing software projects, it rarely helps to redirect a project when it is in it's final stages, as his one seems to be, especially when the people working on the project seem basically competent. What does help is to ask the staff if there is anything they could use that would aid progress. For example, the email thread said they were reconfiguring an old server to use as a test bed. Why not buy them a new server instead? Also, while it typically takes too much time for a new developer to get up to speed to be of much help in the late stages of a project, adding a couple of experienced testers, even on a temporary contract, can often be very helpful and save a lot of developer time. In the current labor market, such people should be easy to find. If this is so important, and I agree it is, the money should be made available and special fundraising might be appropriate. --agr (talk) 15:06, 10 March 2010 (UTC)

Money and resources aren't the problem, there's at least 3 people being paid to work on it already. The problem is simply mismanagement.

• The 2 people in charge of the improvements were not hired for months after we already made a decision on FR.
• They were not given any deadlines nor were they asked to create a schedule or timeline.
• It shouldn't take any extra work to turn on the German system here. If it does, it would mean that the foundation used, and continues to use, software that they consider substandard on the 2nd largest Wikipedia.

-- Mr.Z-man 00:05, 14 March 2010 (UTC)

It's my understanding that the proposal to turn on the German system was not adopted, so how much effort it might take is moot. The version that is being implemented for the English wikipedia involves significant changes and that is the current source of the delay. Critiquing earlier project management won't get the needed work completed any sooner. My suggestions might.--agr (talk) 20:48, 14 March 2010 (UTC)

Timing

This subject has been kicking around for a long time. It is unfortunate that the "poll" was open for less than a week and that many people (including me) did not become aware of it before it closed. Would it be better to adopt a well-publicized process that could take into account that editors do not use Wikipedia 24/7? Thanks. Racepacket (talk) 22:33, 10 March 2010 (UTC)

Yep, to my surprise I also just passed by an invitation to what seems to be a cherry-picked audience for a "quick poll". Reminds me of some wise words of what sausages and policies have in common, the more you know of their creation, the less you value them. This poll is arrogant and disrespectful to the volunteers that run this place. Power.corrupts (talk) 01:31, 11 March 2010 (UTC)

Please read this. --Yair rand (talk) 01:58, 11 March 2010 (UTC)

Cherry-picked audience? It was listed on two village pumps, the centralized discussion template, and the administrators' noticeboard. Short of putting it in the watchlist notice, it doesn't get much more widely advertised than that. Mr.Z-man 02:46, 11 March 2010 (UTC)

It was not listed in those places by way of any effort on Jimbo's part; he just announced it on his main talk page. If there hadn't been an effort by early commenters to get the poll listed in such locations, I (for one) would never have known of it. — Gavia immer (talk) 03:13, 11 March 2010 (UTC)

True, but I don't think its really fair to attribute that to bad faith on Jimbo's part. Mr.Z-man 03:27, 11 March 2010 (UTC)

Jimmy tends to just post things (like ArbCom appointments, for example) to his talk page and let the word spread from there. It usually works pretty well. --Tango (talk) 22:37, 11 March 2010 (UTC)

The whole idea of the polls closing is bad. This is a wiki. Anybody can interpret the current "opinion" of the poll at a given moment. But there's no need to prevent the addition of new votes and views. Jason Quinn (talk) 18:22, 12 March 2010 (UTC)

I know I wasn't cherry-picked, but I might have made an even more skeptical response with longer to think it over. I just had a look at Special:Newpages for the first time... O-My-God, we're backlogged almost a month with unpatrolled new articles, and some people think we'll be able to review every edit? Wnt (talk) 21:53, 12 March 2010 (UTC)

Please see my comments in the poll about how FlaggedRevs actually works. Even if we did adopt the German system, we would not have to review every edit. We would never have to review most of the edits by established users and bots, and it would be months, if not years, after deployment before we had to review edits to every article. Recentchanges patrol (which is a better comparison than newpages patrol) seems to have little trouble reviewing almost every edit already, and some features of FR would make the process even more efficient than now. Mr.Z-man 23:57, 13 March 2010 (UTC)