Wikipedia:Requests for comment/Pending changes trial

This RFC is closed, issues should be directed at Wikipedia talk:Pending changes or more appropriate talk pages.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Background

• flagged protection and patrolled revisions
  , a specific implementation of flagged revisions, was closed on 1 April 2009.
• The Wikimedia Foundation created a team for the rolling out of the trial, a testing site was created to test the configuration, it is used since September 2009.

Situation

• The team in charge of rolling out the trial has announced they were in pre-rollout phase. The rollout is expected in the next few weeks.
• Only flagged protection will be part of the trial, patrolled revisions has not been developed yet.
• The configuration as requested, flagged protection with reviewer usergroup and option to deactivate autoreview, is currently enabled on the testing site and fairly stable.
• For some time the team wanted to deploy for the trial a version with no reviewer usergroup and give to autoconfirmed users review rights while the community had repeatedly rejected this possibility.^[1][2][3][4] It was later reverted to the original implementation.

Closure

Moved to

Wikipedia talk:Pending changes/Trial. Cenarium (talk) 22:25, 13 June 2010 (UTC)[reply

]

Using flagged protection

In the consensus formed for this trial, it had been decided that the policy for using flagged protection was the same as for using semi-protection; and for flagged protection without autoreview, that it was the same as for full-protection. However it hasn't been decided in which cases an admin should use semi-protection instead of flagged protection or vice-versa, or if we should use control groups and such.

Comments

(conversation moved over to

Wikipedia talk:Pending changes/Queue -- RobLa (talk) 21:55, 10 June 2010 (UTC))[reply

]

Reviewing

Comments

I think we need a place where reviewers can report edits they're unsure about accepting or not and where this can be discussed, some sort of reviewers' noticeboard. We also need to get a guideline ready, there's the

Wikipedia:Reviewing guideline which we should probably merge in Wikipedia:Pending changes. Cenarium (talk) 02:24, 11 June 2010 (UTC)[reply

]

Advertising

The trial will need to be advertised to editors. The sitenotice seems not adequate as we should focus on editors and the watchlist notice is not sufficient because a considerable number of editors don't use the watchlist frequently. The use of a notice which is displayed in edit mode and on talk pages, maybe also project pages, and that can be dismissed, has been proposed. But there's no implementation of this.

Comments

Is something been done on this on the technical level ? I.e. a new message created, or can the sitenotice be hidden - in a neat way - in the main/portal/category/file namespaces for the duration of the trial notice ? Cenarium (talk) 13:21, 7 June 2010 (UTC)[reply]

It's probably too late to implement a site notice-type message for edit pages (as far as I know). However, there is still the standard message that does show up on these pages, which can possibly be made more prominent at the beginning of the trial: http://flaggedrevs.labs.wikimedia.org/wiki/MediaWiki:Revreview-locked . On talk pages, it seems like just having a standard template would do the trick. -- RobLa (talk) 05:12, 8 June 2010 (UTC)[reply]

The goal is to let as many editors as possible to know about the trial, so they can give their impression and help build a consensus on continuing or discontinuing the implementation at the end of the trial. We absolutely need to advertize broadly so that the consensus formed is representative of the editing community as a whole. It's distinct from the interface messages used in the articles where the feature is on. I had warned of this issue several times since 2009. Cenarium (talk) 13:13, 9 June 2010 (UTC)[reply]

Just to clarify, I think we should use the sitenotice for logged-in users, but anonymous editors should also be able to know about the trial, so we need to find something to let them know about it. Cenarium (talk) 13:24, 9 June 2010 (UTC)[reply]

Let's see what things look like after the first week. I suspect that this is going to get all of the attention that we want, but we'll try to drum up more interest if it appears we aren't getting enough after a week. One way to do this could be something using an

edit notice on the main namespace, but I'm not familiar enough with how that works to know for sure if that's the right tool for the job. -- RobLa (talk) 04:34, 13 June 2010 (UTC)[reply

]

I've asked at

VPT. I think it's important to have the opinion of unregistered users too on this trial. Cenarium (talk) 04:44, 13 June 2010 (UTC)[reply

]

Granting reviewer rights

To make sure we have a large enough pool of reviewers.

Comments

1. I had mentioned the possibility to add the reviewer usergoup a few days before the trial (with no rights) so we have time to make some granting before it begins, what is your view on this (now a bit late but still possible) ?
2. I've requested a database report here so we can immediately start granting reviewer rights at medium scale without waiting for people to request. The DBR is at Wikipedia:Database reports/Potential reviewer candidates (currently more than one year old so unusable).
3. We should create a standard template explaining the reviewer right, that admins give to users to whom they granted the right (or a variation). We can use two templates or alternatively a parameter to distinguish between when this is requested by the user and when the admin took the initiative to grant the right. Cenarium (talk) 15:07, 9 June 2010 (UTC)[reply]

Agreed, even though we will be starting small I think it would be very beneficial to start handing out the flag prior to implementation so that we have a bit of a running start (or at the very least don't start a mile from the starting line). James (T C) 21:55, 10 June 2010 (UTC)[reply]

I requested this in Bugzilla as bug 23922. Sorry for putting in the request late. -- RobLa (talk) 23:07, 11 June 2010 (UTC)[reply]

I started

Template:Reviewer-notice. Cenarium (talk) 01:31, 11 June 2010 (UTC)[reply

]

FYI, the first database reports have been generated, at Wikipedia:Database reports/Potential reviewer candidates, see also AN. I'm not sure if we should leave an explanatory message to users who are granted the rights, or if the sitenotice is actually sufficient. Cenarium (talk) 03:09, 12 June 2010 (UTC)[reply]

Note: there is now a "Reviewer" group, so it's possible for admins to start granting reviewer rights. Currently, this group doesn't buy you anything that you don't already get with autoconfirmed, but that will change when we enable pending changes. -- RobLa (talk) 17:10, 12 June 2010 (UTC)[reply]

Actually, it also grants autopatrol, which is discussed here. Cenarium (talk) 18:06, 12 June 2010 (UTC)[reply]

Removing reviewer rights

Should we adopt for removing reviewer rights a process other than simply admin discretion ? This would provide a safeguard against unjustified removals and there shouldn't be many removals anyway, it could happen when a reviewer intentionally and despite warnings reviews obvious vandalism or BLP violations. Possibilities are: restricting ability to remove to bureaucrats or stewards, requiring to use a process with a discussion closed by an uninvolved admin, bureaucrat, or left for ArbCom to decide. Cenarium (talk) 03:18, 12 June 2010 (UTC)[reply]

Good points. At a minimum, the process of removing the rights must be and must be seen to be, rational, fair and transparent. Arbitrary granting or removing rights and even the appearance of bias or favouritism will bring the whole system into disrepute. Dr.K. ^{λogosπraxis} 03:30, 12 June 2010 (UTC)[reply]

Why should it ever be removed unless someone just flat doesn't want it? If they are making vandalism/gross BLP violations, then they should be blocked, not just get their toys taken away. --B (talk) 03:46, 12 June 2010 (UTC)[reply]

A reasonable question, but I can envision a case similar to removing rollback, during which an editor makes a controversial edit and then an admin removes their right for this or the other reason. Dr.K. ^{λogosπraxis} 03:51, 12 June 2010 (UTC)[reply]

But this feature isn't supposed to be used for editorial control - it's supposed to be used for vandalism/BLP control. --B (talk) 04:08, 12 June 2010 (UTC)[reply]

So is rollback but rollback has historically been removed from users. Dr.K. ^{λogosπraxis} 04:14, 12 June 2010 (UTC)[reply]

For example, a reviewer deletes an edit that is not clear vandalism. Someone disagrees with the deletion and contacts an admin. The admin contacts the editor who made the deletion, they get into an argument, the editor gets their reviewer rights removed. Dr.K. ^{λogosπraxis} 04:20, 12 June 2010 (UTC)[reply]

...that's the way rollback is removed. Reviewer rights shouldn't be removed for not approving a good-faith edit- there are numerous reasons why a good-faith edit should not be kept. That said, they should be removed asap once they are used to push any sort of POV, especially on a L2 protected article. {{Sonia|ping|enlist}} 04:44, 12 June 2010 (UTC)[reply]

Thanks for providing yet another example as to how this right can be removed. I add that since POV is hard to define sometimes it appears that this right is more easily removable than I would have thought and therein lies the problem. Dr.K. ^{λogosπraxis} 04:55, 12 June 2010 (UTC)[reply]

Ok ... I guess I was confusing reviewer and autoreviewer. This makes sense. --B (talk) 05:23, 12 June 2010 (UTC)[reply]

Yes. Different reviewer types and, what's worse, reviewing levels. I heard about levels L1 and L2 only recently. I have no idea what they are. Gotta catch up with these concepts as soon as I can. Dr.K. ^{λogosπraxis} 05:39, 12 June 2010 (UTC)[reply]

Autoreviewer is entirely unrelated, I've proposed it to be renamed

here. I don't see many ways the review rights could be mis/abused: a reviewer could 'unaccept' a revision previously accepted by a reviewer with no basis for doing so, but it would add the edit back to the pending changes queue, for every reviewer to see, so it would make more sense to simply revert the edit, not abuse of the right per se; the other case of mis/abuse is when a reviewer accepts obvious vandalism or BLP violation, or other blatantly inappropriate edits. I don't think an admin should remove a reviewer right on its own without at least initiating an ANI. And we could also create a specific page where requests for removal are placed, which could also encompass rollback, autoreviewer. As safeguards we could restrict the ability to remove review rights to a subgroup of admins. Maybe bureaucrats is not the best choice, we could use functionaries: oversighters and checkusers. Cenarium (talk) 13:11, 12 June 2010 (UTC)[reply

]

Thanks about the clarification of Autoreviewer, although I was aware of that. As far as involving oversighters and checkusers in removing the rights this is a step in the right direction but I still do not understand why all autoconfirmed users in good standing did not get automatically grandfathered to these new reviewer groups since essentially the existing users are going to lose some of their existing editing abilities under the new regime. I also do not fully understand why this new reviewer right has to be removable. Dr.K. ^{λogosπraxis} 22:45, 12 June 2010 (UTC)[reply]

We're planning on granting the rights to autoconfirmed users in good standing, but the reviewer group has just been created and this is long to grant to several thousands users, there are

database reports we can use. It would be unlikely to see the right 'abused' by experienced users, see Wikipedia_talk:Reviewing pending changes#Eyeball_request for how it could be. But it's possible so we have to take this into account, though it should be so rare (except if the right were to be granted too easily) that there's imo no problem in restricting removal to CU/OS, and this being done after a discussion. Cenarium (talk) 04:18, 13 June 2010 (UTC)[reply

]

Thank you Cenarium for your very informative reply. I think given the details you provided that you are on a good track. Keep up the good work! Take care. Dr.K. ^{λogosπraxis} 04:28, 13 June 2010 (UTC)[reply]

Thanks. We'd need a consensus for restricting removal to CU/OS. Cenarium (talk) 15:34, 13 June 2010 (UTC)[reply]

I would oppose restricting removal to CU/OS for several reasons:

1. It is outside the scope of what the CU/OS groups are for; there are no privacy issues. If this has to be restricted to a non-admin group, it should be bureaucrats, as their role is at least related to dealing with user rights.
2. If it is granted by admin discretion, I see no reason that it couldn't be removed by admin discretion. The fact that it won't need to be done frequently is not a reason to restrict it. Abuse or misuse of this does not seem like it would be much harder to spot than abuse or misuse of rollback.
3. Admins (or any user, really) should not be able to do things that they cannot undo.
4. By requiring a functionary to remove the rights, it becomes a much bigger deal than it needs to be.

-- Mr.Z-man 17:05, 13 June 2010 (UTC)[reply]

That's something of a red herring. Bureacrats can "promote" a user to administrator, but they can't "demote" an administrator to a regular editor, so there is precedent for the removal of this new right to not be in the hands of administrators. There is very good evidence that rollback is not infrequently removed capriciously by administrators, and therefore no reason to suppose that this new right won't be as well.

Fatuorum 17:40, 13 June 2010 (UTC)[reply

]

I agree that we need more, not fewer, safeguards regarding removal as I explained above. I find Cenarium's approach to be the best. Dr.K. ^{λogosπraxis} 18:02, 13 June 2010 (UTC)[reply]

There is a major drawback though, if people see it's too difficult to remove the right, then they will want higher standards to grant it; and it's essential to grant the right to enough reviewers. Bureaucrats have been reluctant to new responsibilities, and it may 'politicize' their function, the same could be said for CU/OS. Personally, I think it should be sufficient to require a rough consensus for removal. Cenarium (talk) 18:34, 13 June 2010 (UTC)[reply]

Okay, let's have the discussion here please. Cenarium (talk) 20:44, 13 June 2010 (UTC)[reply]

Level 2 protection

Moved at Wikipedia:Requests for comment/Pending changes trial. Cenarium (talk) 22:23, 13 June 2010 (UTC)[reply]

Autoreviewer group

The

autoreviewer

usergroup, initially named autopatroller, has been created in 2009, users with this permission are autopatrolled. It had been proposed that we use this group with flagged revisions for users who are autoreviewed, but in this implementation all autoconfirmed users are and flagged protection isn't related to new pages patrolling. As this can cause confusion, it has been suggested to be renamed to autopatroller. Though it can conflict with patrolled revisions.

Comments

Proposed rename

here. Cenarium (talk) 04:19, 13 June 2010 (UTC)[reply

]

Name

See

Wikipedia talk:Flagged protection and patrolled revisions/Terminology

.

Comments

It's probably not practical to change the name again at this point before launch. However, there's more minor terminology that is still potentially debatable at

Wikipedia talk:Flagged protection and patrolled revisions -- RobLa (talk) 05:05, 8 June 2010 (UTC)[reply

]

I think the current name, arrived at after much discussion, gets away from the "flagged" baggage that apparently arose, and I'm certainly not in favor of another change at this point. Development resource should be used for other things. ++Lar: t/c 10:34, 8 June 2010 (UTC)[reply]

Reviewer usergroup

Resolved

 – The configuration has been returned to the original request with reviewer usergoup.

Flagged protection without reviewer usergroup was the original version of flagged protection, discussed

Wikipedia talk:Reviewers#New discussion and poll: reviewer criteria

and in a prior poll.

Reasons for using a reviewer usergroup

• high risk for good-faith autoconfirmed users to be sanctioned for doing bad reviews due to inexperience (and not malice)
• very high risk for malicious users to compromise the system with bad reviews
• lack of confidence in the reviewing system
• no possibility of protection against sockpuppeters and major disruption as afforded the intermediate flagged protection level, need to use full protection as now
• deemed untenable by FlaggedRevs main developer Aaron Schulz ^[5]
• need to double check reviews which in turn may affect the efficiency in the processing of edits

Reasons against using a reviewer usergroup

• less complicated
• more users with the ability to review - less likelihood of backlog

Discussion

• I'm not convinced that this would reduce backlog since there will be a need to double check reviews and deal with bad reviews. We had planned on a liberal granting of the reviewer group so most users interested in reviewing would probably be granted the rights anyway. With database reports identifying candidates likely experienced enough for the right, it would be unlikely to have shortages in reviewers. Further, edits by autoconfirmed users are automatically reviewed when the previous revision is reviewed (except when specifically disabled to deal with socks/major disruption but those instances would be rare) so the number of edits to review is considerably less important that in other type of FlaggedRevs implementation, and also obviously because it isn't used on that many pages. Cenarium (talk) 14:30, 22 May 2010 (UTC)[reply]
• The wiki way is to be as open as possible for as long as possible. This is a trial period. Therefore, it seems to me that the best way to find out if fears about autoconfirmed users gaming the system or causing trouble in some way is to start out with granting the right to autoconfirmed users and then scaling it back after the test if we have empirical evidence that they are doing something wrong.--Jimbo Wales (talk) 15:10, 22 May 2010 (UTC)[reply]

I would agree with that if it were for a passive right, and it's already the case that on flagged protected pages all autoconfirmed users are automatically reviewed if the previous revision is, but here we're talking about reviewing other user' edits. It is unlikely that inexperienced users even know how to read a diff, it will most certainly lead to usability issues by confusing them, etc. I think an autopromotion would be a much better compromise, so we can at least remove the right from good-faith users misusing the right instead of having to block them, and allow to raise the bar a little. Another point, if the community isn't satisfied with the trial, which is most likely if all autoconfirmed users can review and its consequences, then the community simply won't want FlaggedRevs any more. Cenarium (talk) 16:23, 22 May 2010 (UTC)[reply]

I don't understand this logic, so the community will prefer the far less restrictive status quo over FlaggedRevs because FlaggedRevs is not restrictive enough? Sole Soul (talk) 18:09, 22 May 2010 (UTC)[reply]

That's really not a question of being more or less restrictive. All autoconfirmed users' edits are already automatically reviewed if the previous revision is reviewed, and cases where an autoconfirmed user edits a semi flagged protected page with a last revision which is not reviewed should be quite rare. Cenarium (talk) 18:23, 24 May 2010 (UTC)[reply]

I expect it to be rare during the trial, but I'm not sure what will happen later when the enthusiasm for active reviewing subside. There is also something that cannot be measured easily, and that is the psychological barrieir that may prevent an autoconfirmed users from editing a page in the first place when they know that their edits will not appear immediately. Sole Soul (talk) 19:58, 24 May 2010 (UTC)[reply]

• Unless there's some technical reason behind the switch that would result in significant delays (i.e. more than a month) or make deployment actually impossible, the technical staff should not be overriding community consensus. I agree with Cenarium that if the trial goes poorly for any reason, the community will almost certainly not accept FlaggedRevs in any form. Mr.Z-man 16:40, 22 May 2010 (UTC)[reply]
  • Hi there. The problem is manifold: 1. there's a usability issue. the knobs and widgets necessary to implement the full proposal as written need a lot more thought toward usability than we have time to implement. 2. defaults matter. if people are, by default, not included in the review group, there will be a lot of very qualified editors who would not participate due to
    Wikipedia:Flagged protection, and needs to be nailed down very quickly to ensure this feature gets launched in a timely fashion. -- RobLa (talk) 17:47, 22 May 2010 (UTC)[reply
    ]
    • As for #1, I disagree. This aspect of the FlaggedRevs feature is targeted toward admins and experienced users. Usability is a major issue for things targeted toward new users and readers. But for those groups, the result will be basically the same either way. As for number 2, our experience with rollback, autoreview, and accountcreator suggest otherwise. That could also be mitigated using an autopromotion system more stringent than autoconfirmed. What you should be wedded to is the configuration that the community agreed upon. Unless the board agrees to change things or an authorized staff member changes it as an office action or due to actual technical problems (i.e. things that may crash the site, not just assumed usability issues that the WMF has had no problem sticking on other wikis) the staff should implement what the community agreed on. That's how things have worked for years, and I see no reason to change that. You do not run this project. You do not get to override community policies. Mr.Z-man 18:21, 22 May 2010 (UTC)[reply]
    • Usability is a secondary concern at this point. I'm willing to entertain a healthy amount of debate here, but the primary concern should be to get a working implementation of the software that the community has requested. I'm already disappointed that there is yet no implementation of patrolled revisions (which should have been far simpler to implement than flagged protection), but I think it's totally unreasonable for usability to be a blocking issue for this software at this point in time. {{
      ⚡}} 19:02, 22 May 2010 (UTC)[reply
      ]
• Can I ask, (as someone who's only started editing since the discussion, poll etc.) under this system (ie the one proposed for the trial here, with autoconfirmed users being reviewers), will every edit by an autoconfirmed used mark the preceding version as patrolled? It would, wouldn't it? Surely this would lead to large numbers of versions being marked as patrolled by autoconfirmed users who didn't mean to, but were simply trying to make an edit? -- Lear's Fool (talk | contribs) 19:21, 22 May 2010 (UTC)[reply]
  • No, if the previous edit (i.e. the current version) was not reviewed, then reviewing an edit is an active process (it requires checking a box or an extra button), not a passive one. This is independent of the actual system used and will be the same for any usage of FR. Mr.Z-man 21:26, 22 May 2010 (UTC)[reply]
• I oppose FlaggedRevs, as it suddenly disconnects the readers from the editors. On Wikibooks, logged in users see "the latest revision" and the public sees an old revision. For current events, it would be another step to get a needed change (a fact fixed).
  WP:TROLLs, disruptive editors, page-move vandals, etc. would have a new way to mess up the system without a ton of people knowing (most people of this nature are autoconfirmed).--moɳo 20:30, 22 May 2010 (UTC)[reply
  ]
  • Followup: I noticed a comment about patrolled revs would be so much easier to implement (
    WP:LUPIN) than FR and wouldn't confuse anyone. Instead of redefining the system, you could just add something new and not that different. --moɳo 20:35, 22 May 2010 (UTC)[reply
    ]
  • You appear to be confusing FlaggedRevs (the MediaWiki extension) with Flagged Revisions (a particular implementation of that extension). The plan on the English Wikipedia is to use a different system of
    ⚡}} 15:33, 23 May 2010 (UTC)[reply
    ]
• Giving the review rights to autoreviewers seems like a sensible idea. But we should change the criteria for autoreviewer qualification. As not many have made around 75 articles. We could change the criteria to say 100 good edits. Graeme Bartlett (talk) 03:57, 23 May 2010 (UTC)[reply]
  • It does sound like a good idea. But I think 100 good edits is not quite enough, because autoreviewer will still have the same function it has now, I assume. So at least 5 new articles that are referenced and (at least borderline) notable, plus the 100 good edits. I'm saying this as someone who has 2k edits but only four articles, three of which are unsourced. However, if it is possible, I'd like the two groups to be separate. I would like to be a reviewer, that's the kind of job I like, but I'd be a nightmare autoreviewer because I haven't worked much with actual content-building. Maybe, as mono said, the type that would make good reviewers are the people who are already "approving" edits with Huggle- the rollbackers. {{Sonia|talk|simple}} 08:29, 23 May 2010 (UTC)[reply]
    • Well as someone who makes a large amount of edits but rarely start articles. I can tell you are immediately going to hit a wall with that. Perhaps you would wish to review my 500 typo edits this day? Yes??? No, thought not. ;) Regards,
      talk) 09:43, 23 May 2010 (UTC)[reply
      ]
      • Sonia makes a good point; a simple solution would be to have reviewer rights should be included with autoreviewer (to give us an immediate base of trusted people to flag revs; I could also see it being included implicitly with rollback and acc, both levels of trust), but there should also be another usergroup for simply flagging revisions for those who don't meet autoreview (or other rights) granting criteria. –xeno^talk 15:24, 9 June 2010 (UTC)[reply]
      • In the spirit of SunCreator's objection, I'm not sure "x new referenced articles" would be an easy enough criteria to meet, specially considering how often people argue that, with over 3 million articles, the number of notable topics in Wikipedia is approaching saturation... --Duplode (talk) 16:46, 23 May 2010 (UTC)[reply]
  • I believe giving reviewer rights to autoreviewers was always planned. However, the WMF FlaggedRevs people have decided to change the plan and give it to all autoconfirmed users – users who have made 10 edits and have been here for 4 days. Mr.Z-man 14:12, 23 May 2010 (UTC)[reply]
    • That seems sensible, both in method and scope. It's somewhat like the
      talk) 15:51, 23 May 2010 (UTC)[reply
      ]
      • Autoconfirmed does not require an email address. Wikibooks requires significantly more experience before reviewer rights are given automatically - 100 total non-deleted edits, 30 days, at least 50 content edits on 10 unique pages, no blocks, and an email address set. Mr.Z-man 16:44, 23 May 2010 (UTC)[reply]
  • Here is the rationale for choosing autoconfirmed as the first level of flagged protection to roll out. The primary candidates for flagged protection are articles that are currently under semi-protection. Articles that are under semi-protection are currently fully editable by autoconfirmed users. If we use any other level other than autoconfirmed, then putting them under flagged protection actually takes away rights that those users previously held. We can always add more levels later, but the idea is to start off with the most inclusive level so that people can get comfortable with the feature itself, and then expand based on community demand. -- RobLa (talk) 17:27, 23 May 2010 (UTC)[reply]
    • I understand your rationale for preferring it, but what is your rationale for ignoring the community consensus and substituting your own opinion? (And I thought the rationale was usability?) It has taken more than a year to get the trial that we got consensus for last April. Now you're changing things based on your own opinion. Forgive me if I have absolutely zero confidence in the FlaggedRevs team to do anything based on "community demand." Mr.Z-man 17:43, 23 May 2010 (UTC)[reply]
      • Jimbo has been disputing the media's claim that the new system is less inclusive. When you look at the original proposal, the media seems partially correct, as the proposal takes away rights from autoconfirmed users as RobLa said. Sole Soul (talk) 17:53, 23 May 2010 (UTC)[reply]
        • I don't care what the media says. I want to know the WMF staff's rationale for giving themselves the power to overrule the community on matters that are neither serious technical nor legal issues. Up until now, the WMF has limited their involvement in setting local policies and procedures to things that pose a serious problem to the site (technical changes needed to keep the site running, DMCA notices, etc.) or things that there isn't an explicit consensus on (the recent skin change, most new features). Here they appear to simply be substituting their own preferences because they simply don't like what the community decided on. This represents a major shift and I am frankly shocked that they are doing it so lightly. Mr.Z-man
      • Hi Mr.Z-man. I know you are frustrated with how we got where we are, but I'd ask that you please
        later poll about auto-promotion was similarly small, with 13 support, 19 oppose, and 2 neutral. My reading of the polls and the other discussion is that the typical community member isn't tracking things at the level of detail we're discussing here.

        What I did at that point was to create a configuration and post on wikien-l notifying everyone that I was making changes, and that things would be in flux. I later found out that there had been earlier conversations at WMF, and something even simpler than what I first posted was what many folks agreed to there. After talking it over with them, I became convinced myself that they were right, and changed the page accordingly.

        In answer to your question about rationale, the rationale for simplifying it down to one option was usability and the ability to explain how the feature works as we introduce it. The rationale for picking the option we did is explained above.

        We're committed to making this trial successful. We want the editing community to like this feature. We will be receptive to the reasons why what we proposed will not work for the short duration of the trial. Let's focus on the proposal so that we can get something implemented. Thanks! -- RobLa (talk) 21:49, 23 May 2010 (UTC)[reply

        ]
        • What proposal? The option to chose between 2 predetermined names for the system? I don't see anything here being proposed, I see the foundation saying "Well, you asked for that, but we decided to give you this instead, we hope you like it." Mr.Z-man 22:55, 23 May 2010 (UTC)[reply]
        • There's been no proposal, I had to reveal that now as you didn't bring this for comment publicly. Foundation staff discussed this since the beginning of April; a person of influence (not Jimbo) advanced the opinion that we should give review rights to all autoconfirmed users, Aaron was asked to comment on the technical aspect and he raised a few objections, some of the reasons advanced here, he then suggested to ask me. I gave the community position as I see it, and afterwards there has been apparently an overall agreement that autopromotion would be a good compromise. My last email didn't receive a reply and now I learned that there were no more questions, it had been decided to give review rights to all autoconfirmed users, so why ignoring Aaron and the community's concerns, why having decided this with minimal community input ? Cenarium (talk) 03:10, 25 May 2010 (UTC)[reply]

• Endorse RFC concern (if technically accurate) - I would not be comfortable with reviewer rights being auto-distributed, to autoconfirmed users or any other way. Reasons that speak to me:

  1. It's "just a trial". But it's a high profile trial and the entire efficacy of the Flagged Revisions approach will be carefully scrutinized, here and with commentary in the media. A weakened version that allows anyone - including vandals and users who have not shown they understand our policies and criteria (
     Many people get rollback too. But there is a difference between "many" and "indiscriminately anybody". Support "many", oppose "indiscriminate/automated", for reasons the community has agreed as well.
  2. A tool that requires double checking in this way is too different from that discussed. The aim is to save work by having users with some basis of trust and some element of scrutiny to have that access. Not "everyone".

  If the RFC statement is accurate then I would agree with it as being a concern. FT2 ^{(Talk | email)} 00:36, 24 May 2010 (UTC)[reply

• Endorse separate user group. However, admission to the user group should be like rollback, readily granted on request by any administrator. It should be a separate group because of the potential for good-faith abuse, not to mention the other kind of abuse; it could then readily be revoked by any admin without blocking, pending discussion, etc. It is also possible for the right to be automatic, with autoconfirmation, but separately revocable. As a trial, it seems safest to have it be like rollback. --
  talk) 14:42, 24 May 2010 (UTC)[reply
  ]

• 4 days and 10 edits to review? I'm not sure that's a good idea. A separate group is needed. ++Lar: t/c 01:36, 25 May 2010 (UTC)[reply]

• Addressing the points by RobLa:

1. Usability issues would come with the reviewers group removed, not the reverse. Admins and experienced users are already accustomed to relatively complex tools, they won't be afraid by two new levels of protection, while readers and inexperienced users would not be bothered. Further, the configuration as requested is already up and running on the testing site and it works well enough; usability is not synonym with 'indefinite polish up'. Plenty of admins have tested the interface and didn't fin any substantial usability issues in the interface, they can use it, and even then they know where to find help if needed, there's no issue. However, there would be a usability issue, and a big one, if inexperienced autoconfirmed users were faced with strange things named 'diffs' to 'review'.
2. Alleged status quo bias: we're going to use database reports to identify users who are likely experienced enough to be granted review right or as second option an autopromotion so it's addressed.
3. At the risk of repeating it again and again, autoconfirmed users have their edits automatically reviewed if the prior revision is reviewed, cases where an autoconfirmed user edits a flagged protected page with unreviewed latest revision should be quite rare. On the other hand if experienced users have to double check reviews, then there will be less time to review new edits by IPs and non-autoconfirmed users.
4. What's on
   WP:FPPR
   and you know this is exactly the configuration which is on the testing site. I don't get the 'it's simpler' argument, readers and most users won't know the internal, it's going to matter only to admins and the users who are going to review edits, I assure you they can handle this level of complexity.

If we don't get what the community wants of the implementation, then what's the point of having a trial, so far remote of what the community could support using on longer terms ? You can think the two polls on autopromotion are anecdotal, but very clearly the community rejected the first version of flagged protection, without reviewer group, in favor of this one, with reviewer group. Cenarium (talk) 03:10, 25 May 2010 (UTC)[reply]

• I'm generally with Z-man and Cenarium. Can we please just get on with the trial as discussed, and not talk this to death any further? It's a trial, for crying out loud: If we run into a noteworthy backlog, we then change the process.
  To keep the concept somewhat useful, the group of reviewers must be large and active enough to keep the backlog small, but small enough to only contain reasonably trustworthy users. If we manage that, editing remains as open for autoconfirmeds as it used to, and is more open for IPs.
  Four days/ten edits are *far* from what's required to keep the reviewe process meaningful. Not being able to revoke reviewer status and having to fall back to blocks in case makes that change even worse. Amalthea 13:51, 25 May 2010 (UTC)[reply]
  • Amalthea, the reason why I started down the path I did was because I was trying to align the configuration with what was on the web page. After figuring out that I didn't have enough information on the web page to do that, I decided to scratch that, and go with a simplified version. Then, after talking with people at WMF about the conversations they had had before I even arrived, they had something even simpler in mind. So, that's what I went with. -- RobLa (talk) 16:33, 25 May 2010 (UTC)[reply]
    • I don't understand. All of the PHP configuration code has been written and laid out for months. What are you talking about? --MZMcBride (talk) 16:40, 25 May 2010 (UTC)[reply]
      • I haven't been able to find anything current. I recently created User:RobLa/Flagged Rev config for English Wikipedia, which has a very recent config, and one that doesn't align with what anyone wants to roll out to en.wp. -- RobLa (talk) 18:32, 25 May 2010 (UTC)[reply]
        • Just roll out something. Don't post computer printouts, turn on the real thing. Maybe somebody will notice (remember what happened with that nonsense vector - we just switched back to monobook and moved along).
          East of Borschov (talk) 19:23, 25 May 2010 (UTC)[reply
          ]
        • Looks like it was Aaron's doing. Not sure what that's about.... --MZMcBride (talk) 19:30, 25 May 2010 (UTC)[reply]
    • Like MzMcBride I was under the impression that this had all been set up a long time ago on the test implementation. But be that as it may, now that this misunderstanding is hopefully cleared up, can you go with what the community decided? At the moment, the group rights on flaggedrevs.labs seem to be as intended (in that regard). Amalthea 12:05, 26 May 2010 (UTC)[reply]
  • Damn good summary. Turn it on, let's see what happens.
    East of Borschov (talk) 19:23, 25 May 2010 (UTC)[reply
    ]
• I may well be in a minority of one here, but if this new feature requires any new right to be assigned (and by implication removed) by administrators, then I will simply be ignoring any articles to which it is applied.
  Fatuorum 17:09, 25 May 2010 (UTC)[reply
  ]
  • A minority of two, Malleus. After reading this ridiculous proposal, I will also just refuse to edit any articles that require me to have this "right". Admins are pompous enough already without giving them further scope for trying to intimidate us regular editors. BigDom 18:15, 11 June 2010 (UTC)[reply]
    • Articles PC-protected at level 2 (if actually used) would be fully protected otherwise so couldn't be edited except by admins. And articles PC-protected at level 1 would be semi protected so could only be edited by autoconfirmed users, isn't it preferable to have the possibility to allow users who are not autoconfirmed to edit ? Edits by autoconfirmed users are automatically accepted if the previous revision is accepted, and there would be only a few exceptions to that. It seems to me that we gain in allowing IPs and new users to edit, at the expense of exceptional cases where an autoconfirmed user who isn't reviewer may edit just after an IP or new user whose edit were still not reviewed, and is not obviously revertable (if it is reverted to the latest accepted revision, it automatically becomes accepted). Cenarium (talk) 21:09, 12 June 2010 (UTC)[reply]
      • The first time I see that an edit of mine isn't immediately visible will be the last.
        Fatuorum 22:23, 12 June 2010 (UTC)[reply
        ]
        • This is part of a larger problem, that of the "wikipedia for the editors" being distinctly different from "wikipedia for the readers". The gap is widening: they see a different page design (Vector), they see a different page layout (owing to everyone's private image size settings) and now they'd see different texts. But with only 2,000 articles censored, the chances of running into FR are next to nothing, unless you venture into stuff like the
          East of Borschov (talk) 22:50, 12 June 2010 (UTC)[reply
          ]
          • There is also a widening gap between on one hand, potential editors who would like to edit but can't get around to it, and casual editors, and on the other hand, a core of established editors. We should strive to address this gap, because imo this is an existential issue, and pending changes helps doing this by allowing more people to edit. Cenarium (talk) 23:27, 12 June 2010 (UTC)[reply]

• This should be an automatically granted function. I've never been persuaded that FP would do anything other than add a layer of bureaucracy, and would do more to shut down editing on those pages than to open it up, but my opinion on the subject was very much in the minority all the way from the beginning. Frankly, I don't care if User:Never Edited Before can now have the ability to try to add poop vandalism to Ronald Reagan - a revision that will now have to actually be reviewed by a real editor instead of being automatically rejected by our software - if User:Has Edited For Five Years But Has No Interest in RFA, and who has been helping to improve the same article, has to *ask for special permission* to continue doing exactly the same editing he has been doing for five years.

  There's no reason at all to believe there will be any gain, and plenty of reason to believe that we're making work for people who will now have to review edits that would never have got through semi-protection in the first place. More importantly, we've disenfranchised the editors who make up the backbone of the project, and will force them to beg for a permission which can capriciously be denied or withdrawn by admins who have no idea whatsoever about quality content.

  Propose that anyone with one month and 50+ edits have autoreviewer ability, and that the same group be able to review. Let's not shoot ourselves in the foot anymore than we have to with this extension. We don't need Wikipedia to become any more of an MMORPG than it already is. Risker (talk) 02:06, 11 June 2010 (UTC)[reply]

1. The rights will be granted automatically (if we use autopromotion) or semi-automatically and manually based on database reports to experienced users, so most won't have to ask for it.
2. Except in the rare cases where they edit a flagged protected page with unreviewed latest revision or that it is protected at reviewer-level, all autoconfirmed users are automatically reviewed so have no need for the permission.
3. We won't give up semi-protection, articles subject to constant vandalism should be semi-protected, as using flagged protection on them would indeed not be beneficial for the project as a whole. Cenarium (talk) 02:40, 11 June 2010 (UTC)[reply]

Admins can remove that permission indeed, this is needed, just like they can block users entirely, we'll have guidelines on when removal is appropriate - I don't think instances would be that controversial, unlike rollback which can be misused more easily in edit wars for example. Cenarium (talk) 02:51, 11 June 2010 (UTC)[reply]

Well, seeing as the "groups" being looked at as models for "automatic" granting are rollbacker (which is primarily used for vandalism), account creator (which has nothing to do with content at all) and autoreviewer (with an expectation of 75 articles created), we are still leaving the vast, vast majority of competent editors at the roadside. RobLa is right, leave it at autoconfirmed level, which is assigned by software rather than by people. If a page needs more protection than that, it should be properly protected. I believe that it is now time to state upfront that admins who abuse this tool should also be subject to its removal, even if it means their desysopping (in fact, I believe that should hold true for any tool an admin uses), and that inappropriate removal of someone's reviewer access (or any other tool) should be grounds for desysopping too. My overwhelming preference is for an automatic granting of access to this tool, and a very, very low threshold, without any human intervention except perhaps for admins to grant it earlier. And the description of "how it works" indicates that if there's another unreviewed edit in the queue for an article, subsequent edits won't be automatically released. Risker (talk) 18:40, 11 June 2010 (UTC)[reply]

Yes, but it should be rare. The criteria for the DBR is not just other groups, but also independently number of edits and time since first edit, starting high to avoid having too many results then downgrading. Yes, the right to review other users' edits should be granted liberally, some completely automatic way may be ok, but we have no choice but to take into account the experience needed and abuse potential, or the system would be worthless. If rogue admins removing rights is so much of a problem, then we can more severely regulate removals, or even allow removal only by bureaucrats or stewards. Also, what do you think of a special process to remove admin-removable usergroups, instead of this being done at admin's discretion ? Cenarium (talk) 19:22, 11 June 2010 (UTC)[reply]

(ec)Again, it's key that it hardly ever comes to that. If we have a review backlog of more than a few minutes, then we have either too few active reviewers working on the backlog, or too many articles under that protection level.
If you instead put people in the reviews group automatically after a very low threshold you make it worthless. It wouldn't help to protect obscure, unwatched BLPs, and it would make the Level 2 PC protection a complete farce.
Reviewers needs to be editors who have some grasp on the content policies. I'm absolutely fine with giving it out liberally, and requiring discussion for taking it away. Personally, based on the abuse concerns I keep hearing, I think you actually need new admins.
Amalthea 19:29, 11 June 2010 (UTC)[reply]

Cenarium, any method you run will naturally weigh heavily in favour of RC patrollers, Hugglers, Twinklers, and other users of automated editing scripts; and bluntly, most administrators are really not in a position to assess the quality of editing from those who simply edit articles, unless they themselves are knowledgeable about the topic area. Thus the threshold needs to be low. As to level 2 PC, the level itself is something of a farce. It's intended to replace full protection, but there are (as far as I can tell) *no* encyclopedic articles under longterm full protection. Short-term full protection affects only a tiny handful of articles at any given time, and it is usually specific to edit warring or some major degree of vandalism. Disputes about edits should be discussed on talk pages instead of having a "review" function where the edit war can be perpetuated rather than resolved, and where an editor with review ability will have a clear advantage. If the article is protected because of a rash of vandalism (not a frequent occurrence, since semiprotection addresses almost all of these cases), we're wasting valuable volunteer time having to clear out the review queue of vandalistic edits that would have been automatically rejected by the software, and to sort out whether or not any of them have any merit.

Incidentally, one factor that I'm not seeing a lot of discussion about is who is actually planning to do these reviews, which is a separate point from who should have access enabled to do the reviews. It shouldn't be too hard to keep up with only a few thousand articles covered, but if the program expands, there will be the need to divert a LOT more editorial time and energy to reviewing edits than is currently expended. Risker (talk) 20:29, 11 June 2010 (UTC)[reply]

The same editors who are currently using Huggle to check revisions will I'm sure happily review this queue. The tools will need to catch up to make this more easy, but in the end it will use less energy since most edits will only be checked by one or two editors, instead of by all who are running huggle at a time like now.
Point taken about Level 2 PC: One article I had in mind was Justin Bieber, which got quite some autoconfirmed /b/ vandalism. But you're right, there won't be too many pages where this is useful. Obviously not in a content dispute.
And I do think that most administrators are competent enough to assess the content policy grasp I see as a requirement for the Reviewers group: If an editors shows that he knows that facts should be sourced and has been here for some time (like, say, a month, sometimes less) then I, for one, am content. Just some confidence that he'll actually look at the diff and have the basic content policy knowledge. That will, for example absolutely and without question include everyone that has ever written a, say, B class article. No doubt, no concern, no question. And yes, any admin I know can judge that by looking at a handful of edits. I'm very surprised that your opinion of admins is so low, but then again, you're active in very different areas than I am.
Lastly, I continue to question your premise that autoconfirmed editors will even notice. The absolute majority of their edits is still immediately published. A handful of their edits will be placed in the review queue and take a few minutes before they are seen by readers and search engines. Do you disagree with this? My focus has been to make sure we can manage that part, by trying to control how many articles are placed under PC protection depending on the backlog of the pending changes.
Amalthea 21:07, 11 June 2010 (UTC)[reply]

Lvl 2 PCP is not intended to replace full protection, nor is lvl 1 PCP intended to replace semi protection, they provide an alternative. It would not be practical to use PCP for disputes, it shouldn't be, it's aimed for articles which are subject to persistent sockpuppetry or disruption when semi-protection is insufficient. There are quite a few examples, the copernicus vandal, grawp-like vandals, runtshit, nationalistic edit warriors, etc, forced us to fully protect plenty of articles for long time. Currently I can cite among fully protected articles for reasons other than dispute for example

Brahma Kumaris World Spiritual University, Queer Collaborations, etc. There are no more than a few dozen at one time but it's unbearable to have to fully protect them, and henceforth effectively barring any editing, because of one persistent disruptive editor. And there are also semi-protected articles which are still subject to daily disruption which could benefit from an additional lvl 2 PCP, such as Barack Obama. Cenarium (talk) 21:21, 11 June 2010 (UTC)[reply

]

Hope this is the kind of thing you are asking for. FT2 ^{(Talk | email)} 00:21, 5 June 2010 (UTC)[reply]

Hi FT2, here's some answers from my perspective:

• Q1 - From an operational perspective, it'd be nice to get a diverse set of articles (some with heavy editing, some with light editing, some with high traffic, some with low). I've added a new section to
  Wikipedia:Flagged protection and patrolled revisions/Trial
  with TBD. Anyone here should feel free to take the lead on filling that section in.
• Q2 - short answer: 2000 articles, capped by configuration variable. Longer answer:
  Wikipedia:Flagged protection and patrolled revisions/Trial#Initial article count limits
• Q3 - Excellent question. I suppose these will all get created on demand, but it'd be good to get a jump on it. Here's where I'd start:
  Help:Pending changes
  .

Thanks for diving in here! -- RobLa (talk) 00:51, 5 June 2010 (UTC)[reply]

Started

review it and check for what exactly this community has endorsed, and update the page to correctly reflect it, etc. I have assumed this is also going to be a page read by external reviewers from the media as well, and non-editor readers, so it has to explain what this is, what this isn't, and why. FT2 ^{(Talk | email)} 02:34, 5 June 2010 (UTC)[reply

]

Hi FT2, this is a fantastic start, thanks! I'll comment more on

Help talk:Pending changes, and maybe start making the edits I have in mind. -- RobLa (talk) 03:52, 5 June 2010 (UTC)[reply

]

RobLa: The thing is, we decided how we wanted it done, and asked for an implementation of that. Please implement what we asked for. It's that simple, really. ++Lar: t/c 18:32, 5 June 2010 (UTC)[reply]

Hi Lar, it's important for us (and for everyone) to understand why the manual reporter group is so important, not just that its important. For example, over at

Help talk:Pending changes review process, FT2 asks "Are there any situations where the tool could be used in bad faith, given it's an affirmative tool only (not a restricting one), other users can also check, no obligation to check anything, etc?". Could you (or someone here) explain this? -- RobLa (talk) 18:43, 6 June 2010 (UTC)[reply

]

RobLa, I'm not sure I really understand the question. If you want to know why manual reviewer is important you would need to examine the many discussion pages that led to the consensus that it's part of the requirement, and ask each of the participants to elaborate their views. But moreover, I'm not sure I understand why you are asking this question. Are you asking in order to refine your development against the requirements? If so, great, although it's a bit late, isn't it? Or are you asking in order to challenge the requirement? If so, I think there is still confusion here about where direction comes from. ++Lar: t/c 00:21, 7 June 2010 (UTC)[reply]

Lar, the reason why I'm asking is twofold:

1. We'd like to make sure the rationale is clearly explained somewhere. While there are talk pages around, I'm hoping someone can clearly, concisely, and convincingly state the reason that doesn't involve saying
   "talked about it, sorry"
   .
2. There's still some important undecided policy items you all need to decide, such as what the thresholds are actually going to be. For example, the
   Help:Pending changes review process
   page still says that the threshold for becoming a user is "an editing level of ___+ edits a month over some ___ months". The rationale for having a manual group is important, then, in actually determining what the levels are. Speaking with my WMF hat on: we're not as concerned with what the levels are so much is that the levels have been determined and clearly communicated.

So, why is the manual user group important? -- RobLa (talk) 23:29, 7 June 2010 (UTC)[reply]

I'm still lost as to why you're asking this. And why now. These are the requirements and have been for a while. But I'll humor you, I guess, without conceding that it's actually proper for you to ask. Let's start with the second point. Rollback was rolled out without a clear set of criteria of who exactly got it. Nevertheless criteria evolved in short order. Exactly who gets reviewer doesn't have to be decided in advance, decided for all time. It will evolve. Easy peasy. On the first point, besides the fact that this is what the majority, nay, consensus of parties wanted, I'd turn it around and ask you... how on earth would you think that 10 edits over 4 days (and no human review whatever!) would be enough to show that someone was capable of correctly deciding what should be approved or not? The point of this new technology is to reduce the impact of vandalism. If we have vandals approving edits, we have a mess, not a fix. ++Lar: t/c 01:45, 8 June 2010 (UTC)[reply]

Why does the WMF care? Until now, the process for things like this has gone 1) Community gets a consensus 2) Community makes a request 3) WMF verifies there's something that looks like a consensus and implements it. Why is the WMF trying to get so heavily involved here, to the point of putting up what I can only describe as resistance? Its hard enough to make a proposal that the community will accept, if the WMF needs to be satisfied with it too (as opposed to simply being satisfied that the community is satisfied), we're never going to get anything done. Especially since the community generally dislikes specifics in proposals and the WMF appears to be insisting on them. Mr.Z-man 03:30, 8 June 2010 (UTC)[reply]

Per Lar completely, on rationale why the community wishes a manually granted group, and the community's right to have reached consensus that way. To answer your other question, if WMF provides a version of "pending changes" where the reviewer right is given to all admins, and any admin can give it to a non-admin, that solves that. Same basic config as rollback and IP block exemption. The community can take it from there as this is the config expected. The only thing that might be worth doing after that is a quick communal check whether any rollbacker should be considered to have the trust needed for the tool (to provide a large group of reviewers initially). But that's not contentious either way, and a community issue. FT2 ^{(Talk | email)} 11:59, 8 June 2010 (UTC)[reply]

Like I've suggested elsewhere, if we ramp up the number of articles that are flag-protected slowly and in a controlled way, I'm confident that we can keep the backlog of articles with unreviewed revisions minimal even if the reviewers group starts out empty and is filled manually.
I'd suggest creating a page somewhere with a queue of articles that we want to use for the trial, and every day for 30 days 50 articles from the top of the queue are switched to flag-protection. Amalthea 13:35, 8 June 2010 (UTC)[reply]

Important nuance missed. The text already notes that it may be removed "in the event of serious or repeated poor use". The question asked is whether there are any other circumstances it might be removed, where "poor use" wasn't an issue but usage still was unacceptable. Endorsing vandalism would be "poor use", it's covered. The only situation I can think of is where the user is using the tool correctly - but consistently accepts views of one side in a debate (though the other side are making acceptable edits) in order to "push" that side's view into the public eyes more of the time. FT2 ^{(Talk | email)} 19:33, 6 June 2010 (UTC)[reply]

Not sure if this is the right place for it, but could reviewer rights possibly be tied to rollback? If something could be built into Huggle, so that it would notify you if viewing an edit to a flagged article, and you could mark it reviewed through the interface, I don't think we'll have much issues with reviewing the pending changes. The downside, of course, is the hastiness that comes with huggling, but I think this would be a useful way to test it out. There's a large enough rollbacker group, and they do a lot of the same thing anyway- this is in a sense just a positive way of approving good edits instead of rollbacking vandalism. As a rollbacker with no other flags, I do have a COI though. {{Sonia|ping|enlist}} 22:05, 6 June 2010 (UTC)[reply]

An interesting idea but I think this was rejected already. Rolling back vandalism and reviewing edits are two different functions. Not opposed to things being tied into tools such as Huggle, with some thought, but am not sure approval exists to tie the two functions/permissions together. ++Lar: t/c 00:21, 7 June 2010 (UTC)[reply]

Trial page reverted back to original table

I've changed

This appears incorrect to me, it doesn't seem to meet requirements as I understand them. In particular "During the trial period, the community will have the opportunity to discuss the possibility of adding a new level of account access for "reviewers" which would be a new level between 'administrator' and 'autoconfirmed' user. See

Wikipedia:Reviewers for more." seems to suggest that creation of the reviewer group is a matter still up for discussion. It's not up for discussion that I'm aware. Also what is the meaning of two flagged protection levels? Are both settable article states? ++Lar: t/c 01:45, 8 June 2010 (UTC)[reply

]

I fixed the prose, so it now reads: "The 'Reviewers' group is a new group to which users with a moderate level of editing experience can request membership. See

Wikipedia:Reviewers

for more." If there's anything else like that you know for sure isn't right based on what you know, feel free to change it directly.

As to the two different levels, that's how the flaggedrevs.labs site has been configured for quite a while now. The naming the levels was my addition, since it was getting really confusing not to have names, but feel free to propose (or just change) new names. I'm indifferent to what we call them so long as we have a name for each. There may be some confusion because the original proposal called for three different levels, but we recently reconciled with the current config. -- RobLa (talk) 21:26, 8 June 2010 (UTC)[reply]

Thanks for the corrections and for clearing that up. ++Lar: t/c 10:50, 9 June 2010 (UTC)[reply]

Ok, so this matter is resolved. Thanks, Cenarium (talk) 14:44, 9 June 2010 (UTC)[reply]

Viewing flagged revisions by Wikiproject

I brought this up in a couple of other places and never really got an answer. So will we be able to view pending edits by Wikiproject? I am not interested in viewing all pending changes only those within my subject area.

Not directly through the UI (Special:Unreviewedpages) I believe. It is, however, straightforward to create a bot that does this via the API. MER-C 12:03, 11 June 2010 (UTC)[reply]

There's no Special:Unreviewedpages in this implementation since no page has pending changes enabled without being protected first, which automatically reviews the current revision. The special page is Special:Oldreviewedpages, which can be filtered by category. Cenarium (talk) 19:27, 11 June 2010 (UTC)[reply]

Given this is likely to go live in 3-4 days, there have been a number of posts urging policies, notices or the like to be set up. I've had a go at some of these in a non-controversial manner.

I've taken a bit of a chance and updated page protection policy and requests to cover pending changes. The reasons being 1/ we have no process pages set up, 2/ new process approval for completely new process is chaotic, 3/ current protection policy and requests are close enough to be adopted for a lot of it, 4/ one aim is to trial using it instead of long term protection, and 5/ doing so brings this immediately into the "realms of the familiar" for anyone who uses protection already, rather than making entire new processes and pages.

I've therefore added it as "pending changes protection", and it slots nicely in with move protection, page creation protection, and page protection.

• Wikipedia:Protection policy (note  · edits)
• Wikipedia:Requests for page protection (note  · edits).
• Note at
  WP:AN#Pending changes trial imminent!
• Note on
  Template:Cent

This lets pending changes be much easier to start, because its a further protection tool rather than swathes of new stuff. I'm doing an AN summary and then I need to head off for the day.

What I can think of that's needed next in order of importance: 1a/ templates suitable for RFPP and page tagging, 1b/ a rewrite of

• I propose we use WP:Pending changes as the page for the trial policy. I'll now start editing it with that purpose. Cenarium (talk) 16:14, 11 June 2010 (UTC)[reply]

We'll need to have Wikipedia:Pending changes approved as policy for the trial, and Wikipedia:Reviewing pending changes approved as guideline. Cenarium (talk) 18:11, 12 June 2010 (UTC)[reply]

• I think this RFC can be closed and conversations moved elsewhere. Cenarium (talk) 22:26, 13 June 2010 (UTC)[reply]
  • Closed. Cenarium (talk) 07:52, 14 June 2010 (UTC)[reply]