Wikipedia talk:Pending changes/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Comments

I started reading this with some trepidation, but then I smiled. This is actually a really sane proposal. It's the direction Jimbo told me he was hoping for. While I've been against many applications of flagged revisions, this particular way of using it would be non-invasive, and actually improve our soft-security considerably. :-) --Kim Bruning (talk) 04:19, 5 January 2009 (UTC)

Can I request that you be careful about distinguishing flagged revisions from semi-protection? I realize that the proposal is about replacing our current semi-protection system with flagged revisions. But I think it would be easier to understand if you didn't try to mix the two names. Ozob (talk) 08:35, 5 January 2009 (UTC)

Well, I would think of this as an extention to semi-protection actually, that's why I named it as it is. Administrators could technically should still able to semi-protect a page in the traditional manner, but they also have an option to allow "flagged rev" option to the semi-protection, which is an extention that is being proposed in this proposal. I don't know if this will ever completely replace semi-protection but it does give the administrator more options than just semi-protection for sure. Hopefully over the course of time, this method could be more preferrable by admins than traditional semi-protection. Y. Ichiro (talk) 08:57, 5 January 2009 (UTC)

Actually not a too bad idea if limited to cases where protection would apply, i.e. if the protection policy would be kept as strict as it is now. I can see such an idea make sense when an article receives huge amounts of speculation, i.e. misplaced, good-faith edits. It would still not make sense when it's a target for vandalism because that would just create a huge backlog of vandalism-revisions that might not be flagged but still clutter the version history, so I doubt it could replace normal semi-protection (and shouldn't actually). Regards SoWhy 10:34, 5 January 2009 (UTC)

We might want to call this "flagged protection" to make clear that it falls under the protection policy. I agree that we will have to retain semi-protection as it is now for some cases; nobody wants to go through and flag good edits on George W. Bush. A structure of three parallel forms of protection will be clearest. Septentrionalis PMAnderson 16:37, 5 January 2009 (UTC)

Vandalism or not...

The only thing that's really ever bugged me with the whole FR thing is the notion that "an edit should be sited if not vandalism", but what about an edit that isn't, but you revert for another reason? Should it be sited and then reverted? Seems a bit of an extra pointless step. This is definitely a good proposal (and pretty much what I assumed FR would be for when implemented here), but I can kinda see a concern with this (not that it's all that different from now, as undo makes things so easy to mistake a vandalism revert with a non-one...) ♫ Melodia Chaconne ♫ (talk) 12:31, 5 January 2009 (UTC)

Actually I'm debating that issue myself as well. Obviously page blanking, adding offensive content, etc. can be easily ignored. It really depends on how the FR is implemented, if we can put a summary in a simliar fashion for edit summary which allows users to explain why the edit would of been reverted, then sighting and reverting would not be needed. It really depends on what the rest of the community wants to say about this. If it was me, I would rather have an option to reject a revision and explain the reason of rejection with a comment simliar to edit-summaries. The question is that if the FR-extension that is current availble supports this, and we might need to consult with the developers perhaps? Y. Ichiro (talk) 15:48, 5 January 2009 (UTC)

Yeah, you can add edit summaries when you site (check out the test at the lab). ♫ Melodia Chaconne ♫ (talk) 16:03, 5 January 2009 (UTC)

The sample config gives autoconfirmed an autoreview priv; so if you revert, the latest text will be sighted automatically. I think that's the point, that people won't let unsighted non-vandalism edits pile up. -Steve Sanbeg (talk) 22:02, 13 January 2009 (UTC)

Who reviews the performance of the Sighters to keep them honest? You *will* have abuse of this, like any system, so how do you keep them honest? Where will their performance stats be shown? If the don't sight x % of unsighted articles, will they lose the sighter-bit?MikeLieman (talk) 21:57, 25 January 2009 (UTC)

Cavils

This proposal does not really deal with flying attacks made on miscellaneous pages -- I would suggest that there should, in addition to "requested semi-protection" articles, that articles where an IP edit affects an article size substantially, contains certain marginal words (amazing how many vandals collectively have such small imaginations) or redirects an article be automatically "trapped" for review. Collect (talk) 14:19, 5 January 2009 (UTC)

Better to have a bot report them to a central station. Anons can merge articles or edit Seven dirty words, either of which would trigger protection under Collect's variant. Septentrionalis PMAnderson 16:37, 5 January 2009 (UTC)

The latter well ought to trigger a review, I would hope! As for "merges" by anons, I would hope they also should be reviewed -- a significant amoount of vandalism is improper merges and redirects. Collect (talk) 11:45, 6 January 2009 (UTC)

Problems

There are several problems with this proposal:

1. Significant number of autoconfirmed accounts are vandal-only accounts or socks of various banned users. If your proposal is implemented vandals and socks will be able to sight their own edits and, moreover, unsight revisions sighted by other users. This will make vandalism much harder to detect and much more harmful.
2. What to do if a user persistently abuses the reviewer permission? If this permission is hard coded into autoconfirmed user group, there will be no way to remove it. The only option that I as an administrator will have is to block this user indefinitely. Therefore implementation of this proposal will lead to increase in blocking. For instance, rollback can now be simply removed, which allows us to avoid unnecessary blocks.
3. Since FR can be considered semi-protection light many admins will be more willing to apply it in cases when they would deny semi-protection now. It is just human psychology, and no policy will prevent this from happening. So this may lead to gradual increase in use of FR until a large proportion of article is under them. The proposal contains no safeguards against creeping full scale implementation (after all we have 1600+ sysops!).

Ruslik (talk) 16:11, 5 January 2009 (UTC)

1. Vandals and socks can edit semi-protected articles now. This therefore is no change in the present situation.
2. There are two avenues of abuse. If he sights obvious vandalism persistently, then he is a vandal, and should be blocked. If he declines to sight good edits, then we will still be no worse than we are now: such edits would never have been made on a semi-protected article at all. Explain to him that sighting is intended only to stop obviously bad edits, sight the article yourself, and consider unprotecting it (since it is getting good anon edits).
   • This could be used as a WP:OWNership device; but it is no worse in that than semi-protection now is. All our methods of dealing with that still apply - and the anon has the further recourse of asking someone else to sight their edits. The owner could edit-war against that, but we want to block edit-warriors.
3. If this is extended further than is desirable, we can always simply convert all FR articles back to semi-protection and file unprotect requests. The considerable feeling against broad or long-lasting protections will be a significant defense. Septentrionalis PMAnderson 16:26, 5 January 2009 (UTC)

Edits of socks and vandals are patrolled now. However FR will replace patrolling. So when a vandal sights their edit this edit will be presumed good until somebody discovers that it is not. As said above vandals will be able to unsight edits of others.

Edit warring with the reviewer tool alone is perfectly possible. Two editors can sight their own edits and unsight edits of another editor. Such an edit war does not need to involve actual editing, it can consist entirely of abuse of the reviewer permission. The best solution in this case is to remove reviewer access, not to block. This is like with rollback, if it is used persistently in edit warring it is removed, but users are often not blocked.

I am also interested how are you going to "simply convert all FR articles back to semi-protection"? If all admins have tools they will use them. Ruslik (talk) 17:51, 5 January 2009 (UTC)

Has Ruslik read this proposal? It nowhere suggests that RCP be replaced; it offers admins a new tool to deal with persistent anon vandalism, and nothing more.

Of course edit warring with the revise tool alone is perfectly possible. Under this proposal, it's normal editing by autoconfirmed users. Autoconfirmed users can edit war on semi-protected articles now. The solution, as now, will be full protection.

How are we going to "simply convert all FR articles back to semi-protection" if it proves to be necessary? By changing those articles to semiprotection, and turning off FR. Simple. We don't have that many semi-protected articles that the conversion can't be done by hand, and this is the sort of one-pass activity bots were meant for. Septentrionalis PMAnderson 18:24, 5 January 2009 (UTC)

See Notes in http://www.mediawiki.org/wiki/Extension:FlaggedRevs. I must clarify that after bug16495 was fixed FR will not disable RCP over entire namespace, but RCP for 'flagged' articles will be disabled. As to full protection. Yes, it is possible. However why do we need to punish all editors? I think only offenders should lose their tools. Ruslik (talk) 19:01, 5 January 2009 (UTC)

No one suggested punishing anybody; if this proposal is adopted, and if it leads to runaway growth of protection, then it is feasible to turn it off. I don't think Ruslik's original worries that protection will explode are reasonable; but there is a contingency plan if they are. Septentrionalis PMAnderson 20:51, 5 January 2009 (UTC)

I have not even suggested we use the default MediaWiki extention for Flagged Revision as it is now yet. We might need some major modifications to the default extention. Let's say, the ability to change the reviewer permission that's limited to one specific article. If there's a really bad edit war going on article X by registered users, then an administrator should be able to elevate the reviewer status for article X to administrator group, effectively making it simliar to a full protection. It would also perhaps be helpful if we have edits that are sighted appear on RC as an edit so people with huggle can view the edits that have just been sighted. The ability to turn on the flag revision on the protection page would also be helpful since it's used in a simliar fashion to article protection, and it should be flexible as well. Although this might create some work for the devs. As for abuse, I do hope that when users are blocked they can't sight edits either? If needed, maybe create an option to block sightting prviliges on that account? Another option is to give reviewer permission in the same manner as autoconfirmed, but administrators can remove reviewer permission. Y. Ichiro (talk) 19:20, 5 January 2009 (UTC)

Good

This is definitely the best implementation proposal I've seen so far, since it is the only one that will result in a net increase in the openness of Wikipedia and it won't generate huge backlogs. One minor point: a handful of articles (Evolution is the obvious example) are under continuous attack from a banned user who is prepared to get around our current semi-protection feature. These articles either spend a lot of time fully protected or in a vandalised state. Would it be possible to use a form of "flagged revisions as protection" to assist here? Hut 8.5 18:50, 5 January 2009 (UTC)

FR can be used a substitute for full protection (but probably not for semi-protection). However this will only work, if reviewer access is not given to all autoconfirmed users. Ruslik (talk) 19:05, 5 January 2009 (UTC)

There are now 2,047 semi-protected mainspace articles. If not autoconfirmed, than what class of users will be sufficient to police these pages round the clock? (Example: NPP backlog :) ).NVO (talk) 20:16, 5 January 2009 (UTC)

More like 3,000. That's the number in the main cat, but it has several subcats. Septentrionalis PMAnderson 20:47, 5 January 2009 (UTC)

1600+ admins, 2200+ rollbackers and several thousands additional reviewers will be enough for merely 3000 articles. Ruslik (talk) 20:59, 5 January 2009 (UTC)

Certainly. We have 1,000 active admins, assuming they are willing to monitor three pages each (on average) it could be done without even involving non-admins (not that I'm proposing we should). And this is assuming we implement flagged revisions on every one of the 3,000 (which might not even be the case). Hut 8.5 21:09, 5 January 2009 (UTC)

When you start to restrict people from sighting their own changes, you are pretty much going against one of the fundemental philosophy in which Wikipedia was founded on, an encyclopedia that anyone can edit. People will start to get concerned about the fact that the edits will go through a cabal-like system, even if that will not be the case, but the perception is there. Even though it may sounds pretty reasonable at the moment, I'm not sure what majority of the people will think about having selected people on Wikipedia with an "elite" status, and these proposals have been repeated suggested in the past and rejected as far as I know. That's why auto-confirmed user with reviewer access is chosen here. However, if people start to see the need for this new access level, there will be a consensus to make this new access level avaible to editors as I imagine, but I don't know if there is that consensus now. As of now, I am neutral to this debate but I can see that some people will get very upset over the idea of having selected editors to sight changes. Y. Ichiro (talk) 08:07, 6 January 2009 (UTC)

For me, philosophical arguments are not very persuasive. I prefer practical arguments. Ruslik (talk) 22:26, 6 January 2009 (UTC)

I'm not trying to convince you of anything, I'm showing you why the community might not want to do that. In the end, it's the community that decides which kind of philosophy they want to live with, and if consensus feels that Wikipedia should be very open to editing, then it's up to the community to decide. Like I said, the consensus can change in the future. You can't simply ignore the philosophical ideas that the consensus has agreed to, and you can tell that there are significant opposition even to the idea of flagged revision just by looking at the polls right now because many people perceived flagged revision to be against the philosophical belief that Wikipedia was founded on, even if you do not buy into the philosophy that is agreed upon by the community, the idea of an encyclopedia that anyone can edit. I know the arguments I presented are very unpractical, but do you think you can convince the English Wikipedia community that your system will work in practice? If you can, then great, we can all live happily by it, if not, then you will eventually have to compromise to make something that everyone will agree to, and it may not be the most practical solution. Y. Ichiro (talk) 23:36, 6 January 2009 (UTC)

I'd suggest giving out "reviewer" status much the way we give out rollback status: any editor with a history of positive contributions to Wikipedia can have it for the asking. Likewise, any editor who abuses their "reviewer" status will have it revoked. --Carnildo (talk) 04:34, 7 January 2009 (UTC)

This is actually what is proposed for trials. Ruslik (talk) 09:59, 7 January 2009 (UTC)

Hmm just came accross this, the idea of having an encyclopedia that anyone can edit is not the same thing as an encyclopedia that any anonymous user can edit. In my view if this represents a move towards the eventual elimination of editing by anonymous users then it can only be a good thing. --Sf (talk) 18:32, 26 January 2009 (UTC)

No way. Anons are the backbone of Wikipedia. We are the surfers who see something awry and correct it. And, statistically, we are right far more often than we are wrong. We are sincere far more often than we are vandals. I support the idea that Wikipedia should not be a vehicle for libel, but I really hope that no-one here believes in an encylcopaedia that some animals can edit more than others. --78.148.83.181 (talk) 01:06, 27 January 2009 (UTC)

So you don't support (semi-)protection, which this proposal is designed to replace on some pages? ♫ Melodia Chaconne ♫ (talk) 01:26, 27 January 2009 (UTC)

Theoretically, I'd be in favour of the change, because it should reduce the number of articles I'm barred from editing (presumably, though, locking will still be needed to deal with disputes and edit wars (?)). I'd be a little nervous, though, about how responsibly the system will be operated. There will be a lot of edits to review, and some might take a view (wildly mistaken, I think) that IP edits are less likely to be worthwhile. Some editors might even start to reject them as a matter of course, to save time. Then there's the worry of mission creep - will we start to see all kinds of new and innovative reasons why pages should be flag-protected?

Some people will think I should just log in, and that erases the problem. But the circumstances under which I tend to edit Wikipedia (and I believe there are millions like me) is that if I see a bit of bad grammar or some other mistake that's easily rectified, I'll jump in. The extra few seconds it would take to log in will probably discourage me most of the time, particularly if all I want to do is add an apostrophe. I think the overall effect, if this became required, would be that WP would lose a large volume of good edits from users like me. I'd say I'm like one of the worms in the Wikigarden!

So I think there's a problem if users are developing the idea that anons are a problem that needs somehow dealing with. This would be wrong-headed (because, on balance, I think we are the opposite of a problem), and corrosive (because there's a risk of losing your worms). It's about attitde more than technology, IMO.

PS I'm the same person as 78.148.83.181, above. --78.144.183.215 (talk) 22:57, 27 January 2009 (UTC)

PPS These concerns are more worries than predictions, and things may turn out fine. Perhaps something to be watched during the trial phase, though. --78.144.183.215 (talk) 23:01, 27 January 2009 (UTC)

But why would you not "jump in an fix the grammer" with the FRs in place? ♫ Melodia Chaconne ♫ (talk) 23:15, 27 January 2009 (UTC)

Well, if the system started to not work so well from the point-of-view of an anon user, it could be about the degree of uncertainty that the change would be authorised. And since I'm (voluntarily) not part of that process and may not be sufficiently interested to ever check, I may never know if the change went ahead or why it didn't. Even if this uncertainty were unjustified, it might still be discouraging. Plus the instant satisfaction won't be there. --78.144.183.215 (talk) 00:34, 28 January 2009 (UTC) To repeat, though: I do think this is a good proposal and I'm in favour of a trial going ahead on the basis set out. I'm just slightly wondering whether flagging will be taken by people as a great way to be more restrictive (even if they're not consciously thinking of it like that). But perhaps the trial will provide a clear answer to that. --78.144.183.215 (talk) 00:48, 28 January 2009 (UTC)

Successive edits

Is there a technically robust way to flag / reject individual edits in a succession of edits by IPs? Consider the case where, say, three IPs have been editing the same article; you, as a reviewer, must sort through a dozen of overlapping edits. Some were unproductive but they cannot be undone.... the text as a whole, in its current form, is generally OK but a couple words must be deleted. NVO (talk) 20:09, 5 January 2009 (UTC)

... and if the technology precludes successive edits by IPs, does it mean that the three IPs from the above example will create three parallel versions of the article and someone has to decide which one will prevail? NVO (talk) 20:12, 5 January 2009 (UTC)

The current version of flagged rev only allows reviewer to review the most recent edit as far as I know. When you edit, it looks like that you will edit the version that was sent right before it regardless if it's sighted or not. You should check the live demonstration. I do not know what the consensus will be on en-wiki regarding this however, as this could change in the near future. Y. Ichiro (talk) 20:25, 5 January 2009 (UTC)

I could not make the live demo show the contents; all it did was display the title page. NVO (talk) 20:42, 5 January 2009 (UTC)

It is possible to review any revision and sight (or unsight if it has been already sighted) it. Ruslik (talk) 22:23, 6 January 2009 (UTC)

Semi and Full flagged protection

I concur that this is a good idea, and it would probably not attract so much opposition than other Flaggedrevs proposals. I believe though that we should keep classic semi-protection (even in long term), of course for non-content pages, and also because there are cases where short semi-protection would still be needed. For full flagged revisions, this could be used similarly as a downgraded full-protection and could also be used for disputes, etc. I had drafted something about that, see User:Cenarium/Flagged revisions/Confirmed. I proposed there that another usergroup, 'moderator', containing admins, be created, able to flag fully-flagged-protected articles, since the admin group may be too small. Cenarium (Talk) 14:36, 9 January 2009 (UTC)

Good idea

I think this is a good idea as well. I've copyedited the proposal, and clarified that it's not really something integrated into the protection form, but a separate interface (I guess it wouldn't be impossible to add it to the form, but it would be a lot of work for no benefit). I've also listed a suggested configuration below.

config moved to main proposal page Mr.Z-man 02:31, 12 January 2009 (UTC)

I haven't tested this extensively yet, it may need some changes. Mr.Z-man 01:32, 10 January 2009 (UTC)

Well, this may be acceptable (I tweaked the code a bit). Remaining issues are:

1. I would give 'validate' right to 'rollbackers' as well;
2. '$wgReviewCodes = array();' should probably be set to something;
3. '$wgFlaggedRevValues = 3;' I do not known the correct value. Documentation is vague (3 or 2?).

Ruslik (talk) 13:18, 10 January 2009 (UTC)

You can get rollback with a small number of edits and it isn't meant to signify community trust. Since the Full Flagged Protection part is meant to be used on articles subjected to heavy attacks from sockpuppeteers evading blocks I can see vandals working their way up to rollback in order to get the reviewer rights and make their vandalism visible. Hut 8.5 13:45, 10 January 2009 (UTC)

I don't think the rollback group is appropriate either. I proposed to use it as an alternative to full protection or blocks during disputes, so users have to be particularly trustworthy. We may create another group, moderators, if the admin group is too small. It would also mean that autopatrol should be deactivated for that level. Cenarium (Talk) 17:28, 10 January 2009 (UTC)

How many administrators are going to patrol these page? I will certainly not be one of them. My involvement usually ends when protect the page and/or block edit warriors. This proposal will create a lot of work for administrators. Ruslik (talk) 17:32, 10 January 2009 (UTC)

Not that much, and as I said, we can create another usergroup. In case of disputes, edits haven't to be immediately flagged, it's more like editprotected requests. If the edit is non-controversial, then flag, if not, then don't bother, and wait that there is consensus on the talk page for the given revision, then flag. Cenarium (Talk) 17:39, 10 January 2009 (UTC)

I agree the right shouldn't be given to rollbackers. If it does become too much work, another, more trusted, group can be created. As for ReviewCodes, that's not something we need to worry about for the proposal. Mr.Z-man 20:03, 10 January 2009 (UTC)

Should 'validate' be given to bots? Ruslik (talk) 08:12, 11 January 2009 (UTC)

Probably not, that wouldn't be of much use for them, and it's a high-level right, I'd say, like editprotected, which they don't have. If we create an additional user right, we can give it to a bot if needed. Cenarium (Talk) 18:24, 11 January 2009 (UTC)

Should Portal namespace be included? It may make sense. FLR have another feature—reader feedback. It may be interesting to known what readers actually think about all our articles. Ruslik (talk) 20:32, 11 January 2009 (UTC)

Its supposed to be an alternative to protection; how often do portals need to be protected? Mr.Z-man 02:15, 12 January 2009 (UTC)

I think this is an excellent idea. Surveying a page is far less drastic than semi-protection and would likely be as effective as the latter, possibly more so, since we wouldn't be entirely closing out good-faith users because some people are idiots. J.delanoy^gabs_adds 02:26, 18 January 2009 (UTC)

Great idea. I'm opposed to the other proposal for the Flagged Revisions "trial" but I'd definitely support this. - Rjd0060 (talk) 14:55, 24 January 2009 (UTC)

Awful idea

We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. We don't have enough people participating. DS (talk) 02:35, 12 January 2009 (UTC)

• • This proposal merely suggests replacing one system with another. Current protection methodology would require an administrator to handle the edits, while this method would actually widen the pool of potential editors. I think a lack of people is the least of our worries in this proposal. - Mgm|^(talk) 11:02, 13 January 2009 (UTC)
    • Yes, there's only about 4500 non-redirects with some form of protection, any autoconfirmed user can flag revisions on semi-protected ones, an din most cases protection will be temporary. If we don't have enough users to keep up with that, we're screwed regardless of FlaggedRevs. Mr.Z-man 23:15, 13 January 2009 (UTC)

autoconfirmed

It's easy for a vandal to register and become autoconfirmed. How does this proposal think such an event should be handled? It would make a semi-flagged protection useless, but contrary to the current system, it might be harder to discover it is happening because a supposedly trusted individual sighted the revision. Basically, the proposal allows vandals to sight their own revisions unless full flagged protection is implemented. -- Mgm|^(talk) 11:01, 13 January 2009 (UTC)

Actually, if there is a vandalism, and it was reverted, then the edit can't be sighted. Only the most recent edit made by anon IP / new users can be sighted. If a user was found to obviously only sighting vandal edits, then the user gets the same treatment as a vandal, perhaps with even less tolerance because it takes more effort to learn how to game the system and around 2-3 sights should be enough to warrant a block. But you have to be here at the right time in order to perform sighting vandalism because only vandalism that stays in the most recent revision have the potential to be sighted, once they are reverted, which most often they will be reverted in less than 1 minute, it's unsightable. Sight vandalism is actually much harder to perform and takes a lot more effort than simple vandalism, and if your vandalism is obvious, you have to sight the vandalism before User:ClueBot reverts it, and not even RC patroller who can revert vandalism in 10 seconds can beat ClueBot. Y. Ichiro (talk) 16:39, 13 January 2009 (UTC)

I agree that RC patrol would catch it, although many RC patrollers can beat ClueBot, the point remains that sight vandalism is harder and any would be caught by RC patrol.--Res2216firestar 22:33, 13 January 2009 (UTC)

It would be treated the same as any other case where it happens currently; block the user and if necessary, full-protect the page. Currently they don't even have to flag the vandal edit, they just have to make it. This presumes that autoconfirmed would become "more trusted" while this proposal wouldn't really give them the ability to do anything they can't currently do. Mr.Z-man 23:19, 13 January 2009 (UTC)

Actually any revision can be sighted (or unsighted), not only the most recent edits. Ruslik (talk) 20:25, 15 January 2009 (UTC)

balance flagging & protection

I've always thought of flagging as a form of protection, and that it should be used only as an alternative to, and result in a decrease in, traditional protection. It looks like the unsighting will allow autoconfirmeds to effectively revert war, so we'd need to make sure the protection & reversion policies are both updated, so it's clear this isn't a loophole in 3RR.

I think that full & semi flagged protection should work together, they way their current counterparts do now, but I think protection is better suited to some short-term uses; we shouldn't get rid of semi-protection, maybe just limit the time it can be used, i.e. 1 week max before unprotecting, and flagging if necessary. -Steve Sanbeg (talk) 22:26, 13 January 2009 (UTC)

Finalizing

Just wondering if there is still any unanswered questions left by this proposal before this is presented to the Wikipedian community and to be voted on perhaps. Y. Ichiro (talk) 19:52, 14 January 2009 (UTC)

What would this proposal do to the current protection system? Limit it? Work alongside it? Replace it? This is not a big issue for me, but to make this a full-formed proposal, that question should be answered in my opinion.--Res2216firestar 22:31, 14 January 2009 (UTC)

I would you view things like things:

For articles that would normally be semi protected, use flagged semi-protection, if this is still unmanageable, too much disruption, etc, (which would certainly be the case for some of those articles), use semi-protection.

For articles that would normally be fully protected, use flagged full-protection, if this is still unmanageable, use full protection. Cenarium (Talk) 17:15, 15 January 2009 (UTC)

Why?

I am not up-to-speed on what has clearly been a lengthy debate, but the request might benefit from a summary as to why this is a good idea. The method for fixing the problem is elaborated on, but what is the problem that this proposal is attempting to fix? It is apparently designed to "allow anonymous editors and new users to edit protected articles in a limited fashion", but for what reasons? I have no doubt there are such but the opening reads as if it is a proposal to allow a limited amount of additional vandalism, without any obvious benefits. Ben MacDui 10:10, 24 January 2009 (UTC)

Semi-protecting a page does reduce the amount of vandalism it receives, but it does also reduces the number of beneficial edits that it receives. The majority of new and unregistered users are not vandals. This is supposed to be the encyclopedia that anyone can edit, so suspending this principle is a big deal. This proposal would allow Wikipedia to get closer to it's guiding principle. Yes, people could take advantage of this to vandalise the page, but their vandalism would not be displayed to the general public and would only be seen by a few RC patrollers - why bother? Hut 8.5 11:37, 24 January 2009 (UTC)

That sounds like a decent summary, so unless I have missed something, the RfC might benefit from saying so. As it happens I am not at all sure I agree that this is a problem that needs fixing. A quick look at this morning's watchlist notes five anon edits. Three are vandals, one is a nice fix, and one is an uncited and poorly syntaxed edit, which may or may not be true. I'd say that's about average - but maybe I am unlucky. Semi-protection provides high profile pages with relief from endless vandalism and POV pushing, which can use up significant amounts of time better deployed elsewhere (at a time when the total number of editors appears to be in decline). There is nothing preventing anons from asking for a correction on a talk page, or from editing the vast number of unprotected articles. In short, I am not persuaded. Ben MacDui 12:00, 24 January 2009 (UTC)

The thing is, the editprotected process is either too obscure or too much of a hassle for anons (particularly if they just want to make a minor edit like typo fixes). It does deter these users. Flagged protection is a good solution for permanently protected articles, as it means that limitations can be lifted, and those articles really can become something that "anyone can edit". I believe that's what the proposal is heavily aimed at anyway. And of course, POV pushing would mean Full Flagged Protection, meaning that the POV pushers are locked out of making their controversial changes to that article, but every other user can continue to edit it, minimising disruption for everyone. --.:Alex:. 14:27, 24 January 2009 (UTC)

That's true, but there is another aspect to this which goes to the heart of the debate. Because flagged protection is a softer (more permissive) tool than semi-protection, it is likely that it will be employed more often. I think we should be upfront about this because it will happen anyway. In particular, part of the point of flagged revisions for its advocates (I am not one of them) is to provide greater protection for BLPs, so one can expect flagged protection being used more often on BLPs than semi-protection would be. The advantages of flagged protection over other implementations of flagged revisions are:

• It balances this slight increase in the number of protected pages by giving anons the freedom to edit them.
• It does this without introducing any new bureaucracy: any autoconfirmed user can sight a revision, and any admin can turn on or switch off flagged revisions for a given page.

Consequently it offers something to those editors who see the need for some sort of flagged revision tool, while addressing many (but not all) of the concerns of those opposing it. Geometry guy 14:40, 24 January 2009 (UTC)

Good point well made. Many want a blanket flagging for all BLP already. I think we would inevitably see a creeping spread of flagging to just about any article which receives vandalism. I believe these are to a large extent the articles on which, up until now, new editors make their first contributions. Thehalfone (talk) 13:34, 28 January 2009 (UTC)

Agreed that instruction creep is a bad thing - in my proposal, I've tried to limit this by constraining flagged protection to only function within the limits of existing policy whereas this page seems to be too open to extending the use of it to other pages. Of course, my proposal is an attempt at a compromise about BLPs and Flagged protection, and I know your views and mine on this issue are not congruent. Fully agree about preventing creep though. Fritzpoll (talk) 14:59, 28 January 2009 (UTC)

Review or autoreview for autoconfirmed users

There is still a little problem in letting autoconfirmed users reviewing articles, they won't necessarily know what it means, and what it implies, so this will lead to a comparatively high number of bad flaggings, especially in articles with a high level of vandalism. It would also introduce another subtlety in editing for them, while we should on the contrary make editing as easy as possible for inexperienced users. Of course autoreview should be automatically granted to them, which they generally won't notice. Overall, the majority of flaggings will be made by experienced users, who would normally be reviewers, so in term of backlog, giving reviewer rights to all autoconfirmed users won't change much. We could still make an auto promotion with higher requirements, and a rollback-like process for granting. There is also a good number of articles persistently targeted by sockpupetters, some have to be fully protected. A way to handle them would be to deactivate autoreview for autoconfirmed users there, so make an option of it, enabled by default. Thoughts ? Cenarium (Talk) 15:15, 24 January 2009 (UTC)

My concerns about this aspect of the packaging of permissions can be summarised by the following question: can we turn off someone's autoconfirmed status? Fritzpoll (talk) 15:17, 24 January 2009 (UTC)

Not as of now, though this has been discussed in relation with the abuse filter. In the proposed configuration, we could not remove reviewer rights from a problematic user. But we could simulate using an auto-promotion identical to autoconfirmed. That wouldn't address the above concerns though, and the autoreview rights could also be abused, so a possibility would be to create an autoreview rights with auto-promotion identical to autoconfirmed. Cenarium (Talk) 15:51, 24 January 2009 (UTC)

For the benefit of those visiting the feeler poll below and not au fait with the fine details, "autoreview" means (right?) that a revision is sighted (reviewed) automatically when a reviewer (in this case any autoconfirmed account) edits a flagged page where the previous version has also been reviewed (sighted). It is disabled when the previous version hasn't been sighted. Geometry guy 19:38, 24 January 2009 (UTC)

If it is not possible to turn off the ability to review in individual cases (that is if any autoconfirmed user has the ability to review), then this isn't flagged revisions any more. It's been watered down too much to be a good test. Reviewer is an ability to be given out with some thought, and to be taken away if misused. It needs at least much thought as giving out rollback, if not more. NOT automatically. Else I'll be arguing strongly that we should be blocking for inappropriate reviews. (Even if they were good faith, if there's any chance at all that the judgement is still skewed) ++Lar: t/c 02:24, 25 January 2009 (UTC)

Feeler poll

I am taking the liberity to close this poll early because I think we already have an idea what this proposal is missing. I think it's time we should be moving forward and start making changes to it as we see fit. This poll is generating an unexpected amount of drama, I think it is getting to the point where it is counterproductive, and people have lost the sense of direction of where we are going with FR. There are still a lot of specifics that have been left out in the dark that needs to be brought up, and I do not think it is time to dicuss that in a poll. Y. Ichiro (talk) 19:47, 25 January 2009 (UTC)

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

The proposal of Flagged protection seems to be generating far more interest and approval than using Flagged revisions on a wider subset of articles, and I think it would be beneficial just to see what the general feeling is towards this idea. This is not a poll to make any changes or anything of the sort. This poll is simply about whether you support or oppose (or are leaning towards either) the idea put forward by this proposal and whether you think it could be a viable solution, compromise, alternative to other proposed configurations or compliment to a wider implementation of Flagged revisions.

Also, I just think it would be best to mention to make sure you have read the proposal page before making a judgment here, as no doubt some users will waltz on in here without fully understanding what the proposal at hand is; which is to use a particular configuration of the Flagged revisions software in place of protection on some pages, to lift the limitations imposed by the protection system, and allow users and IPs to be able to edit those pages . ;) --.:Alex:. 15:18, 24 January 2009 (UTC)

Here is a link to the proposal, as some people are hyperlinked directly to this poll. -- Fuzheado | Talk 02:16, 25 January 2009 (UTC)

Support

1. Only method of flagged revisions so far that I would even consider supporting; edit-protection is a necessary evil that admittedly goes against the "anyone can edit" philosophy. Flagged protection is the only form of FR that has the chance of increasing an IP's editing capability. Sceptre ^(talk) 15:22, 24 January 2009 (UTC)

   Incidentally, I should emphasise that this does not indicate support of any slope into full flagged revisions implementation. Sceptre ^(talk) 15:49, 24 January 2009 (UTC)

   Provided the appropriate usergroups are held accountable to stay within the scope of the trial/implementation I don't think this will be a problem. After all, we have shown that many think semi-protecting all BLPs is a good idea, but noone does it because it violates our policies on protection Fritzpoll (talk) 15:52, 24 January 2009 (UTC)

   With the caveat that this needn't exclude other uses for the flagged revisions extension (which is how this system would work - see discussion below) that may arise over the course of subsequent discussions. Good because it allows people to edit where currently they are unable Fritzpoll (talk) 15:26, 24 January 2009 (UTC)

2. The only way we can use flagged revisions to open up Wikipedia for new and unregistered users, rather than restricting it. I've linked here from WP:CENT. Hut 8.5 15:38, 24 January 2009 (UTC)
3. Support a slightly modified version: with autoreview only (not review) for autoconfirmed users, as reviewing would be yet another subtlety for inexperienced users, it would be vastly ignored or misunderstood and lead to mis-flagging, while reviewers could handle the number of semi flag-protected articles. (see previous thread to discuss) Cenarium (Talk) 15:38, 24 January 2009 (UTC)
4. Yes, this makes the project *more* open, not less, so I support. My concern was that there would be creep and soon every article would have this, with a massive backlog of unsighted revisions. Actually, that was also a concern about semiprotection before it was implemented, and so far that's worked fine IMO because admins are accountable and don't protect things willy nilly. delldot ∇. 15:43, 24 January 2009 (UTC)
5. Yes, absolutely. I opposed Flagged Revisions both on the basis that in my view they were and are completely against Wikipedia's ethos and its motto. Semi-protection and protection, at least for the moment, are a necessary evil, and this, like delldot says, will only lead to making the project and it's pages more open, not less like Flagged Revisions would and/or will. This is not an alternative to Flagged Revisions, this is instead a highly superior and a highly intelligent idea, and one that is not only thinking with the project in mind, but also thinking about the overall benefits and the after effects, which I don't believe Flagged Revs is.
   
   As an aside, Yamamoto Ichiro, you might have just saved both myself and many others from having to say goodbye to Wikipedia because of the implementation of an unethical system. Hats off to you. — neuro^(talk) 15:53, 24 January 2009 (UTC)
6. Support. I wouldn't have voted in support of the FlaggedRevs trial if I knew this proposal existed. This proposal has all the best parts of Flagged Revisions and takes away the worst.Bsimmons666 (talk) 16:04, 24 January 2009 (UTC)

   Much more workable than other proposals. Mr.Z-man 16:46, 24 January 2009 (UTC)

7. If anything, then this. But only if restricted by the current WP:PROTECT so it will not be used more than protection is currently. SoWhy 16:56, 24 January 2009 (UTC)
8. Makes sense for this to be the first trial of flagged revs as I've suggested elsewhere. I can't imagine there being much of a problem with it and would support rolling out a trial asap. Other editors are going to want further applications of flagged revs and I imagine the odds are good that we'll have other trials in the end. It makes sense to start with this though, particularly since so many users (myself included) are wary of or outright opposed to a wider implementation of flagged revisions. Let's start with this fairly non-controversial version and see how it goes. In my view implementing flagged protection would neither preclude nor guarantee further trials/implementation of other aspects of flagged revisions. --Bigtimepeace | talk | contribs 17:00, 24 January 2009 (UTC)

   Addendum. In supporting this originally I was imagining (which I should have said) that we would tweak the specifics a bit, and thus need to point out that I have a problem (per Cenarium and others) with giving review status to all autoconfirmed users. It might make more sense to only give that to rollbackers initially and eventually to others as well, but in any case it doesn't make sense to give it to all autoconfirmed users for reasons discussed elsewhere on this page. I have a feeling we'll end up adjusting that if we test run flagged protection, and for me that is definitely required and indeed my support is essentially contingent on that. --Bigtimepeace | talk | contribs 16:36, 25 January 2009 (UTC)

9. Much less "hostile" towards anon editors than the earlier proposal. Though I opposed flagged revs, this is something I can agree with. Chamal ^talk 17:16, 24 January 2009 (UTC)
10. While I am wary of this proposal as a possible "foot in the door" for unacceptable implementations of FlaggedRevs, I wholeheartedly support it in and of itself as a method of using this software productively to increase the openness we so value. {{Nihiltres|talk|log}} 17:43, 24 January 2009 (UTC)
11. Support. This will spare me from having to leave the wiki due to a closing up. This would be an opening up. Jonathan321 (talk) 17:51, 24 January 2009 (UTC)
12. Strong support. While I'm usually a stark opponent of flagged revisions, I find this version quite useful. I'd go even further to implement this instead of semi-protection and implement a similar version (with administrators as reviewers) instead of full protection. I hate seeing full-protected articles as one can find things like a missing interwiki link or a spelling mistake and not be able to fix them. However, I despise the option of seeing this implemented en masse. Even compared to protection, FlaggedRevs are a very restrictive measure and are to be used sparingly. Admiral Norton ^(talk) 18:10, 24 January 2009 (UTC)
13. Strong support - This makes Wikipedia more open and makes it easier for anons to edit, while not losing any reliability. There is no reason I can think of to oppose. (Note: My support of this does not mean I oppose other implementations of flagged revisions) --Anonymous101 (talk) 18:45, 24 January 2009 (UTC)
14. Strong support - My proposed trial on the proposed trial page (Option 2) was for something of this nature. I'd definitely support this one, but nothing further at this moment. NuclearWarfare _(Talk) 19:45, 24 January 2009 (UTC)
15. Support. I supported the trial of flagged revisions, despite being wary of them, because there are so many ways to use the enhancement and we might find a beneficial one. In particular, I am against widespread usage, additional bureaucracy, the creation of new elites, and using it for quality review. But the flagged protection approach looks good to me. Indeed since flagged protection is softer than semiprotection, I foresee and favour it being used slightly more widely than semiprotection currently is, particularly on BLPs. In my unbiased opinion :), G'guy said it well earlier this month. It is good to see others coming to the same conclusions. :) Geometry guy 20:25, 24 January 2009 (UTC)
16. The most logical first use of FR, since these articles would be locked from editing otherwise, this actually makes them more open. --Falcorian ^(talk) 20:34, 24 January 2009 (UTC)
17. Strong SupportI agree that we need to trial and that any Flagging should be incremental and leave Wiki as open to all as possible and I believe this option may gain more consensus and more freedom with the added bonus of causeing less complications--Chaosdruid (talk) 21:24, 24 January 2009 (UTC)
18. Strongest possible Support This is a great proposal, that will allow IP and new editors to edit articles that would otherwise be semi or full-protected.--Res2216firestar 21:27, 24 January 2009 (UTC)
19. Support Definitely. PeterSymonds (talk) 21:30, 24 January 2009 (UTC)
20. Support. This is better than the previous proposals. --- RockMFR 21:32, 24 January 2009 (UTC)
21. Definitely an improvement from FlaggedRevs. RockManQ (talk) 21:33, 24 January 2009 (UTC)
22. Strong support. --MZMcBride (talk) 22:08, 24 January 2009 (UTC)
23. Support, could be a useful tool. Tim Vickers (talk) 22:58, 24 January 2009 (UTC)
24. Support This is a great compromise, and is a replacement for semi-protection that balances the ability to edit pages with the need for protection. Steven Walling (talk) 23:49, 24 January 2009 (UTC)
25. Support. Better than semi-protection: allows freedom to edit. This doesn't mean I don't support other configurations of Flagged Revisions too. ☺Coppertwig (talk) 01:40, 25 January 2009 (UTC)
26. Every support ever posted on Wikipedia, combined into a single Support This is the only version of Flagged Revisions that I would like to see implemented, so since were basically guaranteed to have Flagged Revisions, I will support this type very strongly. Until It Sleeps 02:26, 25 January 2009 (UTC)
27. Strong support - This is the only feasible way Flagged Revisions can be used. –Juliancolton ^{Tropical Cyclone} 02:41, 25 January 2009 (UTC)
28. I'm Mailer Diablo and I approve this message! (editors reviewing edits limited to rollbackers is also OK with me) - 03:07, 25 January 2009 (UTC)
29. This is much much better then protection and as long as it is enabled on only articles that fit the protection policy it makes WP more open, not less. FlaggedRevs in general would be a bad idea for Wikipedia but this and only this implementation would be useful Alexfusco⁵ 18:58, 25 January 2009 (UTC)
30. Strong support - A much better idea. Although I strongly oppose flagged revs in non-protected articles, this has a very practical side to it. It rather frees up the mainspace than closes it. —La Pianista ^(T•C) 04:15, 25 January 2009 (UTC)
31. Conditional support I would support something like this only if it took a bit more than being autoconfirmed to be a reviewer. I could see this as a good medium to use for article protection if everything is setup right. §hep • ^Talk 04:20, 25 January 2009 (UTC)
32. Support - maybe the bar for autoconfirmed should be raised by a little bit (to deter those Hagger vandals who make a couple edits and wait to get autoconfirmed)? —Ed 17 ^{(Talk / Contribs)} 05:46, 25 January 2009 (UTC)

    What about raising the bar so that the minimum level is someone with Rollback, rather than an Autoconfirmed user? Thor Malmjursson (talk) 06:10, 25 January 2009 (UTC)

33. We have to do something to deal with BLPs and libel, this will help curb it without locking out edits for weeks at a time. Granted, Davewild's neutral does bring up a good point, it may not be ultimately as effective, since it may not cover lesser-viewe BLPs well. Wizardman 05:56, 25 January 2009 (UTC)
34. Yay! Complete, irrevocable and total support. Utterly and without question a compromise which even I can agree with. I'm in :) Thor Malmjursson (talk) 06:07, 25 January 2009 (UTC)
35. Support for only this implementation of flagged revisions. The other suggestion is far too wide in scope, but this one is perfect. --Chasingsol^(talk) 09:09, 25 January 2009 (UTC)
36. Support I think that flagged revision should only be used as a replacement for semi-protection. If it works well for 3 months and there is no backlog, then we will think about flagged protection for all BLPs. Nicolas1981 (talk) 13:25, 25 January 2009 (UTC)
37. Support - I think this would be a good way to trial out flagged revisions here in a low scale form. I also think that in the long-term flagged protection would be helpful in complementing page protection, though I do not think it should fully replace it. The implementation of this might be best coupled with a raise in autoconfirm requirements, such as changing it to 7 days and 20 edits. Camaron | Chris (talk) 14:14, 25 January 2009 (UTC)
38. Support Flagged protection is strictly better than semi-protection, so of course it should be implemented. (I think flagged revisions should be used more widely, but this is a good place to start and see how things go.) --Tango (talk) 16:58, 25 January 2009 (UTC)
39. Support great alternative to Flagged Revisions and the current protection system. With a few tweaks (autoconfirmed=autoreview?), this will be a brilliant feature. --Patar knight - ^chat/_{contributions} 17:18, 25 January 2009 (UTC)
40. Support: This is by far, a better proposal than the other one (the "trial" one). - Rjd0060 (talk) 18:07, 25 January 2009 (UTC)

Oppose

1. A step down the slippery slope of flagged revisions. Flagged revisions need to be thrown out with all the other bad ideas that Wikipedia has had over the years. Anything that prevents people from editing will shut the door to potential new-users and garner bad press for the encyclopedia. Wikipedia needs to set its founding philosophy that anyone can edit above all else and take a leap of faith that people can work out their differences without Big Brother's intervention. This only adds more bloat and drama to the encyclopedia and allows much more back-door decisions to be made out of the community's eye. The revisions are also subjected to the biased whims of those who are allowed to approve revisions. In short, a really really really really (really) bad idea. Themfromspace (talk) 15:39, 24 January 2009 (UTC)

   Do you also oppose all use of semi-protection and full protection on articles? These prevent anons and newly registered editors from contributing as well, but are deemed necessary. Flagged Protection would allow them to contribute and expand the principle of "anyone can edit". Of course, if you oppose semi and full protection, that's a different matter :) Fritzpoll (talk) 15:41, 24 January 2009 (UTC)

   Yes I do, and yes it is a different matter entirely. Themfromspace (talk) 15:49, 24 January 2009 (UTC)

   Fair enough :) Fritzpoll (talk) 15:50, 24 January 2009 (UTC)

2. Utterly useless - and a major setback against proper flagged revisions I supported the BLP flagged protection with reservations. My reservations were to do with the fact that the major BLP problem is not simple and obvious vandalism but the deliberate insertion of falsehoods that look credible, and my concern was that the pressure on editors to review edits would lead to most BLP violations going unnoticed. However, that proposal was at least a step in the right direction. But letting any autoconfirmed editor review edits? What the hell? How does that help BLP violations? Any libeller only has to wait 3 days and he's off, meanwhile the community is lulled into a false sense of security. Do the other thing, don't do this.--Scott Mac (Doc) 23:41, 24 January 2009 (UTC)

   Off indeed, but with an identifiable account to block, rather than an IP range. Geometry guy 00:02, 25 January 2009 (UTC)

   Semi protection does that already. This offers nothing new to the libelled BLP subject, and by giving reviewing rights to all autoconformed, effectively destroys the possibility of using the flagged feature to offer help in future. The community will be satisfied it has "done something" even when that something is utterly useless. The previous suggestion offered little help, this offers none whatsoever, whilst being an effective spoiler for the other.--Scott Mac (Doc) 00:14, 25 January 2009 (UTC)

   First of all, nobody said that this is primarily aimed at BLP, this proposal is meant to solve the problem that exists in the current protection system, that anon edits are being locked out. Secondly, nobody suggested this is going to be the only flagged rev proposal. If there is a consensus that develops for another very different implementation of flagged revision (perhaps a BLP-oriented flagrev proposal), then it should be implemented alongside with this one, or even super-seed it if that's the case, depending on how consensus change in the future. This proposal is meant to be independent of other proposal flagrev that might come along. Y. Ichiro (talk) 00:23, 25 January 2009 (UTC)

   Em, read the comments in the support column. Whatever the intent (and the timing is suspect here), there are people seeing this as a "compromise" or "better version" of the previous. If this is implemented, it will be instead. It is not being viewed as independent.--Scott Mac (Doc) 00:28, 25 January 2009 (UTC)

   Even if people this is viewed as a "compromise" or a "better version" of the previous flagged rev today, it does not stop anyone from creating another flag-rev proposal sometime in the future. As I understand, consensus with flagrev, may change overtime if people starts to see a need for another different implementation. What stops people from making another BLP-oriented flagrev proposal in the future? If you are right, people will see a need for another flagrev implementation. Y. Ichiro (talk) 00:46, 25 January 2009 (UTC)

   Look at it this way. This is a lot less likely to fail miserably compared to a trial on 16% of articles. If the trial is a success, we can consider expanding the usage of FlaggedRevs. If a FlaggedRevs trial fails, what do you think the odds of ever getting support for FlaggedRevs in any form is? Mr.Z-man 01:26, 25 January 2009 (UTC)

   If a flagged revisions trial fails, then flagged revisions is a failure. There's a unholy alliance here of those saying "this is independent" and those (like you) saying its a compromise or a watered-down version. Yes this is more likely to pass - but it is also quite useless re the BLP problem, and a total distraction at best, and a spoiler at worse from the little but real help proper flagging would be. My opposition is absolute.--Scott Mac (Doc) 01:31, 25 January 2009 (UTC)

   Scott, I appreciate and share your concerns about BLPs. However, there is nothing unholy about seeking compromise in order to get around deadlock and move forward. This proposal is just an idea at the moment, an attempt to feel our way towards consensus in the true sense of something that many editors approve of, and most editors can live with. It isn't set in stone. For instance, would you support this proposal if: (1) it endorsed a wider use of flagged protection on BLPs than articles in general; and (2) reviewers were a smaller group, such as rollbackers? I think many of the supporters would too. Geometry guy 15:26, 25 January 2009 (UTC)

3. I could support this if it was intended to be in addition to the other implementation of flagged revisions. As I understand it, it's intended to supplant that, so I'm opposed. Sarcasticidealist (talk) 00:16, 25 January 2009 (UTC)

   This proposal is not exclusive of other forms of FlaggedRevs being implemented. {{Nihiltres|talk|log}} 00:26, 25 January 2009 (UTC)

   In practice it will be.--Scott Mac (Doc) 00:28, 25 January 2009 (UTC)

   That's an assumption. It could equally open people's minds to the feasibility of other, more restrictive forms of FlaggedRevs. {{Nihiltres|talk|log}} 00:42, 25 January 2009 (UTC)

   No it isn't. I am actually reading what those supporting this are saying. This is instead of that.--Scott Mac (Doc) 00:46, 25 January 2009 (UTC)

   Those are individual supports, where people who oppose widespread use of flagged-revision-by-default FlaggedRevs support this proposal. If those individual supports are enough to push a decent consensus here, then the other option is likely doomed anyway—this proposal will not affect that. On a procedural level, this proposal is not exclusive of other forms of FlaggedRevs. {{Nihiltres|talk|log}} 03:47, 25 January 2009 (UTC)

   For pity's sake; the poll EXPLICITLY says at the top "This poll is simply about whether you support or oppose (or are leaning towards either) the idea put forward by this proposal and whether you think it could be a viable solution, compromise or alternative to a wider implementation of Flagged revisions." How in poll form do you expect peoiple to say that no, this is not a viable compromise or alternative to wider implementation of flagged revisions? That's right, by opposing. 87.254.93.202 (talk) 14:02, 25 January 2009 (UTC)

4. Utterly unacceptable in the present form. Reviewer is a significant permission to be given out with significant review. Not automatically. Per Scott MacDonald I oppose ++Lar: t/c 02:26, 25 January 2009 (UTC)

   Note that de.wikipedia, en.wikibooks, pl.wikipedia, and others use some form of automatic granting for reviewer rights. Mr.Z-man 06:44, 25 January 2009 (UTC)

   Would you support this proposal if: (1) it endorsed a wider use of flagged protection on BLPs than articles in general; and (2) reviewers were a smaller group, such as rollbackers? Geometry guy 16:31, 25 January 2009 (UTC)

5. Oppose. No way. To say that limiting open editing will bring bad press is just completely ridiculous. What gives Wikipedia bad press is the shit we let slide by into the biographies of living people. It's irresponsible of us to continue with a system in which we fail to take every necessary precaution to protect the subject. How difficult is it to grasp that these are real people we maintain articles on. What brings us bad press is when we report that living people are dead, that heterosexuals are homosexuals, that upstanding citizens are pedophiles or terrorists. This does absolutely nothing to protect the subjects of our articles from determined vandals. They wait four days and they're in. An account to block, not an IP. Whoop. They can just create another account. We need a system that keeps this crap our of articles completely. If we can't responsibly maintain BLPs, we as a project need to stop forcing them on subjects that don't want them. It's reckless. لennavecia 05:43, 25 January 2009 (UTC)

   Just to clarify for myself, this proposal or the earlier one on flagged revs were not just about BLPs, were they? There was a survey on implementing flagged revs for BLPs but this was unrelated to the poll on implementing a trial wasn't it? Chamal ^talk 05:48, 25 January 2009 (UTC)

   My concern is with BLPs. Personally, I believe the project is beyond the point where open editing was useful. I'd support registered editing only, but that's a whole other proposal to take place in a frozen Hell. For the matter of realistic possibilities, there needs to some measure to protect BLPs. Any change on this project only comes after an exceedingly obscene amount of discussion and drama. The more narrow the scope, the easier it is to get anything approved. So, for that reason (along with a desire to see how it works before supporting wide implimentation), I don't care about flagging revisions on everything, just BLPs. لennavecia 07:09, 25 January 2009 (UTC)

   Fair points, Jennavecia. Would you support this proposal if: (1) it endorsed a wider use of flagged protection on BLPs than articles in general; and (2) reviewers were a smaller group, such as rollbackers? Geometry guy 14:35, 25 January 2009 (UTC)

   Every BLP should have the greatest amount of protection from vandals we have to offer. It is to a point now that it's just utterly ridiculous and unacceptable. SirFozzie and Lar have it exactly right. This project is consistently being dragged down by the vocal minority. God forbid we lose some IP editors who are saddened that their edits aren't immediately visible. God forbid we upset people who can't grasp that it is necessary to take care when dealing with BLPs. What the project should be worrying about is the established users who are packing up their shit and heading out because they're sick of dealing with the constant battles on this site. Admins and long-time editors aren't heading out because Wikipedia is heading in a good direction. They're running for the hills because the children and the editors lacking clue are taking over. We're more concerned about what editor has "personally attacked" another editor than we are about what libel is sitting unnoticed in our BLPs of people who matter more than the teenager who got his feelings hurt by another editor on his talk page. Our stupid civility policy is invoked more than our BLP policy. It's shameful, ridiculous and pathetic. لennavecia 18:06, 25 January 2009 (UTC)

   I don't disagree with this impassioned statement, but I also don't see how it moves the discussion forwards. You also haven't answered my question. If we can't find compromises nothing will get done about these serious problems. Could you answer the question, pretty please? Geometry guy 19:12, 25 January 2009 (UTC)

   I too understand where Jennavecia is coming from on that front, but I do have to agree with Geometry Guy. I'm seeing a lot of "No way, Jose" talk on this issue, but then nothing is being suggested in its place (this isn't referring to you Jennavecia, just a general observation of the whole mess that happens to go along with what Geometry Guy is saying). It's quite frustrating when there's a group of people who will just say "no" to everything, but not attempt to find any form of compromise or solution. Jimbo is right; there's too much FUD, flip-flopping and confusion. I almost wish I had never started this dicussion, because it's completely misinterpreted an enlightening proposal that should be paving the way for innovation, not stagnation. That's why I'm done with this. My brain hurts. --.:Alex:. 19:37, 25 January 2009 (UTC)

   Flagged revisions on all BLPs which hold edits by any users who do not have rollback. But we know this isn't going to happen, and I'm tired of fighting losing battles while in the majority on this site. I'm over it, and I'm out. لennavecia 05:39, 26 January 2009 (UTC)

6. Oppose, per Scott, Lar, et al. It's nowhere near strong enough and, in practice, is targeted to supplant Flagged Revisions. I've seen far too much sneaky BLP issues over the years here and as an oversighter on the project, have a view on egregious BLP violations and sneaky vandalism that tends towards more protection of BLPs that this will afford. Sorry - it's simply not enough - Alison ^❤ 07:37, 25 January 2009 (UTC)
7. Combines the worst aspects of both FR and semi-protection; it's complicated to request, then requires people to patrol these articles, while still making it reasonably easy for people to have sleeper accounts to flag this stuff and being under a small range of articles. Absolutely terrible and in no way a suitable replacement for either FR or semi-protection. Would also entail a massive delay while it's actually coded. Tombomp (talk/contribs) 08:50, 25 January 2009 (UTC)

   Noone is /required/ to do anything on WP. ♫ Melodia Chaconne ♫ (talk) 12:27, 25 January 2009 (UTC)

   No extra coding is required. The proposed configuration on the proposal page should be enough. All that will be needed is a few changes to system messages, but that would be required with any configuration other than the software default. And, how is this any more complicated to request than semiprotection is now? Mr.Z-man 17:23, 25 January 2009 (UTC)

8. Hell No. This is a backdoor attempt to kill Flagged Revisions by delay. I see the same folks who are screaming to Jimbo that "NO! You can't do that! That's not the WikiWay!", so I'm going to call a Spade a Spade here. And to say that this will make us look bad in the press is asinine. Right now, we're getting killed in the press (and public opinion, you know, the guys that are our audience) because time after time, Wikipedia is used to defame actual, living people. I know I'm a hardliner on this, and this will rub people the wrong way, but all the "Wiki"-fanatics who want something "Anyone can edit all the time" I cordially invite you to create "WikiWorld". Leave the Encyclopedia to folks who actually have a conscience about this. SirFozzie (talk) 08:59, 25 January 2009 (UTC)

   I find your opposition lacks a sufficient amount of bad faith. Surely you can insert a bit more? --MZMcBride (talk) 09:03, 25 January 2009 (UTC)

   I find the opposition (to the general idea of implementing flagged revisions), and support of this watered down perversion of the idea, lacks a sufficient amount of clue. How's that? No, seriously, accusing others of bad faith is a mug's game. You're smarter than that. ++Lar: t/c 15:14, 25 January 2009 (UTC)

   If you really wish, sure. But remember, you asked for it!. The problem with Wikipedia, (other then the problems with BLP's) is that the "Vocal Minority" can stonewall anything these days. Scream loud enough and long enough, and nothing can ever happen to change Wikipedia for the better, because "There's no consensus for it". Well, the vocal minority don't need consensus. All they need to do is "Just Say No" long enough, and nothing ever will change. And the term Consensus has a different meaning on Wikipedia these days. Apparently, you need 75% plus to have consensus. I'm surprised 75% of people can agree that Barack Obama is the President of the United States. It gives the inventive to the vocal minority to never seek consensus. That didn't work in this case, because Jimbo made a tough call... the RIGHT call, the moral call, so several folks are casting about for any way to kill it or to neuter it. They screamed about how this makes us look bad to the press, that "20% of our editors will leave Wikipedia because their edits won't be seen by every Tom Dick and Harry that wanders by". This is just the latest tactic. SirFozzie (talk) 09:15, 25 January 2009 (UTC)

   With all due respect, when you state the other implementation of Flagged Revisions as being "the RIGHT call", that is your opinion alone, nothing more. To summarily dismiss the concerns of so many other editors, many of which have spent numerous hours discussing and agonizing over the best way to deal with the BLP issue, is an enormous helping of bad faith on your part. Wikipedia survives on everybody's contributions, even when we disagree. Compromise and diplomacy are the best way forward. Many of us are not comfortable with the proposed implementation of Flagged Revisions, enough of us that consensus is not reached. We discussed this in good faith with Jimbo, and he has also put his approval behind THIS proposal too. While the implementation may not be dissimilar between the two, it is a compromise that finds more approval between those who previously opposed and allows the primary concerns regarding BLP's to be met. This was discussed in good faith, and not out of malice. --Chasingsol^(talk) 09:36, 25 January 2009 (UTC)

   But what's wrong with "killing" the flagged revisions if there is a better alternative, something that more people can agree with? And btw, it's no secret that a lot of people would be happy to "kill" it, looking at the poll results. So your ideas on why it shouldn't be killed would be welcome. I'm still confused about this BLP thing - isn't that a different thing altogether and related directly neither to flagged revisions nor protection? Chamal ^talk 09:42, 25 January 2009 (UTC)

   "More people can agree with" does not necessarily == "better" unless mob rule is what you are going for here. This alternative is worse, not better. Lead, follow, or get out of the way. ++Lar: t/c 15:14, 25 January 2009 (UTC)

   How is that comment possibly helpful Lar? Seriously, how? You imply that someone might be in favor of mob rule (when no one has said anything remotely like that), and then essentially say "come over to my way of thinking on this or stop talking." The person who originally said "Lead, follow, or get out of the way" was actually a bit more tolerant of dissent (he was a rather famous dissenter himself), and I think you might need to take a step back and realize the effect comments like yours can have on an open discussion like this one. --Bigtimepeace | talk | contribs 15:53, 25 January 2009 (UTC)

   This proposal is so badly flawed that I'm just calling a spade a WP:SPADE. (I mean, really... anyone that's autoconfirmed can flag revisions as good? That takes 4 days and 10 edits, or did. Why bother? Grawp has plenty of sleepers ready to go to play havoc. Have the proponents actually thought this proposal through??? Or are they trying to Embrace, extend, and extinguish it? I'd prefer to think not.... but if not what is the explanation? cluelessness? I'm left with no good alternative if I pussyfoot around here) Sometimes compromise leads to a worse solution than just saying no. So, I think "lead, follow or get out of the way" is extremely apt here. Despite the fact that it steps on some toes, which really isn't my style, and which I regret, it's come to that. If the net result is people are pissed at me but they snap out of thinking this is a good proposal, maybe I measure it worth the cost. ++Lar: t/c 16:12, 25 January 2009 (UTC)

   I agree with you about the problem with autoconfirmed users and reviewer rights, and that is I think a very valid reason to oppose. But that issue (which is a bit esoteric even to experienced users, so there is some element of "cluelessness" involved for some who just don't get all the specifics of how flagging works - hard to blame folks for that) is being discussed elsewhere on this page. I think we might need an alternative proposal to address this issue and then maybe more folks could get on board with it. I'm actually going to adjust my support to note that I have a problem with giving review status to all autoconfirmed users and that we need to tweak it to deal with that. And I really think your typical "Lar style" is more effective than the toe-stepping. It's certainly worked on me on as a reader of your comments on a number of occasions, and I think you can draw attention to flaws in this proposal and seek a better alternative without going into a minor angry mastodon mode. But then again you got my attention so maybe I'm wrong! --Bigtimepeace | talk | contribs 16:29, 25 January 2009 (UTC)

   Why so angry, Lar? There is no need to get pissed at me, I just asked a question so that I can clarify the situation for myself. I just noticed this proposal very recently and thought it was a good idea. Obviously there are people who think it's not, and I want to see if there is something that I have missed or haven't taken into consideration. And as for deciding on whether this proposal or any earlier one was good or not is something that is done by the whole community, I think. Chamal ^talk 16:52, 25 January 2009 (UTC)

9. Oppose Significantly watered down version of flagged revs, I might've supported this if the scope had been to cover all BLPs but in this format it will be useless. An additional reason is some of favourite vandals will get some accounts to autoconfirmed status and start messing around with the sighting tool. Unfortunately, in reality, this will replace any plans to protect all BLPs using flagged revs. GDonato (talk) 11:16, 25 January 2009 (UTC)
10. Good God no, per Tombomp. Giggy (talk) 11:59, 25 January 2009 (UTC)
11. Oppose as liability for Wikipedia and approver(s) could significantly increase if Wikipedia were to be considered a publisher rather than a distributor. Even if less libelous content were to be displayed - some will inevitably get through the net, and that which does could be far more serious. -- samj _in^out 13:16, 25 January 2009 (UTC)
12. In spite of the replies to my "thickie admin" query below, it's quite apparent from many of the other remarks on this page that this is seen as a replacement for German-esque flagged revisions to protect BLPs. It may not have been the intent of the original authors but this is now a spoiler not a sincere proposal. Furthermore, I agree with SirFozzie on the moral responsibility issue, except that I think he is being too restrained. It is best I do not describe the contempt with which I regard those who would filibuster while real people burn. CIreland (talk) 13:33, 25 January 2009 (UTC)

    Or oppose a step in the right direction because it isn't big enough? Geometry guy 14:26, 25 January 2009 (UTC)

    I'm sorry, but how can you possibly say "this is now a spoiler not a sincere proposal?" That comment exhibits a remarkable amount of bad faith, and I'm getting quite sick of seeing that from both sides on this issue. If you want something to happen with BLPs, as do I, a little less demonization of those who have a different view than you is probably advisable. I support this (as a trial, everyone seems to be forgetting that and assuming if this goes through we'll never discuss flagged revs again) and am also open to trials and possibly full implementation on BLPs or some portion thereof. I just think we should move in relatively small steps and that this is a good proposal to get a sense of how flagged revisions work in practice. Should that position invite your contempt? Am I or others merely "filibustering" "while real people burn" because we want to start with something other than full-on implementation on all BLPs? Is such hyperbolic language (and it is hyperbolic, as far as I know no one has ever been set on fire because of Wikipedia) ever helpful in these kind of debates? I am extremely concerned about the BLP problem and would resent anyone who says otherwise. I'd also remind you that Jimbo on his talk page specifically asked for further discussion/compromise possibilities on flagged revs which is what this is supposed to be (he also viewed it as a possible "way forward" and something he would be behind), so if you really look at this as immoral filibustering you might want to take it up with him. Not everyone, or even most, of the people who want to try this are bad people. One thing is guaranteed. If we keep attacking the good faith and indeed morality of those we disagree with we'll never get anything done on the BLP issue. --Bigtimepeace | talk | contribs 14:02, 25 January 2009 (UTC)

13. Moved to oppose - when I supported, it was on the assumption that this implementation of Flagged Revisions was one of several that could be used. Given that people in the support section seem to believe fervently that this is not Flagged Revisions, they clearly view this as an alternative to all other possible uses of the software extension. As a result, I can't support on this basis. Fritzpoll (talk) 15:06, 25 January 2009 (UTC)

    I promise I'll stop bugging oppose voters after this, but I'm really having trouble understanding this position and am wondering in all seriousness if you can clarify it for me. Of course you were correct in your initial assumption that this implementation is "one of several that could be used." Any of the supporters who think that, if we go with this, we automatically will never have any other form of flagged revisions are simply wrong. You, or anyone else, can propose a different trial implementation and if it garnered enough support we would do it. This is just indisputable (it's not like anyone could stop you or anything). So what I don't understand is why some folks are voting oppose because they think that some editors (and it is only some) in the support section take the (mistaken) view that this is going to be the end of the line as far as flagged revs. Does voting against this proposal somehow make it easier to get a more expansive implementation passed? Seems unlikely, since the folks in the support section you mention will oppose a wider implementation no matter what happens here.

    So in point of fact isn't it the case that you are voting oppose not on the question of whether testing to see if replacing semi-protection with flagged protection is a good idea (which is all we are talking about, and which you initially seemed to think was a good idea), but rather because you think that if this passes it will somehow aid those opposing a wider implementation of flagged revisions? I guess I just don't see the logic in that (again, their opposition presumably will not change regardless of the result here), but I might be missing something and am genuinely trying to understand your view so I'm wondering if you can explain your thinking a bit more. --Bigtimepeace | talk | contribs 15:56, 25 January 2009 (UTC)

    Your analysis is predicated on the idea that voting is the only way to get flagged revisions implemented. I believe you are incorrect, this project is not a democracy. But if you are correct, then this proposal needs to be scuppered because it is a proposal that is standing in the way of a good one. This proposal is fundamentally flawed, it won't work, it will make things worse, but it lets some folk that haven't thought that through feel like they "did something". ++Lar: t/c 16:17, 25 January 2009 (UTC)

    I know Wikipedia is not a democracy, obviously, as I've been here awhile. My analysis is predicated on the idea that some relative consensus is the best way to get flagged revisions implemented and I'm surprised anyone would suggest otherwise. But I must ask, what is the "good" proposal which this one is standing in the way of? I really mean that - I don't know what proposal you are referring to. We've had some polls about flagged revs, but I know of no specific proposal being discussed besides this one as to how to implement a trial. Could you point me to the proposal you are referring to? Obviously I mean something more specific than "turn on flagged revs encyclopedia wide" since there are a lot of particulars to work out.--Bigtimepeace | talk | contribs 16:57, 25 January 2009 (UTC)

    With regard to Fritzpoll's concern about some people mixing up flagged revs and flagged protection as completely different things, I guess that's mostly my fault. I used the words to try and show the difference, but it might have seemed like I was saying that they were completely different. Just my stupidity :) Chamal ^talk 16:31, 25 January 2009 (UTC)

    Largely, Lar reflects my opinions here. Additionally I feel that if people don't think that this is Flagged Revisions, they will automatically oppose further trials of it because we "already have flagged protection in preference to FlaggedRevs". I can't be a party to letting Wikipedia tie itself in knots this way. The fear, uncertainty and doubt has to end somewhere, and that's only by people actually taking the time to understand what they're voting on. Fritzpoll (talk) 17:11, 25 January 2009 (UTC)

    It's simply a possible configuration that could be used as either an alternative or a compliment to Flagged Revisions. FR opposition may and probably will support it as a replacement to the proposed permanent usage of this on articles (Jimbo has called for these people to come up with possible compromises), yes they prefer such a compromise as an alternative; but others may support it as a first step or a system to work in conjunction with FR. The problem is, everyone is going too deep into this, when this is merely a feeler poll. An exact specified usage for such systems are long way off from being determined. We're merely looking at possible configurations and uses and whether they would actually be viable or not. What is used in the end (if anything) obviously remains to be seen. I will make this more clear above. Yes, I now know what I missed, and now I'm tired, confused and... meh. --.:Alex:. 17:56, 25 January 2009 (UTC)

14. No, this is a pointless compromise that would eviscerate the BLP protection that FR offers. You can say that this wouldn't be the end (at least for the near future) of possible FR implementations, but it reality it would be. RxS (talk) 16:24, 25 January 2009 (UTC)
15. Moved from support. Looks like this is just yet another divisive bitch-fest we don't need. Mr.Z-man 18:31, 25 January 2009 (UTC)

    I don't understand how switching from support to oppose is less divisive. Can you clarify? Geometry guy 19:17, 25 January 2009 (UTC)

16. I just don't think the problem this is trying to fix is a problem at all. I honestly don't mind that a tiny fraction of all articles are protected from the inevitable vandalism they attract and putting a huge amount of effort into turning 99.9% of articles that can be edited by anyone into 100% doesn't seem to me to be time well spent. I'm open to being persuaded, but I just don't see the point. By all means trial it for BLP articles if there is strong feeling amongst editors of the same it would be a good idea. I generally avoid 'em myself. Ben MacDui 19:04, 25 January 2009 (UTC)
17. Unacceptable, as it doesn't address the BLP problem at all. We're not doing this for technical kicks. Cool Hand Luke 19:17, 25 January 2009 (UTC)

Neutral

1. I am hesitant to support this as although I support flagged revisions this proposal does nothing for the area where I particularly think flagged revisions would do the most good on - less watched and edited BLPs. On articles such as this one where clear vandalism was there for 5 days in December visible to everyone before it was spotted elsewhere and it was reverted. This proposal only applies to articles where there is heavy vandalism and so I cannot support this as an alternative to flagged revisions. There is nothing here that I fundamentally oppose as it would be a good way of opening up some semi-protected aricles which I think is great, however I think this would be seen as an alternative to flagged revisions and thus delay/stop flagged revisions on BLPs which I think we do need. I have also have a bit of a concern that this makes it too likely that vandals could get autoconfirmed and then start flagging vandalism/libel which would be a PR nightmare for wikipedia. Davewild (talk) 17:23, 24 January 2009 (UTC)
2. I do not think that granting 'review' and 'autoreview' review rights to all autoconfirmed users is a good idea. After such right are granted it will be impossible to take them away, and all autoconfirmed accounts including socks of vandals will be able to review and sight any revision they want. I do not think it is reasonable. I will do little to reduce vandalism or open more page for editing, but will lead to increase in blocking (because 'review' and 'autoreview' rights will be impossible to remove, the only option will be to block problemetic users). Ruslik (talk) 17:38, 24 January 2009 (UTC)

That does bring forth an interesting technical question to anyone who might know the answer; if all autoconfirmed users were given the reviewer flag, then can this flag be removed or disabled from individual users via some sort of exemption list? --.:Alex:. 17:43, 24 January 2009 (UTC)

Yes, that would be much more useful than granting the rights to a small pool of users. While I wouldn't be affected anyway, I'd hate to have to keep an eye on tons of minor changes when I have better things to do here. Quis custodiet ipsos custodes is a principle that is here usually overrated by a very large degree. Admiral Norton ^(talk) 18:21, 24 January 2009 (UTC)

This relates to 'autoreview or reivew', see below, we could remove the rights by simulating autoconfirmed status using an auto-promotion to reviewer status, but it wouldn't help the problems I mentioned below. Good-faith editors would have those rights removed because of misuse ('I made a good edits, I flag'), and autoreview would also be removed, thus destroying the purpose of the proposal. We shouldn't impose to editors the understanding of the relatively complex review process to allow them to edit would-be semi-protected pages. While if we give autoreview only, most concerns are alleviated. (see below) Cenarium (Talk) 18:33, 24 January 2009 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Discussion

Hate to do this, but this is Flagged Revisions, just applied to a small subset of articles. FlaggedRevs is a technical bit of software - how it is used is a different question. This appears to have been something not widely understood by voters on both sides. Fritzpoll (talk) 15:22, 24 January 2009 (UTC)

Perhaps I should make myself more specific? I just meant that some users will probably see "flagged", go red and oppose without realising that this is actually a spin on the software implementation and not the exact same proposal as the others. --.:Alex:. 15:28, 24 January 2009 (UTC)

I'm not aware that we have discussed any other proposals as yet :) I see what you mean, but yes, I'd just restate the general thrust of what this feature does, and try to avoid connecting it to the recent divisive poll that caused a lot of confusion about what it was asking Fritzpoll (talk) 15:30, 24 January 2009 (UTC)

Ah, I see. How's this? I removed any mention of aforementioned poll and reiterated the proposal in a nutshell. Otherwise, just edit that part yourself if it's not suitable enough. --.:Alex:. 16:02, 24 January 2009 (UTC)

When we kick out semi-protection, this would actually be less restrictive than the current system. I believe the security measures on Wikipedia are detrimentively high already and this would, unlike the infamous FlaggedRevisions proposal, actually lower them. Admiral Norton ^(talk) 18:24, 24 January 2009 (UTC)

Well, except, as I say, this is FlaggedRevisions and needs the software that the "infamous" poll was asking to install. The recent poll was not to flag any articles, just to install the software required for proposals like these! :) Fritzpoll (talk) 22:54, 24 January 2009 (UTC)

Indeed, all this is is a proposal for a specific trial of FlaggedRevisions, just like the last poll decided we should do. I don't get why people are calling this an "alternative" to FlaggedRevisions - perhaps they didn't realise what they were voting vote for/against in the last poll? --Tango (talk) 17:59, 25 January 2009 (UTC)

Yes, you are absolutely right, and I should have made that much more clear at the top. I have changed it so it refers to this proposal as a possible alternative for other proposed configurations and wider uses of FlaggedRevisions and not a replacement for the software feature itself. --.:Alex:. 18:06, 25 January 2009 (UTC)

Review or autoreview

We need to discuss whether we should give autoreview and review, or autoreview only to autoconfirmed users. I think only autoreview should be given to autoconfirmed users, as 'review' will puzzle inexperienced users, lead to bad mistakes, example: an IP makes a bad edit to a page, one minute later, an autoconfirmed user edits constructively the page, and having little understanding of Flaggedrevs, flags the new revision in complete good faith... Since this is intended for would-be semi-protected pages, this is bound to happen a lot, and we would have no way to remove reviewing rights for the user, except if we simulate autoconfirmed status with an auto-promotion, but even so, we would be forced to remove the 'autoreview' rights also for the well-intended user... So this would destroy the good intentions of the proposal. In the same time, most edits will be automatically reviewed, so it shouldn't add much to the backlog if we use a reviewer usergroup and give autoreview to autoconfirmed users. Cenarium (Talk) 18:26, 24 January 2009 (UTC)

I think I agree with your thinking on this Cenarium, but would you be willing to explain a bit what is meant by autoreview, review, and autoconfirmed users for the sake of editors weighing in here? You obviously have a very good handle on the technical details, but I think part of what's complicated about flagged revs is that a lot of other editors do not. I agree we absolutely need to figure our what to do about this issue and there seem to me some obvious problems with giving review status to autoconfirmed users as you suggest, but we need to make sure everyone understands what we are talking about (there's been so much discussion about flagged revs all over the place, folks can be forgiven for missing some of the technical specifics). --Bigtimepeace | talk | contribs 19:04, 24 January 2009 (UTC)

(From an earlier comment.) I guess "autoreview" means that a revision is sighted automatically when a reviewer (in this proposal any autoconfirmed account) edits a flagged page. I'm in favour of that approach as it makes sighting more invisible to users. Geometry guy 19:26, 24 January 2009 (UTC)

I'm striking because I misunderstood "autoreview". It only applies when the previous revision was sighted. Geometry guy 19:47, 24 January 2009 (UTC)

I would oppose this. People flagging revisions without looking at the diff of all of them or reading through the page need a slap upside the head, and if they keep doing it, a block for disruption, as we would do in any similar circumstance now. The point of this is to create an alternative to semi-protection. If people who can edit semiprotected pages can't approve other people's edits, and we need an additional user group or admins to do it, its starting to significantly stray from the intent of the proposal. Mr.Z-man 19:28, 24 January 2009 (UTC)

I think Cenarium's point is that new editors who would be "autoconfirmed" cannot realistically be expected to understand what's up with flagged revisions, and they should hardly be punished for that lack of understanding as you describe above and as they perhaps would have to be if they had "review" status. Think of how it works now. If a vandal makes an edit and then someone else comes along and does something constructive without reverting the previous edit, we do not punish the second person for missing the vandal edit. But as I said above I think we need to first have a clear understanding of these terms before we commence debating about them. I think I basically get it but don't want to misrepresent anything so I'd like Cenarium or someone else who has spent more time with this stuff to explain it thoroughly and in an easy-to-understand-for-non-techies fashion. --Bigtimepeace | talk | contribs 19:40, 24 January 2009 (UTC)

Do you really expect that user who made only 20–30 edits will be aware of the policy? They will simply see a new button and use it (in good faith) without checking anything (most of them at least). Of course, you can block them, but this will look like biting newbies. My opinion is that this is a poor alternative to semi-protection, because it is useless. Ruslik (talk) 19:49, 24 January 2009 (UTC)

No editor should be punished for making a good faith mistake. That does not necessarily mean they should be denied the opportunity to contribute and (yes) make good faith mistakes. My understanding is that when a flagged page is edited and the current revision differs from the displayed revision, then editors are presented with a diff. I trust the software will make it clear to the editor why they are being presented with a diff. I think for the majority of users, we can trust them to look at that diff before they save their edit. If it were possible, I think there is even a case to be made that autoreview should always happen when an autoconfirmed account edits a flagged page: no new button to click. If a user regularly (and in good faith) fails to check the diff, they should be advised on their talk page, not blocked. Geometry guy 19:57, 24 January 2009 (UTC)

They aren't being punished for a good faith mistake. Read my comment again. Its not like this doesn't have parallels in current processes. If they do it once, they get a friendly notice. If they do it repeatedly after getting several notices, we no longer AGF. Mr.Z-man 22:13, 24 January 2009 (UTC)

In reply to Ruslik (I had a couple of ec's), users with only 20 or 30 edits will be unaware of most of our policies. They will add original research, non-neutral material, unsourced opinion, and whole load of other policy violations. Accidentally sighting a vandalized revision is a relatively minor misunderstanding of policy in comparison. As I say above, I would hope the software would make it abundantly clear to editors when there is a difference between revisions, so they wouldn't need to know about the policy. Geometry guy 20:04, 24 January 2009 (UTC)

Autoreview means that when a user edits a semi-flag-protected page and when the previous version is flagged, the new version is automatically flagged. Review means that the user can review revisions, it will add lots of review links, a box at the bottom of articles, etc. A problem of Wikipedia is that editing is too complicated for new contributors (a group has been appointed by the WMF to simplify the editing interface, this made the news), this would make it worse for those articles, and it would also complicate contribs, watchlists, etc. New contributors should not be held responsible to review edits, this task is too demanding. I'd fear that it may even deter some contributors, especially if they are blocked for 'abuse' or have their autoconfirmed or autoreview rights removed (since they are bundled with review if we don't add another usergoup). I was originally completely supportive of this proposal but this now strikes me as a major flaw.

In response to Geometry guy, the problem is not much with next edits, but previous edits: inexperienced users generally edit without checking history before (if they know about it at all), most of the time they won't notice previous insertions of vandalism, libel, etc. A diff is exactly the kind of things we cannot expect an inexperienced user to fully understand. While this may happen relatively rarely on the majority of pages, since semi-flag-protection is intended to be used on would-be semi-protected pages (so because of high, sometimes massive, levels of vandalism, blpvios, etc), this will happen a lot and considerably decrease the efficiency of this system compared to semi-protection.

So my proposal is to give autoreview to autoconfirmed users, they generally won't even know about it, but not review. Of course, this implies the creation of a usergroup 'reviewers'. I think that it won't particularly affect the backlog because anyway, inexperienced users are not the ones who will patrol Special:Oldreviewedpages to review new edits. Cenarium (Talk) 20:31, 24 January 2009 (UTC)

I agree with the goal to simplify the interface. Is it possible for autoreview to apply even when the previous version isn't flagged? Geometry guy 20:43, 24 January 2009 (UTC)

Impossible, that would eliminate all the interest of flags. An IP could vandalized, then an autoconfirmed user could edit without noticing and it would get automatically reviewed. Cenarium (Talk) 20:56, 24 January 2009 (UTC)

I'm asking whether it is technically possible. I would want the autoconfirmed editor to be presented with a warning in big red letters that what they are about to do may be a very bad idea, but is that technically possible? Geometry guy 21:24, 24 January 2009 (UTC)

Perhaps a better idea is to, create a system which will automatically give reviewer status to autoconfirmed accounts, as long as proper steps are followed, perhaps through the account preference interface, and when they choose to enable reviewer status on the preference, it will take them to a page explaining about the flagged revision system and how it should be used, etc. Although this does require more work on the editor part. Y. Ichiro (talk) 20:49, 24 January 2009 (UTC)

Wouldn't it be easier to just ask the permission at WP:RFR ? Cenarium (Talk) 20:56, 24 January 2009 (UTC)

Well, this type of permission shouldn't really be denied to users, I really see no reason to deny reviewer, and if they abuse this then they are probably POV-pushers/vandals who would of gotten blocked for edit-warring and vandalism anyways. Secondly, if you know how to use your preference setting, chances are, you will probably spend time learning about how Flagged revision work, and how to use them properly. Another problem I might see with this is that this is that having admins to give out review status might create "standards" that needed to be met before obtaining the reviewer status even though in my personal opionion it shouldn't be denied without a REALLY good reason, like reallly blatant edit warring for instance. That's just my take on it though. Y. Ichiro (talk) 21:07, 24 January 2009 (UTC)

I would also be quite liberal in granting reviewer rights, as long as the user is minimally experienced, has not recently engaged in vandalism, libel or other clearly blockable offenses. Standards for reviewer rights will necessarily develop though, since it will sometimes be removed, we will have to consider granting it back. There is the possibility to use an auto-promotion to reviewer rights, with higher requirements than autoconfirmed. When a user is experienced enough, it may 'surprise' him/her to have those new rights, but probably positively. There are also some other things that may be bundled with reviewer rights (I'll come later on this). The auto-promotion requirements will have to be discussed, but autoconfirmed ones are far too low in my opinion. Something can be said on Flaggedrevs in the user preferences, but I think it should point to WP:RFR in the end. Cenarium (Talk) 21:58, 24 January 2009 (UTC)

If reviewer rights have to bemanually granted, this is basically the same as the other proposed system with a trial on semi-protected pages, except we trust autoconfirmed users to sight their own edits, but not others and admins replace the "surveyor" group. Mr.Z-man 22:13, 24 January 2009 (UTC)

Yes but this is a huge difference. When an autoconfirmed user edits, the latest version has a high chance to be already flagged, so will be the new one. An explanation message will be displayed when the previous revision was not flagged, in the most user-friendly possible way, and if an editor is interested in flagging, s/he can ask at RFR. We can still make an auto-promotion to reviewer rights, but 10 edits/4 days is just too low. Cenarium (Talk) 22:29, 24 January 2009 (UTC)

The problem is that I've seen what happened to rollback. When it first came out, people handed it out like candy, since then, the requirements for getting have changed (for no real reason) to require a "demonstrated need". Even with the low requirements, we only have a few hundred more rollbackers as we do admins. A lot of people just won't know to request it. Also, as far as I can tell, there's no way to mark a revision as sighted, without actually viewing a diff of the changes since the last reviewed revision, or scrolling down to the bottom of the page (which presumably means they read it). I really don't buy the argument that it'll make things too complicated and people will review revisions with vandalism. Mr.Z-man 22:35, 24 January 2009 (UTC)

Although I do not quite agree with reviewer status should be granted manually by administrators, I don't think it should be too much of a big deal if we raise raise the requirements for auto-promotion of reviewer status, to, 7 days and 50 edits perhaps? One week of editing I think should be enough time for new users to get familiar with the flaggedrev system, in my opinion. Y. Ichiro (talk) 22:46, 24 January 2009 (UTC)

This proposed change is based on a flawed concept: "an IP makes a bad edit to a page, one minute later, an autoconfirmed user edits constructively the page, and having little understanding of Flaggedrevs, flags the new revision in complete good faith"

FlaggedRevs doesn't work that way! If there is a non-flagged revision, any user editing the page will see a diff between the last flagged revision and the current one, as well as the vandalism in the edit window, and they then have to physically check a box (before save) of click a button (after save) to mark it as reviewed. What's the point of having instructions if we don't trust users to follow them? Any autoconfirmed user can screw up a semiprotected page now if they don't know how to edit, they can move a page to wrong title if they aren't familiar with naming conventions, they can upload an image even if they don't understand copyright, they can mark new pages as patrolled without knowing CSD, they can mark edits as minor that shouldn't be. Why is FlaggedRevs so special that we can't trust them with it? Mr.Z-man 22:47, 24 January 2009 (UTC)

The diff shown to the user just after editing is precisely the kind of things inexperienced users won't fully understand, so they probably won't review, or if they do, not necessarily rightly so. In other cases, the box at the bottom of the page is also tempting... Rising the requirements for granting automatically reviewer rights, so that users have more experiences before flagging, is a solution to this. Cenarium (Talk) 23:01, 24 January 2009 (UTC)

1. I can see several different points of view in this debate:

1. We need to protect living people from the havoc that can be wreaked on their lives by inaccurate BLPs. 2. We need to hold together a community that is being torn apart by a drive to implement FRs in a clumsy and ill-defined way that is not sufficiently restricted to prevent 'creep' across the whole encyclopedia 3. Most of the arguments against FRs still apply to Flagged Protection - some would call it 'FR lite' others a more precise and clearly delimited version of FRs. 4. It's a foundation principle of Wikipedia that anyone should be able to edit it. To change a foundation principle must require huge backing from across the community - much more than is available at present. 5. There don't seem to be many people, on either side, that wish to reach a compromise that a REAL consensus could form around, despite Jimbo clearly giving us the opportunity to do this. I thought Flagged Protection might offer the basis for such a compromise, but noone seems keen to shift their position. 6. Technical solutions are not likely to be as effective as solutions that reward good WP behaviour.

I'd really like to support this, and put it forward as a possible compromise option in the increasingly heated FR debate. This would require a lot more willingness to shift from both the FR Fanatics and the FR Oppositionists, without that willingness to shift and given the problems inherent in restricting rights to edit in any way, the best I can do is remain neutral. Riversider2008 (talk) 14:09, 26 January 2009 (UTC)

How long to flag-protect articles?

Is it possible, under this system, to institute a flagged protection that will automatically lapse after x days, like Protection currently does? NuclearWarfare _(Talk) 19:11, 24 January 2009 (UTC)

Yes. Mr.Z-man 19:29, 24 January 2009 (UTC)

(e/c) Yes. Pipped at the post, damn it. — neuro^(talk) 19:31, 24 January 2009 (UTC)

Don't shoot the messenger, but I'm not aware of this being technically possible at the moment. Which is not to say it's not a very good idea... :D Happy‑melon 21:48, 24 January 2009 (UTC)

I have set an expiry time when testing on test.wikipedia, see [1], default:stable then downgrades to default:current. Cenarium (Talk) 21:57, 24 January 2009 (UTC)

Yes, the flags on the revisions don't expire, but the stable version settings per article can. Mr.Z-man 22:14, 24 January 2009 (UTC)

I see. This is excellent news. Happy‑melon 18:11, 25 January 2009 (UTC)

Dumb question from thickie admin

Forgive me because it probably says somewhere and I just can't see it. Am I correct in assuming that implementing this proposal would not be intended to preclude or replace stricter uses of the flagged revisions system (e.g. on BLPs)? i.e. If we had a "Flagged Protection" option similar to what is proposed here, we would not be removing the option to have a German-style flagged revision system on BLPs? Correct? Or not? CIreland (talk) 18:02, 24 January 2009 (UTC)

That's correct. As I see it we're at the stage now of figuring out what kind of trials we want to run of the flagged revisions feature (ultimately "flagged protection" is just a form of flagged revisions), so this is essentially a proposal for a trial. On his talk page Jimbo asked for proposals that could draw a larger consensus than that at the poll on whether to turn on flagged revs for trials (which ended at 60/40 in favor).

I think the idea with flagged protection is that many who are wary of a wider use of flagged revisions are likely to be fine with it, and those who want to use flagged revs for BLPs or something else probably won't have much of a problem either. Taking things one step at a time rather than leaping ahead to a massive trial on BLPs I guess, the latter being something that would still be up for discussion now or later and which we could decide to do or not. --Bigtimepeace | talk | contribs 18:12, 24 January 2009 (UTC)

I think that the two systems are technically compatible, but it would require a modification of the extension. Assuming we only give autoreview to autoconfirmed users (see above for discussion), it would simply require an option to deactivate autoreview for autoconfirmed users on an article (with the exception of reviewers), in the form of a check box maybe, checked by default...

As I believe that we should use semi-flag-protection by default, and deactivate autoreview if there are still problems with autoconfirmed users (classic example, but there are many more, especially articles targeted by sockpuppeters, some even have to be fully protected, like this one). Some other high-risk blps or persistently problematic articles could also benefit of this, consensus will say. Cenarium (Talk) 21:23, 24 January 2009 (UTC)

Actually it's possible to integrate this perfectly with a 'traditional' FlaggedRevs implementation without any modifications. FlaggedRevisions implements a scale of flags, some higher than others, and defines for each article a 'trigger point' on the scale above which revisions flagged to that level become instantly visible. We're used to thinking of it being a binary system, but there's really no reason why that must be the case. We could create a three-flag system ('unsighted', 'sighted' and 'uber-sighted'), give the ability to flag as 'sighted' to autoconfirmed users, and give the ability to flag at 'uber-sighted' to say, rollbackers and admins. Then people with the stablesettings permission (we called them surveyors in the trial proposal) can set the 'bar' on an article either to "below 'unsighted'" - all revisions are visible immediately, to "between 'unsighted' and 'sighted'" - both 'sighted' and 'uber-sighted' edits are treated equally, and differently to 'unsighted' edits; or to "between 'sighted' and 'uber-sighted'", which means 'unsighted' and 'sighted' edits are treated the same, and differently to 'uber-sighted' edits. Full FlaggedProtection, anyone? Happy‑melon 21:54, 24 January 2009 (UTC)

A second grade is used in the proposed full flag protection, as an alternative to full protection, for example for disputes (so it should be restricted to admins, or maybe moderators, a new usergroup, but not for rollbackers). We could use another, intermediary grade, but it wouldn't reduce exactly to semi-flag-protection in one case and traditional flagged revisions in the other. The 'disable autoreview' option would do this in a light manner. Cenarium (Talk) 22:19, 24 January 2009 (UTC)

I like Happy-melon's idea here. IMO, the goal for FlaggedProtection would be to replace the current semi-protection and full protection. Also, stablesettings should not be awarded to users below uber-sighted level and uber-sighters should not be any less than admins for the same reasons why only admins can edit full-protected articles right now. Admiral Norton ^(talk) 11:16, 25 January 2009 (UTC)

Wiki has changed

When I first was involved with Wiki in 2004 it was a different kettle of fish. Wikiworld was about creating new pages and checking old ones, but it was mainly the feeling of spreading free knowledge that was at the forefront of my mind. Improving the articles was easy and there were many many of them to create. It was a pleasurable if short lived time as I had to give Wiki up to concentrate on life for a while.
When I rejoined mid last year I was put off because I missed the creation of the new, so I spent a few months mooching around Wikiworld and seeing what was there, put it in my browser as my search engine and carried on. After a while though, I started spotting mistakes and wanting to contribute and eventually I got infected again.
In those months I realised that I actually enjoy this challenge more than the old one. Sure it was a good feeling to create something new, but now I have to research much more on every task I attempt, and I have to learn more to be able to input more. I like it and I have grown and changed to accommodate this new Wikiworld. We also have to accept that in the attempt to gain more accurate and publicly trusted information we need to perhaps let Wikiworld change too.

I do not want to stop anybody from having the feelings I had when I first edited a line, re-wrote someone else's badly written page or even created one, and I welcome any change that will make Wiki more accessible to editors both established and new.
We have to accept that there are people out there who take pleasure from deleting a whole page and putting ARSE there instead, that is unacceptable. We have to show each other and the rest of the world that we can achieve harmony and accuracy of content and I believe leading they way in this is through whatever the outcome is of these discussions.

I support these proposed changes because I think it achieves those two goals, more open editing and at the same time more flexibility on control of the ARSE element.
Hope we can get the results of the trial soon and that it is a positive outcome.--Chaosdruid (talk) 21:18, 24 January 2009 (UTC)

Raise the auto-promotion thresholds?

There has been discussion about the current auto-confirmed threshold being too short. I wonder if we can raise it to 7 days and 50 edits? or 90 days with 100 edits instead for reviewer status (TOR proxy autoconfirm threshold is 90 days with 100 edits), for the auto-promotion of reviewer status? Y. Ichiro (talk) 07:53, 25 January 2009 (UTC)

Personally, I might go for 7 days and 20-30 edits, but 50 or more is just too much IMO. Admiral Norton ^(talk) 11:18, 25 January 2009 (UTC)

If this is implemented, then we would absolutely have to increase autoconfirmed to something like 7 days and 50 edits (if not more) and that would really get in the way of good contributors uploading images or moving pages. Otherwise, we are bound to have bad revisions getting reviewed (esp. by vandals known to abuse autoconfirmed tools). The best way, therefore, would be a separate user group like in trial #2. GDonato (talk) 11:41, 25 January 2009 (UTC)

I'd say this would be necessary. A considerable amount of opposes are based on the fact that giving autoconfirmed users the ability to "review" edits would be harmful. Chamal ^talk 12:05, 25 January 2009 (UTC)

Raising the autoconfirmation requirements raises the same question as the section below, which is one of the reasons why I strongly opposed the general FlaggedRevisions system. Another reason is the fact that, while I can easily amass 50 edits in an hour or two playing with some WikiProject banners or spell-checking, it's not that easy for new Wikipedia users. It took me more than a month to get to that number when I first registered on Wikipedia. The majority of vandals is probably not willing to go that far, but also not willing to go much less either. Also, the vandals that do slip through can cause a large financial damage to Wikipedia and I do not feel like supporting a fundraiser to pay off a series of no-name film producers or mayors of Anytown, PA. Admiral Norton ^(talk) 14:11, 25 January 2009 (UTC)

Mind you I saw someone (who ended up getting into a *vociferous* dispute over a BLP in their first non-trivial edits and creating an attack article, then railing against its ultimate deletion) rack up 18,000 edits using Huggle and Twinkle in their first month making minor fixes. Orderinchaos 06:10, 29 January 2009 (UTC)

Beware increased liability (Publisher vs Distributor)

Does liability for libel not significantly increase when content is moderated? IANAL but is it not true that while fewer problematic edits will slip through, those that do could prove far more serious both for Wikipedia and the approver(s)? For example:

In the Prodigy case, Prodigy was sued for defamation based upon the statements made by one of its customers in a Prodigy discussion group (or bulletin board). In determining whether Prodigy was liable for the defaming statements of its customer in this case, a New York state judge was left to determine whether Prodigy was a "distributor" of information, such as a bookstore or library, or whether Prodigy was a "publisher" of information, such as a newspaper. As a mere distributor, Prodigy would not be liable for the statement. In contrast, if Prodigy was considered a publisher (with greater control over the information's content), Prodigy would be liable. In a decision that shocked most on-line service providers, the judge held that, as a result of Prodigy's well-publicized policies of monitoring and censoring its forums, Prodigy was a publisher and was potentially liable for the defaming statement. Although the case was settled by the parties and Prodigy moved for a withdrawal of the judge's decision, the judge refused.

This is a significant change that appears to be a kneejerk reaction to criticism from old media, and thus one that requires more deliberation. Note that the offending edit was not quoted as fact (no sane journalist would use Wikipedia without checking references), rather used to attack Wikipedia despite the content being almost instantly removed. Perhaps further rules could be added to limit the effects, for example autoapproval of pending edits that are not reviewed within a relatively short time (e.g. a day rather than a month ala wp.de).

Anyway, in other news I left my computer off for a week and it didn't get any viruses, though I still wouldn't call this trial a complete success. -- samj _in^out 13:11, 25 January 2009 (UTC)

I was about to raise almost exactly the same issue, someone should probably contact Godwin about this since I would also agree that there is a chance that a proposal such as this could have Wikipedia defined as a publisher and then therefore liable for all the statements that any autoconfirmed user happens to approve, GDonato (talk) 13:39, 25 January 2009 (UTC)

No. By all means contact Godwin if you think that flagged revisions were implemented by the WMF and brought into use on other Wikis without him hearing about it (maybe he was having a nap at the time) but the issue for Prodigy was that it was Prodigy who were, at least ostensibly, monitoring and editing the content. There is already a whole bunch of people monitoring and editing the content of Wikipedia; the important thing (at least, the principle that the WMF wish to rely on) is that those people are not the WMF and do not work for the WMF. That would still be the case with flagged revisions. The "blame" for anything that happens would continue to be with the community, not with the WMF. 87.254.93.202 (talk) 14:32, 25 January 2009 (UTC)

the important thing (at least, the principle that the WMF wish to rely on) is that those people are not the WMF and do not work for the WMF. You may have a point there. In any case, I highly doubt the developers of the extension expected autoconfirmed to be used as the reviewing group and there is probably a very good reason for that: bad reviewing and poor protection for the subjects of the articles, GDonato (talk) 15:00, 25 January 2009 (UTC)

Someone already asked Mike Godwin: [2]. Hut 8.5 15:06, 25 January 2009 (UTC)

I think we should just be careful about what we specify as the requirements for sighting. If we say "free of libel", then there might be an issue (saying publicly that something isn't libel could be considered equivalent to saying it is true, thus potentially libel itself). If we say "free of obvious libel", then we may be a little safer (and it means reviewers don't have to go and find a copy of the source and verify it before being able to flag). --Tango (talk) 17:06, 25 January 2009 (UTC)

What are the reviewers doing if they're not going to check against the source? "Obvious libel" isn't a problem, pretty much by definition, since the reader can tell it isn't true and will disregard it other than to bear in mind that they need to take the rest with a grain of salt. It's when the libel isn't obvious that it causes the damage. 87.254.93.202 (talk) 17:15, 25 January 2009 (UTC)

If you expect reviewers to actually go and find a copy of the person's autobiography, or whatever, before flagging the edit, you're going to get a massive backlog. This is supposed to be something that can be done by RC patrollers without significantly extra effort. --Tango (talk) 17:37, 25 January 2009 (UTC)

And if we don't check against sources, then what's the point here? This is exactly the reason why I'm completely opposed to any massive use of Flagged Revisions, even in BLPs only. Admiral Norton ^(talk) 18:07, 25 January 2009 (UTC)

So, Tango, which do you think is a bigger problem; a possible (or even inevitable) backlog on review of BLP edits, or a lack of comprehensive review of edits made to BLP articles? 87.254.93.202 (talk) 19:39, 25 January 2009 (UTC)

General comment on oppose votes

An interesting flip here from the previous vote on having trials of flagged revs. On that poll people who opposed flagged revs in at least some form often opposed because they saw a "slippery slope" to full implementation (I was one of those), whereas here a number of people are opposing one possible trial because they assume there will be no further trials and that we'll never have flagged revisions on BLPs (which is the real concern for many if not most).

Of course that is possible, and there are people above who say they would only support flagged revisions. But I would ask those opposing per Scott McDonald's rationale to consider the following:

1. There are currently 39 support votes. A quick perusal of those shows 11 votes which seem to suggest that the editor is categorically opposed to any other form of flagged revisions. 7 editors expressly said they are open to the possibility of other usages of flagged revisions. The other 21 said nothing specific either way (though I'm guessing more fell into the former camp). I'm not sure how this leads some of those voting oppose to assume, as SirFozzie suggests, that this is "a backdoor attempt to kill Flagged Revisions by delay." I would also point out that many who voted early here came from registering opposition to flagged revs on Jimbo's talk page, so the voting is a bit skewed. It's also worth mentioning that this poll was set up because Jimbo called for compromise proposals, and he even remarked that this might be a good way forward. Not everyone views this as a Trojan Horse to kill off a wider implementation of flagged revs, and the fact that some do does not remotely rule out further discussion of other approaches.
2. Along those lines, please remember what this is (or should be) - a proposed trial. Nothing more or less because that is the stage we are at right now. It does not preclude other trials, and there is no guarantee that we would even keep flagged protection around if folks did not like it after the trial. If you want to test out flagged revs on some BLPs (something I've suggested here in tandem with this proposal) then go argue for it on one of these pages. Flagged protection and flagging for BLPs are not remotely mutually exclusive.
3. If you want a wider implementation of flagged revs, you'll probably need to convince some of those who are adamantly opposed. Forcing flagged revs on all BLPs or certainly all articles is not the way to do that. The 11 editors above who are categorically opposed to any other form of flagged revisions will still be opposed if we run a poll on BLPs. But, maybe, if this trial with flagged protection goes well, some (certainly not all) of that opposition will loosen a bit, because people might be less wary of it once they get a sense of how it functions and the good it can do. I'm surprised no one is mentioning this point.
4. I think there are real concerns which I share about who gets "reviewer" status. We need to hash that out, and perhaps alter this proposal such that not all autoconfirmed users become reviewers. I'm guessing many voting support would be open to that possibility, and that problem in itself is probably not a good reason to kill off this proposal.

In general I'm disappointed that both sides of this debate have dug their heels in to such a degree, and that throughout this multi-page debate there has been no shortage of wild accusations and, quite frankly, rank incivility ("you're destroying the Wiki way!" "you're immature and don't care about real people!"). Like anything else on Wikipedia we need to work together, and we should all be open to compromise and multiple approaches. The fact is, none of us have experience with flagged revisions on en.wp, so it's remarkable how sure most of us are about what it will or will not do. Recognizing that fact might make us all more open to different means of testing and using this feature, and it will certainly make it easier to talk to one another. --Bigtimepeace | talk | contribs 14:49, 25 January 2009 (UTC)

Well, as one of the original authors of this proposal, I'm probably even more disappointed how people are mis-interpreting the proposal for the only FR proposal that is going to be implemented ever. Originally, I thought of it as a proposed replacement for semi-protection, or something to work alongside with semi-protection at least, not even as a compromise FR proposal, just something that needed to be done to solve the problem that exists with the protection system. The only connection between this proposal and FR is that it uses flagged revision feature, nothing more. I really wonder where do people get this idea that this will be the last FR proposal that will be made. In fact I wrote this proposal as something to start with so people could see how FR is used, and maybe some new proposal will form as consensus develops, not to be some end-all solution to the FR problem. I mean, if people believed protection policy is an "end-all" solution policy, then I don't think people would of came up with semi-protection to begin with. Y. Ichiro (talk) 17:48, 25 January 2009 (UTC)

Well said Bigtimepeace. Y. Ichiro, I liked your idea from the start, and sympathise with your frustration that it has become part of a broader debate on how to use FlaggedRevs. For better or worse, this is a wiki: it says below the edit window "If you don't want your writing to be edited mercilessly or redistributed for profit by others, do not submit it." This applies to ideas too, especially good ones. Geometry guy 18:20, 25 January 2009 (UTC)

Proposed modification

In this comment Geometery guy asks Lar if the proposal would receive Lar's support if it:

• "endorsed a wider use of flagged protection on BLPs than articles in general"
• "reviewers were a smaller group, such as rollbackers"

I would like to build on this since, as an initial opposer of this proposal, I would support the proposal if these modifications were to be made. I therefore propose that the proposal be modified to set these as new conditions. Would this be something the supporters of the original proposal are happy with? Would this be something the opposers of the original proposal are happy with? Is it an effective compromise? GDonato (talk) 16:43, 25 January 2009 (UTC)

As a supporter I think we need to go this route. Again though, all we are talking about here (or should be) is one trial. That keeps getting lost I feel and as a result we are having 3 or 4 different conversations and folks are often talking past one another (we really, really need to get this straight). We are not talking about deciding how we permanently use flagged revisions on the English Wikipedia. We don't need to decide if there would be "a wider use of flagged protection on BLPs than articles in general." Personally I think I would be in favor of that, but nothing in this proposal precludes it from happening. We can have this trial and another one that would run on a subset of BLPs. If that gets more folks to support this then I'm fine with it, but this page is not for making permanent policy on flagged revisions.

I do agree reviewers need to be a smaller group and think this would allay some folks' concerns. For the purposes of a trial lets just have it be rollbackers, and as time goes on we could always add more.--Bigtimepeace | talk | contribs 16:52, 25 January 2009 (UTC)

@GDonato: I would weaken my opposition to this (I'm not ready to support it, see below) if reviewers were a group that was granted by humans, not automatically. Preferably, with at least as much discussion as around granting rollback, or more. It should not be the same group as rollback, it should be a different one so that the permission can be tuned as needed.

@Bigtimepeace: My issue is that despite what some supporters are saying (that this is not the only possible proposal that could be implemented), other supporters are saying this is the only proposal they would accept, and they are in advance saying they would oppose any other proposal. Which means they would block implementing a better one. This issue really has now moved beyond voting, in my view. Sorry to sound strident but it's time to do flagged revisions. By fiat if necessary, and this proposal, right now, is in the way. It is a "feel good" proposal. We need to not "feel good" about this. We need to do the right thing. The current state of BLPs is a disgrace. That's been pointed out over and over, and yet we have people saying "there is no BLP problem"!!! They are the ones that really need to get out of the way. Or be gotten out of the way, whichever. ++Lar: t/c 17:00, 25 January 2009 (UTC)

This is exactly the same system that was in the first proposal. In it we proposed to give review access to all sysops and rollbacks, and to any other users who ask for the review right. There is no need to invent the bike. Ruslik (talk) 17:14, 25 January 2009 (UTC)

I would agree with that. Better that the reviewer flag was given out to people who simply know what they are doing, rather than every Tom, Dick and Harry. Plus there would be better control over the permissions in the event of something such as abuse. Yes, that would be better than giving it to all autoconfirmed users. --.:Alex:. 17:28, 25 January 2009 (UTC)

I wouldn't: a significant difference is that it in no way restricts editing beyond the current system, GDonato (talk) 17:32, 25 January 2009 (UTC)

"Doing the right thing" should make one feel good, shouldn't it? The problem is that there are many shades of opinion on what the right thing is. FlaggedRevs can be deployed in many ways. Further, they are only one tool to tackle the BLP problem. I agree we have to start trying out this tool and there is consensus to do that (see WT:Flagged revisions/Trial#One_possible_breakdown_of_oppose_vote). However, we should not, any of us, say dogmatically, "it has to be done this way and no other way is acceptable". That is a recipe for getting nothing done.

A key aspect of the flagged protection approach is that, like (semi-)protection, flagging is only enabled on an article-by-article basis. It allows us to do the right thing while retaining the wiki spirit. It effectively says "We wish we didn't have to do this, but we do have to do it in some cases". See also WP:3IAR, which is particularly apt here. Geometry guy 18:15, 25 January 2009 (UTC)

Added Problem Statement Section

I wonder if this will make things clearer for people as to why this proposal was written in the first place. Y. Ichiro (talk) 18:08, 25 January 2009 (UTC)

Thank- you, yes it does. If I may paraphrase, I understand that the idea behind the proposal is that the principle of allowing anyone the opportunity to edit any article is being given primacy over the idea that such rights be restricted on approximately 0.1% of all articles - to protect them from repeated vandalism by new and and anon editors. If implemented the proposal would enable edits by new/anon users to be undertaken, but not seen by the public until "approved". The (say) 90% of such edits that are vandalism, childishness, poorly spelled and syntaxed, uncited and generally dubious would (in principle) not be approved and never seen by the public. Ben MacDui 18:54, 25 January 2009 (UTC)

Attempted merge

I added the full flagged protection feature to the implementation from Wikipedia:Flagged revisions/Trial. The result is here: User:Ruslik0/Sandbox2. I think the full flagged protection is a useful idea that should be included. Ruslik (talk) 19:08, 25 January 2009 (UTC)‎

Partial PHP configuration

00

Analysis of options for modification

Several people have expressed interest in tweaks to this proposal, to make it slightly more restrictive. This post is an analysis of the options for modification to this proposal, for feasibility, (undesirable) side effects, and desirability for those who opposed the original proposal for wider use. I cannot speak for desirability for those who desire wider use as I am myself opposed to such and wish to not misrepresent their opinions. The suggestions follow, in no particular order:

Increase autoconfirmed threshold

• Feasibility: An easy technical change for any developer to make, but would require wide consensus to change such a global feature
• Side-effects: This increases the protection threshold for any articles left semi-protected
• Desirability for those opposed to wider use: This is somewhat chilling, again, of open editing, but it would be preferable to widespread use of FlaggedRevs. If flagged-semi-protection completely displaced "normal" semi-protection, it might even be preferable, depending on how extreme the new threshold would be.

Restrict reviewing to a new usergroup above autoconfirmed

• Feasibility: Easy technical change, likely non-controversial
• Side-effects: No universal changes aside from a new user group; user-group proliferation is not a major concern
• Desirability for those opposed to wider use: While this is not a desirable modification of the proposal, it is definitely preferable to widespread use of FlaggedRevs, especially if the relevant user group would be given out automatically.

Endorse wider use on biographies of living persons (BLPs)

• Feasibility: No technical cost, but likely controversial
• Side-effects: This may involve, due to the large number (in the range of 300,000, according to a recent Signpost article) of BLPs, some of the theoretical drawbacks of other widespread use of FlaggedRevs. This side-effect might be mitigated somewhat if only a subset of BLPs are flagged under this option.
• Desirability for those opposed to wider use: This option effectively destroys the advantage of flagged protection over other FlaggedRevs proposals, and is thereby unacceptable. The undesirability might be mitigated somewhat if only a subset of BLPs are flagged under this option, but whether this would correspondingly mitigate opposition is dubious.

Use autoreview only for autoconfirmed users

• Feasibility: An easy technical change for any developer to make, unlikely to be very controversial in and of itself
• Side-effects: Another group will be required that has the review right, otherwise pages that receive unsighted revisions will remain unsighted permanently.
• Desirability for those opposed to wider use: This isn't a big problem in and of itself, but as it effectively requires a new usergroup above autoconfirmed to be created, it inherits the problems of that proposal.
• Desirability for those in favour of wider use (I think that this is a point that both sides can probably agree on): Allowing autoconfirmed users autoreview effectively discards the anti-vandal elements of requiring a group above autoconfirmed—since an autoconfirmed vandal can get their vandalism sighted through autoreview—while still requiring a group above autoconfirmed.

I'm open to checking out more options, and this is primarily my opinion (though I've aimed to stay relatively objective) and could be wrong. Any thoughts? {{Nihiltres|talk|log}} 19:18, 25 January 2009 (UTC)

I was actually working on something very similar at User:Mr.Z-man/yet another FlaggedRevs proposal, basically a combination of FLP and some ideas from Scott MacDonald. Note that rather than increasing the autoconfirm threshold, we can use $wgFlaggedRevsAutopromote which has a lot more options, and (I think) allows the right to be manually revoked, unlike autoconfirm. My proposal also would add another group for reviewing BLP articles, so that it would only be given to trusted users and would be revocable, even from admins. It would also limit the use of FlaggedRevs on BLPs to at-risk BLPs; I don't believe that its possible to use the system on all 300+ thousand BLPs and still give each the level of review necessary to have more than a token effect on the problem of libel in BLPs. Mr.Z-man 19:28, 25 January 2009 (UTC)

Your proposal is better for me and would probably get my support as a trial as it addresses my two main concerns from this proposal, namely that it puts a focus on BLPs as well as just semi-protected articles and it lets us have a higher threshold than just auto-confirmed. I think this could certainly be a basis to work on. Davewild (talk) 19:53, 25 January 2009 (UTC)

Agree with Davewild, and while I'm sure it could be tweaked, in general I like the looks of what Mr.Z-man is proposing as a trial (precisely because it would be a trial it would be easy to adjust it). I think it might help assuage some of the concerns of those who are in opposition to this current proposal. --Bigtimepeace | talk | contribs 20:01, 25 January 2009 (UTC)

I also like Mr.Z-man's proposal and would like to see it expanded on (I would be happy to help with this). It is certainly one of the better flagged rev proposals and I only have minor reservations with it (specifically, the scope). GDonato (talk) 20:08, 25 January 2009 (UTC)

I think it may be implied that admins automatically get rights to flag revisions even on BLP articles. Tying rights to admin status isn't ideal because getting admin status removed for carelessness will not be easy. Ideally it would be a separable right even if all admins get it by default. Otherwise very good. 87.254.93.202 (talk) 20:10, 25 January 2009 (UTC)

I would hope admins have enough clue to avoid flagging bad revisions on BLPs :S Perhaps I have too much faith in them then ;) , GDonato (talk) 20:14, 25 January 2009 (UTC)

I explicitly mentioned "another group for reviewing BLP articles, so that it would only be given to trusted users and would be revocable, even from admins" - I guess I don't have quite as much trust that all admins care as much as they should about BLP issues. Mr.Z-man 20:19, 25 January 2009 (UTC)

Thanks, you're right I was reading into it an implication that wasn't there. I'm not sure that it's even about caring as such but being good at, e.g. vandal fighting, isn't the same as being a good reviewer of content which is what is needed here. I like your proposal - especially the way it focuses on the riskiest BLPs. 87.254.93.202 (talk) 20:24, 25 January 2009 (UTC)

Yeah, perhaps I do have too much faith. One final question: Why only risky BLPs and not all? Just because a BLP has a good PR team should not mean that it should be considered a free-for-all... GDonato (talk) 20:37, 25 January 2009 (UTC)

We have over 300000 BLPs. We can provide protection for blatant vandalism for all of them, or we can provide real review of edits - checking for actual libel - for a subset of them. We don't have enough manpower to provide real review for every BLP. If it takes a week to review edits on BLPs that get one edit a month, that's not as much of a problem as taking a week to review edits on BLPs that get 10 edits per day. I personally don't think protection against blatant vandalism only really helps anything when it comes to protecting the subjects of BLPs.

Excellent points, but also it isn't just about "PR teams". The level of attention given to high profile BLPs (e.g. President Obama, Jimbo Wales) doesn't just mean a lot of edits to review - it also means that lots of people are already reviewing them. Unsourced claims are already objected to and reverted. If we have to start on a smaller scale to manage resources then those are the ones that need the least added attention. 87.254.93.202 (talk) 21:02, 25 January 2009 (UTC)

I've been thinking about protecting all articles - or indeed any page - from blatant vandalism using the abuse filter, instead of using only positive review levels (review, validate, etc), we use one or several negative levels: if the abuse filter detects vandalism, it will 'defer' the edit by reviewing it negatively. Pages show the latest non-negatively reviewed version (see here for a draft), and revisions get reverted, overwritten or flagged. This won't catch all vandalism, but a good part of it. We may use three (positive) review levels, but it would require three new usergroups. We have so many blps that using a specific blp-reviewer group might not be enough manpower. I think rising the requirements for reviewer should be enough, and possibly fully flag protect most sensitive ones. Admins can bypass review by configuring the page, so why not allowing them those rights ? Cenarium (Talk) 21:18, 25 January 2009 (UTC)

We have to decide what we actually want for BLPs. We can have real review of edits by users in a trusted user group. This means that edits to at-risk BLPs may take a while to get reviewed. Or we can have a quick review by a reviewer which will likely just be a check for vandalism done while doing RC patrol. I really don't see any way we can have both quality and quantity/speed here. If we raise the requirements for reviewer too high, then the backlog on non-BLPs will increase. If we have too many user groups, it just becomes a confusing mess of bureaucracy. As for admins changing the stability settings to bypass review, most admins would probably be in the BLP reviewer group anyway, but I imagine de-BLP protecting a BLP-flagged page unilaterally would be comparable to unilaterally undeleting an article deleted for BLP reasons. Not everything can be enforced by the software, for some things, a policy saying "Don't do this" should be enough. Mr.Z-man 21:48, 25 January 2009 (UTC)

Perhaps a certain degree of quantity over quality is preferred: there is no way of predicting which BLP will lead to the Foundation being dragged to the courthouse and therefore we should protect as many as possible. Our definition of "risky" BLPs may not be the ones that actually end up causing problems whether they be legal or the site's reputation, GDonato (talk) 21:54, 25 January 2009 (UTC)

(←undent) Perhaps quantity was the wrong word. We can have as much quality and quantity as we want, the main trade-off is speed - how long it takes edits to be reviewed. We can increase speed by decreasing quantity and/or quality and vice versa. I've posted a proposed configuration to User:Mr.Z-man/yet another FlaggedRevs proposal, note that until bugzilla:17157 is resolved, BLP-flagging and full-prot-flagging are almost entirely functionally equivalent, the only real difference is in the name. Mr.Z-man 22:10, 25 January 2009 (UTC)

Quantity would probably be preferable—that would probably end up being more open overall. I think that it is fair to say that most of our editors know about the BLP policy, and that even more would avert stupid claims of death, et cetera. It's worth noting that in the most recent publicized failure, where the article on Ted Kennedy (page history) was vandalized, none of the vandals adding the nonsense were autoconfirmed. {{Nihiltres|talk|log}} 22:34, 25 January 2009 (UTC)

I imagine they would. However, false claims that major public figures are dead and blatant "John Doe is a douchebag" vandalism, while they might get the most media attention, are not the types of things that cause people real world harm. Mr.Z-man 22:43, 25 January 2009 (UTC)

bugzilla:17157 has been resolved, allowing BLP-flagged revisions in my proposal to override all other flag levels. Mr.Z-man 06:03, 27 January 2009 (UTC)

Possible compromise proposal

There seems to be a disagreement on the efficiency of the proposal for certain blps, and so that we should also be able to use classic Flaggedrevs. So I propose a merge like this: we give autoreview to autoconfirmed users (when the latest version is flagged, the new revision is flagged) but not review, and we use an auto-promotion to reviewer rights to be determined, with higher requirements than autoconfirmed. Cases where a non-reviewer autoconfirmed user edits a page with latest version unreviewed should be quite rare, so this won't change the 'spirit' of the proposal much, and if we notice that a good editor is often in this situation, we can give the rights, and we can also tell the user how to request them on the explanation message displayed after editing. Additionally, we create a usergroup 'moderator', able to validate articles, for articles that would be fully protected otherwise. The bridge between classic flaggedrevs and semi-flag-protection is then to have the option to disable autoreview for autoconfirmed users (except reviewers) on a particular page, in the form of a default-checked check box for example. This would have to be requested as this is not available in the current extension. For high-risk blps or other very problematic pages, we can disable autoreview. Cenarium (Talk) 19:32, 25 January 2009 (UTC)

PHP configuration (incomplete)

# Limit it to mainspace only
$wgFlaggedRevsNamespaces = array( NS_MAIN );
# Don't set any FlaggedRevs level for new pages
$wgFlaggedRevsAutoReviewNew = false;
# Pages display the current version by default - i.e. unprotected
$wgFlaggedRevsOverride = false;
# This requires it to be turned on by an admin for each page
$wgFlaggedRevsReviewForDefault = true;
# Flagging types
$wgFlaggedRevTags = array( 'protection' => 2 );
# Number of levels (full=2/semi=1/none=0)
$wgFlaggedRevValues = 2;
# Restrict autoconfirmed to flagging semi-protected
$wgFlagRestrictions = array(
    'protection' => array( 'review' => 1 ),
);
# Group permissions for autoconfirmed
$wgGroupPermissions['autoconfirmed']['autoreview'] = true;
$wgGroupPermissions['autoconfirmed']['movestable'] = true;

# Reviewer group
$wgGroupPermissions['reviewer']['review'] = true;
$wgGroupPermissions['reviewer']['unreviewedpages'] = true;

# Giving reviewer rights to rollbackers
$wgGroupPermissions['rollbacker']['review'] = true;
$wgGroupPermissions['rollbacker']['unreviewedpages'] = true;

# Rights for bots
$wgGroupPermissions['bot']['unreviewedpages'] = true;

# Group permissions for moderators
$wgGroupPermissions['moderator']['review'] = true;
$wgGroupPermissions['moderator']['unreviewedpages'] = true;
$wgGroupPermissions['moderator']['validate'] = true;
$wgGroupPermissions['moderator']['unwatchedpages']  = true; #?
$wgGroupPermissions['moderator']['rollback'] = true; #? 
$wgAddGroups['moderator'][]         = 'reviewer'; #?

# Group permissions for sysops
$wgGroupPermissions['sysop']['review'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;
$wgGroupPermissions['sysop']['validate'] = true;
$wgGroupPermissions['sysop']['stablesettings'] = true;
$wgAddGroups['sysop'][]         = 'reviewer';
$wgRemoveGroups['sysop'][]      = 'reviewer';
$wgAddGroups['sysop'][]         = 'moderator';
$wgRemoveGroups['sysop'][]      = 'moderator';

# Auto promotion to reviewer status, requirements to be determined
$wgFlaggedRevsAutopromote = false; #TBD

# Can users make comments that will show up below flagged revisions?
$wgFlaggedRevsComments = true; #?

• I could certainly support this as a compromise but why separate moderator and sysop? Do you think sysops will be overrun with the work? (Sorry if I have misunderstood the PHP there) GDonato (talk) 19:49, 25 January 2009 (UTC)

  Yes, admins have already much work, I'm sure non-admin users could help as 'moderators'. This would require a light selection process, but it shouldn't be a big deal. Cenarium (Talk) 20:21, 25 January 2009 (UTC)

• Sounds fine to me, since it looks like just another option should vandalism from autoconfirmed users ever get particularly bad (correct?), not an automatic part of the feature. Steven Walling (talk) 20:09, 25 January 2009 (UTC)

  Yes, some pages still receive vandalism and/or blpvios even when semi-protected (see here for examples), and using full flag protection would be too drastic. Cenarium (Talk) 20:21, 25 January 2009 (UTC)

• Would you please clarify on which articles FlaggedRevs would be used under this proposal? {{Nihiltres|talk|log}} 20:14, 25 January 2009 (UTC)

  We could use semi flag protection for would-be semi-protected pages and maybe more liberally on blps, like in the initial Flagged protection proposal, and if there are still problems, we disable autoreview for autoconfirmed users. In extreme cases, or disputes, we use full flag protection. Cenarium (Talk) 20:24, 25 January 2009 (UTC)

Anything with autoconfirmed getting the right is a non-starter. It'll just add anew dimension to the POV battles that incessantly rage about WP (Nationalistic disputes, contentious areas etcetera). Instead of just battling over the text, it will expand the battle to include flagging the article in their preferred area. It needs to be reasonably tightly granted, and easily removed if misused. SirFozzie (talk) 21:25, 25 January 2009 (UTC)

Autoconfirmed users don't get the review right, only the autoreview right (see above), just like autoconfirmed users can edit semi-protected pages. It is also possible to disable autoreview for autoconfirmed users on a particular page, thus becoming exactly the classic Flaggedrevs. I clarified the key points in the proposal. Cenarium (Talk) 21:34, 25 January 2009 (UTC)

The higher the requirements go, the easier it is to "pwn" the article and the harder it is for the "pwned" one to stand his ground. In my opinion, the starting requirements should be relatively lax to avoid things like POV-pushing community-approved users or WP:BITING, yet it should be easy to revoke the privilege. I'd advise keeping a noticeboard for privilege abuse (something like WP:AN3), but also expanding the number of affected articles (from 3,000 to, say, 5-6,000) to include articles like Texas hold 'em that are routinely vandalized, although they attract useful anon edits and don't meet the semi-protection requirements. Admiral Norton ^(talk) 22:28, 25 January 2009 (UTC)

A noticeboard dedicated to flagged revisions will definitely be created. We could expand semi flag protection, but we'll have to do so progressively, so make priorities, and blps should be at the top of the priorities. Not all of them - but the ones already prone to vandalism/blpvios to begin with, then expand. Vandalism is a threat to all articles, we can semi flag protect the most seriously affected (some will still have to be semi-protected I'm afraid), but not all, that's why I'm trying to develop a semi-automatic 'anti-'flagging system. Cenarium (Talk) 01:40, 26 January 2009 (UTC)

I cleaned up the code a bit (removed unnecessary assignments). It is now easier to read. Ruslik (talk) 07:57, 26 January 2009 (UTC)

It doesn't make sense to give autoreview to someone but not review. They can merely make null edits to review anything they like. Dcoetzee 08:19, 26 January 2009 (UTC)

No as the new revision will be automatically reviewed only if the previous revision was already reviewed (either by a reviewer or automatically). Cenarium (Talk) 09:17, 26 January 2009 (UTC)

This proposal takes away the reasons why people who opposed the trial would support this proposal: It does create new hierarchy (which is bad) and makes it more complicated (also bad). The point of this proposal was that autoconfirmed users can review non-vandalism IP edits, thus having many people to do the job without complicated structures. After all, there can't be anything bad that an IP can add which an autoconfirmed user can't but you propose we allow the autoconfirmed user to add the bad content but deny them to review bad content by another? I do not see why there should be a difference and I for one would oppose such an implementation. I don't see why you have to make a good proposal (allow more editing with less work and no new hierarchies) worse (adding hierarchy and less people to do the job)... SoWhy 09:29, 26 January 2009 (UTC)

I have given some arguments for that at #Review or autoreview. The fact is: reviewing is a responsibility, some even goes so far to say this is a legal responsibility. Giving the rights to inexperienced users, who probably won't understand diffs or the consequences of reviewing, might not be in their best interest. Some will understand straight away, others will make good-faith but inappropriate reviews, and might getting blocked or having their reviewer rights removed (and autoreview lost too, so defeating the purpose of the proposal) but most will just avoid reviewing as this looks, precisely, too complicated. We should make editing easier, not more complicated. But autoconfirmed users will be granted autoreview rights, which they probably won't even notice, so the quasi-totality of their edits will be automatically reviewed. Cases where an autoconfirmed user edits a semi flag protected page with an unreviewed latest version should be quite rare, so we should be able to handle them even with a reviewer usergroup having higher requirements for auto promotion. If a good faith user is often in this case, it'll be noticed through Special:Oldreviewedpages, so we can manually grant him/her reviewer rights. Yes it adds a new usergroup 'reviewer', but this one will have an auto promotion, and any minimally experienced good-faith editor will be granted the rights. Inexperienced users aren't the ones who will patrol Special:Oldreviewedpages and the like, so it won't change significantly the backlog. As for the 'moderator' usergroup, it's simply because admins will certainly be overworked and some non-admin users may help out to review changes to full flag protected articles (because of disputes, edit wars, etc). But if this is too much a concern, we can remove it. Cenarium (Talk) 11:42, 26 January 2009 (UTC)

I think these are precisely the problems that make this whole endeavour problematic from the start. That said, there's clearly something to be said for splitting review and autoreview privileges. The problem is that we don't know what percentage of pages will be flagged and what percentage will not, therefore we don't know how many pages autoreviwing will actually apply to. If we don't have an sizeable, active, and vigilent review corps, many many pages will get unflagged and stay that way, making the autoreview privilege effectively meaningless. As with pretty much everything else related to this idea, it all comes down to who's going to be reviewing (a theoretical problem) and how effective they will be at it (a practical one).

My guess is that any implementation, no matter how well thought out, is going to have to be significantly revised once we start seeing it in practice. Specifically, I expect that the requirements for the reviewer group are going to loosen up significantly, but we'll see. I guess that's the point of the trial... ;) LSD (talk) 18:59, 28 January 2009 (UTC)

Key tweak

I would strike out '$wgGroupPermissions['autoconfirmed']['review'] = true;'. This makes vandal reviews pretty easy. Autoreview should be good enough most of the time, and admins can clear out those edits that are not autoreviewed. If the backlog somehow is too large, we can set $wgAutopromote['review'] to something higher than autoconfirmed, without actually messing with autoconfirmed. Aaron Schulz 20:45, 25 January 2009 (UTC)

Yes, that would be similar to #Possible compromise proposal, a reviewer group with an auto promotion higher than autoconfirmed, that can be manually granted and removed. However even semi-protection is not always enough for certain articles, so the option to disable autoreview for autoconfirmed users who are not reviewers on an article would permit both classic Flaggedrevs and semi flag protection. Cenarium (Talk) 00:07, 26 January 2009 (UTC)

Well, I'd personally suggest 14 days and 50 edits. Does that seem reasonable, or is that too drastic? — neuro^(talk) 00:19, 26 January 2009 (UTC)

Well, this can't be decided on the fly, we'll have to discuss this specifically then make polls... It'll be 14 days/50 edits for some, 3 months/1000 edits, for others, etc, but we can use finer conditions, such as number of edits in mainspace. A condition that might be interesting is no recent block, that is $wgFlaggedRevsAutopromote['block'] = x days : not blocked in the latest x days. Most autoconfirmed users won't need reviewer rights since they should edit a semi flag protected article with unreviewed latest revision quite rarely. If it happens often to a user, this will be noticed since his/her edits will come up in Oldereviewedpages, so any admin can evaluate and grant the user reviewer rights. A nice thing to do when a user becomes automatically reviewer would be to give an information message, technically in a way similar to new messages. Cenarium (Talk) 01:31, 26 January 2009 (UTC)

See Wikipedia_talk:Flagged_protection#What_happened_to_review_.3F I oppose the removal of review. Mion (talk) 18:33, 5 February 2009 (UTC)

Rights and reviewers for BLP

Is it possible to allow those newly confirmed with autoreviewer rights to become "mentored" for, say, 50 edits where their work is flagged and enters a pool so that already experienced reviewers or admins can check their work ?

Alternatively an approach similar to Distributed Proofreaders could be adopted (although a more formal approach) where an instructional quiz asks them to do some basic editing - on DP it is not recorded until they pass and are allowed to take it as many times they like till they get it correct. I can imagine it would take the form of asking which to allow and which not to etc.

I appreciate this would cause extra work but it would mean that at least the fledgling could be helped in the first weeks.--Chaosdruid (talk) 02:23, 26 January 2009 (UTC)

To clarify, on DP the quizzes are not "real" page assignments where the responses are reviewed instead of saved; they're pre-prepared quizzes with a script comparing the answer to the "official" one. They do have projects reserved for reviewing users for promotion, but the work is saved for those. Dcoetzee 06:12, 26 January 2009 (UTC)

What about WP:GAMErs who do their fifty and then go to hell?--Cerejota (talk) 07:36, 26 January 2009 (UTC)

It's not really as simple as that because the projects are proofed three times before going to the formatting stage.

So if P1 (lowest level) edits the basic text in the mentor section, the next level P2 edits the page that the P1 has done and this produces a diff page the same as in Wiki. Any diffs are then reported back to the P1 so they can see how the P2 changed their P1 version.

After P2 the page goes to P3 where the page is yet again checked for mistakes and another diff page is created. After this stage the page is deemed to be correct and is moved to formatting stages. Every P1 that qualifies for P2 is asked to mentor newbie P1's - it's not compulsory. Similarly when they enter the F1 stage for formatting.

Whilst it is true that these P1 completed pages are stored, they are not complete as they have to pass P2 and P3 before going up the chain to F1 - and so I cannot see how it would be very difficult to make a similar process here in Wiki.

As for the quizzes, that is my point, they do not produce anything of merit, just ensure that the P1 has gleaned enough knowledge to correctly edit at the P2 level. The quiz is designed to test their knowledge of correctly proofing pages so that they will spot any mistakes the P1 make, and not pass those mistakes through as sighted.--Chaosdruid (talk) 14:02, 26 January 2009 (UTC)

Oldvalidatedpages ?

Is it possible to have a page similar to Oldreviewedpages, for validated revisions ? That is, listing all full flag protected pages with a latest revision that is not validated ? That would be useful to monitor disputes. We'll still have to create a template, something like {{requestvalidation}}, for users to request that an admin (or moderator) validates a revision, similarly to {{editprotected}}, because the revision has consensus or is a non-controversial change to the latest validated version. Cenarium (Talk) 18:11, 26 January 2009 (UTC)

Maybe this special page should be restricted like Oldreviewedpages, so to admins and moderators, it would require another group permission. Cenarium (Talk) 18:26, 26 January 2009 (UTC)

Idea

Idea for better reliability on Wikipedia (and vandal screening):

• Every edit needs to be approved (seconded) by at least one other editor, within a 24 hour waiting/cooling off period.
• Every time an editor gets an "approved edit" they (like on eBay) gain a "+" on your their wikiprofile. This would be a measure of their edit-credibility (edibility)
• Every time an editor gets a "disapproved edit", they gain a "-" on their wikiprofile.
• I'm sure editors will strive to keep their edibility high (expressed as a percentage).
• Other editors can suggest an improved text to a pending edit, say to fix typos in a pending edit, to stop essentially goods edits being voted down for trivial reasons.
• Also, a editor should have the right to retract an edit before the 24hr period expires if they change their mind about an edit, i.e. to avoid a "disapproved edit" if they agree with any comments made.
• If an editor gets 100% disapproved edits (e.g. 0% edibility), over say 10 edits, their account is suspended/barred.
• The bigger/more edits an article has, the more positive votes will be required before an edit gains the "approved edit" status, and thus gets posted on wikipedia, for example:
  • e.g. 1 net positive votes (over 24hr period) for new-ish article with say 100 edits
  • e.g. 2 net positive votes (over 24hr period) for an established article with say a 1000 edits
  • e.g. 5 net positive votes (over 24hr period) for a well established article with say a 10000 edits
  • e.g. 20 net positive votes (over 48hr period) for and article with say 100,000 edits (e.g. 22 positive votes verses 2 negative votes - this would count as one "positive edit", not 22 positives and 2 negatives edits). Obviously the threshold and amount of edits can be customised to best suit practice.
• A person with a high rating has a high indication (but only an indication) that their edit is good.
• Is this too time consuming ... high edit articles probably have a lot of "reviewing" editors that read most edits on that page so I'm guessing not.
• If not enough votes are cast in the time period, the period can be extended (e.g. doubled) or it gets approved or dis-approved based on weighted vote. On low edit articles >50% or more votes, on high edit articles >75% may be needed etc ..

I posted this a while ago on the village pump (it got a mixed review) ... I'll float it one last time here with some tweaks ... —Preceding unsigned comment added by 82.3.228.145 (talk) 22:54, 26 January 2009 (UTC)

That sounds horrid, for various reasons. For starters, what happens after 24 hours if the edit hasn't been approved or not? Will it only be to mainspace edits or to any space? What if they change their mind but someone already made further changes? ♫ Melodia Chaconne ♫ (talk) 23:24, 26 January 2009 (UTC)

For your first question see the last bullet point in the opening post. For your second question - this would apply only to articles not discussion pages etc. For your third question, I guess you can't edit something that has not yet been approved (or dis-approved yet), this would give that editor more impetus to approve or disapprove the outstanding edit and so would drive forward approval of outstanding edits. This idea is an idea in progress, so if you think can be improved then chip in ...

• Firstly, that sounds like a technical nightmare: different pages with different vote thresholds, complex "approval periods", and individual approval percentages -- which, incidently, will very often be misleading, not just 'cause percentage comparisons are notoriously unreliable, but because editors on more popular articles will rake up points whereas those on less trafficked ones will not, regardless of quality. Besides, social ranking systems of this sort inevitably degenerate into popularity contests. Those on one side of a dispute will "+" each others edits and "-" those of their opponents, and vice versa. FR is complicated enough! Adding even more layers of protocols and figures would take it from complex to downright inscrutable.
• Secondly, I don't really see the point of making it harder to "second" older/busier articles. Besides, vandals can easily create 20 sock puppets to "second" their edits, not to mention "+" each other's accounts. Like it or not (and I'm not crazy about it myself), the whole idea of flagged revisions is predicated on a distinct class of trusted editors granted the ability to review. Absent that elite group, and you're left with all of the problems and none of the bennefits; vandalism wouldn't decrease, but it would take longer to effect changes. Hardly ideal!

LSD (talk) 19:24, 28 January 2009 (UTC)

Flagged protection with all BLPs flag-protected?

I have suggested Trial 13: Three month trial of all BLPs + flagged protection? Basically, would FlaggedRevs on BLPs and individually selected articles be a reasonable compromise? --Apoc2400 (talk) 23:08, 26 January 2009 (UTC)

Shear number of BLPS means not really.Geni 02:02, 27 January 2009 (UTC)

There is probably no crisis at the BLP. Now stop worrying and enjoy editing. 82.230.24.185 (talk) 02:10, 27 January 2009 (UTC)

I am not a fan of flagging all BLPs, but in a spirit of compromise I would agree with such a trial. Nicolas1981 (talk) 02:16, 27 January 2009 (UTC)

For a trial, I think it would be a huge mistake to have FlaggedRevs on all BLPs, of which there are well over 300,000. The whole point of a trial is to test out how it works, and we don't want to go from 0 to 60 instantaneously which is basically what we would doing. Trial 3 (all BLPs starting with "z" or some other more limited group) makes a lot more sense since that would only affect a few thousand articles.

One thing to bear in mind is that the very first flagging (I guess it's being called "surveying") is very important and we want to take our time with that. If we turn flagged revs on for all 300,000 BLPs at once, editing will be locked on all of those until someone with "surveyor" status if that's what we call it (a limited group) goes through and reads an article very carefully and verifies there are no BLP violations (this will not be a simple check for vandalism, folks "surveying" an article will need to check sources and the like). In order to avoid an enormous backlog right off the bat it's much better to test subsets of BLPs and to survey them in batches. --Bigtimepeace | talk | contribs 03:27, 27 January 2009 (UTC)

Trials must be limited as voted in the poll, so this is not a valid trial. Cenarium (Talk) 11:00, 27 January 2009 (UTC)

On the discussion page that Apoc links to, I've suggested limiting it to the top 1000 non-top-importance BLPs by the quantity of vandalism over the past 3 months. The trial does need to be limited. I suggest taking discussion to that page. Fritzpoll (talk) 11:13, 27 January 2009 (UTC)

Yes, I'm writing a comment there. Cenarium (Talk) 11:20, 27 January 2009 (UTC)

3 month trial of Flagged Protection on all BLPs beginning with Z makes sense, it's beginning to sound like a worthy proposal that could finally offer a consensus way forward. Riversider (talk) 23:36, 27 January 2009 (UTC)

Except that I don't think that the BLP pages starting with Z include any of the high-profile people - the pages which are both the most likely to have problematic content inserted, and the pages where such content is the most damaging. I believe that it's more important to protect the Hillary Clinton article from problematic edits, than it is to do so with Zeny Zabala. עוד מישהו Od Mishehu 08:26, 28 January 2009 (UTC)

No, that's backwards. OTRS doesn't get a steady stream of complaints from high profile people like Hillary Clinton about problematic content. Hillary's article probably has several dozen people watching it in several timezones. We should be more concerned with the effect the problematic content has on the subject of the article, not on the PR aspects. Mr.Z-man 15:10, 28 January 2009 (UTC)

So am I. The content of a page doesn't harm anyone until someone actually reads it. I think that few people have ever seen the Zeny Zabala page; many have seen the Hillary Clinton page. עוד מישהו Od Mishehu 15:51, 28 January 2009 (UTC)

Hilary Clinton is big enough to look after herself. People have enough sense generally to realised that outrageous suggestions about Hilary are likely to be lies, and through her political career, she will have developed a particularly thick skin. On top of this, there will be plenty of people looking out for her and checking every detail of her entry as Z-man says. People who are not used to being in the public eye, who are less notable and do not have powerful allies, are much MORE likely to find that people believe invented rubbish written about them, and false information published here about them is much more likely to be damaging to their lives, even if it is read by far fewer people, given this, if you feel it would improve the trial we maybe could FP BLPs beginning with Z plus 500 super-notables whose biographies are currently fully or semi-protected - what do you think? Riversider (talk) 16:53, 28 January 2009 (UTC)

Zeny Zabala is read on average 2-3 times per day. However, it hasn't been edited by a human since December 2007. Of the few humans to edit it, only 3 are still active. I would be surprised if it was on any active editor's watchlist. Subtle libel, that on a high-profile BLP like Hillary Clinton would be almost immediately reviewed by a dozen people, might sit for weeks, if not longer before either the subject finds out and complains or someone actually looks it up elsewhere after reading it. There's currently 130 open tickets in the OTRS quality queue, the majority of which are complaints regarding BLPs. Mr.Z-man 20:55, 28 January 2009 (UTC)

See WP:Flagged protection and BLPs for more details on this kind of proposal Fritzpoll (talk) 17:53, 4 February 2009 (UTC)

New Proposal - need some feedback before moving into project space

In order to address BLP concerns in addition to opening up the project, I have concocted a trial of the two systems occurring simultaneously in my userspace at User:Fritzpoll/BLPFlaggedRevs. This bit of spam is neede to get more eyes on it to get a well-rounded proposal before moving it to project space. No polls, please, but edit freely both the main page and the talkpage Fritzpoll (talk) 15:04, 28 January 2009 (UTC)

FlaggedRevs documentation

We now have a number of parallel discussions now ongoing that consider possible implementations of the FlaggedRevs functionality, covering a huge range of configuration options; however, they all have a number of things in common, and I think that these areas should be the focus of our attention. Foremost, every proposal must either include an explanation of, or make an assumption that readers are familiar with, the FlaggedRevs user interface and how the flagging process works.

It is my belief that an important step forward for FlaggedRevs on en.wiki is to create a full but accessible documentation for the aspects of FlaggedRevs that are invariant across all the proposals: how pages are reviewed, how flagging is encouraged, how the workflow of the wiki is affected. An easily-accessible explanation of what the extension will entail and what features it will provide will, I think, go a long way towards resolving some of the innumerable 'trivial' concerns with the entire principle, and leave us free to focus on the important and legitimate issues.

This documentation needs to be independent of any particular configuration of FlaggedRevs, and focus only on the aspects that apply to all users on all wikis. It needs, in effect, to be "site neutral". Partly for this reason, I propose that we write this documentation on http://www.mediawiki.org, in its public-domain Help: namespace. This way, our work will be accessible to any other wiki that wishes to consider FlaggedRevs, and we can ensure a fair and neutral representation of the system. mediawiki.org is a website run by the Wikimedia Foundation, and is part of its SUL network: if you have a global account, you already have a login there - you should be logged in automatically. It runs MediaWiki just like en.wiki, and all the same features are available; it has most of the same community standards as en.wiki although its focus is on the documentation of the MediaWiki software. And it's where all our help content is running away to anyway :D. Since it will be a public-domain resource, once written it can be copied or moved in its entirety without any of the licensing issues that bug us constantly on normal wikis, so we can get it back here without any trouble at all, while moving it from here would be much more difficult.

I have begun work on a framework for the documentation on the appropriate page at mediawiki.org. I have added a few notes on the talk page for those who haven't been to mediawiki.org before. If anyone is interested in helping with this little project, your assistance would be very much appreciated. Happy‑melon 20:29, 28 January 2009 (UTC)

I concur and hope other interested editors will do likewise. Geometry guy 00:32, 29 January 2009 (UTC)

Proposed changes

I propose to change the proposal in the following ways:

• Instead of granting reviewers rights to autoconfirmed users by default, we use auto promotion, so that we can have higher and finer requirements. Autoconfirmed users are still granted autoreview, which means that their edits are automatically reviewed if the previous latest revision was already reviewed.

Rationale: Autoconfirmed users are most often inexperienced and don't know about diffs, the reviewing process, etc, so we shouldn't ask them to review other persons' edits, as editing should be as easy as possible for newcomers, and they shouldn't have such a responsibility. In case of abuse or even good faith mistakes, they may be blocked or have their autoconfirmed rights removed, which we don't want. Reviewer rights can also be granted manually, especially to users often editing semi flag protected articles with latest revision unreviewed. It would be nice to have an explanation message explaining reviewing to users granted with the right.

More discussion: #Review or autoreview, #Review or autoreview for autoconfirmed users, #Key tweak, #Raise the auto-promotion thresholds?, #What happened to review ?

• We have the option to disable autoreview for users who are not reviewers on a particular page. (requires consensus to be turned on)

Rationale: Semi protection is often insufficient for certain articles, especially the ones targeted by sockpupetters or subject to heavy vandalism due to external events. Such articles sometimes require full protection (examples: [3], [4], [5])). A level intermediary to semi flag protection and full flag protection would help to solve those problems.

• We use a 'moderator' user group, able to validate revisions of full flag protected pages, additionally to the admin user group.

Rationale: Admins already have much work and it will necessarily increase due to a number of pages being semi flag protected instead of semi protected. The work or moderators is essentially to moderate disputes by validating consensual or non-controversial revisions. While similar to the {{editprotected}} process, many non-admin users may help in doing so.

PHP configuration

# Limit it to mainspace only
$wgFlaggedRevsNamespaces = array( NS_MAIN );
# Don't set any FlaggedRevs level for new pages
$wgFlaggedRevsAutoReviewNew = false;
# Pages display the current version by default - i.e. unprotected
$wgFlaggedRevsOverride = false;
# This requires it to be turned on by an admin for each page
$wgFlaggedRevsReviewForDefault = true;
# Flagging types
$wgFlaggedRevTags = array( 'protection' => 2 );
# Number of levels (full=2/semi=1/none=0)
$wgFlaggedRevValues = 2;
# Restrict autoconfirmed to flagging semi-protected
$wgFlagRestrictions = array(
    'protection' => array( 'review' => 1 ),
);
# Group permissions for autoconfirmed
$wgGroupPermissions['autoconfirmed']['autoreview'] = true;
$wgGroupPermissions['autoconfirmed']['movestable'] = true;

# Reviewer group
$wgGroupPermissions['reviewer']['review'] = true;
$wgGroupPermissions['reviewer']['unreviewedpages'] = true;

# Giving reviewer rights to rollbackers ?
$wgGroupPermissions['rollbacker']['review'] = true; #?
$wgGroupPermissions['rollbacker']['unreviewedpages'] = true; #?

# Rights for bots
$wgGroupPermissions['bot']['unreviewedpages'] = true; #?

# Group permissions for moderators
$wgGroupPermissions['moderator']['review'] = true;
$wgGroupPermissions['moderator']['unreviewedpages'] = true;
$wgGroupPermissions['moderator']['validate'] = true;
$wgGroupPermissions['moderator']['rollback'] = true; #? 

# Group permissions for sysops
$wgGroupPermissions['sysop']['review'] = true;
$wgGroupPermissions['sysop']['unreviewedpages'] = true;
$wgGroupPermissions['sysop']['validate'] = true;
$wgGroupPermissions['sysop']['stablesettings'] = true;
$wgAddGroups['sysop'][]         = 'reviewer';
$wgRemoveGroups['sysop'][]      = 'reviewer';
$wgAddGroups['sysop'][]         = 'moderator';
$wgRemoveGroups['sysop'][]      = 'moderator';

# Auto promotion to reviewer status, requirements to be determined
$wgFlaggedRevsAutopromote = ; #TBD

# Can users make comments that will show up below flagged revisions?
$wgFlaggedRevsComments = true; #?

Note that technically, the original version can be recovered from this one by setting the autoconfirmed level as auto promotion and removing the moderator rights. Please indicate whether you support or oppose this change, or part of it. Cenarium (Talk) 10:02, 29 January 2009 (UTC)

This sounds close to my proposal - any chance you could help me with the technical config of mine? Fritzpoll (talk) 14:46, 29 January 2009 (UTC)

My proposal is significantly different as it doesn't allow autoconfirmed users to review unless they are reviewers (though they have autoreview). Both can be merged if we add an additional blp-reviewer user group as in Mr.Z-man's proposal. But I'm unsure at the moment if there is consensus to massively apply Flaggedrevs to blps. Cenarium (Talk) 15:03, 29 January 2009 (UTC)

Yes, it has been brought up on the talkpage and I said that I'd wait for more input - I think that the suggestion is quite reasonable, but I have no idea how to implement this, or any othr element of my proposal from a technical standpoint. Feel free to edit the page yourself! :) I would not, with regards to BLPs, that the early straw poll on this page was garnering opposition because of BLP concerns. A simultaneous trial might get us to a point of larger consensus. Fritzpoll (talk) 08:50, 30 January 2009 (UTC)

• Support. This seems to answer the objections raised above by people who want more strict flagging criteria. Furthermore, as long as the criteria for turning on flagged semi-protection are roughly equivalent to the present criteria for semi-protection, this makes Wikipedia even more open. (As a side note, I would oppose turning on FRs for all BLPs by default, because I think that closes Wikipedia too much. However I would not mind if the criteria for turning on flagged semi-protection were somewhat looser than the criteria for ordinary semi-protection, since flagged semi-protection is much more open than ordinary semi-protection is. My best guess, based on the BLP straw poll, is that there would be consensus for this.) Ozob (talk) 17:58, 29 January 2009 (UTC)

• General support: this version maintains most of the openness inherent in the original proposal, while allowing for some finer-grained control. While I have my doubts about a system that proposes to (partially) replace semi-protection (which autoconfirmed users can freely edit) with a system where autoconfirmed users have only autoreview, it's still acceptable. Some of the elements relating to rollback might be debatable, but I don't particularly mind these. I just hope that flagged-protection proposals can be seen, by those advocating wider use of FlaggedRevs, as independent (rather than exclusive) of the idea of implementing what they advocate—I fail to see any non-political drawbacks to flagged-protection. {{Nihiltres|talk|log}} 18:27, 29 January 2009 (UTC)

  The rollback considerations such as should rollbackers have reviewer rights or should a moderator be granted rollback may be discussed later. I added ? next to those kind of entries. There is also whether moderators should be able to grant reviewer rights, or have additional user rights, such as access to unwatchedpages, and same for reviewers. Cenarium (Talk) 18:45, 29 January 2009 (UTC)

• Question. As I understand this is the same proposal as the one above? The code is at least identical. However I see several problems. Both moderator and reviewer permissions are assigned by administrators. However the moderators should satisfy much higher requirements than reviewers. These requirements should be specified (at least approximately). In addition, moderators are granted the right to assign (but not to remove) reviewer permission. What is the rational for this? I actually like this proposal much more than the initial version of FLR Flagged protection. Ruslik (talk) 19:04, 29 January 2009 (UTC)

  Yes, it's to see if there is support to change the text of the proposal and also if there is support to implement the disable autoreview option. The options marked as ? are not definitive and will have to be discussed later. Moderators will essentially 'moderate' disputes by validating consensual or non-controversial revisions, so the requirements would be a certain experience in dispute resolution, a minimal understanding of reviewing. A light process should probably created, but not RFA-like, maybe a 2,3 days discussion, then an admin can grant the access if there is enough support. Questions like "have you been involved in any content dispute ?" should be answered as moderators and admins should recuse from moderating disputes they're involved in. In old drafts, I had considered using the moderator group to oversight the reviewing process, and so to allow them to grant reviewer status to editors in good standing. Not to remove it because they don't really have the 'authority' for that, it's rather an admin rights. But now with the auto promotion it may be unneeded. User groups with multiple rights are also more difficult to handle from a selection standpoint, so maybe we should just add the right to validate. Cenarium (Talk) 02:11, 31 January 2009 (UTC)

• Finally, a !vote. Good God! This is like the third time I've seen this exact proposal on this talk page. But this is the first one to actually have a !vote going. Wholeheartedly support, in any configuration remotely similar to this one --Thinboy00 @295, i.e. 06:04, 30 January 2009 (UTC)
• Weak support - I really don't like the idea of an autopromoted sighter group and giving autoreview to autoconfirmed users at the same time. If we give all autoconfirmed users autoreview, then that means the better we are at keeping the flagged revisions of pages up to date (having the top revision == the last flagged revision), the easier it will be for a vandal using sleeper accounts to vandalize pages and have their vandalism sighted, which seems rather backwards. Perhaps we can start with that configuration initially until we get the autopromoted sighter group requirements tweaked to ideal levels, but I don't see it working as a long-term solution, or even a medium-term solution, especially if we're going to be using semi, rather than full or a special BLP level on BLPs. Mr.Z-man 17:00, 2 February 2009 (UTC)

I think the auto promotion to the reviewer group should be relatively high, but that we should identify good-faith users in need of the rights. If we don't give autoreview for autoconfirmed users, it would be stronger than semi-protection, I don't think we would have support for that. Having the option to disable autoreview for non-reviewers for certain high-risk articles would address most problems with sleepers. We may try other ways to assign autoreview in the future, for example higher requirements for automatic assignment and when an autoconfirmed user is "confirmed" by at least three reviewers, or once by a sysop, autoreview rights are granted. Cenarium (Talk) 16:46, 4 February 2009 (UTC)

autoreview doesn't work on high risk pages, which are under full flagged protection (edits are reviewed by admins), and they can be placed under full protection again if needed for pov pushers, as there comes more specific surveillance on the edits of these 3000 articles, its a good way to find vandals, 150 edits, 30 days as a starter. Mion (talk) 17:07, 4 February 2009 (UTC)

The problem is, that the better we are at keeping up at keeping the top revision == the stable revision, the easier it becomes to vandalize an article and have it be shown to the public. If the top revision isn't flagged, then any edits by people without the review right will have to wait for a reviewer, but if the current version is the stable version, then anyone with autoreview can create a new stable version. Any system that works better when we have a backlog seems rather broken to me. Mr.Z-man 17:18, 4 February 2009 (UTC)

That would rather be very high risk pages or disputed pages, I don't think standards for full flag protection should be much lower than full protection.

Yes, but we have to make the balance between the need for oversight and the need for minimal backlogs. Most articles in Category:Wikipedia semi-protected pages probably won't require autoreview disabled and the vast majority of autoconfirmed users are reliable. Of course, it would be nice to be able to remove autoconfirmed (autoreview if not possible) from a user when abused. But initially and globally, we should assume good faith, and not impose higher security measures than is necessary. In the future, when the system will be well established, we may use more complex assignment methods (such as confirmations by reviewers), but as a start, autoconfirmed looks like a decent level, while if we restrict autoreview to reviewers, we would immediately have enormous backlogs if enabled on too many pages. Cenarium (Talk) 18:37, 4 February 2009 (UTC)

Oppose the requirements are only raised for BLP concerns and render this semi protection proposal unacceptable, see What happened to review ?, people who want to raise the bar to meet WP:BLP per review should discuss this on Wikipedia_talk:Flagged_protection_and_BLPs and not here. Mion (talk) 12:23, 6 February 2009 (UTC)

The proposal in its present state is incomplete (semi-protection is not only used against vandalism) and unrealizable (autoreview has been removed by a developer), so a change is irrevocably needed. This is not only raised due to BLP concerns, I gave plenty of other reasons. Cenarium (talk) 07:42, 10 February 2009 (UTC)

Deferred revisions

Wikipedia:Deferred revisions is a new proposal to use the abuse filter to defer suspect edits for review without the need to enable 'classic' flagged revisions, but able to work with it. Please express your opinions on the talk page. Cenarium (Talk) 18:38, 29 January 2009 (UTC)

Patrol for Flagged protection or not?

Is a solution found for this:

• sighted versions:For articles in the flag group, Recent changes patrol is disabled and talkpages are not flagged.
• Flagged protection: The role of RC-patrolling will be vital on articles with flagged protection on.

Is it technical possible to keep Patrol enabled on the Flagged protection articles ? Mion (talk) 12:09, 2 February 2009 (UTC)

Even as Patrol should be disabled on BLP protection articles ? Mion (talk) 12:11, 2 February 2009 (UTC)

What happened to review ?

$wgGroupPermissions['autoconfirmed']['review'] = true; is deleted from the proposal, "remove untenable setting" , what is untenable ? Mion (talk) 18:25, 5 February 2009 (UTC)

I see Wikipedia_talk:Flagged_protection#Key_tweak, but you're wrong there, instead of opening up the edits, all edits of the autoconfirmed group are rendered suspicious.

So I Oppose the removal of review. Mion (talk) 18:31, 5 February 2009 (UTC)

Edits by autoconfirmed users are still autoreviewed, please see discussions above concerning this. If the developers consider this setting untenable, then the community cannot override this. Cenarium (Talk) 18:59, 5 February 2009 (UTC)

Aaron Schulz thinks the 150 edits number is to low, but that setting is up to the community and no reason to remove "review" from the proposal, but maybe it needs more discussion. Mion (talk) 19:03, 5 February 2009 (UTC)

Autoconfirmed is given after 4 days and 10 edits, not 150 edits. A higher auto promotion plus allowing granting and removal seems necessary, it comes back to the proposed change. Cenarium (Talk) 08:50, 6 February 2009 (UTC)

The discussion about the autopromotion level 10/150 edits is still open, there is no evidence that people who are now able to edit semi protected (the autoconfirmed) should be tagged as vandal editors as in the proposed change, as for removing review rights by admins that already exists, I put a notice on the talkpage for Aaron asking for some more info, lets wait for that....Mion (talk) 09:17, 6 February 2009 (UTC)

I explained in that section that not giving them reviewer rights is not because we think they are vandals, the vast majority of autoconfirmed users are reliable and trustworthy editors, but because they are inexperienced, and we should make editing as easy as possible for newcomers (this is one of the most serious problems of Wikipedia - for example see this). Having review links and diffs all around is not going to make editing easier. Additionally, it would make mistakes in flagging more frequent and users strongly supporting Flaggedrevs to deal with blps would be opposed to this. We won't agree with so low thresholds. Cenarium (Talk) 09:37, 6 February 2009 (UTC)

Yes but the BLP folks are talking on Three_month_trial_of_all_BLPs_.2B_flagged_protection so no talk about BLP in this proposal as this proposal only handles semi and full protection, and if we state that autoconfirmed users are reliable and trustworthy editors we should start from there, and its a trial, as of this moment it would be helpfull if the requested tools on the projectpage go online so we can run statistics on the current incoming edits. Mion (talk) 09:52, 6 February 2009 (UTC)

As for the BLP proposal i requested for a name change BLP protection as people are confusing it with this proposal Mion (talk) 09:52, 6 February 2009 (UTC)

Who and where? Fritzpoll (talk) 09:55, 6 February 2009 (UTC)

User_talk:Fritzpoll#Wikipedia:Flagged_protection_and_BLPs you and there Mion (talk) 09:58, 6 February 2009 (UTC)

Lol - no, I mean "who" is confusing it with this, and where are their statements indicating confusion? Fritzpoll (talk) 10:08, 6 February 2009 (UTC)

Cenarium for example: "and users strongly supporting Flaggedrevs to deal with blps would be opposed to this" Flagged protection is not specific aimed at BLP's. I think we should discuss BLP Protection on the talkpage there instead of here. Mion (talk) 10:33, 6 February 2009 (UTC)

I am not confounding the issues at all. Another flag for blps is not something we are going to agree on any time soon. Semi flag protection will be used for blps as well (some blps are already semi-protected, we're going to try to use semi flag protection for them instead), so we have to consider this and it raises opposition if thresholds are too low. You didn't address my comment on inexperience of new users. Cenarium (Talk) 10:40, 6 February 2009 (UTC)

The difference is that this proposal is specific aimed at general vandalism and the BLP requirement for review on Three_month_trial_of_all_BLPs_.2B_flagged_protection is much higher minimum Wikipedia:BLP, all semi protected articles outside BLP don't need it, and BLP protection settings override flagged protection. Mion (talk) 10:52, 6 February 2009 (UTC)

Yes, and my proposal is to trial the two systems side-by-side, so I need to include the name "Flagged protection" in my proposal as well. Your suggestion of "BLP Protection" is illogical, as it implies only one trial. Fritzpoll (talk) 12:22, 6 February 2009 (UTC)

Cenarium, I don't know if this is true - I don't think you'll get a wide consensus by making it harder for autoconfirmed users to edit semi-protected pages. If the issues relate to BLP semi-protection, as seems to be the underlying concern of the majority opposed, let's trial the things separately as I propose, and discard the bits we don't like at the end of the trial. Fritzpoll (talk) 12:31, 6 February 2009 (UTC)

Fritzpoll, i never said there should only be one trial, I think there is a lot to gain for the BLP trial proposal as a clear proposal with its own tools, review requirements and targets. If we look at it from a user perspective, if you review a flagged protection page, you can lookup the ins and outs on Wikipedia:Flagged protection, the same for BLP page review, the less complex Wikipedia:Flagged_protection_and_BLPs is, the better it works, as for the number of reviewers required on BLP review, that is a high number, so as a side by side trial is technical possible there is no reason to mention semi protection in the BLP page. Mion (talk) 12:55, 6 February 2009 (UTC)

Yes, but I fundamentally disagree that having separate trials is sensible. If we want to find out if multiple things work simultaneously, we must test them simultaneously because their implementation is not exclusive. Fritzpoll (talk) 13:27, 6 February 2009 (UTC)

BLP FlaggedRevs settings overrides Flagged Protection, no test needed for the override.Mion (talk) 13:41, 6 February 2009 (UTC)

(outdent) But we have to see if we have the resources to cope with both systems running in parallel - what happens to backlogs if people who would be doing FP reviewing suddenly start focussing on BLP? Does onehave an adverse effect on the other? Whilst I appreciate what you are saying, in practise separating the trials will not be an efficient or effective way of testing these two systems Fritzpoll (talk) 13:50, 6 February 2009 (UTC)

That is exactly the point why the proposals have to be split, by introducing the proper tools Wikipedia talk:Flagged protection and BLPs/Tools ? for BLP FlaggedRevs there is more control over the trial, for the reviewers on Flagged protection if there is a backlog we can ask the Hugglers if its ok to list these edits on top of the huggle list or something like that, as for BLP review, the amount of pages is hughe and the requirements for review are high (meaning you have to know how to do BLP review), from this review group it would be wastefull if they check edits on Flagged Protection, as we need the expertise on BLP review.Mion (talk) 13:58, 6 February 2009 (UTC)

What's so huge? my trial only flags 1000 more articles than this one? And if you can review BLPs in my proposla, you are also an FP reviewer so the two things are intertwined Fritzpoll (talk) 14:05, 6 February 2009 (UTC)

Yes these are the trial numbers, but I hope we set the trial proposals up for the end targets of the proposals, which is 3000 pages for Flagged Frotection and 225000 pages for BLP's ? What i'm saying is that with 225000 pages you need a big team. Mion (talk) 14:10, 6 February 2009 (UTC)

Yeah, I handle scaling issues in part 3 of the trial. Basically, for BLPs, the trial doesn't come to an end until it's been scaled up over successive incremental increases in flagging Fritzpoll (talk) 14:14, 6 February 2009 (UTC)

(unindent) This comes to the heart of the problem: the proposal in its current state is incomplete: it is (essentially) intended to replace semi-protection when possible, but semi-protection is not only used against vandalism: pov pushing, blpvios, spam, etc, are also reasons for protection. We could multiply the flags - a BLP flag, a POV flag, etc (see this for the extreme case), and assign to each flag a specific reviewer group, but there ! : welcome bureaucracy and other nasty things the community abhors: it'll never happen. Yes, we could single out the blp case, it's one of our most passionated and polarizing issue, maybe a blp-reviewer group would be more accepted (though I doubt it), but it comes down to trust: they are certain users that we should trust as reviewers, but not as BLP-reviewers. I think not, users who are experienced enough to be granted reviewer rights should be trusted enough to follow the reviewing guidelines, that ... we should determine. This means they have to be more informed of course, this is partly addressed by my proposition to use edit intros for all blps, and we could also make sure that the latest entry in the stablesettings log is visible to reviewers (as is done currently for semi-protected pages). Flag protection should not be restricted to prevent vandalism (we should not review blpvios, in a blp, or anywhere), but rather somehow like this: Anything that is either:

• vandalism (as defined here)
• a clear and indisputable BLP violation
• a clear and indisputable copyright violation
• clear and indisputable spam
• ?..

should not be reviewed on any page. It is then up to the user's judgment to edit the page, revert, review, etc.

Additionally, if the administrator who flag protected the page indicates one or several reasons for doing so, reviewers should take those in consideration and make especially sure the edits are in compliance with the relevant policies.

In cases autoconfirmed users make problematic edits to a semi flag protected page, we disable non-reviewer autoreview for this page.

In cases there are still problems with reviewing, we use full flag protection for the page.

Reviewer rights can be removed. It would be nice to be able to remove (and reassign) autoconfirmed also.

Now several possible trials:

1. the flag protection trial: flag protection implementation restricted to would-be semi-protected pages
2. the blp trial: using flagged revisions for randomly-selected blps as a preemptive measure (either in the same configuration as flag protection, or using a specific blp-flag)

I'm biased w.r.t. #2 because I feel we shouldn't use flagged revisions preemptively, but instead increase awareness of our blp policy (with the editnotices) and improve patrolling for blps (using patrolled revisions, a form of passive flagged revisions) before attempting some drastic measures.

I would prefer a trial like this (with reviewing guidelines outlined above):

• Flag protection as in the implementation I suggested: for would-be semi-protected pages and for blps with a history of vandalism/blpvios (less strict, more liberal than the semi-protection policy) - this with proper size restrictions that would vanish in a complete implementation

Cenarium (talk) 02:37, 7 February 2009 (UTC)

The reason I agree with the idea of a secondary BLP reviewer group is precisely because I believe that a) Flagged protection should replace our existing protection mechanisms, and should make it easier, not harder for editors to contribute and b) that BLPs do need to be preemptively protected since the potential damage is that much greater. These two things are impossible to achieve in a single reviewer group, since someone who is misusing their ability to review BLPs should have it removed as a preventative measure (as we do with rollback now) - we can grant it as liberally as we like, but it must be removeable. But it should not be that removing that ability compromises an editors ability to work on other aspects of the project as well, so the permissions should be separate. That's why I want a dual trial of FP and protection for BLPs so that we can see its technical and social effects over the course of the trial - you have to treat them separately precisely because their usage is so dif::ferent. Fritzpoll (talk) 13:57, 10 February 2009 (UTC)

Looking at the page history, I think reviewer for autoconfirmed and surveyor for administators for flagged protection, and a new userright group moderators for BLP reviewers which can be autopromoted (on the required level for BLP) and revoked by administrators and higher ? question for the devs if the new moderator group is ok and is it technichal possible that the surveyor group next to setting flags on pages also have the exclusive ability to review full flag protected pages ? Mion (talk) 14:18, 10 February 2009 (UTC)

Following this reasoning, we would have another reviewer group for articles flag protected due to POV pushing, etc. The reviewer group is removable, reviewers abusing their rights on blps, on pov-pushed articles, or subject to vandalism, will have it removed. If there is consensus to do so later, we can use semi flag protection for all blps (or even during the trials for a few of them), but having separate flags is unpractical. If a user is experienced enough and trusted to review articles semi-protected due to vandalism, POV-push and whatever, why not trusting him/her to review blps ? This is a breach of AGF, and anyway not only blps suffer from blp violations, all reviewers must be aware of the problem. As for preemptive semi-protection, there are other ways to improve our control of blps before considering something so drastic. Cenarium (talk) 16:01, 10 February 2009 (UTC)

I see your logic on emerging groups, but believe it to be flawed. In the case of semi-protection, we currently apply a single instrument to cover vandalism, POV pushing, etc. in the form of semi- or full- protection. In my suggestion that autoconfirmed users are granted the ability to review these pages, I am not deviating from the status quo and am attempting to follow my interpretation of the consensus here and elsewhere that appears to favour the protection system being opened up, and not closed down with a higher bar of suffrage (for want of a better word).

In the case of BLPs, the contentious part about semi-protection under our existing system was the closing off of a large number of our articles. Flagged revisions affords us the ability to meet the concerns of the "libel must be prevented" and "open editing" camps halfway, and in a more effective manner, since all will be able to contribute, but the worst libel is prevented from being immediately visible to Google and our readership (who vastly outnumber our editors). Your logical jump to say that wanting a separate group is akin to wanting separate groups for POV pushing, etc. is based on the assumption that flagged protection replaces the concept of "semi-protection for all articles". The two are not equivalent - I envisage different pieces of work done by two groups, as I lay out in my oft-linked proposal.

Your comment: If a user is experienced enough and trusted to review articles semi-protected due to vandalism, POV-push and whatever, why not trusting him/her to review blps ? This is a breach of AGF.. - I have never specified what bar should be set for the BLPReviewer group. If preferable, it can be automatic, but I want to see it possible to be separately revoked since it is Flagged Revisions being used in a manner other than to identify and prevent obvious vandalism - if a user can't do this, it would be an even greater assumption of bad faith to remove an editor's ability to edit less sensitive articles because of misuse of this reviewer priviledge.

I am not proposing preemptive semi-protection - I am proposing Flagged Revisions. This may sound like a pedantic comment, but in these debates, especially as the community become more widely involved, precision is important. Preemptive FlaggedRevs is more contentious than Flagged Protection because it represents a slight closing up for most BLPs (although an opening up for the permanently semi-d ones), but it is, in my opinion, a necessary one, and one that sparked the initial rush of interest to these pages since it was Jimmy's reason for forcing FR through. I think it is worth trying. Fritzpoll (talk) 16:19, 10 February 2009 (UTC)

Granting reviewer rights to all autoconfirmed users is not going to happen. This setting has been removed by a developer. I gave other reasons as to why this is indeed untenable at #Proposed changes and so the need for a reviewer group: lack of experience of new users, making editing more complex and difficult, much more mistakes in flagging, etc. It would also prevent the use of a 'deactivate autoreview' option for certain articles which need it. So the two reviewer groups can be merged (while giving any autoconfirmed user the ability to flag blps would be largely insufficient to protect blps indeed, but the reviewer group can do this.).

As for blps, there are alternatives to consider before taking such a drastic step, examples: using patrolled revisions, or equivalently, a passive flag to improve our patrolling of blps (using special:unpatrolledpages and special:oldpatrolledpages with a category filter), using a report mechanism so that readers can report "bad content" to reviewers, increase the awareness of our blp policy to editors (already happened using the edit intro, and also offers a link to blp/n, can still be technically improved). Cenarium (talk) 17:42, 10 February 2009 (UTC)

I don't personally believe that the edit notice will be effective, although it may deter some regular editors. I remain to be convinced that passive methods for BLPs will function, and I'm still not convinced that the functions of the two groups are the same and so should be merged for the reasons I have already given relating to the need for granular control in the event of misuse (however well-intended). In the event that BLPs are not included in FR, which I believe to be the most effective, balanced and appropriate way to solve our issues in that area, I will certainly be looking for other methods. But I see no reason for a sticking plaster approach, when we have a system here that is capable of balancing the arguments of many of those on opposing sides. Fritzpoll (talk) 18:06, 10 February 2009 (UTC)

This category filter, next to the split BLP and BDP are all BOP's tagged by category:country ? Mion (talk) 00:29, 11 February 2009 (UTC)

Found it, but the tools need revision Wikipedia:People by year/Reports/No other categories, listed with pages full of categories. Mion (talk) 01:03, 11 February 2009 (UTC)

In the event a blp reviewer misuses the tool by flagging a blpvio, I would also remove the normal reviewer flag as blps are not the only articles affected by blp concerns, so the argument doesn't hold. The community is very reluctant to multiply the number of usergroups and we know a normal reviewer group cannot be the entire autoconfirmed group. So I don't believe we'll have consensus for both a reviewer group and a blp reviewer group. So we're finished if we don't merge them. If an editnotice can deter regulars, then I wonder what flagged revisions could make to new and unregistered users... If a user wants to hide it, I'm sure it can be managed in the monobook.js. For massive implementation, we'll surely have a massive backlog, at least if we're not prepared, that's also why we need a passive implementation to see how we can manage backlogs. Cenarium (talk) 17:47, 11 February 2009 (UTC)

Flag protection, patrolled revisions and deferred revisions

I have made three proposals related to Flaggedrevs. The proposals are a variant of Flag protection (already discussed in #Proposed changes), Patrolled revisions and Deferred revisions. Comments would be appreciated to see if there is support for some of them and what to do next. Cenarium (talk) 15:25, 22 February 2009 (UTC)

Wikipedia:Flag protection and patrolled revisions

I have proposed a version of flagged protection along with patrolled revisions (a passive flag) for consideration here. Cenarium (talk) 15:48, 7 March 2009 (UTC)

Poll on reviewer autopromotion for flagged protection and patrolled revisions

There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers#Poll on autopromotion, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:49, 12 April 2009 (UTC)

Wording and clarity issues

"Readers by default"

"Can edit; a new edit is visible to registered users, but not to readers by default until confirmed by a 'reviewer'". What is a "reader by default"? Is it the same as a non-registered user? Questioningly, GeorgeLouis (talk) 04:35, 26 May 2009 (UTC)

It's meant in the sense "but not by default to readers", where readers is intended as non-registered or logged-out user, yes. There are two tabs, logged-in users go on the 'draft' tab by default but can click on the 'article' tab, and vice-versa. Example on testwiki. Cenarium (talk) 22:15, 26 May 2009 (UTC)

"...but not by default to readers until confirmed..." FT2 ^{(Talk | email)} 08:57, 22 May 2010 (UTC)

"Intermediary"

Surely "intermediate"? FT2 ^{(Talk | email)} 09:02, 22 May 2010 (UTC)