Jump to content

Wikipedia talk:Flagged revisions/Trial/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5

Closing time for this poll

The straw poll on implementation will be a week old in about five hours, and the rate-of-change of both !votes and discussion is inevitably declining. What is a suitable time to close the poll and present it to the developers for evaluation? This evening? After it is ten days old? Two weeks? Happy‑melon 12:06, 9 January 2009 (UTC)

Two weeks at least, ideally a month IMO for such a change. MBisanz talk 16:07, 9 January 2009 (UTC)
IMO practically any time now, except that at least 24 hours notice should be given. - Hordaland (talk) 17:36, 9 January 2009 (UTC)
No reason to close yet, people are still voting, Wikipedia will still exist after this is over. Give it at least another week. — neuro(talk) 18:00, 9 January 2009 (UTC)
I agree that we should not close at such a time as to prevent significant numbers of contributors from participating; however I think we approach the point of diminishing returns - leaving it on the watchlist for a month would not result in significantly more participation than leaving it for just a few more days. I concur that the close should be announced well in advance. Happy‑melon 22:05, 9 January 2009 (UTC)
The reason why I say a week is because we are not in a rush to get this implemented - we will still be here no matter how long we wait. There is no harm in waiting for a little bit of time, I'd say at least 5 days warning would be preferable. — neuro(talk) 22:51, 9 January 2009 (UTC)
Because this affects IP users in a huge way, can this please be placed in a place where IP users will see it? And can something be added to WP:Flagged revisions? It's hard to get here from there. I hope this isn't closed before IP users find out about it and have a chance to comment. 141.151.174.108 (talk) 21:50, 10 January 2009 (UTC)
Close it out it out at the end of January. Not everyone edits every day or even every week, and while I've been editing every day for the last week I only noticed the message about this on my watchlist a few hours ago (just didn't see it before that, others might see it and might not have time to click on it, or might click on it and not have enough time to read and understand what in the hell is going on here). There is absolutely no reason to close this early. Let people comment, ask questions, and discuss. The more people are aware of/invested in this process the better. If there's a way to let regular or semi-regular IP contributors know about this, then we should absolutely do so. --Bigtimepeace | talk | contribs 22:01, 12 January 2009 (UTC)
I for one would have missed voting in the poll had it been closed after a week or so. Even after two months off from editing, the only thing I've checked for updates is my recent contributions list - as you can only sit still for so long in a southern clime. I think for most of the Australian editors, the watchlist is simply too big to manage right now, and a month's grace period should mean that everyone sees this page. Ottre 03:41, 14 January 2009 (UTC)

participation

No matter which side you're on, it sure is nice to see 450+ people chiming in. Both sides are making very compelling arguments. I'm glad to see so many people care so much about this project. Cheers to all, Kingturtle (talk) 17:12, 9 January 2009 (UTC)

Indeed. Too bad so many people hold the wrong opinion. :) --ElKevbo (talk) 21:53, 9 January 2009 (UTC)
I don't want Wikipedia becoming a walled garden. That's why I oppose. doktorb wordsdeeds 10:02, 10 January 2009 (UTC)

Vandalism problem

If flagged revisions do become policy (to which I am strongly opposed), what happens when the vandals figure out that they can still vandalise pages by creating huge backlogs? E.G: Possibly submitting up to 100 revisions with nonsense like "Mr. Example is a load of poo" and/or "I have hairly legs, hehe" in them. Huggle can quickly revert normal vandalism, will it be able to quickly dismiss silly revisions that vandals submit? - Sorry if this has already been covered or if i've missed the point of flagged revisions completely! But this possibility is bothering me. John Sloan (view / chat) 17:23, 9 January 2009 (UTC)

It's no different than now is it? People still have to revert such nonsense now, and people can still be blocked just the same for vandalistic edits even under FR system. ♫ Melodia Chaconne ♫ (talk) 18:13, 9 January 2009 (UTC)
Doesn't seem pertinent to the poll in question. Sounds more like something to consider as part of a trial - else we'll never know. Fritzpoll (talk) 18:19, 9 January 2009 (UTC)
In fact it would be nice to be able to flag a revision "bad", which would eliminate the need to revert, and make the whole process quicker and lighter-weight than now. The idea would be that if you click "edit" by default you get the most recent non-bad revision. You could still start from a bad revision via the history list, just as yout can start from an old revision now. The ability to flag (or unflag) "bad" would be part of the same package as the ability to flag (effectively "good") in the present implementation. This would also reduce history overload on pages which currently go vandal - rvv - vandal - rvv etc, making it easier to follow the useful history of the page. (Off topic, I know, but people are reading this page...) PaddyLeahy (talk) 18:42, 9 January 2009 (UTC)
I think doing that WOULD give credence to all the oppose votes who think this goes against the "anyone can edit" edict. As it stands on WP now, you click edit, you edit the most recent version of the page, whether or not there's been a change. This is something that FR should not change one bit -- which is why all those oppose votes don't hold much candle IMO. ♫ Melodia Chaconne ♫ (talk) 20:25, 9 January 2009 (UTC)
Flagging an edit a bad is not a good idea, in that it will still need to be reverted from the draft eventually. The biggest problem we have today with vandalism, comes when there are multiple new edits and the newest ones are valid edits. It is too easy to assume that the vandalism was removed at the same time as the good edit was added. Dbiel (Talk) 20:55, 9 January 2009 (UTC)
The point of my suggestion is that with this change we don't have to revert, ever. You only need to edit the text if you have something constructive to add. Seems like a benefit to me, but each to his own! I also don't see why being flagged "bad" would be any more traumatic to new editors than having their edit reverted (with a dismissive edit summary), which is what usually happens now. PaddyLeahy (talk) 19:56, 10 January 2009 (UTC)
No, we still would have to revert, because the vandalism would still be present in the draft revision. Remember, when you edit the article, you always edit the most recent revision, regardless of whether it's been flagged. This situation would be no different than it is now; just revert the vandalism. Pyrospirit (talk · contribs) 23:38, 10 January 2009 (UTC)
Flagging bad means the "current draft" becomes the previous non-bad version. Functionally, my proposal is equivalent to a revert except that it doesn't create a new entry in the history list. For frequently-vandalised pages this would cut the history list almost in half and make the actual development of the page much easier to follow. PaddyLeahy (talk) 11:59, 11 January 2009 (UTC)
Your proposal, would, in that case mean the deletion of all the edits since the bad one. A terribly bad idea, and one which would discourage people from editing completely - why edit if its going to be deleted because of something an IP slipped in before you. It would also be liable to abuse.Nigel Ish (talk) 18:29, 11 January 2009 (UTC)
Good point, the rule should be "latest non-bad" version; I was assuming that only the latest draft is likely to be flagged. PaddyLeahy (talk) 18:50, 11 January 2009 (UTC)

toothpick or blanket

All the discussion ahs been around using flagged revisions as a blanket approach, in the section above Wikipedia_talk:Flagged_revisions/Trial#statistics_please in there the discussion said that only around 3-7% of edits would be within the target of this proposal. That means we are talking about applying it to 93-97% edits where its unnecessary, this makes a blanket approach very hard to justify, I think long term even if implemented many editors will become lazy and just review all edits as a matter of course.

So how do we use this as a tool like a toothpick, against the 3-7% of edits? What if flagged revision was available as an admin tool like semi-protection and full protection are. Could it be made into a user specific condition for arbcom/ANI remedies where an editor could be restricted to having their edits reviewed ie an enforced mentoring. Gnangarra 03:18, 10 January 2009 (UTC)

The main point of FlaggedRevs is to apply a minimal level of checking before our passive readers see the page, but in your model there's lots of visible disruption before any sanctions are taken, which defeats the point (why not just ban these users, as now?). I don't see a positive flag as "unnecessary": this check will significantly improve our reputation if we make it clear to the public what is going on. And flagging is mostly light work: edits by experienced users and bots would be automatically sighted, so reviewers only have to take positive action for edits by non-reviewers (IPs and newly-registered users). And of course we want to shut out a larger fraction of these than 3-7%. For instance from HappyMelon's statistics, 25770/238100 = 11% of IP edits were reverted manually, and then there would have been lots of bot reversions which he didn't count. And that was a low-vandalism period. PaddyLeahy (talk) 20:33, 10 January 2009 (UTC)
There is a toothpick proposal at WP:Flagged protection. Testing for that purpose, and with safebuards, would be acceptable to me; if we could avoid giving the impression that it was the camel's nose in the tent, it might be acceptable to a substantial supermajority. But the proposal is still, sensibly, under development. Septentrionalis PMAnderson 01:18, 11 January 2009 (UTC)
I actually support the use of flagged revisions as a blanket measure on all articles, as long as there's a technical provision to sight pages that haven't been edited in a certain time (e.g. 24 hours, but I could see this go as low as just an hour or two, it would still do good). I believe "anyone can edit with minimal effort" is what matters, not instant gratification; it's natural and acceptable for there to be some predictable amount of delay, no different from posting to a moderated mailing list. Dcoetzee 02:29, 11 January 2009 (UTC)

If hundreds comment or vote here

How come the number of people playing around here measures in the tens? I'm just sayin'. David in DC (talk) 18:17, 15 January 2009 (UTC)

Good question. But most people propbably just read the implementation description (i hope at least) and considered that info sufficient, also you can look at the other WPs already using flagged revisions to see what it looks like. also personally i found it annoying that testing seem to require (yet another) account.--Kmhkmh (talk) 04:17, 16 January 2009 (UTC)
I subscribe to your last sentence, Kmhkmh. That was also my impression when I took a look. - Hordaland (talk) 10:10, 16 January 2009 (UTC)
Thanks for the link David. In this implementation one can sight their own edit, which I thought we are not going to be allowed to do here? BTW Kmhkmh I was a bit annoyed by having to create another account, but then saw the link to unified accounts, so I unified my accounts, it was a piece of cake Special:MergeAccount. I had no idea this was possible before, so that's a real result!! Apparently if you unify your accounts yu automatically get an account in en.labs. Alun (talk) 13:29, 16 January 2009 (UTC)
If you have a global account, you can log in in most Wikimedia wikis. In the proposed implementation, an edit by a reviewer is automatically flagged if the latest revision is flagged, and any user with no recent vandalism or libel can become reviewer on request. Cenarium (Talk) 14:36, 16 January 2009 (UTC)
I tried, it does not work at all. All I could see is that sorry title page; where's the content to be watched? NVO (talk) 06:00, 17 January 2009 (UTC)

This test page is rather worthless from my point of view as it does not fuction anywhere near what we are talking about here. We say that an IP user will not see an unreviewed page. Yet the test page displays the unreviewed page when not logged in. It does include a not that the current version is unreviewed, but the link looks like this [[Help:Page validation|current revision]] - The link should be to the current revision on to a help page. It provides no information on what an IP user will see. And when logged in (after having set your permisions as a reviewer) the only option is to site the article. The test page is just a total waste of time. 207.78.65.254 (talk) 04:57, 17 January 2009 (UTC)

Separate page for votes

I just moved the votes to a separate page because this one is becoming monstrous and most discussions are still too alive to archive. Apologies if this screwed something up, but I don't have the fastest computer and this talk really hangs while loading. Estemi (talk) 17:21, 16 January 2009 (UTC)

I'm sure I've read somewhere summaries of the ongoing polls with # of people pro/cons. Can anyone please provide a link to such a report (also in my talk)? I've been searching for these infos for hours now. --Elitre (talk) 21:44, 16 January 2009 (UTC)
Link was half way up the page. I've added another one at the top.Ronhjones (talk) 22:10, 16 January 2009 (UTC)

Looks like it is being adopted

The godking has said he will be asking for flagged revisions to be switched on soon. [1]. DuncanHill (talk) 00:14, 17 January 2009 (UTC)

This is a total kick in the teeth to the community. 60% has never been enough support to delete an article, let alone throw away a foundation principle. Switching off anonymous article creation didn't work one iota; this won't either. Sceptre (talk) 18:18, 17 January 2009 (UTC)
You may wish to view the continued conversation in that same area then, which may be found here. It's starting to get a little heated but it may be worth keeping up with. Thor Malmjursson (talk) 18:28, 17 January 2009 (UTC)
(ec) I respect Jimbo in general, but I really wonder how a 60% support ratio can be considered strong support. We would never trust a user with admin tools below 75% or a crat below 85% but we should implement such a feature with 40% of the community opposing? If this were any other discussion, any admin would consider this a no-consensus close, but surely not a support one. But then he talks about it coming "without any question at all", it kind of sounds like he would have implemented it no matter how the poll would have ended. Just lucky for me that I already speak German, seeing that Jimbo apparently wants us to become de-wiki step-by-step. SoWhy 18:34, 17 January 2009 (UTC)
SoWhy - I have already stated to Jimbo that using de-wiki as a comparison for Flagged Revisions is pointless. The German Wikipedia is about 3 times smaller than English Wikipedia, and my main concern is that we're gonna have major issues with queueing for review. I have done new page patrol on de.wikipedia a couple of times, and your new page creation rate is much slower than en-wiki. We're gonna be swamped. Thor Malmjursson (talk) 18:43, 17 January 2009 (UTC)
It looks like he announced it on a radio programme, then in passing on his talk page. Maybe he's unaware of this talk page? DuncanHill (talk) 18:37, 17 January 2009 (UTC)
It's kind of hard to miss, it is our biggest poll in history... :D Happy‑melon 19:04, 17 January 2009 (UTC)
Looking at the top of Wikipedia talk:Flagged revisions, it appears that editors were not entirely free from pressure from him in this matter. DuncanHill (talk) 19:13, 17 January 2009 (UTC)
It certainly wouldn't have been appropriate on the staw poll page itself (note how Jimbo (support #7) didn't give any comments in the actual poll?) but note that A) that's been there for months, and B) the box wasn't posted by him - when he originally made the comment, it was rather more low-key. Anyway, this is rather tangential to your previous point, isn't it? Happy‑melon 10:06, 18 January 2009 (UTC)
Iceflow: Isn't this, actually, for good? The sooner this nonsense fails, the better. If this buttongame is inevitable, I'm for a full deployment as soon as possible - no test can imitate scale factors. NVO (talk) 19:48, 17 January 2009 (UTC)
No. It's not good, far from it. Screw FUD. This is a clear case of messing up our values and our world. If you want full deployment, fine, you are entitled to your view, but you're rapidly heading into a minority. Over 40% of users here now don't want this at all and its getting closer, last time I checked, just over 126 people between the support and oppose camps. Thor Malmjursson (talk) 20:29, 17 January 2009 (UTC)
Here's the thing -- the poll's numbers aren't exactly correct. Most of the 'votes' (from BOTH sides, but far more in the oppose) seem to be voting as if it 1) Weren't just a trial and 2) Is going to be on all articles. It seems to be the poll was handled quite badly, causing people to really not understand what it is they were voting on. ♫ Melodia Chaconne ♫ (talk) 20:14, 17 January 2009 (UTC)
The voting numbers are spot on according to people's views. The first step to implementation is testing. Sightly off topic, and just an example, look at the UK's membership of the European Union. It was only joined by the UK as a trial and for free trade which we could pull out of at any time. Now the whole of the UK is practically run from Brussels and we're on the verge of losing the last bit of our national identity, our currency. Flagged Revisions is gonna be a suck in. We'll start with the trial, the results "go" in WP's favour, and we wind up stuck with it. If we don't stop it now, we'll never stop it. Thor Malmjursson (talk) 20:36, 17 January 2009 (UTC)
I disagree with Melodia's statement - a lot of the "Support" votes explicitly mention that they're only supporting a trial, with some being along the lines of "well, it's just a trial". If it was a poll on actual full implementation, many of those might've voted against. All Hallow's Wraith (talk) 11:47, 18 January 2009 (UTC)
Nobody is going to enable FLR for all articles overnight. It has never been proposed. I personally think that this is unnecessary. However some articles like BLP may benefit from them. Ruslik (talk) 20:22, 17 January 2009 (UTC)
Yes, but my point is it seems many people answering the poll are thinking that's what it's about (more or less), based on their explanations. But that's just the way I see it. ♫ Melodia Chaconne ♫ (talk) 21:57, 17 January 2009 (UTC)
Maybe they just don't believe that it will stop at a trial? Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Studying law, I know some good examples: Wire-tapping for example has been introduced into German law with the promise that it will only be used in cases like murder. Nowadays it's being used for a score of crimes, even such crimes as forgery or bribery. Many who opposed this law with the slippery-slope-argument were ridiculed that they were opposing something that noone planned. Now we know they were correct, but the damage has been done. I think the same may as well apply in this case and people may want to prevent it. Apart, of course, that this feature, no matter how limited its use, does in fact remove "anyone can edit". SoWhy 22:32, 17 January 2009 (UTC)
I see that as a matter of opinion. If you want to hold "anyone can edit" to that level of purity, then the principle is already dead in the water. What are protection and semi-protection templates? What does blocking IPs and preventing anonymous page creation do? Flagged Revisions takes, on the other hand, only delays the appearance of contributions. Sure, you can argue that FLR will be abused to block valid contributions, therefore killing "anyone can edit", but it's not as if WP:AFD and reverts aren't abused in the same way. Estemi (talk) 22:44, 17 January 2009 (UTC)
Exactly. Especially if it's used in place of semi-protection/protection, it offers more editing ability, not less. Not to mention, blocking anyone in general means that "anyone can edit" isn't true if you want to get all technical. But this has all been said before, in a better heading devoted to such. ♫ Melodia Chaconne ♫ (talk) 23:16, 17 January 2009 (UTC)
Thor Malmjursson (who apparently lives in the UK; who'da guessed) gives above the example of the UK's trial membership in EU "which we could pull out of at any time." Similarly, SoWhy gives other "slippery-slope" examples, stating: Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Several of us have argued along these lines. Above, these arguments are not answered; the "answers" involve only anyone-can-edit purity, which is not the (main) point. Ignoring the slippery-slope concerns has practical consequences. We've already used many hundreds of man-hours reading, discussing and !voting. If/when the trials begin, even more man-hours will be required to define and evaluate them -- how many of them is unknown. I have opposed and I think this argument should be taken seriously. Thanks, - Hordaland (talk) 01:03, 18 January 2009 (UTC)
I strongly support this proposal--I think that we should at least try flaged revs in some limited fashion before rejecting them. But I think that this kind of disregard for the community's wishes is terrible. Because Jimbo has indicated that he will be moving forward, I think that the community now needs to open a dialogue not on weather flaged revs themselves are a good idea, but if enabling them despite clear lack of consensus is a good idea. I urge my colleagues to recognise that this action will split and damage the community, even if you think that flaged revisions ultimately could be a good thing. We need to speak up now if we are going to keep this from happening. Cheers, — Jake Wartenberg 03:56, 18 January 2009 (UTC)
Agreed, we need a poll on WP:Flagged protection, the proposal that Jimbo seems to support, before it goes forward.--Res2216firestar 04:03, 18 January 2009 (UTC)
I don't even want the extension switched on--that's what this proposal is about--without consensus, which we clearly don't have. And that needs to happen before we even think about doing trials. — Jake Wartenberg 04:10, 18 January 2009 (UTC)

(unindent) Please refer to this clarification by Jimbo: "I, too, do not support turning on FlaggedRevs in the configuration the Germans are using, as I consider it to be much too aggressive. I am also willing to be proven wrong, and who knows what we will find. My view is that it should be "as a protection type system"", then continuing that he would be in favor to use it instead of semi-protection and more liberally for blps. So the implementation he proposed to turn on would indeed be the proposed trial implementation, and I suppose he would support, among the proposed trials, to use it instead of semi-protection and on most problematic bps. Cenarium (Talk) 16:50, 18 January 2009 (UTC)

trial or not

Hi all

I, and I suspect others, was just wondering why the word "trial" does not appear in the proposal line ?

At the moment it reads "Should the proposed configuration of FlaggedRevisions be enabled on the English Wikipedia?"

I was under the impression that it was only a trial.

I expected to see "Should the proposed configuration of FlaggedRevisions be enabled for trial on the English Wikipedia?

can someone clarify as i have spent some time reading about it now and would like to vote !

thanks Chaosdruid (talk) 09:21, 18 January 2009 (UTC)

The "proposed configuration" is a trial. Estemi (talk) 09:41, 18 January 2009 (UTC)
I understood after reading many of the articles, comments and pages that it is supposed to be a trial, but i wonder if there aren't people out there who haven't yet voted simply because it appears that we are actually "straw polling" on having flagged revisions implemented, rather than a trial
I feel that it would be a wonderful thing if locked pages could be opened up by flagging, but that having "normal" and new pages flagged would slow down and possibly detract from the freedom we all enjoy at present. I did try the demo though, and admit that it is easy to use.
Still, my objection is only because if i vote "yes", i am still voting for flagged revisions to be enabled, and not to be put in trial - if this was a pollster approaching me in the street with "we will do this" and they said it was only for a trial i would vote no, if they said "we will do this for a trial period" i may well vote yes, as signing the first one means that they could say "well you voted for it to happen without us trying it out" .
I am not assuming that this is the case, but am pointing out that it could be and, to avoid confusion, simply sticking those words in would help sway at least one voter to yes rather than undecided
Chaosdruid (talk) 10:04, 18 January 2009 (UTC)
It says on the proposal page, on the first line in boldfaced and italicized letters no less, that this is a limited trial implementation. How much clearer can the point be made? Estemi (talk) 10:11, 18 January 2009 (UTC)
By putting it in the header line on the voting page Chaosdruid (talk) 12:09, 18 January 2009 (UTC)
The current proposal is not about an actual trial of flagged revisions; it's about turning on some software options that would be needed before one or more future trials of flagged revisions could be performed.
If the current proposal is implemented and the software features are turned on, the features would nevertheless remain unused (for the time being), and nobody except people in a special user group would even notice that the features were turned on. The only change would be that people in the special user group (called "surveyors") would get a new user interface that would allow them to turn on "flagged revisions" behaviour on some articles.
If the current proposal is implemented, surveyors would not (yet) be authorised by policy to turn on flagged revisions for anything. Some future proposals could give surveyors permission to configure certain articles to work the "flagged revisions" way for a trial period. Only after such future proposals (if any) are passed will you see a real difference in how any articles are viewed and edited.
If you can imagine any future flagged revisions trial that you would support (for example, using flagged revisions on some heavily vandalised articles, or on some pages that hardly ever get edited, or on a few randomly chosen pages, or whatever), then you should support the current proposal to turn on the software features that would allow that future trial to take place. If you can't imagine any future trial that you would support, then you should vote against the current proposal which would make those future trials possible.
It appears to me that many of the people voting "oppose" on the current proposal have misunderstood the proposal, and I don't blame them for that, because the proposal hasn't been well explained. —AlanBarrett (talk) 19:34, 18 January 2009 (UTC)
Thanks you for that explanation, after trawling through numerous pages of extreme legnth and various links, i did the trial on Wikilab, and enjoyed it lol
With your explanation I am more than happy to vote yes, as I know that eventually this will benefit Wiki much more than it will detract.
Chaosdruid (talk) 19:40, 18 January 2009 (UTC)
One of the problems with setting it up like this is something that SoWhy explained earlier. A lot of people "just don't believe that it will stop at a trial? Many bad things were introduced step-by-step, grinding away opposition by saying "it's just limited cases". Studying law, I know some good examples: Wire-tapping for example has been introduced into German law with the promise that it will only be used in cases like murder. Nowadays it's being used for a score of crimes, even such crimes as forgery or bribery. Many who opposed this law with the slippery-slope-argument were ridiculed that they were opposing something that noone planned. Now we know they were correct, but the damage has been done. I think the same may as well apply in this case and people may want to prevent it. Apart, of course, that this feature, no matter how limited its use, does in fact remove "anyone can edit"." Now, you can say that each case will individually require consensus, but I'd prefer to just vote on each case one at a time. If I support this software importation, I have no idea if Flagged Protection (the only trial I support at the moment) will be one of the ones up for vote. If someone started an RfC about Flagged Protection, I'd be happy to support it, but until then, I must oppose. NuclearWarfare (Talk) 19:53, 18 January 2009 (UTC)
Yehbut sometimes "grinding away opposition" just means showing people that their fears were irrational, so that what was initially unpopular becomes acceptable. And if you think the powers that be are hell-bent on imposing this even if it continues to be unpopular with a significant minority of users, then they are not going to pay any attention to this debate so you're wasting your time here. Since bureaucrats will have control over who gets the key "surveyor" right, you had better spend your time trying to elect bureaucrats you can trust. PaddyLeahy (talk) 20:55, 18 January 2009 (UTC)

Straw poll on implementation

We have now had plenty of time to discuss and refine this proposal to the point where the majority of its bugs have been ironed out. It is now time, I believe, to proceed to demonstrate a consensus for or against its implementation by means of a straw poll. The question to be considered is effectively:

Support for this proposal effectively implies support for one or more small-scale trials of FlaggedRevisions on en.wiki articles, although it does not necessarily imply support for a 'full deployment' either now or in the future. I would like to request that contributors read at least the discussion higher on this page as well as the details of the proposal before commenting. If you want to know more about how the system will look and feel on real articles, please investigate the live demonstration on en.labs. As usual, this is a straw poll, not a straight vote: discussion and debate is always welcome and encouraged. If you participate, please watchlist this page and be prepared to participate in any subsequent discussion. Usual no biting/kicking/sockpuppeting/bitching/scratching rules apply :D. Happy‑melon 17:40, 2 January 2009 (UTC)

Discussion

Widely advertised. Happy‑melon 18:18, 2 January 2009 (UTC)

Its not on the Watchlist header ? Mion (talk) 18:23, 2 January 2009 (UTC)
Things aren't added unilaterally to the watchlist header anymore; one of those links is to me proposing that we add it there. Happy‑melon 18:50, 2 January 2009 (UTC)
Can I say that the notion that this has been "Widely advertised" is a farce beyond measure. The day you put a notice in the anon notice explaining to the anons that this is happening is the day that you can say it is widely advertised. Considering this affects anons more so that anyone else your notices borderline on the spirit of wp:canvass for "Selective" notification as for anons will most likely not see this is even happening.   «l| Ψrometheăn ™|l»  (talk) 10:00, 8 January 2009 (UTC)

Errr One reason why I usually don't vote on these matters is that I haven't the faintest idea what the heck they mean. The words are English, I have a very good command of English - having once compiled a rhyming dictionary; reading this stuff makes me think that the Pentagon has had a hand in it. My apologies to whoever did word it - I would be insulted to be compared to the Pentagon. To a specialist, no doubt it is crystal clear. But, as with manuals written by experts (and read by total amateurs), could I ask for these things to be run past a relative newcomer before they are put out for consideration? Peridon (talk) 18:19, 2 January 2009 (UTC)

My best advice would be to go to the Live demonstration at en.labs and have a see for yourself. In one sentence, FlaggedRevisions means that when edits are made to certain articles, those edits are not immediately visible to readers, until they have been "sighted" by someone trustworthy to ensure they do not contain obvious vandalism. In one more sentence, this proposal is to give ourselves the ability to have a 'play around' with various options to work out how best to use this system on en.wiki. Hope this clarifies, feel free to ask any further questions. Happy‑melon 18:25, 2 January 2009 (UTC)
We could do with you giving a summary when they come up with these policy things. That seems nice and clear, thanks. Peridon (talk) 18:44, 2 January 2009 (UTC)
Don't feel bad...I speak English and this is still all very unclear. What I gather is that we'll actually be able to preview the edits as we edit, saving us clicking the preview button. This would replace seeing the code. Personally, I think the idea of guaranteed closed tags is wonderful, but I can only imagine how many unused closed tags there will be, and the once-lightweight wiki may become extremely heavy like Microsoft Word documents due to ghost tags. Bob the Wikipedian (talk • contribs) 05:49, 6 January 2009 (UTC)

I'm generally opposed to the idea, but if it must be passed, a few suggestions.

  1. Make users reviewers automatically after 100 edits with at least 50 in the mainspace to be able to keep up with the site's edit volume.
  2. Allow admins to grant revoke the permission as well, revoked users must have an admin grant them again to prevent abuse and reward good-faith editors.
  3. Get rid of the "unsighted revision" and "sighted revision" messages found in other projects with FlaggedRevs, it would look unsightly.
  4. Allow all edits by reviewers to be sighted (known as the autoreview permission) to make it more streamlined.
  5. Create an "editor" class with the addtional permissions of:
  • "Unsight" can return the page to the state (but not the version) before being reviewed so any edit will be made to the page itself. Can be undone by a reviewer re-reviewing then page (unless it's under a "review protect" that can be placed by admins, preventing reviewing of the page by non-admins). To keep pages that need to be rapidly edited open.
  • "Sightundo" can undo the sighting of another reviewer to undo errors.
  1. Allow reviewing of the wikipedia namespace. However only policy and guideline pages should be reviewed.

I reiterate my stance I am opposed to the idea as I think it would turn away newcomers who don't understand or agree with the FlaggedRevs idea.--Ipatrol (talk) 22:26, 2 January 2009 (UTC)

It is a change to protect all pages so that any edits made will be reviewed before any page is changed, is that right? It is an arms length from the public. Of course it is a good idea if I understand it correctly as a step to ensure the accuracy and vandalism protection of articles but it is unlikely to be a good idea across the whole board, is it? Again, a good idea but I reckon it is going to rush in without setting out where it applies. (also) There has never been an announcement to all users (for anything not just this), has there? Will there ever be? Shouldn't fundraising be promoted on all user pages with a community message here and there? ~ R.T.G 01:21, 3 January 2009 (UTC)
The sad truth is, a great many of our most intelligent contributors don't know their foot from their ass. Anything that brings complexity to Wikipedia is going to turn a large many people away. Anything that brings complexity, even the necessary things we have in place now. This is not one of those things. --♥pashtun ismailiyya 04:12, 4 January 2009 (UTC)

Now that this is being publicised across all of Wikipedia, it will dearly help if this could all be clarified as to what, exactly, it is. I haven't the faintest idea what I'm supposed to either support or oppose. The vast majority of Wikipedia users are not particular technical-oriented individuals, but so far much of this information appears to be written for an audience that is more familiar with Wikipedia's technical workings. Unless this is already what is being considered or has been considered before, has there ever been consideration of a rating system for users (a la eBay)? Over time, it could be easier to ignore edits in your watchlist made by established users and you could set your watchlist to highlight those made by those with a negative and/or minimal record. Cheers! --Bossi (talk • gallery • contrib) 18:30, 3 January 2009 (UTC)

  • What is consensus and how will we judge it? This poll has been running at ~65% for quite a while, and doesn't seem to have any signs of budging from that. How are we going to be able to judge if there is truly a consensus or if there is an absence of consensus about this issue when we are done. I say that 65% is clearly no consensus, but others might disagree. NuclearWarfare contact meMy work 01:42, 5 January 2009 (UTC)

If we're going to have scalability issues like some people anticipate, then I would think that [2] would be the perfect solution. Kevin Baastalk 20:53, 5 January 2009 (UTC)

Just a point I've been considering about this straw poll. It's a poll to (attempt to) indicate the community's consensus for a trial of the FlaggedRevisions system. Many of the responses under 'support' are ones saying the trial couldn't hurt, and it's worth a shot, the others are commenting on the idea of FlaggedRevs themselves. As I see it, this could actually have the opposite effect to achieving consensus - this poll should have been more clearly asking if editors supported or opposed a draft of 'x' policy on FlaggedRevisions, with a trial to be held if there was an indication of consensus.

If the poll shows support for a trial, this may be (mistakenly) seen/be used as support for the system as a whole. In the same vein, if it is shown as against a trial, this does not necessarily mean the consensus is that FlaggedRevs should not be used, just that the conditions of a trial should be set differently. Something to think about. - RD (Talk) 00:41, 7 January 2009 (UTC)

I don't think there will be enough support, there needs to be consensus which typically entails atleast 75% support.   «l| Ψrometheăn ™|l»  (talk) 18:47, 7 January 2009 (UTC)

::No comprendo The page linked to said GOTCHA. A joke or a feature or a hack??I

have no idea what it means or how it works; which is why I voted to only let registered users edit BLPs. But if gets rid of tag teaming, sock puppets, meat puppets, partisan deletion freaks, and agents of foreign govts I'll be delighted. Ha ha ha. OK, I read WP:Flagged revisions and finally got it. Will opine elsewheres. CarolMooreDC (talk) 22:37, 7 January 2009 (UTC)

I just wanted to mention here as well, that the German Wiki backlog objection argument ignores the fact current Protection policy is more disruptive to a Wiki environment than a FlaggedRevs system. Using FlaggedRevs on popular articles that are heavily trafficked, vandalized and consequently watched by active patrollers & admins -- a backlog simply will not form given the number of editors involved. When a backlog does occur on articles that have become under supervised over time, then a bot automatically nominates FlaggedRevs to be removed. If no one objects, it happens automatically and all held edits go live. The English Wiki has far more manpower available and if FlaggedRevs is used judiciously it free us from using Protections and gets Wikipedia back to its motto of letting anyone edit. Wikipedia's motto in no way guarantees every edit will go live. - RoyBoy 05:50, 8 January 2009 (UTC)

You make a good point. The only version of flagged revs that makes sense to me is the one where flagged revs replaces semi-protection. But that's one of only several trials that are being proposed. Most of them would see flagged revs live ALONGSIDE semi-protection. In those cases, then flagged revs would not be an increase, they'd be yet another layer of bureaucracy. Lot 49atalk 07:46, 8 January 2009 (UTC)
Im starting to be concerned now that flagged revs could be abused by administrators as a tool in an editwar with other users who dont have the reviewer right, as for the scrutiny for the use of flagged revs will be less than that of protection.   «l| Ψrometheăn ™|l»  (talk) 10:04, 8 January 2009 (UTC)
It's not just administrators who have the ability to sight revisions. That permission is also given automatically to all rollbackers, and there is another user-right 'reviewer' that can, and will, be distributed widely to editors. The standards for getting the ability to sight revisions are likely to be lower even than those for getting rollback, so a huge number of people (probably over ten thousand) will have this permission. As such, edit wars are not very likely to be unbalanced in the way you describe. And if you think about it, it doesn't actually make much difference: as all logged-in users see the current version, the edit war is just as visible to them as before, so it will be sorted out as quickly, if not more quickly, than it would be without FlaggedRevs. And the worst that can happen from the point of view of a logged-out reader is that the article spends some time stuck in the wrong version, which happens anyway with protection but often for much longer and more arbitrarily. Most importantly, even if there is a 'sight war' over one section that results in that section being locked in the Wrong Version, other sections of the page can still be improved by impartial editors, which is not the case with protection. FlaggedRevisions is certainly not a solution to edit wars or POV-pushing, but it is much less disruptive than protection, either full or semi. Happy‑melon 12:02, 8 January 2009 (UTC)
Most importantly, even if there is a 'sight war' over one section that results in that section being locked in the Wrong Version, other sections of the page can still be improved by impartial editors, which is not the case with protection. Can you explain this further? This does not match up to my understanding of sighting which is on a whole-page basis as I understand it. What am I missing? Lot 49atalk 10:09, 9 January 2009 (UTC)

A Kill Date?

If this "trial" goes ahead, when will it be voted on again to confirm wether flagged revisions stays or go?   «l| Ψrometheăn ™|l»  (talk) 09:45, 8 January 2009 (UTC)

If this proposal goes ahead, there will be subsequent discussions on what exact trials we want to conduct. When those discussions produce a complete and sensible proposal we'll go through the same stages of community ratification that we've done here, and a bureaucrat will judge whether there is consensus to run the trial. Each trial must have a definite endpoint, no trial can be open-ended. Once we've conducted a number of trials and analysed the resulting data, we will be in a better position do decide how we want to use FlaggedRevisions on en.wiki, and if we even want to use it at all. Whenever we want to make a final decision on that, we will need one final round of community consensus to ultimately set FlaggedRevs however we decide. Happy‑melon 11:54, 8 January 2009 (UTC)

Sighting versus reviewing

I'd like to see a clear distinction maintained between sighting and reviewing. Sighting is about verifying that an article (or a diff) contains no obvious vandalism or other gross forms of badness. Reviewing should be more than that; for example, reviewing could include fact checking, assessment of readability, assessment of completeness. The proposal currently under discussion deals entirely with the process of sighting, not with reviewing, except that it uses the term "reviewer" for the name of a user group. When (if) this proposal is implemented, please rename the user group to "sighter", not "reviewer". Documentation and system messages will also need to be checked for confusion between sighting and reviewing. —AlanBarrett (talk) 13:05, 15 January 2009 (UTC)

Sighter is an ugly military term, really we shouldn't use it. The proposed implementation is used for trials only, we won't have additional usergroups except surveyor, so reviewer won't be confused. Other possibilities of name may include patroller, but we'll see later what kind of groups we'll need in future implementations. It's also quite certain that fast-checking, assessment of completeness or readability affecting editability so much will never be accepted on Wikipedia. Cenarium (Talk) 19:26, 15 January 2009 (UTC)
IMO, sighter sounds much more "civilian" than patroller. However, this is just my opinion. Admiral Norton (talk) 19:07, 16 January 2009 (UTC)
Any suggestion is welcome. Cenarium (Talk) 21:56, 16 January 2009 (UTC)
Here's one suggestion. I too dislike sighter/sighting. Would checker/checking perhaps be better? (I mean that in the sense of quickly checking, rather than fact-checking as part of a review.) --Tryptofish (talk) 17:20, 19 January 2009 (UTC)

Canvassing?

I'm not sure what to make of this, which User:Promethean has advertised on a very large number of users' talk pages (eg). The message, "say no to Flagged revisions" with a link to the #Oppose section above, was MfD'd as canvassing, but was snowball-kept after Promethean changed the link to not point specifically to the 'oppose' section. It is rather disconcerting, therefore, to see an edit where Promethean changed the link back just under an hour later, eight minutes after the MfD was closed. Promethean also seems to have substituted a number of these templates, such that the WhatLinksHere no longer accurately reflects the number of transclusions in existence. All of the substituted templates link to the 'oppose' section.

The MfD was open for less than ninety minutes, although I do not disagree with SoWhy's WP:SNOW closure given the content of the discussion. I am more concerned that the discussion was not linked to here and the fact that this template is in use (and links, as of this post, to the 'oppose' section of the straw poll) was not remarked upon. I am interested in obtaining wider comment on the situation. Thoughts? Happy‑melon 12:13, 11 January 2009 (UTC)

Short comment on that: I closed the MfD because its scope was only if the template itself can be seen as canvassing, which I think everyone at the MfD agreed can't be more canvassing than most userboxes. The way it was promoted to talk pages though could be regarded as such (although I doubt it) but we cannot MfD behavior, only pages. SoWhy 10:00, 19 January 2009 (UTC)
Always thought that the anti-canvassing rule on wikipedia was silly and never more so for a major issue like this. I'd be very happy to display a pro-flagging equivalent! PaddyLeahy (talk) 12:21, 11 January 2009 (UTC)
I hate the anti-cancassing rule. But User:Promethean should be blocked for inordinate bad faith manipulation of this whole thing (see the point above about the incorrect issue of 21 days). In my opinion. But that's just me. ♫ Melodia Chaconne ♫ (talk)
I'd already voted oppose and was offered the gawdy userbox to use if I wished. It wasn't added, just offered. I chose to not use it and not respond. If it was only offered to people who'd already !voted no, then it's certainly not canvassing. Spamming, maybe, but not canvassing. - Hordaland (talk) 13:14, 11 January 2009 (UTC)
It wasn't canvassing in my opinion because he only showed the link to those that had already made up their mind. And displaying the template with a link to #Oppose is no worse than displaying a notice about an RfA or similar discussion. Its in my opinion a really trivial thing that shouldn't really have any affect on the outcome Alexfusco5 17:56, 11 January 2009 (UTC)
I got the note and displayed the box until I switched to support, I agree with Alex, this is trivial and should not have much of an effect.--Res2216firestar 18:28, 11 January 2009 (UTC)
Just noting that as the creator of the image I strongly disagree with the mass messaging, but I don't consider it 'canvassing'. — neuro(talk) 23:08, 11 January 2009 (UTC)
This is not canvassing but certainly aggressive campaigning with the objective to sway consensus in a community discussion. The template also adds to the incomprehension on the subject of this poll, which is not whether we want to massively enable flaggedrevs on all articles, but whether we can enable the proposed configuration in order to make trials that have to be supported by consensus. Those factors will have to be taken into consideration when closing the poll. Cenarium (Talk) 01:04, 12 January 2009 (UTC)
No more so than the repetitious reverence for Jimbo. Anyone who closes a poll of just over 60% approval on a change of this magnitude as anything other than no consensus may expect to explain themselves to ArbCom. Septentrionalis PMAnderson 18:11, 12 January 2009 (UTC)
As I said somewhere above, Wikipedia:Requests for arbitration/Brion VIBBER is perhaps the most amusing idea I've seen all week. Happy‑melon 18:36, 12 January 2009 (UTC)
Yes, four weeks ago on Wikipedia_talk:Flagged_revisions/Trial#RfC_on_implementation you said "A clear consensus is required to present to the developers to have the extension installed". I thought Brion VIBBER is a lead developer ? so whats amusing ? Mion (talk) 19:08, 12 January 2009 (UTC)
The fact that Pmanderson proposes to take the Wikimedia Foundation's Chief Technical Officer to the en.wiki Arbitration Committee for alleged breaches of policy. A clear consensus is indeed required, but to suggest that we have any control over how that consensus is judged is what's amusing. The best we can do is present coherent arguments, and to get widespread involvement. I'm not sure if this is the highest turnout we've had in Wikipedia's history, but it's certainly coming close; that's the definition of "strong consensus": something that reflects the opinions of the widest possible array of Wikipedia editors. What this poll is judged a consensus for is entirely out of our hands. Happy‑melon 19:56, 12 January 2009 (UTC)
So a high turnout = "strong consensus"? Not at all. Wikipedia is not a democracy, and a majority vote is not enough. Septentrionalis PMAnderson 22:18, 12 January 2009 (UTC)
This isn't canvassing; canvassing is an attempt to sway a large number of user's opinions in a community decision. Promethean sent the message to people who had already opposed. –Juliancolton Tropical Cyclone 18:25, 12 January 2009 (UTC)
Where are the reverences ? Which percentage of users even knows about Jimbo's position ? Jimbo's statements are rather turned in reasons to oppose. What will have to be taken into consideration is that most comments are for or against an unrestricted implementation on all articles like on de.wiki, which is ... off-topic. The majority of comments are not to the point. Cenarium (Talk) 19:16, 12 January 2009 (UTC)
Anybody who glances at the first nine supports; and plainly some have done so. And what percentage of editors have been swayed by Promethean? As his edits say, he wrote those who had opposed. Septentrionalis PMAnderson 19:46, 12 January 2009 (UTC)
Users noticing the template on a userpage, especially from users they know, are driven-by. Even if it's not clearly forbidden by policy, it's a deliberate attempt to sway consensus by inciting users to vote 'no'. More have seen them than Jimbo's !vote, but overall none have a major influence. Cenarium (Talk) 22:56, 12 January 2009 (UTC)
(ec) AGF? If indeed the "majority of comments are not to the point," then the point has been poorly presented. However, it seems to me that some proponents dismiss valid concerns, such as mine. This discussion has already taken hundreds of man-hours. The parameters & evaluations of each trial are to be decided by consensus = hundreds more man-hours. With that much invested, it is human nature to want not to backtrack. Such concerns are not off-topic. - Hordaland (talk) 20:01, 12 January 2009 (UTC)
Please reread what I said, i.e that most comments both in the support and oppose sections are (increasingly as the poll run) directed at whether we should massively enable flaggedrevs or not, which is not was is asked here, but whether we can enable a passive configuration in order to make specific trials, each one requiring consensus. I wouldn't be opposed to use an editnotice to clarify this in a neutral manner (as has been done for the mosnum RFCs). If your concern is that changes won't be visible immediately (and thus decrease participation), then I agree that it is also a concern, and it is one of the reasons I am opposed to a full, unrestricted implementation. But the trials are not of this kind. Trials are limited and require consensus. More long-term proposals range from using a light version of flaggedrevs instead of semi-protection, or a semi-automatic implementation where only edits identified as probable vandalism are not shown. I do not believe that those trials will open the door to a full, unrestricted implementation, the community is too strongly opposed to this, but is is indeed a concern to a few users. Cenarium (Talk) 22:56, 12 January 2009 (UTC)

Requests for Surveyorship?

Continued from New userrights group discussion

Looking by the previous discussion on the usergroup 'surveyor'. So how are we going to choose surveyors? RfA-style? Crats no longer play mere technical roles, but social roles too in determining consensus. We already have enough politics in choosing administrators, we do not need to bring it to a whole new level - where editors start asking how should the usergroups get hierarchically arranged! I support FlaggedRevs in principle, but certainly not implementation in this form... - Mailer Diablo 19:40, 13 January 2009 (UTC)

At least for the duration of the trials, we really shouldn't be adding and removing flagged revisions from articles arbitrarily. Only a few people need to have it just to set up the trials at the beginning. Dcoetzee 00:17, 14 January 2009 (UTC)
It's obvious isn't it? If this thing were to be implemented, then in reality any editor with a proper account and an arbitrary number of edits and time served should automatically be deemed trusted. Say 1,000 edits and active for a year? Something like that. Then they get to OK edits. The last thing we need is more politics, if it's automatic for experienced users then there is no politics. Personally I think anyone with say 10,000+ edits should automatically become an admin and I think arbcom members should be drawn randomly from the community, with say 100 serving at a time. But then I hate hierarchy of any kind, and Wikipedia is doing it's best to turn itself into an authoritarian system "ruled" by those with the best networking and political skills. Alun (talk) 08:50, 14 January 2009 (UTC)
You've confused surveyors with reviewers. Dcoetzee 09:00, 14 January 2009 (UTC)
So we have "sighters", "reviewers" and "surveyors". Any more utterly absurd types of elitist sinecures we should create for the budding "content police". Surely we need a better hierarchy than this. Maybe some more military sounding "ranks" perhaps? Alun (talk) 10:51, 14 January 2009 (UTC)
BTW I didn't use the words "surveyor" or "reviewer". But reading this, it looks to me as if one needs the "reviewer" right to "survey" pages and then mark them as "sighted". So these seem to be all the same thing. Can you clarify the difference between a surveyor and a reviewer for me? Alun (talk) 11:06, 14 January 2009 (UTC)
This "surveyor" doesn't sound like the version that was put on the table for this trial proposal. - Mailer Diablo 14:03, 14 January 2009 (UTC)
Sure. I didn't make up the names, but it is the reviewer who reviews and sights (or flags) revisions. The surveyor is a position that exists only for the duration of the trial; they have the ability to enable or disable flagged revisions on specific articles. The purpose of this is of course to allow us to conduct a structured small-scale experiment. Dcoetzee 18:40, 14 January 2009 (UTC)
Surveyor is already taken Wikipedia:Flagged_revisions/Quality_versions#Reviewer_rights, Reviewers are surveyors who can mark pages as "quality" in addition to "sighted". Or would you like to test Quality versions in the same run ? Mion (talk) 20:46, 14 January 2009 (UTC)
On the de.wiki you get the Sighter status as you're registered for 60 days, you're not blocked before AND you made 300 edits, as a Sighter with "review" rights you can only validate edits from others, if a page is Sighted and you make an edit, your edit is not going live before its approved by another Sighter.
Update The group Sighters has now review + autoreview rights. Mion (talk) 17:25, 14 January 2009 (UTC)
Now discussion is ongoing on the de.wiki because of r45636, autoreview is enabled on the system, with the following set: All users with a confirmed email address, 1 year on the project and more than 3000 edits become autoreviewers, in effect, this group is auto sighting its own edits, the edits go directly live if the last version was a sighted version, if there are edits from others to sight in the article all stay invisible until another Sighter validates, its similar to the Bot-flag on de.wiki. Mion (talk) 10:46, 14 January 2009 (UTC)

Err...we really should just have one group, whatever it's called. Aaron Schulz 18:01, 14 January 2009 (UTC)

I think it should be called "editors". Now there's revolutionary. Alun (talk) 19:19, 14 January 2009 (UTC)

I am very sceptial about FR, BUT, I always say (maybe as a [European] liberal, heh), that it is always best to have a role in a situation which purports to improve the lives of other people than stand on the sidelines shouting. So I would be interested in putting myself forward for this "editor/what have you" role. doktorb wordsdeeds 19:29, 14 January 2009 (UTC)

  1. Like this
    Surveyor Sighter admin
    1 Sighter (reviewer + Autoreviewer) 300 edits AND 60 days
    2 Admin (reviewer + Autoreviewer)
    3 Registered users 3000 edits AND 1 year (Autoreviewer)
    4 Registered untrusted users (auto confirmed) 10 edits AND 4 days (none)
    5 Registered untrusted new users (none)
    6 Unregistered untrusted users (IP) (none)
SSA would be more clear. Mion (talk) 21:13, 14 January 2009 (UTC)
On the Twelve day of the trial, my b'crat gave to me..... - Mailer Diablo 06:20, 15 January 2009 (UTC)

Don't you think that too much emphasis is put on the "edit count" of an editor. I happen to have a low edit count compared to other users who have been around for about the same amount of time I have. I am confused as to who would have what, because of my edit count would I be considered a "untrusted user" or because of my rollback rights or being here more then a year would I be a reviewer? -Marcusmax(speak) 21:30, 14 January 2009 (UTC)

60 days and 300 edits is enough for reviewer (Sighter), its unlikely that editors with less get rollback rights granted. Mion (talk) 21:39, 14 January 2009 (UTC)

Let's only discuss the trial here, as it confuses to bring up other implementations that we know won't happen on Wikipedia anytime soon.

1 Surveyor (can review and change page configuration) (informally granted for the needs of a trial is best option)
2 reviewer (can review) (any user with no recent vandalism or libel edits with minimal time and edits here)
3 User (can't review, see latest rev per default)
4 IP (can't review, see latest flagged rev per default)

Cenarium (Talk) 21:55, 14 January 2009 (UTC)

Hmm, I'm skeptical about how much sense it makes to show logged-in users the latest rev by default. After all, many logged-in users are only occasional editors and primarily readers. Dcoetzee 00:29, 16 January 2009 (UTC)
Users can configure their preferences to see the latest flagged rev. Cenarium (Talk) 14:29, 16 January 2009 (UTC)
I'm still kind of confused here, so maybe someone can explain it to me in basic terms. I'm not an administrator, I do not plan to be one, and I've a megaton of edits dating back to 2007. I often make a lot of edits a day. If Wikipedia becomes Flagged Revisionpedia - will I be able to make an edit and immediately view it? For a random example, if I go to the page Melissa and change "Full of wrath" to "full of wrath" (or, just to be daring, delete "or Full of wrath" alltogether), will that be visible immediately? All Hallow's Wraith (talk) 11:59, 18 January 2009 (UTC)
First off, there would be FAR more sighters than admins. Secondly, ANYONE can view the most recent version of a page, the main difference is what you see initially. If you're seeing the sighted version, you can click a link to switch to the draft, and vice versa. Also, any edit made by anyone will show the editor the draft version when done. ♫ Melodia Chaconne ♫ (talk) 12:41, 18 January 2009 (UTC)
On the German wiki there are 312 admins and -/+ 50 active sighters, User:Hut 8.5/DEWP reviewer stats/ Mion (talk) 12:50, 18 January 2009 (UTC)
Of course, you would have sighter/reviewer rights. Any user with minimal experience (1 month here/100 edits for example) will be granted reviewer rights, unless s/he recently vandalized or added libel. But why would Melissa have flaggedrevs on ? This is not a proposal to use it on all articles, and most users supportive of a trial would oppose it. Realistic long-term proposals are: using it on blps, on articles instead of semi-protection, etc. Proposed trials are described here. Cenarium (Talk) 13:21, 18 January 2009 (UTC)

A lot of people are confused. From my understanding, the original proposal I saw at Flagged revisions was only 'reviewer', which flags a revision as reviewed. This version of the proposal wants to have 'reviewer' and 'surveyor', with the latter deciding which article is to have flagrevs turned on and only given out by crats. If that is true, it isn't that hard to guess that people probably would have to go through one of the most politicized processes on Wikipedia to ask for it..... - Mailer Diablo 11:03, 19 January 2009 (UTC)

I agree that the terminology is confusing if you try to read the various proposals together. Rather, think of them as progressive evolutions on the same idea; the user groups that are available, and the permissions they have, have changed as the discussion has progressed. As such, it is both impossible and confusing to try to directly compare the groups from proposals that differ in time.
The 'surveyor' permission is intended to be a stricly temporary role, one that is retained only as long as is necessary. The best current analogy is the role of stewards on small wikis. If a small wiki without local oversighters needs an edit to be hidden, they can make a request on meta and a steward will give themselves oversight permissions on that wiki, hide the edit, and then remove the permissions immediately afterwards. In a similar manner, when we have a consensus to start a trial we will have a need for one or more surveyors. We probably use an informal RfA-style process to select a few users who we believe are trustworthy with the extra tools, and the bureaucrats will flag them. Once the trial is completed, the permission is no longer necessary and so the surveyors will either resign (they have the ability to remove their own surveyor status) or be deflagged by a bureaucrat. If we need more surveyors at a later date, we can reappoint previous users or nominate new ones, as desired. But 'surveyor' is not a permanent position. Happy‑melon 13:05, 19 January 2009 (UTC)
Here's my prediction - 'surveyor' becomes permanent (as the "trial" would be) because the community and the originators would not be able to find the momentum to shift the (by then) status quo when the trial is implemented. (hey, we don't even have a bright-line date when the trial ends?) We are running on a Wiki with the size of 2.7m articles, not 270 articles. Are you aware how difficult is it to remove any userright/position that is admin and above over here?
Like it or not, this is how it's gonna actually work. The 'surveyor' usergroup would then be seen as higher than admin but lower than B'crat. People would queue up for them at RfS, thinking as part of the Content Certifying Committee of the Surveyors Socialist Cabal Union of the WWWP they would be able to a exert subtle but more control over articles and an extra hat, adding on to the hierarchies of Wikipedia. Bad, bad, bad idea. - Mailer Diablo 13:28, 19 January 2009 (UTC)
While the analogy is entertaining, I don't believe your concern is justified. On this issue, the proposal is crystal clear: indeed the only imperative clause in the entire proposal is that "each trial must have a definite endpoint". Similarly, the proposal is quite clear that "For each trial, a bureaucrat will appoint several 'surveyor's... At the designated end of the trial, the surveyors will... remove themselves from the 'surveyor' group". There won't be a Requests for Surveyor process, in the same way that there is no RfO for Oversight or RfC for Checkuser - the positions are created only when they are needed. For a bureaucrat to create surveyors outside the scope of a trial would be a violation of the proposed policy, which we trust them not to make (that's why they're 'crats in the first place, because we trust them). User rights such as admin, 'crat, checkuser, oversight, etc, are difficult to remove on this wiki because they can only be unset by stewards, and the only group on en.wiki that has the authority to instruct the stewards to take action is the Arbitration Committee. The situation is totally different with 'surveyor', where they can not only resign (and would be expected to do so at the appropriate time) but can also be deflagged by the bureaucrats. Failing to resign their surveyor status at the end of a trial is an overt violation of the proposed policy, for which a suitable reaction would be... loss of surveyor status. And lo, we have twenty users capable of taking that action. So your doomsday situation can only occur with the co-operation of the entire bureaucrat community. Do you have any evidence to suggest that this is likely to occur? Happy‑melon 13:46, 19 January 2009 (UTC)
"Each trial"...Are you sure one trial can even be completed? A "trial" till this day -> Article creation restricted to logged-in editors on "experimental basis", post-Seigenthaler, Seigenthaler 1 year after
"We probably use an informal RfA-style process"..."There won't be a Requests for Surveyor process" Well, even "RfO" and "RfC" is up for reform and be handed out to more editors who will use them. -> CheckUser and Oversight appointments reform. Furthermore, some WMF projects do hand them out by RfO/RfC.
"So your doomsday situation can only occur with the co-operation of the entire bureaucrat community."
Y not? -> Carnildo's re-promotion, Ryulong's RFA passing at 69.4%!?
What makes you think that everyone is willing to follow policy down to the letter? - Mailer Diablo 14:40, 19 January 2009 (UTC)
So you are comparing a knee-jerk reaction 'experiment' that was announced and implemented unilaterally and without any consideration of a review process, with a proposal that has been evaluated by over six hundred editors and which excludes an explicit prescription that every trial must have an endpoint (a level of prescription that is rarely used in policy, even in core principles)?
You misunderstand the nature of the proposed checkuser/oversight appointment process, which is about as far from RfA as you can sensibly get, if you think it is intended to lead to a proliferation of the CU/OS rights. Checkusers and Oversights will be appointed through that process only when they are required; if anything, the proposed endorsement method enshrines that principle rather than eroding it. Surveyors will be appointed in the same way.
There's really little I can say on your apparent distrust of the bureaucrat community; the examples you offer are like comparing chalk and cheese. Both situations are controversial, but there's a whole world between making controversial decisions, and endorsing an overt policy violation and abuse of power. IAR is not a catch-all "ignore any policy you disagree with" (and remember that there are a number of bureaucrats ranked on both sides of this discussion) but "ignore policy in situations where you ernestly belive that you are following the spirit if not the idea". If you honestly believe that there is a genuine risk of our entire bureaucrat cadre misinterpreting three policy clauses so badly as to essentially invert their meaning, there's very little else I can say. Happy‑melon 15:10, 19 January 2009 (UTC)

Crucial difference between the (successful) German implementation and suggested English trial

There seems to be a small but important difference, which actually matters a great deal to much of the discussed criticism of flagged revisions. In short: While the suggested English implementation arguably severely interferes with the "all can edit"-principle the German implementation does not.

This is how the German implementation works: An article displays in the default mode with a button at the top right (zur aktuellen Version allowing all readers to switch between the default view and the latest edit, when they are not identical. From the perspective of the (anonymous) reader all that the sighted status does, is influencing the default display, but he can always access the latest nevertheless. The default is the determined the following way:

  1. if there is a sighted edit, the default display is the latest sighted edit
  2. if there is no sighted edit, than the default display is the latest edit.

Note that this means all edits by anyone continue to go live immediately (just not in the default display) and if new articles is created by an IP it is in the default display even.

Here is the suggested English implementation: When FlaggedRevisions are enabled on a particular page, logged-out and anonymous users will see the most recent sighted revision, and all edits to that page can be sighted by members of a second usergroup, 'reviewer'. By default, all logged-in users, reviewers or not, see the most recent version of such pages, although this can be customised in personal preferences.

Here is no mentioning of a button allowing all readers to see the latest edit (and hence ensuring all edits are live immediately).--Kmhkmh (talk) 11:29, 15 January 2009 (UTC)

The proposed implementation in the english wikipedia will also have the button you are talking about. It's true that the text you quoted does not mention "a button allowing all readers to see the latest edit", but that doesn't mean that the button won't be present, it just means that the proposal is not very easy to understand. The actual proposal is at Wikipedia:Flagged revisions/Trial, especially in the "Technical implementation" section of that page. The proposal is phrased in terms of the way certain software configuration options will be set, not in terms of the observable behaviour of the software when it is configured in the proposed way. You can try the Live demonstration on en.labs.wikimedia.org to get a better idea of how the software works. Reading some of the answers to questions asked by other people would also have shown you that "all can edit" and "all edits by anyone continue to go live immediately (just not in the default display)". —AlanBarrett (talk) 12:43, 15 January 2009 (UTC)
well thanks for the clarification, unfortunately this site is rather long, so i didn't read all comments on that matter. However just reading some of the comments seems to indicate that many people are/were not aware of it, so it might be a good idea to explicitly include that fact in the quoted suggestion, which btw was taking directly from "Technical implementation" section of that page. The problem is, that the actual configuration of that button is crucial, i.e. it is not "just" some minor configuration issue to be settled after the test, but it should be an integral part of testing itsself. Also for most readers/editors the behaviour, i.e. the behavioural description, is the only thing that matters. So it's not a good idea to leave out such information from a proposal on which readers/editors are expected to vote. --Kmhkmh (talk) 13:03, 15 January 2009 (UTC)
Oh, I agree, the proposal should have been better worded. —AlanBarrett (talk) 15:32, 15 January 2009 (UTC)
(This is tongue in cheek, don't shoot me!) - The easiest way to word the proposal is done in 5 words. "This idea has been abandoned!" :) Thor Malmjursson (talk) 19:11, 17 January 2009 (UTC)

Moved from the voting page

Moved from the voting page as the discussion is getting big (and difficult to follow). --X-Weinzar (talk) 13:26, 19 January 2009 (UTC)

  1. Support FlaggedRevs and specifically setting up for the planned trials. Splitting the decision between principle and specific details of trials is a good idea, and I note that the quality of the specific proposed trials has improved a lot since this poll started, mainly due to edits by users who (unfortunately) are still opposing this motion. Now we have some feedback on the German experiment and it seems to be scaling OK (>92% of pages currently have their most recent page sighted), and is doing its basic job of shutting out most vandalism. If it was the disaster some are claiming it would have been switched off by now; furthermore, we could configure it better than their current set-up. PaddyLeahy (talk) 18:24, 5 January 2009 (UTC)
    Well, shutting out most vandalism is done by the RC patrol, you don't need flagged revisions for this. As we have produced (though hard to measure) several MB of discussion already I'd be interested in your suggestions for "configuring it better than their current set-up". Once in a while new ideas do show up but only rarely by now. --X-Weinzar (talk) 15:29, 7 January 2009 (UTC)
    I sometimes think RC patrollers oppose FlaggedRevs because it will spoil their game or something, although of course they could just as usefully patrol the special pages listing unflagged revisions. Needless to say at present RC patrollers can't get rid of the vandalism before it has been displayed to readers for a finite time. As for improvements over the de version lots have been discussed, my favorites include (1) actually turning off semi-protection where no longer needed (2) extending the "sighter" permission to a larger fraction of the community, on an automatic basis, and (3) only applying flagged revs to articles which really need it (I would include BLPs, FAs, and currently semi-protected and protected pages). PaddyLeahy (talk) 11:03, 8 January 2009 (UTC)
    • Well, there is no way to do without RC patrol. You can't let them vandalize dozens of pages and console yourself by thinking "well, none of this will be visible anyways, we can revert this at some point later".
    Why not? We can!
    Well, think about how edits would pile up. The first IP blanks the page, now another user wants to add something to the article. Obviously, he will edit the last flagged revision. But what about this case: There is one useful edit, then some bad edit and then some useful edit again, and they all pile up. Now when YOU want to continue editing you first have to go through the stack of non-flagged revisions to choose between good and bad edits that argued about each other's additions? In that case, you can't just edit the last flagged revision but have to merge the best edits from the stack of non-flagged revisions.
    • I don't think any of them feels that flagged revision would "spoil their game". Besides, they could just return to playing Counter-Strike or whatever in case they should really feel unnecessary ;-)
    Well, there's this and this but he's probably not being serious...
    I can assure you from my experience at DE:WP: Flagged Revisions have no influence on vandalism. Vandalism fighters will still be needed and, as outlined before, vandalism still needs to reverted as quickly as possible.
    • 1) You won't have much fun turning off semi-protection at topics like rap stars, porn stars, wrestlers.
    First we'd have to turn it on; hardly any of these are semi-protected on en:wp (de:wp uses semi-protection a lot more). Of course if we don't implement FlaggedRevs there is a strong push to semi-protect all BLPs.
    • Semi-protection is still useful.
    Often asserted, but have you (de:wp) actually tried to turn it off now you have FlaggedRevs? If so can we have a translation of the report where it is shown that didn't work? PaddyLeahy (talk) 02:46, 18 January 2009 (UTC)
    There was recently a discussion at the administrators' noticeboard where someone complained that so many articles were semi-protected (especially articles about music for teenagers). As one user put it, there are already enough stupid edits by auto-confirmed users in those topics. If you would turn off semi-protection you would have to revert every few minutes. The few useful edits would not be worth all the work having to revert all the time and would also mess up the page history. So there was consenus that there are articles where you just can't turn off semi-protection. (all those sentences are more or less quotes, except for the last one which I use to summarize the discussion)
    • (There will also be some articles where someone forgot the semi-protection but that's a different topic).
    Quite. If we didn't tolerate human error we wouldn't have wikipedia at all.
    • 2) If you give out "sighter" permission to everybody you can forget about the experiment or about the flagged revisions altogether. Of course, you could argue about what the requirements should be. I think what we have is okay. Automatic basis doesn't work, than you can forget about it too.
    Not everybody but 10-100 times as many people as admins (not for a limited trial, obviously). And evidence please on the last point. PaddyLeahy (talk) 02:46, 18 January 2009 (UTC)
    Actually, I'm not sure what you meant by "automatic basis". I understood it as giving the right to every registered user. Did you mean giving it on automatic basis to like users with 300 edits? --X-Weinzar (talk) 13:25, 19 January 2009 (UTC)

Example where Flagged revisons would have helped

This is an example of a good faith IP user unknowingly hurting an Wikipedia article. He views the article and sees some very obvious vandalism and edits the article to remove it. (see diff1) The problem with the removal of the vandalism is that it should have been removed using the undo function which would have also added back the valid section of text deleted by the previous IP user who added the vandalism in a single edit. (see diff2) Had flagged revisions been in place, the good faith editor would have never seen the vandalism in the first place. The partial reverting of vandalism is the single biggest problem in Wikipedia in our fight with vandalism. It is also the main reason that most long term vandalism is permitted to remain in Wikipedia. Dbiel (Talk) 20:13, 11 January 2009 (UTC)

This is a recurring problem indeed, but it also happens with registered users. It is something that could be partially handled by the semi-automatic flaggedrevs proposal: we could use a special page listing articles with suspect revisions (see this for details, though this is hardly readable), it would detect many such cases. Cenarium (Talk) 20:42, 11 January 2009 (UTC)
No need for Flagged revisions there, the existing tools are Cluebot ,SoxBot III etc they are already able to counter such vandalism. Mion (talk) 20:55, 11 January 2009 (UTC)
If they were able to catch all vandalism, libel, etc, that would be nice indeed. But this is not the case. Cenarium (Talk) 21:02, 11 January 2009 (UTC)
An example was given, the bots are able to handle the given example, and now you're raising the requirements ? Mion (talk) 21:05, 11 January 2009 (UTC)
The bots haven't reverted it, they revert only a small part of all vandalism edits, even when such edits match their filters. And this is a blanket revert, while a combination of the abusefilter and flaggedrevs would defer all suspect edits to the analyse of a trusted user. Cenarium (Talk) 21:17, 11 January 2009 (UTC)
It requires only a small amount of people to run bots like this to handle big ranges of articles compared to the sighter scenario which creates a huge backlog, to answer your other question, the German wikipedia is discussing changes in the criteria for analysis by sighters because the current system isn't working (not all vandalism, libel, etc are caught), by making the criteria stricter, it takes more time, which will increase the backlog. Mion (talk) 21:30, 11 January 2009 (UTC)
The difference here is that in the proposed semi-automatic implementation, only edits that match the filter are 'delayed' to the draft page, and other edits are unaffected, and since most vandalism edits are quickly reverted, the backlog won't grow as big as it would in a total, unrestricted implementation like on de.wiki (that I would oppose very much), since when a new edit makes the latest revision no longer 'suspect', it is shown to IPs. Cenarium (Talk) 21:50, 11 January 2009 (UTC)
the proposed semi-automatic implementation: only edits that match the filter are 'delayed' As other (obvious) vandalism is caught by the bot and directly reverted, 97 % of the edits by IP's is ok, so 2,5 of the edits are questionable, now the German wikipedia needs human eyes to filter this vandalism and libel (see the discussion to raise the criteria), the question comes up: can you show me a ruleset (the filter in the proposal) for a bot, for lets say 100 articles, that allows the passing of the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism ? Mion (talk) 22:36, 11 January 2009 (UTC)
Your assumption that almost all obvious vandalism is reverted by a bot is incorrect, even if we count quick Huggle reverts or quick manual reverts (less than one or two minutes after the edit), still a considerable part of obviously vandalized versions remain visible for a few minutes or hours, if not more. The semi-automatic proposal would prevent this, and provide a special page listing articles containing suspect revisions, thus detecting incomplete reversions. As you know it, a perfect filter doesn't exist, but we would have much more liberty than in anti-vandalism bots' filters. They could be specialized for certain types of articles, for example articles on living persons, or articles targeted by a sockpuppeteer, or against a specific type of vandalism that can't handle bots without too many false positives. Cenarium (Talk) 00:46, 12 January 2009 (UTC)

This is also the sort of situation where FR are most risky. The anon made an obviously useful edit; there is a risk that any flagger will not check further, but will flag the repaired text; at which point the text lost to the vandal may well be permanently lost, unless someone goes behind the flagging. Septentrionalis PMAnderson 01:14, 12 January 2009 (UTC)

When flagging, the diff to the latest flagged revision is given, so any user with a little understanding of revision history can make the appropriate actions. There are many more cases where text will be saved thanks to flagged revisions than lost because of bad flagging. Cenarium (Talk) 01:57, 12 January 2009 (UTC)
That's precisely the problem. Diff1 by itself is an excellent edit, and any flagger should be tempted to confirm it. Septentrionalis PMAnderson 02:45, 12 January 2009 (UTC)
No, the latest flagged revision would be presumably this one, so the diff to the latest flagged revision would be this, which clearly indicates a lost of information. Anyway, history should always be checked before flagging, but this diff is a signal. Cenarium (Talk) 19:28, 12 January 2009 (UTC)
Except with FR, it wouldn't have happened that way in the first place, so it's something of a strawman to put it that way. ♫ Melodia Chaconne ♫ (talk) 03:09, 12 January 2009 (UTC)
@Cenarium:my assumption is correct, because in the proposal a small set of articles is targeted, you need a bot for this set, so if you take a SoxBot III as a tool to build the filter upon it will revert the obvious vandalism on this set, however in this proposal there is still the problem that you can't create a valid ruleset for the proposed FILTER and thats why this specific trial proposal can't work. Mion (talk) 10:32, 12 January 2009 (UTC)
We have no need for bots, the abuse filter automatically checks all edits and acts based on its own filters. When an edit matches some filter with an action 'deflag', it's 'moved' to the draft page until a no longer suspect revision exists (in particular, when reverted). Cenarium (Talk) 19:28, 12 January 2009 (UTC)
ok, so instead of Soxbot III the abuse filter to handle obvious vandalism, still the additional filter set for the 97% good edits+catching the 2,5% of edits that contain libel and smart in dept vandalism is missing. Mion (talk) 23:36, 12 January 2009 (UTC)
We can't catch everything, but anti-vandalism bots can continue to work as normal (they will never catch and revert every obvious vandalism, but a considerable part, the abuse filter will catch and defer even more). There is more support to enable flaggedrevs on blps, a semi-automatic implementation could help here too: instead of deferring suspect edits, it would allow edits identified as non-controversial (like interwikis, additions of links to an existent page, etc). There I think the proposed expiration system (old enough revisions are visible to IPs, e.g. 48 hours) would help too, as backlogs would still be important. The abuse filter could also be used to report specific edits to blps, like 'death announcements' to a special page (with the option to defer if supported by consensus). Cenarium (Talk) 00:46, 13 January 2009 (UTC)
There is NO support to enable flaggedrevs on blps, as that is no vote but to bring up arguments, and yes the abuse filter can do everything cluebot can, the rest of the arguments is assumption as there are no possitive statistics from the DE wiki, in fact, it doesn't matter if you handle users as second class citizen with a waiting time of 48H, 6 days or 21 days, remember they are volunteers Mion (talk) 01:39, 13 January 2009 (UTC)
From the discussion, there is more support to enable flaggedrevs on a blp that there is on another article. The all or nothing argument is getting weary here, we can enable flaggedrevs on certain articles and/or restrict it to a subset of edits. In any case, and especially in the perspective flaggedrevs is, restricted or not, enabled on a vast class of articles, the additional benefit of a semi-automatic (virtual) flagging will be to avoid deferring most non-controversial edits. It can do better than ClueBot, since it is more adaptable and reactive, and would be especially useful against persistent sockpuppeters, often causing undesirable semi or full protections. If you do not believe that this or an expiration system would be a benefit on the basic implementation like on de.wiki, then fine, but you can't reproach me of trying to find ways to improve the system. As I said, I'm opposed to massive unrestricted implementations, but I still believe that an article with a reasonable flagged revision system is better than a semi-protected one. And I don't see disadvantages to a semi-automatic implementation if the filters are well designed. Also, using flagged revisions (flagging sysop-restricted) in a dispute instead of full-protection may work well. Cenarium (Talk) 03:19, 13 January 2009 (UTC)
There is your IF, show me the FILTERS well designed Mion (talk) 03:25, 13 January 2009 (UTC)
I am not familiar with the abuse filter's filters, so I can't code specific filters. I assume we could initially adapt the filters from the anti-vandalism bots, since they are clear-cut cases, then propose new filters for community approval, then implement them if there is consensus. If a filter causes too much trouble (read too many false-positives), then revise it and remove if it can't be fixed. I can only extrapolate, since there is no wiki where both extensions exist as far as I know. Cenarium (Talk) 03:46, 13 January 2009 (UTC)
Thinking of it, as Flagged Revs is enabled on the de.wiki, why don't you do the proposed trials on the de.wiki, looking at the current state, it can only go up with other approaches ? Mion (talk) 02:12, 13 January 2009 (UTC)
Abuse filter:"Please keep in mind that this extension's aim is not to catch simple vandalism, as some bots already do. This extension will help preventing harm from some known persistent vandals (hagger), with very specific modi operandi. It won't catch childish vandalism or page blanking" Mion (talk) 13:59, 21 January 2009 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Flagged_revisions/Trial/Archive_3&oldid=1145849928"