Wikipedia talk:Flagged protection and patrolled revisions/Archive 1

Archive 1

Flagged protection

Section link

I like this, some suggestions:

• Autoconfirmed is not a very high requirement. I suggest completely deactivate non-reviewer autoreview. Hopefully we will have enough reviewers.
• Suggest that all low-profile underwatched BLPs be semi flag protected. Keep adding more as long as the flagging backlog is short.
• Focus this on vandalism and libel. Don't make reviewers into referees in content disputes.

--Apoc2400 (talk) 20:10, 7 March 2009 (UTC)

Thanks for your comments.

• For most semi-protected articles, semi-protection is enough to prevent vandalism/blp violations, etc. So I don't think it's needed to restrict autoreview to reviewers by default (I think it should be done case by case, when justified by disruption from autoconfirmed users - this will have to be determined by policy). If we want to review edits by autoconfirmed users, it can be done using patrolled revisions, as reviewers only are autopatrolled (it's one of the reasons I propose patrolled revisions along with flag protection). This is my personal view but I also think we wouldn't have consensus if we don't give autoreview to autoconfirmed users (based on my analysis of various discussions on this, it would be stronger than semi-protection, more to review so more backlogs, etc).

• I suggest to leave this to another discussion, this is equivalent to use classic flaggedrevs for blps or low-watched blps, which is a contentious issue and has no consensus. My intention is to propose a moderate, but still significant, move, that has a chance of success. Where we should apply (flag) protection is a policy matter, pertaining to the protection policy (which can of course be modified, by consensus). Initially, requirements would be the same than for normal protection, as I prefer to avoid additional policy considerations for now. Even without flag protection, patrolled revisions allow to monitor those articles (it's the main reason I propose it), although it has no preventive/protective effect.

• In case of dispute, the article would be fully flag protected, and admins who are able to validate revisions would deal with this (although we could create an additional 'moderator' usergroup in the future if admins are overburdened). Admins would validate revisions if they are consensual or non-controversial. Reviewers wouldn't have any special status and our dispute resolution process wouldn't be altered. Cenarium (talk) 23:07, 7 March 2009 (UTC)

Semi-flagged protection has disadvantages too, if I understand it correctly. Any change (good or bad) by a new or IP editor locks a page, preventing "normal editors" (autoconfirmed non-reviewers) from making visible changes. An exception allowing all editors to undo vandalism (revert a flagged change and unflag) could reduce the impact. Certes (talk) 18:18, 16 March 2009 (UTC)

It's why it's important to keep the backlog of Special:OldReviewedPages minimal, but since the number of pages where it's used is not very important (compared to massive implementations), we should have enough reviewers to review changes in a timely manner, and so make such occurrences rare. It would be nice to autoreview revisions making a null edit compared to the latest flagged revision, but that would probably affect performance too much. Cenarium (talk) 03:56, 17 March 2009 (UTC)

Patrolled revisions

Section link

I don't get the point of these. Why not just use sighted versions instead? Pages that have them don't have to be configured to use them by default. Also, passive flags tend to be just extra complexity that is neglected, like new page patrol here. On .de wiki, the RC patrol flags for articles are tied to sighting, and so there are barely any unpatrolled new pages there. Aaron Schulz 03:45, 16 March 2009 (UTC)

I think part of the point is to avoid the opposition of those who see the days-long backlog on de-wiki as a failure of FlaggedRevs and evidence that it is unmanagable to use ubiquitous active flagging.--ragesoss (talk) 05:10, 16 March 2009 (UTC)

If we use the same flag for reviewing and patrolling, then we'll have a few problems:

1. Since autoconfirmed users are (generally) autoreviewed, reviewers won't be able to check their edits via patrolled revisions, and so some 'bad' edits will pass through without their notice. Instead, reviewers only are autopatrolled.

   Admins/reviewers could rate pages higher ("quality", or we can call it 'reviewed') than autoconfirmed users (who can only autoreview). This higher level could be used for seriously checking the content of changes, rather than just the "sighted" (patrolled) flag. Aaron Schulz 15:43, 16 March 2009 (UTC)

   The name patrol may be misleading, but I meant it to be a serious flag, more demanding than patrolled edits. I suppose we could use a low-level flag, and a higher one, but I think one or the other would be underused then, or it would be used disparately, as it would multiply the special pages. That may also create problems with autoconfirmed users being autoflagged for the lower one, we couldn't check their edits if the page were not previously reviewed to a higher level. I think we should keep the active flags and passive flag(s) completely independent, the former as a protection tool (very focused), the latter as a monitoring tool (global). Cenarium (talk) 03:55, 17 March 2009 (UTC)

   If the potentially-active flag were underused due to having a different special page, why would a passive one with a separate special page fair better? Also, whether the flags are independent or not, you still need to "patrol" the page first, before being able to diff-review edits (such as those by anons). Aaron Schulz 06:47, 17 March 2009 (UTC)

   Since we want to be able to choose whether an autoconfirmed user is autoflagged or not on flag protected pages, we'd need a flag 'patrol', with autoconfirmed users autopatrolled, and a higher one 'review' with reviewers autoreviewed, but then we'd have the special pages Unpatrolled, Oldpatrolled/active and oldpatrolled/passive, Unreviewed, Oldreviewed/active and oldreviewed/passive, while we have only three (excepting full flagged protection) if we keep them independent, with one passive flag. Cenarium (talk) 16:36, 17 March 2009 (UTC)

2. Special:OldReviewedPages needs to be as short as possible, this is vital to have a successful implementation, so if it also contains Special:OldPatrolledPages, old reviewed pages (where the flag is active) will be lost among old patrolled pages (where the flag is not active), while those are not so vital to review.

   The list can (now) be filtered by "patrolled"/"reviewed". Aaron Schulz 15:43, 16 March 2009 (UTC)

3. The review flag is used to serve as a protection mechanism, while the patrol flag is used for monitoring purposes, so it's not really compatible. For example, when flag protecting a page, the version at the time of protection should be automatically reviewed (to avoid that an old version become the stable one).

   FlaggedRevs will not auto-review the current revision; it will instead tell the admin if they are out of sync and jump to the diff when the configuration is changed. This makes it so that someone actually knows what version is the default after "protection" through such a configuration change. Aaron Schulz 15:43, 16 March 2009 (UTC)

   Not sure I understand correctly, my concern is that admins will stabilize the page the same way they protect, and won't flag the latest revision, or take the time to review it (even if asked to) after that. So no flagged version will exist, so it won't have any effect, or the stable version will be from an old protection. Also, we should have no need for Special:OldReviewedPages or Special:OldValidatedPages. Maybe if there are no intervening edits between the time the admin accessed the stable versioning page and the confirmation, it should be automatically flagged at confirmation. When they are intervening edits, the diff should be shown, and ask for confirmation. Cenarium (talk) 03:55, 17 March 2009 (UTC)

4. Many reviewers won't like to have the diff to the latest patrolled version shown when editing, or the patrolling/reviewing box at the bottom of articles, for pages where flagged revisions are not active. So the patrolling interface should be deactivated by default (maybe an option to turn it on, for interested users), while the reviewing interface should be enabled (for semi flagged protected pages). I don't know if it were possible if we used a single flag.

   Not sure exactly what is meant here, but this doesn't see to require too many tweaks. Are pages only meant to be patrolled from the special page lists? Aaron Schulz 15:43, 16 March 2009 (UTC)

   Yes, only from UnPatrolled, OldPatrolled, recentchanges and from watchlists (maybe others). I think a passive flag shouldn't be too intrusive when editing, or it'll annoy users. Cenarium (talk) 03:55, 17 March 2009 (UTC)

I made a few technical notes at Wikipedia:Flagged_protection_and_patrolled_revisions#Implementation.

A passive flag will give the opportunity to coordinate and substantially improve the monitoring of blps, we have no process so efficient as a flag, even passive, to do that. It would have much more interest than the newpages patrol, so more people would be involved in this. And it would be quite easy for users to patrol the pages they watch and patrol them from time to time: a new way to monitor watched pages. Cenarium (talk) 14:16, 16 March 2009 (UTC)

Maybe, but I wouldn't have much confidence that people would well-maintain passive flags, even for blps. Aaron Schulz 15:43, 16 March 2009 (UTC)

I think it's the idea to use an active flag preemptively that makes opposition to FlaggedRevs so important on en.wiki. But using a passive flag mainspace-wide, and an active flag on a per-page basis, covered by a special policy, could be accepted. So I think we should make a distinction between (passive) flags used for monitoring purposes, and (active) flags used as a protection measure, for community and public reception. Passive flags won't be as well-maintained as active flags, but they'll still provide a monitoring system with no equivalent. Cenarium (talk) 03:55, 17 March 2009 (UTC)

The higher 'patrol' flag doesn't have to have precedence. It can simply act as a passive benchmark. However, it can be made active by "full flag-protecting" a page. As long as it has the capability to become active, then people might use it. Aaron Schulz 06:51, 17 March 2009 (UTC)

There is a 'validate' flag for full flag protection, only available to admins, that can be used in cases of disputes for example. There is a difference of scope between patrol and review/validate: patrol is used as a monitoring device, essentially to improve our monitoring of blps, especially low-watched ones, while review and validate, to enforce a protection. The protection flags should be independent because, for example, an article could be semi flag protected because of vandalism, or fully flag protected because of dispute, while having never been patrolled, or not recently, so it may have other objectionable content that should come to the attention of 'patrollers', on their watchlists through patrol. Inversely, a reason for protection may be particularly specific, for example subtle pov-pushing or blp violations, or sockpuppetry, that wouldn't be well-covered by the patrol flag. In this configuration, I don't see how making the patrol flag active would be natural, and when it should be done from a policy point of view. Cenarium (talk) 16:36, 17 March 2009 (UTC)

Then why not make 'patrolled' as the third level flag (canonically 'pristine')? Aaron Schulz 20:49, 18 March 2009 (UTC)

Maybe we could do that. When the poll ends, if there is consensus for a trial, we'll create an /implementation subpage, where all the details of the implementation will be discussed. We'll need some time to agree on those (and decide the conduct of the trial).

If possible, patrolling a page in the 'patrolled revisions' sense, should automatically mark the page patrolled, in the newpages sense. But it should be one-way only, as the requirements for patrolling should be higher, new pages are NP-patrolled when nominated for speedy deletion, etc. Since reviewers are autopatrolled, this will also have the cascade effect to patrol the articles they create in the NPP sense. The patrolling interface (the box with patrolled/unpatrolled) should appear for pages accessed from Special:NewPages too.

We could add (patrol) links in watchlists also for pages that have never been patrolled, linking to the page with the patrolling interface at the top. This way, reviewers would be encouraged to patrol pages.

To avoid clogging histories with [patrolled by ...] - which would happen for highly edited pages - maybe we should only note the latest patrolled revision, with a simple (patrolled).

I don't see what alternative we have to improve our detection and monitoring of articles, especially low-watched blps, than a mainspace-wide passive flag. Cenarium (talk) 21:04, 20 March 2009 (UTC)

Right, it must generally be passive. But having a third-level flag for patrolling would have the potential to be active, such as if a page is protected. Aaron Schulz 16:34, 21 March 2009 (UTC)

We have three flag protection levels: semi - with review, intermediary - with review and non-reviewer autoreview disabled, and full - with validate. I don't see why we would need another, and it wasn't mentioned in the proposal. The patrol flag has been presented as completely passive and independent, also because it may happen that one or the other proposal be rejected. If we allow the patrol flag to become active, I think it'll confuse people, and what would be the policy basis for activating patrol ? Cenarium (talk) 18:58, 23 March 2009 (UTC)

If a revision is patrolled, it obviously should have at least the rank of a "semi-reviewed" revision This would also avoid workload duplication. Aaron Schulz 21:04, 23 March 2009 (UTC)

Couldn't the flag 'review' be only available for currently semi flag protected pages (and validate for currently fully flag protected pages) ? This would save from loads of complications. Whether patrol implies review for semi flag protected pages would depend on their use, maybe this should wait until we have clarified a policy. Cenarium (talk) 18:50, 24 March 2009 (UTC)

I think we could do this yes (patrolled=>semi-reviewed), independently of a policy, if the reason for flag protection appears when patrolling, so that reviewers can know why the article has been flag protected. It should also appear when reviewing. So we could place the latest stablilization log entry below the reviewing box for example. Cenarium (talk) 13:16, 26 March 2009 (UTC)

I am a bit lost among all these ideas. My understanding is: articles can be reviewed to the first level (semi=1, which corresponds to 'sighted') by 'reviewers', and autoreviewed by 'autoconfirmed' (if the previous rev is sighted); articles can be reviewed to the second level (passive patrol=2) by reviewers, autoreview is not possible, and the level is supposed to be passive (currently corresponds to 'quality', which theoretically can be made active, but should not); reviews to the third level (full=3, corresponds to 'pristine') are made by 'sysops', autoreview is not possible. Ruslik (talk) 08:51, 24 March 2009 (UTC)

I think the easier way is to make the flag 'review' only available for currently semi flag protected page, and the flag 'validate' only for currently fully flag protected pages. So that there's only one flag that is available for all articles: 'patrol', with reviewers being able to patrol any article, and being autopatrolled (but not any autoconfirmed user). The flag shouldn't be visible when editing, but only when the page is accessed from a special page (newpages, watchlist from a (patrol) link, etc).

When a page is semi flag protected, the page is automatically reviewed at the time of protection, reviewers can review when editing, only with [unreviewed]/[reviewed], and same in case of full flag protection, admins have [unvalidated]/[validated], but review is not available. Patrol can still be used, but only when accessed from special pages. It would keep the flags separate. Cenarium (talk) 18:50, 24 March 2009 (UTC)

Excess groups

Why are there 'reviewer' and 'moderator' groups. Both may as well have rollback and such (which seem to be the differences). Also, autopromote only works on the group canonically named 'editor'. You can edit the UI to make 'editor' have the name 'reviewer' though. Aaron Schulz 04:15, 7 March 2009 (UTC)

As I understand 'moderators' have 'validate' right, but 'reviewers' do not. Ruslik (talk) 09:51, 7 March 2009 (UTC)

It would be really nice to avoid a 'moderator' group; we want to add as few "levels" as possible I'd assume. Aaron Schulz 10:46, 7 March 2009 (UTC)

It would be used if we don't have enough administrators to supervise disputes. Although we can spare it for now and see if there is a need for it later. I'll make it less prominent in the proposal. Cenarium (talk) 14:06, 7 March 2009 (UTC)

I just left a brief note on this. Yes, reviewers would be 'editors'. Cenarium (talk) 14:17, 7 March 2009 (UTC)

About rollback: I don't think we should grant reviewers rollback rights. Rollback is sometimes removed due to misuse in disputes, and having to remove reviewer rights together would be drama-seeking. Many admins would also dislike an autopromotion to rollback, even with strong requirements. Rollback is really a tool-like rights, and some users obtained it even though they were not autoconfirmed, so inversely, rollbackers shouldn't be given reviewer rights. I had proposed it for 'moderators' but if we don't use this usergroup Cenarium (talk) 23:35, 7 March 2009 (UTC)

Groups

I suggest automatically making users into Reviewer after 3 months and 100 edits. It can be given or taken away by an administrator manually as well. --Apoc2400 (talk) 20:13, 7 March 2009 (UTC)

Requirements for autopromotion will be determined by polling. It can also be granted at WP:RFR. Cenarium (talk) 21:00, 7 March 2009 (UTC)

I would suggest holding the poll before seeking to get the whole proposal accepted. --Apoc2400 (talk) 22:09, 7 March 2009 (UTC)

Agreed. I said a poll because users will propose various requirements and to sort out which ones are the best supported, some kind of poll would probably be needed. Cenarium (talk) 23:43, 7 March 2009 (UTC)

PLEASE SEE DISCUSSION PAGE AT Wikipedia talk:Reviewers

Editing this proposal

I edited the proposal a bit. Are you ok with this? --Apoc2400 (talk) 21:32, 12 March 2009 (UTC)

Yes, thanks. Cenarium (talk) 02:03, 14 March 2009 (UTC)

Remove Full Flag Protection?

I suggest removing the "Full Flag Protection" option. Not because it is bad, but because it complicates the proposal. Normal full protection will still be available. If needed, Full Flag Protection can be proposed later. --Apoc2400 (talk) 21:25, 12 March 2009 (UTC)

If it annoys people, we can remove it before the final discussions to gather consensus. I'd prefer to leave it up now to give an alternative to full protection. Cenarium (talk) 02:03, 14 March 2009 (UTC)

Should edits by autoconfirmed users really be visible immediately?

I think edits by autoconfirmed users should also require flagging by reviewers. On the other hand, it should be easy to become a reviewer. Just having edits checked by someone is a big improvement. --Apoc2400 (talk) 21:28, 12 March 2009 (UTC)

If we do that, people will oppose because it's too restrictive (it would be more restrictive than semi-protection). There is an option to disable autoreview for non-reviewers on a per-page basis though. Also, edits by autoconfirmed users who are not reviewers are not autopatrolled, so they can be checked using patrolled revisions. See also some comments on this here. Cenarium (talk) 02:03, 14 March 2009 (UTC)

Who are reviewers?

I think we need to define who reviewers are. I suggest we set a starting point and invite people to suggest changes of the proposal. How about 3 months + 100 edits. That should be enough to keep out vandals and sockpuppets, but low enough to let anyone with honest intentions be a reviewer. --Apoc2400 (talk) 21:34, 12 March 2009 (UTC)

It's always possible to lower the threshold, but difficult to remove rights that have been granted en masse. Thus, I think we should err on the side of caution, for the trial, and keep requirements relatively high. Maybe 500 edits, 9 months. Cenarium (talk) 02:03, 14 March 2009 (UTC)

Maybe it should be requested like rollbackers. And at first, automatically give it to rollbackers. ViperSnake151 23:53, 15 March 2009 (UTC)

Any trial run of this will probably generate a lot more buzz and interest than when rollback was released on request, so there could be quite a backlog of people requesting permission and admins trying to sort through who should get it or not. An automatic confirmation would both eliminate that workload and make it a transparent process. As Cenarium points out, it is probably best to take it slowly, though remember that even if rights are granted en masse, if this trial is unsuccessful, it could simply be turned off for everybody. 100 edits can be easily attained with some cat-sorting or spelling patrols, so I'd think a 500 edit, 6-12 month requirement would ensure some level of commitment and knowledge of the project at least for the start. From there it could be brought down to less if need be. Joshdboz (talk) 17:08, 16 March 2009 (UTC)

PLEASE SEE DISCUSSION PAGE AT Wikipedia talk:Reviewers

Flagged protection requirements

I suggest the following requirements for flagged protection:

Initially the requirements for applying flagged protection to an article is the same as for Semi-protection, but it can be applied more liberally to biographies of living people as long as the review backlog is short.

--Apoc2400 (talk) 21:38, 12 March 2009 (UTC)

Something that we may work out in step one or two below. I had proposed this at WT:FLR, based on your initial suggestion:

• "For the trial period, the requirements for applying semi flag protection to an article are the same as for semi-protection, but it can be applied more liberally to biographies of living people as long as the review backlog is short."
• "For the trial period, the requirements for applying semi flag protection with autoreview disabled to an article are those for semi flag protection with additionally, evidence that the disruptive actions are due to autoconfirmed users (sockpuppetry considered)."
• "For the trial period, the requirements for applying full flag protection are the same as for full-protection."

We could revisit the issue when more people will have weighed in. Cenarium (talk) 02:03, 14 March 2009 (UTC)

I am leery of vague statements like "more liberally". While I recognize that BLPs are an area where we want be more watchful for vandalism, etc., we need a statement that doesn't imply that arbitrary protection of a page is acceptable. If we really want a clause like this (I remain neutral on that point), I suggest a more definite wording like "but the threshold for flagged protection can be considered lower than of semi-protection for biographies of living persons as long as […]" or something. {{Nihiltres|talk|log}} 17:54, 16 March 2009 (UTC)

Agree, we'd probably need a discussion if we want to add this. For now, I think we should just use the respective requirements from the protection policy. The only case that has no equivalent is intermediary flagged protection (semi flagged protection with non-reviewer autoreview disabled). After the trial, if we continue flagged protection, a special protection policy will have to be written along these lines. Cenarium (talk) 04:19, 17 March 2009 (UTC)

Do we need a trial?

How about instead of a formal trial, we let this be rolled in gradually as more pages are flag-protected? Passive flagging cannot possible cause any harm, so no trial should be necessary for that. --Apoc2400 (talk) 21:40, 12 March 2009 (UTC)

Yes. People needs to rest assured that there is a sunset clause and that all the issue will be reconsidered after two months. Otherwise, some will be reluctant to support. Cenarium (talk) 02:03, 14 March 2009 (UTC)

There currently isn't a sunset provision in the proposal, though. -- Kendrick7^talk 20:25, 17 March 2009 (UTC)

Before the end of the trial, we'll have a discussion to decide whether we should continue flagged protection and patrolled revisions (separately), if there is no consensus, it will be stopped. If there is consensus to continue, we'll continue. But default is stop. Cenarium (talk) 20:59, 17 March 2009 (UTC)

It's probably time to bring this to more people's attention

I like this proposal, and think it could gain enough support to move forward. I suggest putting some pointers to here up at the centralized discussions board and the community portal noticeboard.--ragesoss (talk) 23:33, 13 March 2009 (UTC)

Yes, I had plan to proceed in three steps:

• note of this at VPR and FlaggedRevs/protection/BLP-related forums for a preliminary discussion, clarify and explain the proposal
• make a centralized discussion, work things out in more details, address concerns, start to assess support, etc
• if there is enough support and we agree on a roll out strategy, watchlist notice to gather final consensus for implementation

A tiny issue, though. I had taken the habit to call this "flag protection" instead of "flagged protection". Maybe we should rename to the later, as it's more used. Cenarium (talk) 02:03, 14 March 2009 (UTC)

Deactivation of 'autoreview' can be implemented by creating a user group (canonically named 'Editor'), to which the 'autoreview' right is assigned, and then autopromoting users to it. Requirements can be low, but administrators will able to remove this right. Ruslik (talk) 09:11, 16 March 2009 (UTC)

I don't know if we'll be able to autopromote to reviewer rights if we do that. We could remove autoreview if we had the ability to remove autoconfirmed, which has been requested for some time. Cenarium (talk) 15:04, 16 March 2009 (UTC)

Appearance

So how will flagged reviews appear to the 'passer by looking up something'? What is the procedure to ensure that 'most changes' are dealt with rapidly (ie tweaks, updates and similar uncontentious additions)? Who will monitor articles where there is a degree of controversy, a rapidly changing situation, or very obscure topics? Who will monitor the monitors? What happens if a patrolled article is shown to have been changed in a negative direction?

Has there been any statistical analysis of changes to articles - what percentage are 'neutrally changed or improved', 'minor errors and confusions, promptly corrected' and 'malicious, argumentative, pseudo-humorous and similar' etc?

There should be a review of the situation at 'certain points' after the system has been settled in to see how effective it is. It may be more appropriate to have certain categories of article flagged and others merely checked and monitored.

The Keynes quote about changing views as the situation changes can be appropriate - but not always. Jackiespeel (talk) 15:43, 16 March 2009 (UTC)

Patrolled revisions is merely an enhanced way to monitor changes to articles, additionally to watchlists and recentchanges. It has no effect on the version viewed by readers.

Reviewers are autopromoted (with requirements TBD), and the rights can also be requested at WP:RFR. Everyone can monitor any article, reviewers have just an easier way to do that. The monitors will be monitored by everybody, following the wiki principle, the rights can be removed by admins in case of abuse. The dispute resolution mechanisms are unchanged. In case of dispute, an article would be fully flagged protected, or protected, admins would handle them. If it is found that an article has problems, they should be fixed.

I'm not aware of such statistics, and I don't think it's feasible to a comprehensible level.

After the trial, a discussion on the future of the implementation will be opened. Patrolled revisions (a passive flag) is enabled for all articles, flagged protection (active flagging), for flagged protected articles only, an admin can do that when it meets specific requirements from the protection policy. There is no preemptive or massive active flagging proposed in this trial. Cenarium (talk) 04:13, 17 March 2009 (UTC)

As for appearance, patrolled revisions have no visible effect to readers. For flagged protected pages, when the latest revision is not reviewed, there is a 'draft' tab linking to the latest revision next to the article tab, that displays the latest flagged revision. There's also an icon mentioning this. See for example pages on Testwiki: or De:. Cenarium (talk) 14:54, 17 March 2009 (UTC)

Full flagged-protection and disputes

One issue that occurred to me a moment ago was that, in the case of full flagged-protection, the usual disclaimer of "This protection is not an endorsement of the current version" would not quite apply: by definition revisions which are flagged are endorsed to some degree. Does this constitute a conflict with current dispute processes and, if so, is there a simple way around the problem? {{Nihiltres|talk|log}} 17:09, 17 March 2009 (UTC)

I think that in cases of disputes, the revision at the time of protection should be (automatically) validated, and then, a later revision should be validated (by an admin) if there is consensus for this revision, or if its is non-controversial compared to the latest validated version. So this would constitute an endorsement, by the community, or the admin making the judgment call if it is believed to be non-controversial, of the evolution of the article compared to the latest validated version. However, the first validation, along with the protection, does not constitute an endorsement of the version. So a version of the article is not endorsed, it is the evolution compared to the previous validated revision that is endorsed, which does not imply endorsement of the new version itself. Cenarium (talk) 17:32, 17 March 2009 (UTC)

That sounds reasonable. {{Nihiltres|talk|log}} 18:22, 17 March 2009 (UTC)

Polling

Can we start polling on this please? --MZMcBride (talk) 17:13, 17 March 2009 (UTC)

This is a wiki. Why not? I added some sections below. Anyone can refactor them if they don't think it's time yet, though. {{Nihiltres|talk|log}} 17:26, 17 March 2009 (UTC)

Complaints about the last poll included that it was buried way down an existing talk page (until it was eventually moved). I suggest starting the poll on its own page, and advertising it more thoroughly than the last one, and have a clear description at the top summarizing what's being polled.--ragesoss (talk) 17:30, 17 March 2009 (UTC)

Moved to /Poll. Dunno where to advertise it. --MZMcBride (talk) 17:33, 17 March 2009 (UTC)

Added to Template:Cent and Template:Announcements/Community bulletin board. Cenarium (talk) 18:11, 17 March 2009 (UTC)

You could advertise it at the village pump too. --Apoc2400 (talk) 18:06, 17 March 2009 (UTC)

Some questions

1. Is there a sunset provision for the edits made to pages? I couldn't find one on the project page, so my apologies if I missed it?
2. Is it necessary that we change 'full protection' along with semi protection? I see some comment on the project page and above about creating yet another usergroup to deal with "fully protected" pages that will not actually be protected. I'm hesitant to change the protection scheme because I like full protection as is--no one makes changes to the page without going through some consensus process. Most edit wars are between registered users anyway, so allowing them to edit a version seen by registered users seems silly. If this supplements rather than replaces fully protection, then I apologize for misreading things.
3. At the end of the day, how many usergroups will there be?

I'll probably have more questions later. Thanks in advance. Protonk (talk) 18:38, 17 March 2009 (UTC)

• Normal semi- and full protection will still exist. I suggested a sunset provision for the edits, but few seemed to agree. --Apoc2400 (talk) 18:41, 17 March 2009 (UTC)

Flagged full protection would be able to deal with exceptionally severe cases of vandalism. Evolution for example spent some time fully protected because of long-term vandalism from one serial sockpuppeteer, and would have been an ideal candidate for flagged full protection. Hut 8.5 18:57, 17 March 2009 (UTC)

I guess I should be more clear. I see the value of flagged protection but I am unclear if the implementation of flagged protection will prevent me from protecting articles traditionally. Protonk (talk) 19:06, 17 March 2009 (UTC)

Whoops. Just saw the above reply. Thanks. Protonk (talk) 19:07, 17 March 2009 (UTC)

We may try to use it in cases of disputes, and see how it works. It would be done as I explained here. But full protection could also be used, in cases of unstoppable edit wars for example, although edit-warring for a draft page is quite pointless...

Semi-protection would also be available. For example if a page is very heavily vandalized, we should semi-protect it, temporarily. Or the history would be full of vandalism/revert, vandalism/revert, etc. It's not worth the pain.

The number of pages where flagged protection would be used isn't comparable to a massive implementation, so I dare hope revisions will be reviewed within minutes, a few hours at most. We'll see, but I don't think we should consider the use of an 'expiry' for flags yet.

I had proposed a 'moderator' group to validate edits (to avoid overburdening admins), we could try to gather consensus for that separately. Cenarium (talk) 19:21, 17 March 2009 (UTC)

Questions

I have a few questions that I could not see addressed elsewhere (sorry if I missed where they are answered).

1. When an article is full flagged protected is an edit by an administrator automatically validated? If not do they presumably have the option to mark it as validated? Will admins be allowed to validated their own edits or will it require another admin to review them? Will the usual standard from fully protected articles be applied, ie. administrators should make sure that any edit they make has consensus on the talk page before making it?
2. Has the standard for patrolling articles been decided? At the moment I see it says "satisfy certain other requirements defined by a guideline" but this is a pretty important point - if there are a lot of requirements then I would be less likely to support and participate in reviewing than if it just sticks to the avoiding vandalism and BLP violations requirements.
3. Similar question to number 2 but what is the standard for reviewing semi-flagged protected articles? Davewild (talk) 18:43, 17 March 2009 (UTC)

1. Admins would not be autovalidated, and wouldn't be asked to validate. But they could validate their own edits manually, and even if we disallow this, they could bypass by changing the stable settings of the page, so devs probably won't want to do that. I considered to add an option 'dispute', no autovalidation, not proposed to validate if enabled, but autovalidation and proposed to validate if disabled, but that would make things more complicated. Maybe later.
2. That would be requirements concerning violations of policies, such as vandalism, blp violations, npov, spam. But nothing about quality, accuracy assessment, etc. We can start working on a guideline.
3. The standards for reviewing articles would be, the same than for patrolling, but with additionally, taking into consideration the reason for protection. For examples, if it's sockpuppetry, making sure the user editing is not an obvious sockpuppet, with the same disruptive edits. If it's blp violations, a particular attention should be given to avoid blp violations.

There is also some kind of a "reviewers noticeboard", where in ambiguous cases, the proper course of action can be discussed. Cenarium (talk) 19:42, 17 March 2009 (UTC)

With question one I am less talking about the software preventing admins from reviewing their own edits but rather about the policy that is set down. I can see arguments both ways on whether admins should be able to review their own edits (having a check to make sure admins are editing within protection policy as against unnecessary bureaucracy.

I do not want npov to become a requirement for reviewing - it can be awfully subjective whether adding or removing some content is unbalancing an article and making it pov. The requirements for reviewing need to kept straightforward enough that any good faith editor would agree on whether the edit should be reviewed or not. It should also be kept simple enough that a long time is not required for each review. Davewild (talk) 20:03, 17 March 2009 (UTC)

I agree it should be ok to review your own edits if you are a reviewer. Many articles have a small number of editors that edit and monitor them routinely. It is precisely those editors, who are most familiar with the subject matter, who you want to be reviewers and that means they ought to be able to review their own edits, as that will make things easier on everyone. Admittedly this won't help in cases where editors with a POV are edit warring, but I don't think any automatic mechanism is going to help in those cases. I see flagged version as mostely being useful to prevent those cases, and I can think of several, where a silly or POV inspired edit is visible on a page is visible for several hours (or even days) because all the editors that have that article on their watch lists are busy doing other things. Rusty Cashman (talk) 04:25, 19 March 2009 (UTC)

Editing a fully flag protected page then validating one's own edits should be regarded the same way as editing a fully protected page. So, the policy on admins editing protected page should be applied.

Patrolling and reviewing is fundamentally different in the sense that there is no 'urgency' to patrol a revision, while there is a certain urgency to review edits to flag protected pages, or deal with them. I agree the guideline should avoid introducing ambiguous cases, especially for reviewing. But in the same time, users should be encouraged to raise ambiguous cases to the relevant noticeboards: if a user is unsure about some content in a blp, it should be raised at the blp, or reviewers noticeboard. Agreed it should be quite straightforward when to patrol/review and NPOV is indeed highly subjective, but they are still clear and indisputable cases, so we could say something like "blatant npov violations should not be reviewed", and same for blatant copyvios (e.g., clear from a google search). We could also distinguish the instructions in the guideline from advises, and hints of best practice. The first patrol should also have a special care. But we're really going to discuss this issue after the poll if there is consensus for the trial. Cenarium (talk) 22:10, 22 March 2009 (UTC)

"version viewed by readers by default is the latest flagged revision."

The line "Flagged protection is a proposal to allow administrators to enable an "active" flag on a given article. Reviewers can flag revisions, and the version viewed by readers by default is the latest flagged revision." seems to be causing some confusion in the poll, as it appears to contradict the table in the next section. Should it be clarified to say that IP edits to semiprotected pages and all non-admin edits to fully protected pages are not viewed by default? Right now it looks just like flagged revisions until you read further, so its contradictory at this time. –Drilnoth (T • C) 19:24, 17 March 2009 (UTC)

Scope of test?

So, I'm imagining all currently protected pages (except WP:MAIN, etc.) would be switched over to flagged protection for the duration of the two month testing period? -- Kendrick7^talk 20:04, 17 March 2009 (UTC)

I'm not sure whether this switch would automatically change protected pages to flag-protected pages or now, but I think that a fair number should be done manually if it isn't automatic. –Drilnoth (T • C) 20:06, 17 March 2009 (UTC)

As I described here it is not a good idea to switch all protected and semi-protected articles to semi-flag protection and full flag protection. Instead we should switch about half of the articles. This will allow us to compare the effects of flagged protection with the effects of ordinary protection so that we can quantify how much better or worse it actually is. Right now, we have no hard data, so the true foundation of all our arguments is emotional; that's why discussions of flagged revisions are so violent. The right fix is to get some data. That will settle the issue (and likely in the direction of flagged protection). Ozob (talk) 13:18, 18 March 2009 (UTC)

Sounds good. –Drilnoth (T • C) 13:19, 18 March 2009 (UTC)

Trial conditions

What are the trial conditions? I mean, I'm a long way out from science, but in my experience there are normally measures put in place at the outset which are used to indicate the success or failure of a trial. It would be nice to see some thinking on this before the trial begins, to save divisiveness after the trial ends. What are we looking for with this trial? There doesn't seem to be any indication of what the purpose of the trial is, or to what articles it applies to. Is it only BLP's, or all articles? Is it a subset of BLP's, so we have a control group, or are we comparing against the previous two months worth of data? What comparisons points are there? Is there a way to randomise between semi-protecting and flagging, by which I mean, could the devs whip up a randomiser so that when an admin goes to semi-protect, it will either semi-protect or flag? What are we looking to achieve with this trial? Better protection for BLP's? If so, what do we compare? And what else will we measure? Will we look at whether anonymous editing drops off? And if so, is two months a long enough period? And what level of drop off is acceptable? I think it is silly polling on whether the trial should happen. It's far better to work out how to run the trial. Refusing to run the trial means we learn nothing. I take it that after the two months the Wikipedia will be restored to the functionality it has now while the community discusses the trial and works out what lessons have been learnt? Maybe a two week discussion and reflection period and then a poll on whether and how to roll out fully? Hiding T 14:06, 18 March 2009 (UTC)

Lot's of questions there! I'll just say that I think that, for this trial, implementing it only on BLPs would probably be good... it would limit the number of articles that need reviewing and really focus on where most of the action with patrolled revisions. If we decide to continue on, I think that implementing it on all articles would be good.

I also agree with your assessment that after the trial we deactivate the feature, discuss for a couple weeks, and poll for a couple weeks to see what general feelings are about the test. –Drilnoth (T • C) 14:15, 18 March 2009 (UTC)

I see this not so much as a trial to scientifically find out how it works, but rather to let people try it and see how it works in practice, rather than just trusting what people say. --Apoc2400 (talk) 16:03, 19 March 2009 (UTC)

I disagree with you. Whatever trial we do should be done as carefully as possible because people are going to rely on the statistics we generate. Even if we introduce a huge, obvious bias into those statistics, people will use them because they'll have nothing else.

As far as the specifics of the trial, it seems to me that as stated, the proposal works like this:

• The proposal applies to all articles, not just BLPs.
• The proposal does not provide for a control group.
• The proposal does not define success or failure of the trial.

What I think should happen is this:

• There should be a control group. It should be easy to tell which articles are in the control group and which are not; this is why I've suggested elsewhere that the control group should be articles beginning with the letters A-M and the numbers 0-4.
• Success of flagged protection should mean:
  1. Semi-flagged protected and fully flag protected articles have a statistically significant smaller quantity of vandalism than unprotected articles.
  2. Semi-flagged protected and fully flag protected articles have a statistically identical or greater number of anonymous edits than unprotected articles.
  3. On average, edits requiring manual flagging are flagged in 24 hours or less. (The precise number is subject to discussion, of course.)
• Success of patrolled revisions should mean:
  1. Wikipedia experiences a statistically significant decrease in total vandalism during the two month trial period than in the preceding two months.
  2. Wikipedia experiences a statistically significant decrease in the median time to reversion of vandalism.
  3. On average, all edits are patrolled in one week or less. (Again, the precise number is subject to discussion.)
• Failure would be the opposite of these, such as statistically significant increases in vandalism.
• The trial is inconclusive if these criteria are only partially met or if there are no statistically significant changes in the quantity of vandalism.

That leaves open the question of how exactly to measure some of these. At one time I came up with a long list of possible metrics. It's at Wikipedia:Flagged_revisions/Trial/Proposed_trials#Possible metrics to measure success of trials. It's an imposing list, but it would be nice to have all of this data available. I think it would give us enough information to figure out how effective the proposal is. Ozob (talk) 22:52, 19 March 2009 (UTC)

Post-poll discussions

If the trial is accepted, before the implementation, we should create /implementation and /trial subpages to discuss the issues. I think guidelines should be created at WIkipedia:Flagged protection, Wikipedia:Patrolled revisions and 'Wikipedia:Flagging guideline' (encompassing patrolling, reviewing and validating), and an informal page Wikipedia:Reviewers.

• /Implementation: discussion on the details of the implementation, technical aspect, wording of system messages, etc
• /Trial: conduct of the trial, and related matters (measures of success, etc)

When all this is done, we can implement the two-month trial and at the end, start a community discussion on whether we want to implement flagged protection and patrolled revisions (separately). The default is: stop the implementations, so we'd need consensus to continue one or the other implementation. What do you think ? Cenarium (talk) 18:10, 23 March 2009 (UTC)

Yes, this is a good idea. Could we also list issues to think about on the subpages? Hiding T 12:54, 24 March 2009 (UTC)

Sounds good. –Drilnoth (T • C) 13:25, 24 March 2009 (UTC)

Issue to think about: Who, during the trial period, are "reviewers"? Should it be granted like rollback? Automatic for a certain set of users? (maybe not autoconfirmed, but 1+ month and 1000+ edits or something like that?) Any other ideas? –Drilnoth (T • C) 18:53, 24 March 2009 (UTC)

That would be an issue to discuss at /Trial. Cenarium (talk) 18:57, 24 March 2009 (UTC)

I'm concerned that post-poll discussions will provide further mechanisms to delay what is already long overdue. The talk has been going on (in various forms and forums) for a year or so; let's get on with it. SteveMcCluskey (talk) 18:28, 26 March 2009 (UTC)

←Is there any issue with starting this discussion now? The poll result seems certain. Kevin (talk) 00:33, 27 March 2009 (UTC)

I agree with Steve here. Let's go. --MZMcBride (talk) 03:13, 27 March 2009 (UTC)

OK. Seeing as this is a trial, is there any benefit to creating all the separate pages listed above, instead of keeping things centralized, either here or on a sub-page? Kevin (talk) 03:29, 27 March 2009 (UTC)

First I agree with the point that we need to wrap up any "post-poll discussion" very quickly and get on with it already. But at the same time there are clearly some things we need to talk about, and it's okay to take an extra week or two to make sure we do this right rather than going off half-cocked. I would suggest we limit as much as possible the things under discussion and also set a firm deadline (maybe 10 days?) by which the discussion will conclude. In addition to some of the technical stuff that I don't understand (and which will hopefully be easier to deal with) I see at least two big things we'll need to figure out:

1. How do we measure (roughly - we don't need to get to crazy with this) success or failure? What kind of metrics do we use?
2. Who are the reviewers?

I think it is absolutely critical to figure out number one before we run this. We need ways to extract information from this trial that helps us figure out how the trial went. Post-trial discussion can then be based on actual data rather than a bunch of subjective impressions. We can change/add metrics as we go if necessary, but we should have at the outset something which says "these are the kind of things we are going to be looking at/for during the trial."

The reviewer question will probably be easier to settle. I would think the most likely group will be all rollbackers, but regardless we should not get bogged down in permanently deciding the reviewer issue. Rather we should just do whatever seems most feasible and reasonable since this is just a trial.

And while the poll may not close for a little while I think we can set up the broad parameters of the discussion right now on the safe assumption that we have consensus for these trials. Also I guess I agree with Kevin that it's probably better to keep discussion as centralized as possible, rather than splitting it into several pages. "Flagged revs" has been an overly confusing and labyrinthine discussion as it is. --Bigtimepeace | talk | contribs 06:17, 27 March 2009 (UTC)

It's critical to complete and agree on the 'principles' of the implementation, and the promotion to reviewer rights should be discussed then set clear here, discussion already began. Please participate. Cenarium (talk) 18:06, 28 March 2009 (UTC)

Created Implementation and Trial subpages. We need to complete and agree on the implementation 'principles', and work on the trial conduct and draft policies. It should be fine to start with preliminary discussions before the end of the poll. Cenarium (talk) 00:51, 28 March 2009 (UTC)

Absolutely. We can start discussing the trial implementation details while the poll is running. It will probably end with a large majority in support, but we can leave it open for a while to let everyone comment. Meanwhile, we can work on the details. --Apoc2400 (talk) 18:13, 28 March 2009 (UTC)

Another Question

I am fairly certain I know the answer to this, but I would simply like to make sure: would the implementation/trial of this proposal in any way affect unprotected pages? I believe that it doesn't, but I would like to make sure before voting. ErikTheBikeMan (talk) 20:31, 24 March 2009 (UTC)

Flagged protection should have no effect on unprotected pages, in the trial or in full implementation if we get there. Patrolled revisions apply will apply to all pages, including during the trial, but they function as more of a monitoring system and should have no real impact on the ability to edit articles, functioning kind of link a better version of Recent Changes Patrolling. –Drilnoth (T • C) 20:35, 24 March 2009 (UTC)

Community attention

About bringing the community's attention to this... isn't it time yet? A watchlist notice would help to bring the opinions of a lot more people, and as I remember we had this for the last poll at an earlier stage. Chamal ^talk 05:15, 29 March 2009 (UTC)

This has been advertised at WP:CENT and various pages. There's sufficient participation for a trial proposal imo, we'll use the watchlist notice for the major discussion with poll that will happen at the end of the trial on the continuation of the trial. Also, adding it now that the poll is well advanced would be a little unfair, as the tendency is clear. Cenarium (talk) 17:20, 29 March 2009 (UTC)

Clarity?

Quoting from the article:

"When an autoconfirmed user edits a semi flagged protected page, the new revision is automatically reviewed when the previous one is. But not when the previous one is not, to avoid insertions of unnoticed vandalism or violations of policies. This second case should happen quite rarely, as edits are continually flagged by reviewers."

This is not very clear.

Questions to try to understand this:

- the new revision is automatically reviewed when the previous one is WHAT? Reviewed?

- What does "automatically reviewed" mean?? - isn't review a "manual" process, done by a human reviewer?

- "but the new revision is not reviewed when the previous one is not". Is this supposed to mean the new revision CANNOT BE reviewed before the earlier revision is reviewed and approved???? If so, it would be clearer to say that.

Thanks, Wanderer57 (talk) 22:08, 30 March 2009 (UTC)

I think the second and third whens here mean if, i.e. an autoconfirmed non-reviewer's updates to a semi-flagged article would appear once all outstanding unreviewed IP/newbie edits had been reviewed, or immediately if there were no backlog. The logic is that you might autoconfirm a useful edit without noticing vandalism pending review at the other end of the article. This can happen however careful you are: if the vandal strikes whilst you are reading the article prior to clicking a section edit link, you may never be shown the offending text. Please can a proposer confirm or correct this interpretation? Certes (talk) 12:19, 31 March 2009 (UTC)

I'd like to see personal flags

One of the BLP's I've taken an interest in is subject to frequent vandalism, POV editing, etc. Much of it gets reverted or edited by the various people watching. Something I've been doing is once every week or two I a diff against my last edit to detect vandalism or POV text that managed to slip past the the editing/correction by multiple parties. What I'd like to be able to do is to flag that a particular version is "good" meaning that in my opinion the net edits since my last edit or flagging have been constructive. These flags would only be visible to me.

Personal flags would also be useful to someone that visits an article intermittently and is also interested in the changes since the last visit. I watchlist them but would love it if there was a way for me to flag a particular edition and much later I could go back and do a diff against that edition. In this case I'm interested in the net changes made and normally don't care about the day to day edits. --Marc Kupper|talk 01:24, 1 April 2009 (UTC)

Bug

On account of the fact that Brion has indicated that turning FlaggedRevs on on en.wiki is a Big Deal that is going to take a lot of optimisation, performance upgrades and load balancing to avoid crashing the site like they did with the first rollout of the AbuseFilter, there's nothing to lose by getting the ball rolling on that ASAP. Accordingly, I have filed T20314. Start the clock... :D Happy‑melon 20:45, 2 April 2009 (UTC)

Resolved as a duplicate of bug 18244. Let Cenarium do his thing. --MZMcBride (talk) 21:01, 2 April 2009 (UTC)

Things like requirements for autopromotion of reviewers are not fixed yet. I'd also strongly suggest to consider moving FlaggedRevs autopromotion to the core, which should be done before the implementation, as we'll probably have several usergroups with autopromotion, if we're going to make autoconfirmed a usergroup or use an intermediary usergroup. Cenarium (talk) 20:26, 3 April 2009 (UTC)

A test implementation on testwiki would be great for testing beforehand, however. Cenarium (talk) 20:44, 3 April 2009 (UTC)

I submitted T20334 for a test implementation. Cenarium (talk) 02:31, 4 April 2009 (UTC)

Poll on autopromotion

A poll on autopromotion is drafted here, help in its elaboration is welcome. Cenarium (talk) 00:11, 12 April 2009 (UTC)

It is now opened. Cenarium (talk) 13:45, 12 April 2009 (UTC)

When is the trial period?

I haven't been following very closely to this discussion so the question I'm asking might have been answered somewhere. But I've tried for a few hours today to figure out when exactly the trial period is. The only thing I seem to be certain is that the poll has ended on April 1st, the trial period will be two months, but I still don't know if it already started or when it will. Can someone help? Thanks. —Preceding unsigned comment added by 140.247.4.64 (talk) 18:51, 23 April 2009 (UTC)

We're not sure. Now that we know what we want more precisely, we'll request that the developers implement the configuration (see just below). It may take some time, but they have already started working on this. Cenarium (talk) 22:53, 29 April 2009 (UTC)

It would be good to state that the trial is starting in summer or not befor august or has not started yet. This would make the search for the answer on the talk page unecessary.--Stone (talk) 12:20, 20 June 2009 (UTC)

So, are we waiting for some development. Isn't vandalism higher during the summer? Sad, there has been no progress since April? Can we publicize what proponents can do, here? -- Mjquin_id (talk) 23:04, 22 August 2009 (UTC)

Implementation request

I think that now we can formally request the implementation. The poll on autopromotion for reviewers closed as no consensus. There are still a few unresolved issues at the implementation subpage, they can be handled by developers at bugzilla, and we'll probably have enough time to finish to set up most of the policies before the implementation. It's T20244. Cenarium (talk) 22:49, 29 April 2009 (UTC)

According to a post by Brion on wikitech, the developers are planning on rolling this out, but there's no fixed schedule yet. Cenarium (talk) 20:35, 25 May 2009 (UTC)

Alternative: Time-limited invisibility

Did anyone play with the idea of making non-reviewed revisions automatically visible after some time, say, 17 hours after the "last known good" version, with various additional effects? This would address at least two issues:

• kills the immediate gratification of drive-by vandals
• alleviates the dependency on the reviewers.

Possible additional bells and whistles:

• Time-released: When 17 hours passes after the last review, only those non-reviewed edits will start popping up which were made 17 hours ago since the current moment. Drawback: extra load on servers; but this may be done in disrete batches, say, every 4.7 hours absolute time.
• "Mark as inappropriate": Visible non-reviewed versions may be marked as inappropriate by any editor, so that the viewable version reverts to the reviewed one.
• A notice pops up, with the option of see/diff-to the "last known good".
• Etc.

Any thoughts? - 7-bubёn >t 15:01, 18 March 2009 (UTC)

There has been some discussion about making unreviewed edits visible after a time limit. I favor it as a safety valve against unreasonably long flagging backlogs, but others are against. For a two month trial I think we can do without. If the backlog is kept short then it is moot, if it is long, then more people will agree on a time-release. --Apoc2400 (talk) 16:02, 19 March 2009 (UTC)

No software changes would be required in this case, anyways: The community could just agree to grant reviewer status to a bot. The bot could also include additional safe-guards which would not be appropriate in the mediawiki software proper. --Gmaxwell (talk) 19:09, 25 August 2009 (UTC)

Details needed

Could we have more details in the project page answering these questions:

Criteria for protection

At the moment the current version just says "During the trial, semi flagged protection is intended to be used with the same requirements as for semi-protection, and full flagged protection (see below), with the same requirements as for full-protection." Unfortunately, I couldn't find any policy which actually details these criteria beyond a comment on WP:RPP that "Full protection is used to stop edit warring between multiple users or to prevent vandalism to high-risk templates; semi-protection is usually used only to prevent IP and new user vandalism". WP:PROTECT is surprisingly silent on the issue, although it does refer to the essay WP:ROUGH. Although it makes some sense to allow admins to apply judgement and discretion for PP, it may be appropriate for something as contraversial and polarising as flagging to have more definite criteria.

Admin rights

The current version gives "Reviewers" rights over semi-flagged pages and "Admins" rights over full-flagged protection. Could someone explain - in the project space - the rationale for giving admins these rights rather than reviewers.

Full flag protection is the equivalent of full protection, and only admins can edit fully protected pages, so it makes sense to grant the validate rights to admins and admins only. Cenarium (talk) 23:58, 29 March 2009 (UTC)

Without this the main page couldn't be made editable by everyone. :) --Gmaxwell (talk) 19:07, 25 August 2009 (UTC)

Criteria for approving

Rather like WP:CSD, I think we need a clear understanding of what kind of edits will be disapproved and a clear bias in favour of approval. I've started a proposed guideline at Wikipedia:Flagged protection approval - please edit away! AndrewRT(Talk) 23:35, 29 March 2009 (UTC)

Inactive?

Should we tag this as {{historical}}? There seems to be little hope of an actual implementation. Kevin (talk) 22:42, 18 August 2009 (UTC)

I'm finding it hard to follow the evolving status of the Wikipedia:Flagged revisions and/or Wikipedia:Flagged protection and patrolled revisions proposals. Are you saying that they're unlikely to be implemented? How do you know that, and/or where is the best place to follow the progress of all this? — Mudwater ^(Talk) 23:29, 18 August 2009 (UTC)

Any relevant discussion is all over the place and very thin on the ground. A request to turn on the feature was made in April, then in May User:Brion Vibber posted that it could be set up by Wikimania (late August), then more recently posted that we may see a test configuration on a test server this month. My feeling is that a potential test configuration is an awful long way from an actual implementation. Kevin (talk) 23:53, 18 August 2009 (UTC)

I see (sort of). Thanks. — Mudwater ^(Talk) 00:08, 19 August 2009 (UTC)

http://flaggedrevs.labs.wikimedia.org/wiki/ looks to have something. {{Nihiltres|talk|edits}} 05:03, 25 August 2009 (UTC)

New York Times article

The NYT just posted an article related to this: Cohen, Noam (2009-08-25). "Wikipedia to Limit Changes to Articles on People". The New York Times. ISSN 0362-4331. Retrieved 2009-08-25.. But it seems to me they got the impact of the trial wrong, as I clarified here: http://community.nytimes.com/comments/www.nytimes.com/2009/08/25/technology/internet/25wikipedia.html?permid=42#comment42 - did I get it right, or are "wikipedia officials" talking about a different kind of trial? There have been a confusing array of proposals out there.... --NealMcB (talk) 03:28, 25 August 2009 (UTC)

See also the clarification by the foundation: [1] --NealMcB (talk) 05:19, 30 August 2009 (UTC)

OldReviewedPages private?

1. Reviewers have access to Special:OldReviewedPages, listing all flagged protected pages where the latest revision is not confirmed.

This could be interpreted as saying that access to OldReviewedPages will be limited to reviewers, was that the intent? If this information is treated as confidential it will be more difficult to measure and report on the impact of the change. Since the information is inconveniently available by scanning page histories, I can't see what gain could be achieved by making access more difficult. Does anyone oppose changing the page to read "Special:OldReviewedPages is public list of all flagged protected pages where the latest revision is not confirmed"? --Gmaxwell (talk) 19:05, 25 August 2009 (UTC)

As currently implemented, OldReviwedPages displays the number of users watching each page; it is this data, not the FlaggedRevs content, that is sensitive. (also)Happy‑melon 19:30, 26 August 2009 (UTC)

Big policy changes under the radar.

First, it was the new living biographies policy and now it's the flagged protection policy: I learned about the changes through the news media rather from Wikipedia itself even though I visit multiple times a day. Editors are not being given enough notice that major policy shifts are about to take place and where they can join the discussion before the final vote takes place. Issues such as these should appear on the main page asking for more feedback from editors before being put into affect. Wikipedia has no problems asking for money or for users to take a survey on the main page so why not asking for feedback on issues that shake the foundations of the site and its philosophy to the core. The majority of editors are actually improving content rather than playing the Wikipedia power struggle game and scanning the policy proposals (of which there are too many to follow all of them anyway). I have in the past contributed to discussions about flagged revisions and would have done so more if I knew that the debate was coming close to an end.

The idea of flagged revisions is interesting and if there was a problem of excessive vandalism I would be for it. However, all the proponents of flagged revision --- with all of their rhetoric about vandals --- seem to neglect that Wikipedia has still been getting better overall despite vandalism. This means the current model is still working and all this doomsday talk about vandals ruining Wikipedia has no basis in reality. I've even seen quotes in article about this change saying that Wikipedia's slowdown in article creation is related to the site's quality and therefore flagged revisions are needed. Jam-packed with non-sequitors! It seems to occur to no one that the reason article creation has slowed down is because Wikipedia's coverage is largely complete. If a person cannot see that, their judgement as a Wikipedian is basically worthless. Flagged revisions are not necessary at this moment in time and most of the arguments that support them are flawed. If Wikipedia doesn't start notifying editors better about major changes, article creation will suffer. Why? Because if there's a third time a major policy change occurs and I didn't feel like the community was informed enough beforehand, I'll stop contributing. Jason Quinn (talk) 18:54, 26 August 2009 (UTC)

Despite media reports to the contrary, this page is actually the definitive plan for how flagged revisions is proceeding. It was advertised extensively when the discussion and polling was going on, and is basically a compromise worked out following the earlier discussions that you may have participated in. The actual plan is a lot more open than what media reports have implied.--ragesoss (talk) 19:16, 26 August 2009 (UTC)

AsI understood what we accepted, we accepted a trial limited to BLPs only, of flagged revisions only, and in some one particular mode. Not multiple modes and simultaneous trials of other changes also, extending to all of Wikipedia. Ragesoss, who is actually running this, and who will be monitoring this? I do not think the details here have any general acceptance in the community--we were told the details were just a matter of figuring out the technical implementation, but this is much more than that. I suggest that it be narrowed down very considerably. DGG ( talk ) 18:42, 27 August 2009 (UTC)

This was more or less what the poll was about, and seems to be the closest thing to a community-created plan that we have. I don't know how much it's changed since the poll, but I don't think much. It's a two month trial, but it's actually more conservative than using it for all BLPs: it introduces flagged protection as an alternative to protection. It also allows flagging of any other article (patrolled revisions) that does not affect how the page is displayed so the latest edit is always visible even if not flagged. The earlier poll was about a more aggressive trial that I think put the equivalent of flagged protection on all BLPs, but this was the compromise that raised the level of support from about 60% to about 80%.

The recent news has been taken out of context: figuring out the implementation is what is going on at the new test wiki. I don't think there is anyone specific running the final decisions about how to deploy it here; Brion, it seems, will make the decision on when to start the trial once test wiki configuration has been tested and the workflow figured out, but he's going based on the assumption that the poll showed widespread (80%) support for the gist of this proposal. At the end of the two month trial, there will be more discussion to decide where to go from there. The Foundation has been pretty clear that the Wikipedia community is in charge of whether and how to use flagging and that they aren't going to impose things on us.

As for the other extension being tested, Reader Feedback, there hasn't been any on-wiki discussion that I know of and that may actually be imposed on us in order to have similar configurations deployed on all projects for cross-project comparison.--ragesoss (talk) 19:31, 27 August 2009 (UTC)

To be fair to Jason Quinn, the discussion wasn't that widely advertised. Most Wikipedians that don't watch the village pump constantly probably didn't notice. On the other hand, this is just a test implementation and there should be an even bigger community discussion at the end of it. The press is somewhat jumping ahead. --Apoc2400 (talk) 21:23, 27 August 2009 (UTC)

There was a watchlist notice as well, but even that isn't something that all active editors see regularly. It'd be nice if we had a normal procedure for advertising the really important polls, something hard to ignore like the notice of new talk page messages. Even the biggest discussions don't attract more than a tiny fraction of active users.--ragesoss (talk) 22:17, 27 August 2009 (UTC)

Wikipedians that do not follow their watchlist notices, the signpost articles, the weblog postings, the mailinglists, nor the Village pump, with all due respect, should not complain about missing their opportunity to express their opinion. If you don't follow the news, how can you expect to be informed ???? Are people supposed to start mailing all individual contributors when discussing important stuff ? Should we call you by phone, or send snail mail letters? Now THAT would garner a lot of complaints, and even then not everyone is likely to have read stuff. If you want to have a say, be an active Wikipedian. Active Wikipedians take note of their watchlist notices or other venues of information. If you don't, well, too bad for you, in my VERY personal opinion, you have lost your right to complain about "not being informed". It's like these parents that expect their children to be raised by the schools these days. Sorry, but you simply don't get my sympathy, if you refuse to pay attention. —TheDJ (talk • contribs) 00:40, 28 August 2009 (UTC)

I think you actually highlight part of the problem, which is that there's no one place to go to stay informed. Most of those venues have signal-to-noise ratios and publication paces geared toward metapedians, and none of the venues are consistent enough to be the sole way to stay informed. It's tough to know what one ought to follow; the Foundation blog and the Signpost are the only ones from your list that I would consider very well suited to people who aren't super involved, and even then most of the content won't be of interest and so may not draw people to check back often. The Signpost only has about 1000 - 1500 readers per week, I estimate. I don't know how widely watchlists are used, but there are a significant number of longtime contributors who don't use them and casual contributors are probably even less likely to check watchlists. And for major changes in the way the site works, we ought to want to give occasional contributors a voice as well as really active contributors.--ragesoss (talk) 01:46, 28 August 2009 (UTC)

We want people to work on improving the encyclopedia rather than just hang out in project space, on blogs and arguing. The watchlist notice is good, but if I remember right this poll was only on there for a few hours. --Apoc2400 (talk) 10:19, 28 August 2009 (UTC)

I've proposed to use a talknotice to better advertize in the future. But there's been no responses yet. The discussion on continuing the implementation at the end of the trial should be massively advertized. Cenarium (talk) 15:52, 30 August 2009 (UTC)

So has the trial already started or not? Or did it already end? Lots of talk about it, but where is it? NVO (talk) 20:29, 30 August 2009 (UTC)

It hasn't started yet. They're still doing (or rather, just starting) configuration testing on a test wiki. "The coming weeks" is the best we have for an ETA.--ragesoss (talk) 00:34, 2 September 2009 (UTC)

Honestly, unless it's something displayed in a 72pt bold, bright red, flashing marquee in readers' faces or having a bot spam announcements to all >1 million user talk pages, I don't see how it's going to get more into the discussion. Perhaps this is more symbolic is turnouts in many U.S. elections if not worse. That or that many people have been under a rock for about the past year. Or maybe some just plain DGAF or are otherwise ambivalent about the whole thing. MuZemike 00:14, 4 September 2009 (UTC)

Standard of review for patrolled revisions

What exactly is the standard of review being proposed for patrolled revisions? Saying an article about a living person does not violate WP:BLP is not so simple. Are we talking about:

1. a best effort scan for obvious BLP problems?
2. verifying that each potentially contentious statement has a reference?
3. checking each reference to verify that it actually says what the article claims?
4. checking that each reference is a reliable source?
5. checking the living status and notability of each person mentioned besides the subject?

One arguably might need to do all of the above (and more) to assert the article does not violate BLP. It could require more work than a featured article review.

While I am not a lawyer, it seems to me there is also a potential legal issue here. As I understand it, while the Wikimedia Foundation is largely protected from legal action over article content by Section 230 of the Communications Decency Act, this protection does not apply to individual editors. While I suspect an editor who makes a good faith edit while ignoring some defamatory content faces little risk, I'm concerned about the potential exposure for a reviewer attesting that an article is free of such content, particularly in a way that other reviewers will then rely on.

One possible solution might be to make it clear that reviewers are only expected to do 1. above and that subsequent reviewers should not rely completely on the patrolled flag. Another approach, at least for the first review, might be to ask the editors who follow the article if they know of any outstanding issues with the current revision and set the patrolled flag the first time only if no such issues are raised. The initial reviewer would then be merely summarizing a collective judgement, not asserting their own opinion. (I first raised these issues at Wikipedia talk:Patrolled revisions, but no one seems to be watching there.) --agr (talk) 23:14, 30 August 2009 (UTC)

Good point. I hope Wikimedia's lawyers take a good look at this and address the concern. 2help (message me) 17:30, 1 September 2009 (UTC)

Flagged protection - which articles?

I'm trying to figure out which articles will be flag protected when this is implemented. Is there a discussion somewhere? Will it only be semi-protected and fully protected articles? Thanks. Mahanga^Talk 22:06, 1 September 2009 (UTC)

I think BLP first. Darrenhusted (talk) 22:22, 1 September 2009 (UTC)

I don't think there is a consensus. The trial that was approved some months ago did not specifically mention BLP. Ozob (talk) 23:54, 1 September 2009 (UTC)

According to the stuff up above it will be for BLP protected articles first. Darrenhusted (talk) 00:04, 2 September 2009 (UTC)

I don't think that's the case. The proposal calls for flagged protection as an alternative to conventional protection during the trial, so it won't be rolled out en masse to any class of articles; instead, it will be left to administrator discretion (as with semi-protection) for articles that need it on a case by case basis consistent with the current semi-protection policy.--ragesoss (talk) 00:32, 2 September 2009 (UTC)

which leaves testing incomplete - results of a test run with 10,000 articles cannot be scaled up to 1,000,000. Fine for testing the tools, but won't <if successful> say much on efficacy in full-scale deployment. Perhaps the number of censored articles must progress during the test to hard targets, say, 10,000 BLPs on day zero, +10,000 on day 14 etc... NVO (talk) 04:51, 4 September 2009 (UTC)

Results of a test run where flagged protection is applied "by hand" will show that the mechanism works (or not). It tells us nothing of the sociological impact of large-scale, automatic application of the mechanism. But I think that's OK - we need to learn whether "hand-applied" flagged protection can work in practice. --Alvestrand (talk) 06:02, 4 September 2009 (UTC)

Implementation

This mailing list thread may become something of interest. --Gmaxwell (talk) 04:15, 28 September 2009 (UTC)

The powers-that-be are aware of concerns and pledge to poke the techs.  Skomorokh  04:35, 28 September 2009 (UTC)

FWIW, in addition to asking a couple times on Wikitech-l I ask board member Kat Walsh on at Tue, Sep 15, 2009 at 12:17 AM and Mon, Sep 21, 2009 at 12:06 PM to get updates from the staff. She did not obtain and updated and advised me to take it up with Sue, which is what inspired me to create the foundation-l thread. --Gmaxwell (talk) 04:46, 28 September 2009 (UTC)

It's been so long that I wonder what the real impediment is. I'm thinking that there must be active resistance at a foundation/staff level for this to have stalled for so long. Either that or they are working on something way better to show us. Kevin (talk) 05:16, 28 September 2009 (UTC)

The whole flagged revisions deal got too confusing after a while, but I was just wondering what the major difference to the code is between our version of Flagged Revisions and the German Wikipedia's. Never really understood why it takes many many months to code what seems like it should be a simple adaptation. NW (Talk) 05:21, 28 September 2009 (UTC)

The enwp configuration here is pretty different from dewiki's … what was decided here was a more focused and gradual tool: Making flagging work as kind of softer protection. Kudos to all who contributed to that solution, I think it's more clever than anything I would have come up with.

There has not been any coding going on related to this recently, at least not anything in the public repository but this isn't surprising because the work is already done. The completed configuration is here. Of course, it is likely there will be bugs and required enhancements which require development resources— but with nothing activated even on the test site we won't discover these things. --Gmaxwell (talk) 06:14, 28 September 2009 (UTC)

Time to give it a spin

It's time to give it a spin: http://flaggedrevs.labs.wikimedia.org/wiki/Main_Page

Looks like there are a lot of UI issues that need to be worked out. You can help by leaving comments on the comments page and by becoming an admin there (just ask) and changing the user interface messages yourself. Cheers. --Gmaxwell (talk) 03:30, 29 September 2009 (UTC)

• Where's the beef? I mean, the content? Found Ronald Reagan but look at these red links. NVO (talk) 04:27, 29 September 2009 (UTC)
  • Any problems if we copy paste complete articles from en:wiki across for the trial?--VirtualSteve ^{need admin support?} 07:28, 29 September 2009 (UTC)
    • I suppose there must be some critical mass of articles and users for a meaningful test. Right now it's a test of a test (of a test?), good enough to see that the upper right corner buttons are hardly legible on my screen... and that's it. Fix the buttons and go live. NVO (talk) 08:00, 29 September 2009 (UTC)
      • The most important articles to copy over would be those with templates or images in the upper right hand corner. Red links in the body of the text hardly matter for this test.   Will Beback  talk  19:24, 29 September 2009 (UTC)

Intermediary flagged protection + semiprotection

Just a technical question: Will it be possible once flagged protection is implemented to have a page be under both intermediary flagged protection and semiprotection, such that anons can't edit, and autoconfirmed users can submit edits for review? Someguy1221 (talk) 01:12, 30 September 2009 (UTC)

Yes, I had imagined this could be used for heavily vandalized, highly contentious pages (such as Barack Obama), or strongly vandalized pages with socking problems, and in other similarly severe situations. Cenarium (talk) 15:45, 30 September 2009 (UTC)

Per Webster's New World and other dictionaries, "intermediary" is the wrong word; as an adjective, it means "providing a link between"; it suggests an agent operating between two entities. "Intermediate" is the word we're looking for here, I think. - Dank (push to talk) 13:05, 7 October 2009 (UTC)

Wikipedia:Targeted Flagging

This has now been delayed for months due to technical requirements, it is also somewhat complicated. I've come up with a much simpler proposal that might do a lot of good, happen sooner, and really help with BLP problems. Please take an open-minded looks at Wikipedia:Targeted Flagging.--Scott Mac (Doc) 17:14, 23 December 2009 (UTC)

Patrolled revisions...the same as recentchanges with flags?

See Wikipedia_talk:Patrolled_revisions#How is this different from Special:recentchanges->living people? ηoian ‡orever ηew ‡rontiers 05:01, 25 December 2009 (UTC)

Inconsistent wording

"A revision can be confirmed by a reviewer only when the page is semi or intermediately flagged protected (and not when fully flagged protected). A revision can be validated by an administrator only when the page is fully flagged protected." I think this means to say "A revision can be confirmed by a reviewer who is not an administrator only when the page is semi or intermediately flagged protected (and not when fully flagged protected). When the page is fully flagged protected, only an administrator can confirm." DGG ( talk ) 16:23, 6 January 2010 (UTC)

tech blog update

See http://techblog.wikimedia.org/2010/01/flagged-revisions-your-questions-answered for the latest from the Foundation. - BanyanTree 05:24, 8 January 2010 (UTC)

New version

I have made a new updated version here, what do you think of it ? Cenarium (talk) 01:10, 1 May 2010 (UTC)

Hi there Cenarium; I've glanced at the diff between the versions, and I think this is an improvement, but I'm not positive just yet. It's tough to look at differences based on a totally separate page. Since we know that the current page is outdated, here's what I'd suggest: go ahead and make the change to that page, preferably breaking your change up into several edits (though if you want to make one big edit, that's probably ok). The rest of us can make fixes to what you wrote, and make sure that nothing got lost in the process. Sound good? -- RobLa (talk) 00:03, 6 May 2010 (UTC)

Helping out with Flagged Revs

(repeat of my mail to wikien-l): Hi folks, as of yesterday, I'm working as a contractor at Wikimedia Foundation, helping out with several things, one of which being the Flagged Revs rollout.

One thing I'm going to be helping William and the crew out with is working out some of the unanswered questions in the description of the rollout phase on this set of pages.

I've been following the threads and playing around with the features, but I'm probably not as up to speed on this stuff as many of you are, so I'm sure I'll be begging your indulgence from time-to-time.

If there is anything on the pages above that you know needs correction or clarification based on the existing consensus, please be bold make that fix. Citations back to email discussions on anything controversial would be especially helpful for me, but not required. I'll be updating those pages based on my understanding, so it'll be helpful to start from a base of current understanding rather than what the understanding was a year ago.

Thanks for your help! -- RobLa (talk) 00:20, 6 May 2010 (UTC)

I noticed there's no images on this complicated (to new users, at least) page. I probably don't need to tell you that images greatly help users understand concepts and features. You could go even further and create an example page with a use case complete with screenshots. Even more, a short 1-2 minute video could be created and embedded on the page. Mahanga^Talk 15:53, 20 May 2010 (UTC)

Yup, you're right. There's a number of things that are too complicated about this set of pages. Regarding pretty pictures, there's a start on that here: Wikipedia:Flagged protection and patrolled revisions/Terminology. As soon as the naming discussion concludes, it'd be a good time to put those diagrams front and center. -- RobLa (talk) 07:01, 22 May 2010 (UTC)

Restructuring this set of articles

There's a lot of work to be done on this set of articles. Here's what I think needs to happen, and would love some help in actually making it happen:

• The template should purely be for Flagged Protection (or rather, whatever name comes up in the naming discussion
• The navigation template should be: "Trial · Terminology · Reviewing guideline · Testing". Everything else should probably find a new home somewhere (perhaps archived)
• The more complicated proposals for permission schemes should be preserved, but they shouldn't be front and center. The permission proposal at Wikipedia:Flagged protection and patrolled revisions/Trial is the one that should be displayed most prominently at this point.

I'll hopefully get to this next week, but would love it if someone beat me to the punch on this. -- RobLa (talk) 07:10, 22 May 2010 (UTC)

Unacceptable to modify the trial completely in a way that the community repeatedly rejected and not even informing of it. I am going to open a request for comment immediately. Cenarium (talk) 12:49, 22 May 2010 (UTC)

First, for the record, I notified the community on May 14. However, the most controversial change has been undone, so I'm hoping we can move on.

Now, since we're one week away from deployment, these pages still aren't very close to being ready. Is there anyone ready to take the lead on paring these down to a sensible subset, and reworking the terminology? I may do it if no one steps in. -- RobLa (talk) 00:59, 8 June 2010 (UTC)

Request for comment on flagged revisions trial

I have created a request for comment on the flagged revisions trial, motivated by an unexpected, unannounced and publicly undiscussed change of configuration removing the reviewer usergroup. Please weigh in there. Cenarium (talk) 13:01, 22 May 2010 (UTC)

Some concerns

I have some concerns about this program, first of all while I am glad to see that something is finally being done on the issue of overprotection, I do worry that Flagged protection will simply replace it. Specificly I'm worried that patrolled revision will simply make the situation worse, preventing several well known editors from immediatly updating a majority of articles. I don't know, to me it seems like a slippery slope and in a lot of situations I feel semiprotection would be favorable over the highest level of security offered by this inituative. Basically, I'm afraid that several pages will be prevented from immediate changes without much of a criteria. Is there any talk of criteria that will be used to evaluate these pages before the highest level of protection is offered? --Deathawk (talk) 20:18, 11 June 2010 (UTC)

The conditions for using the highest level are the same as for using full protection. Cenarium (talk) 20:25, 11 June 2010 (UTC)

That would be level 2 right? --Deathawk (talk) 20:36, 11 June 2010 (UTC)

Yes, and for level 1 it's the same as for semi protection. Cenarium (talk) 21:23, 11 June 2010 (UTC)

(ec) See WP:PROT#Pending changes protection (trial) for the current draft of the criteria.
Regarding your concerns that editors won't be able to make changes that are immediately visible anymore, I can only repeat what I've been saying all day long: The key is to keep the backlog of unreviewed changes very short, in the order of a few minutes. If we can manage that, then any autoconfirmed editor can still continue to edit Level 1 PC protected articles as before. There is no question that you, with only a glimpse at your registration date and edit count, will be immediately made a Reviewer. That means you actually will be able to edit some articles that are currently fully protected due to ongoing autoconfirmed vandalism, if they are switched over to Level 2 PC protection.
Again, if we can keep the backlog of unreviewed changes minimal, then editing privileges will remain largely the same. Freer than before in some respects, very brief delays until publication to logged-out readers in some rare circumstances (registered users will still always immediately see it!). What we get out of it is that we need to worry much less about libelous statements introduced into the many thousand obscure BLPs we have, assuming they are protected with it. It's a slight trade-off, but I am convinced that most content editors will never even notice the difference! If they do, we'll be using it wrong and should adapt.
It's possible that Pending Changes protection will largely replace current protection levels, somewhere down the line. Nobody can say that yet, though, that's one part why we do this trial, on a limited number of articles, for a limited time span: To find out how well these new levels will work here on enWP.
Amalthea 20:43, 11 June 2010 (UTC)

Guidance?

A week ago I posted proposed revisions to the first 4 paragraphs in the "critical thinking" article on "talk". Short explanation too of why each is being suggested. No responses yet from any of the administrators or watchers of that article. In contrast to what happened initially, which was that I naively tried to edit the article and my edits were immediatly deleted. Seeing your guidance: How long should I wait for responses/discussion on the talk pages? Is there a way to post the draft revision of the article (without the explanatory interjections)? Thanks. --Pfacione (talk) 22:05, 16 July 2010 (UTC)