This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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 So Why 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)

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)

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)

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)

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)

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)

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)

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)

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)

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.-- Res 2216 firestar 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)

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)

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.-- Res 2216 firestar 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)

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 Mac Dui 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 Mac Dui 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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 Mac Dui 18:54, 25 January 2009 (UTC)

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)‎

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)

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)

# 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)... So Why 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)

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)

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)

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 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)

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. River sider ( 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? River sider ( 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)

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)

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)

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.

# 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 -- Thin boy 00 @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)

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)

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)

$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)

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)

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)

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)

"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)