The complete extension is translated to Norwegian (bokmål), but proofreading is missing for some of the strings. This should although be good enough for an initial setup. We expect some discussion about proper wording for some of the roles and actions.

We want to use the extension for a two-level scale, where featured articles must have the highest level set to pass. We are open for discussion on how to best implement this, but for now we go for the following (unless there are some good ideas on alternate approaches)

$wgFlaggedRevTags = array(
    'accuracy' => array( 'levels' => 3, 'quality' => 3, 'pristine' => 4 ),
);
$wgFlagRestrictions = array(
    'accuracy' => array( 'review' => 3, 'autoreview' => 2 ),
);

Any time estimates on this one?

Anything happen at all? The bug is now close to one month old.

I will not renew the note about this at our "Tinget" ("Parliament"), so it will be archived in a week from now. I'll add a link to the archived version when that happen.

Dereckson / Reedy: Could somebody deploy this?

The thread is now archived, it happen 17. jun. 2014 kl. 03:11‎ (CET)

Dereckson / Reedy / Greg: Could somebody deploy this?

FR config is a pain...

What's our current policies on allowing more wikis to take on FlaggedRevs? I vaguely remember that we wanted to stop people using it as it didn't work out well for communities (making editing harder and scaring away far more people than it brought in), but I can't find anything from a quick search.

Realistically, this is low priority, as in having little chance of being picked up by someone other than the proposers. I've added some tips based on observation of past cases to https://meta.wikimedia.org/wiki/Flagged_Revisions#Enabling

(In reply to James Forrester from comment #10)

What's our current policies on allowing more wikis to take on FlaggedRevs?

None.

I
vaguely remember that we wanted to stop people using it as it didn't work
out well for communities (making editing harder and scaring away far more
people than it brought in), but I can't find anything from a quick search.

There wasn't any such discussion, only some "private" grumbling by people dissatisfied with its usage on mediawiki.org etc. However, I've added some considerations to https://meta.wikimedia.org/wiki/Flagged_Revisions#Results , I think it's about time everyone who has knowledge on the matter writes it down.

I am not satisfied about the progress on this bug. It is the _community_ that wants this to happen and there is _no_ progress at all.

As I see it feature requests like this from the community should be handled by WMF and it should be done ASAP.

I will now escalate the importance of this bug.

I have posted a note on Wikipedia:Tinget about the delay.

https://no.wikipedia.org/wiki/Wikipedia:Tinget#Implementering_av_pending_changes

After talking this through with colleagues, our answer is that we are not accepting new wikis to enable Flagged Revisions, given the very significant problems that Flagged Revisions poses in terms of engaging new users, adding complexity and confusion to the existing too-hard-to-understand interface, and badly impacting the quantity, quality and depth of the wikis on which it has been used.

Sorry for the slowness of the response.

[For the records, bumping the priority field due to missing progress, instead of new arguments that justify a higher urgency, traditionally does not help getting things done faster.]

I must ask that this should be a statement from WMF, and it should be posted on nowikis signpost (Wikipedia Tinget).

As I see it this is WMF going against a community, and I will not take any individual developers or employees opinion as a fact on this matter.

I'll await the note on [[w:no:Wikipedia:Tinget#Implementering av pending changes]].

Our main concern, as James has pointed out, is that FlaggedRevs adds a lot of complexity to the editing experience, when we already have challenges motivating new users to join Wikimedia projects. Yes, many wikis use it. I agree we should state the policy regarding the extension clearly and apply it consistently (even if we grandfather existing setups indefinitely) - please give us some time (through August) to do so.

In the meantime, it would be very helpful if you could clarify what motivated this request in the first place. In your email to me you mentioned an increase in vandalism, is this backed up by data?

The vandalism is constant but the number of patrollers are declining, so in effect the amount of vandalism that survives are increasing. The effect is visible as the list of unpatrolled changes are now more often than not non-empty, while previously it was mostly empty.

The current trends on new editors
https://commons.wikimedia.org/wiki/File:Wikipedia-stats_new_users_2014-05-01.png
and on big editors
https://commons.wikimedia.org/wiki/File:Wikipedia-stats_100_users_2014-05-01.png

We don't have exact numbers for patrollers, but we expect them to be part of the "big editors" group.

We do know that we are loosing editors at a fast pace, and we do know that we are loosing new editors faster than the bigger editors. Other than that it is mostly speculations about whats going on.

The current state is that it is more important right now to maintain quality than trying to maximize editor retention.

We don't have new numbers for the summer, but the graphs are made from Erik Zachtes statistics, so perhaps he can produce updated numbers and graphs.

nsaa.wikipedia wrote:

«Consensus: https://no.wikipedia.org/wiki/Wikipedia:Tinget#Patruljering_og_pending_changes (we have also discussed it in other threads)»
has been archived at https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-23#Patruljering_og_pending_changes

Great if this is implemented as described by Jeblad in the top post now as a test (close to the English setup, not the German).

(In reply to James Forrester from comment #15)

After talking this through with colleagues, our answer is that we are not
accepting new wikis to enable Flagged Revisions, given the very significant
problems that Flagged Revisions poses in terms of engaging new users, adding
complexity and confusion to the existing too-hard-to-understand interface,
and badly impacting the quantity, quality and depth of the wikis on which it
has been used.

Sorry for the slowness of the response.

Just some personal experience, probably not too relevant for this bug:

When I joined Wikipedia (the German language one) in January 2012, FlaggedRevs gave me some kind of security when editing as I knew *someone would review* my edits and fix mistakes I made, and they are not going to be unattended. At that time, I was even shocked to see that other language editions did not have this feature enabled which helped me a lot with my first steps on Wikipedia. I would probably even never had dared to edit any page if I hadn't seen these "ungesichtete Versionen" banners across the entire wiki.

(In reply to Erik Moeller from comment #18)

FlaggedRevs adds a lot
of complexity to the editing experience [...]

Is this backed up by data?

In your email to me you mentioned
an increase in vandalism, is this backed up by data?

This bug is not a WONTFIX until an actual reasoning for the WONTFIX is provided, ideally backed up by data as Erik likes arguments to be. Erik said such a thing is being worked on this month, so this may be temporary.

In the meanwhile, I'm closing this bug as INVALID instead because the request (currently) fails to meet minimum standards for such an important change on such an important project, now written down at https://meta.wikimedia.org/wiki/Flagged_Revisions#Enabling . Yes, they were not written down, so it's not your fault.

Hi John,

Thanks for your patience. A couple of follow-up questions:

1. Is this the only discussion that has happened on this issue in the Norwegian Wikipedia community?

https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-23

I realize it is a small community, but there are 350+ active and 50+ very active editors according to http://stats.wikimedia.org/EN/TablesWikipediaNO.htm - it looks like this was a discussion only among a very small number of people, for a very big change that will affect the future of the project for years to come. Am I missing something? It seems like it would be appropriate to advertise this via a poll in the sitenotice, no?

Please note that these deployments have historically been contentious; English Wikipedia never agreed to a full FlaggedRevs deployment, and Russian Wikipedia's vote was divisive (see bug 13659). It's important that the community is aware that this change is being proposed, and what it means.

2. Google Translate is not especially helpful in understanding the level of preparation that has taken place. There is very little evidence that links FlaggedRevs to editor activity, as far as I know. However, there is strong and clear evidence that a successful FlaggedRevs implementation depends on a well-organized effort to prepare the community, track metrics, and keep up with recent edits.

Compare:

https://de.wikipedia.org/wiki/Spezial:Sichtungsstatistik?uselang=en

https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D1%82%D0%B0%D1%82%D0%B8%D1%81%D1%82%D0%B8%D0%BA%D0%B0_%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BE%D0%BA?uselang=en

German Wikipedia's use is very well-established and the community is taking great care to keep up with recent edits; in contrast, Russian Wikipedia has a high percentage of pages that are outdated due to lack of reviewers. The end result is a more stale reader experience where even when just randomly browsing you see diffs of pending edits piling up. Is this something the community wants to avoid? If so, is there a plan in place to motivate reviewers, track the statistics, etc.? Perhaps a post-launch campaign via sitenotice to let people know why this is happening and how to be part of the effort?

In general, WMF has historically enabled FlaggedRevs configurations without much review. We are not going to blanket veto them at this time, but we will develop a more systematic checklist to ensure such significant changes are well-supported in communities that request them, and that the level of preparation is consistent with what's required. Once again, I understand that the Norwegian community is very small, but would strongly recommend at least advertising the discussion via sitenotice for a while if this has not already happened.

Hope this makes sense. Reopening the bug since we're open to enabling it provided due diligence has been done.

One problem with these discussions is that due to the complexity of the FlaggedRevs extension, important details are often lost. So let's be clear what is actually being proposed here, as well.

John proposes to set $wgFlaggedRevsOverride to false, which means that readers always see the most recent version except on a per-page basis. This is also the configuration for Russian Wikipedia, mitigating the impact of their large backlog.

I still think that this is something that merits more discussion than what looks like a single Village Pump thread (and no comments on the proposed configuration itself) but the impact is far less broad than the German Wikipedia configuration.

1. Discussions at WP:Tinget (virtually WP:Parliament) will end in a decision if there is sufficient consensus or there is a final vote. If people does not involve themselves they do know it will have implications for themselves. We have another forum WP:Torget (virtuall WP:Bazar) which is more like a QA, or a Vallage Pump -page.

Discussions have been on-going about FlaggedRevs for a long time
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-23#Patruljering_og_pending_changes (one month long discussion leading up to this request)
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2014-33 (note about this thread)

Some other threads
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2009-07#FlaggedRevs
https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2010/januar#Flagged_Revisions:_Your_questions_answered.21
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2010-10#Stabile_versjoner
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2010-24#.C2.ABPending_changes.C2.BB_eller_det_som_er_kjent_som_.C2.ABflagged_revisions.C2.BB_tas_i_bruk_p.C3.A5_en-wp
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2009-35#Nytt_system_for_redaksjonell_kvalitetssikring_av_artikler_p.C3.A5_engelsk_Wikipedia
https://no.wikipedia.org/wiki/Wikipedia:Torget/Arkiv/2009/oktober#Kvalitetssikring

It is a long time since we set up patrolling as a replacement for FlaggedRevs
https://no.wikipedia.org/wiki/Wikipedia:Tinget/Arkiv/2007-41#Utvidelse_av_RC-Patrol_.28inntil_vi_evt._f.C3.A5r_stabile_versjoner.29

At nowiki we have had patrolling for a long time, here is our page for information about this process
https://no.wikipedia.org/wiki/Wikipedia:Patruljering

2. Because we already have patrolling in place I can't see any big changes in the present process if we switch to FlaggedRevs, especially with the configuration we want, as this will create a process very close to the present one. Some of the limits we want is although a bit strange, they are set fairly high for Autopromote, but that is because of present consensus on what should be used as limits for patrollers and autopatrollers.

The configuration we want is a minimum footprint where we only block access to unpatrolled pages when the situation is highly troublesome, and then only for å very limited number of pages. I guess that will be pages that intersect with themes from public school. Normally we do not protect pages at nowiki to avoid vandalism, we block the vandals.

The number of patrollers are declining, even if it is still pretty high.
https://no.wikipedia.org/w/index.php?title=Spesial:Brukerliste&offset=&limit=500&username=&group=patroller

I would like to signal very clearly to editors that they get additional features as they build trust in the community, and let the FlaggedRevs be one of those additional features they gain access to. I think that can motivate people to become reviewers and perhaps also to stay active.

There is a problem that we have to little metrics/stats on the impact of this extension. Even so I don't think nowiki should solve those problems, I think that is something for WMF. One way to do this could be to classify user actions, and then formulate a total workload the community is able to handle. This has implications not only for patrolling (or page review) but also for other actions like categorization or spell checking.

I have looked at how we could better track the number of unrevied pages, as a kind of quick and dirty metric, and how to better match that against the number of reviewers. One option could be as simple as setting a fraction (num active reviewers / num unreviewed pages) and if it becomes to high a visible marker will be set somewhere on the reviewers webpage. That should be fairly simple and should be sufficient to keep control on the number of unreviewd pages, and if that does not work we can simply remove pages from flagged review.

A configuration change like this is not the proper place to discuss additional development work, but it could perhaps be a place to identify the problems and to initiate new bugs that describe new product features.

It is correct as Erik write in his last note, we want $wgFlaggedRevsOverride to be set to false so we avoid the huge buildup of unreviewed changes. Whether this is sufficient we do not know, but we hope it will be. As such it is more like what they use on fiwiki. Our intention was to "keep what we knew work at our present patrol scheme, but add additional tools".

A final note; there should be no real problem restarting the discussion yet another time, but this time with site notice about the on-going thread on WP:Tinget. Only problem would be that people gets tired of repeated consensus building, especially if it ends in voting.

dyveldi wrote:

Question. At Norwegian Wikipedia we are wondering what more we have to do do get this change implemented. We have had a pretty conclusive discussion on our parliament/Storting (and we are waiting for the result, see https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&diff=next&oldid=13395205#Implementering_av_pending_changes_.232 se link on top to previous thread). Please advise us so we can proceed correctly.

dyveldi wrote:

Question no 2. Will this be reversible if it is implemented?

Sorry for the delay. Based on the explanations provided (esp. that it's a narrow, limited use case) I see no reason not to go forward with this. Reversibility should not be a concern but Sam can weigh in with details.

Ready to deploy the change from my end; James, please weigh in if you have final concerns about the proposed config.

Again, apologies that no.wp got hit with a very delayed response here; we want to make sure we consider expanded FlaggedRevs use carefully, but this seems very well thought out and limited in scope.

dyveldi wrote:

Thanks. Regards Dy

I've been asked here to hold off til the vote in progress closes:
https://meta.wikimedia.org/w/index.php?title=User_talk:Erik_Moeller_(WMF)&diff=9848765&oldid=9698325

If nowiki opts for a more dewiki-style configuration, we should talk a bit more about the prep.

A new voting is in progress, and I don't think it should stop that.

Any final outcome here?

Outcome of voting over FlaggedRevs is in thread "Implementering av pending changes #2" [1], result in subthread "Resultat av avstemming" [2].

Of 29 votes 16 was for pending changes, or 55%. The more restrictive version got 6 additional votes so in total 76% was for testing out FlaggedRevs in some configuration. It on the lower end on number of participants, but that is expected when a previous consensus has been built and has been discussed over a long time.

There was two users that was rather vocal about the voting, but both was for FlaggedRevs. Seems like it was mostly about the way and why we were voting.

There is one user that disagree with the voting a week after the voting was closed. He has been involved in the detail discussions.

A further detail discussion "Detaljer for uttesting av Ventende endringer" [3] has the following points, but note that this can be changed during the testing.

• We do not want to test out strict stable versions aka the German solution
• We want two levels for page protection
• We will keep the 7/20 model for autoconfirmed, but with the addition of two separate edit groups and edits on at least to pages, possible even more rules
• We want an additional role "editor", this is according to our present patrol model which has a role "autopatroller"
• We want the simple UI if possible, but if number of scales grow it could be to cluttered
• We want all newly created pages by anonymous and new editors to go through review
• We want to use the AbuseFilter for flagging suspicious edits (this is bug 49770)
• We want some name changes (we will do this ourselves in Translatewiki)
• We will use a normal setup for user rights
• We will use a minimum setup for quality scales initially
• We will not set any maximum number for protected pages
• We would really like it if we could give positive feedback to the editors through the revision summary (this is bug 52510)
• We will not set any specific demands for any analysis or research for doing this testing, but if anyone wants to do it will help out if possible (this is to avoid blocking progress)

[1] https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&oldid=13428142#Implementering_av_pending_changes_.232
[2] https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&oldid=13428142#Resultat_av_avstemming
[3] https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&oldid=13428142#Detaljer_for_uttesting_av_Ventende_endringer

Erik: Any objections to this?

No - do we have a proposed config?

(i.e. an updated version of https://no.wikipedia.org/wiki/Wikipedia:Konfigurasjon_for_FlaggedRevs )

The discussion about details are now closed and archived.

We should initially use the simpler UI with a simple scale. After a while we will probably change to a scale that accomodates the FA-articles at nowiki.

The red flags for unpatrolled edits should be set for anonymous, new, autoconfirmed and confirmed users, but not for users at autoreviewer and reviewer level.

Normal edits should show the current version as default, yet users can chose to only view the stable version.

New pages should initially be set to be hidden if they are created by an anonymus or new user until they are confirmed by a reviewer. Not sure if this is in fact supported by FlaggedRevs, but the most serious vandalism we have is at new pages.

The configuration example linked to by Erik Mõller is slightly outdated.

Last version of our discussion with the voting and such before archival
https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&oldid=13445778#Implementering_av_pending_changes_.232

Last version of our details discussion before archival
https://no.wikipedia.org/w/index.php?title=Wikipedia:Tinget&oldid=13452322#Detaljer_for_uttesting_av_Ventende_endringer

Does someone volunteer / have time to pick this up and work on this?

Jeblad, was any of the four steps at https://meta.wikimedia.org/wiki/Flagged_Revisions#Enabling completed? It seems not, because https://translatewiki.net/wiki/Special:MessageGroupStats/ext-flaggedrevs-0-all shows the extension is only 83 % translated in nb, and I don't see anything of the rest.

This request is from May 1th 2014 and Nemo_bis changed the enabling section of "Flagged Revisions" July 26th, I think it would be fair to review the later changes before older requests should follow this change.

That said; this request had a complete localization as said in one of the first postings in this thread, also from May 1th 2014, "The complete extension is translated to Norwegian (bokmål), but proofreading is missing for some of the strings."

I have made some patches, but they are all outdated now. Don't think any of them was actually uploaded, except for some only meant for internal discussion on nowiki.

I was quite sure that I asked about a test wiki, but I can't find a request for it. Probably didn't get around to it.

This process has become quite slow, and I'm not sure how much time I can put into this. Note that the request for this change is from May 1th 2014 and we're now at March 24th 2015. At least I can't do much followup on this right now, but I can check the latest additions to the message group and complete the translations.

Yes, enabling FlaggedRevs is painful. As I tried to say in T66726#709995, it always was, and that's always been the process AFAICS; however it was unwritten. :(

Thanks for your translations! Updates to nb translations in last year were 95bb818, 396a24f, 9156381, 2e2400e, 4fdc637, 390ecc1.

It was the localization of the API that killed the translation stats. Nothing really new, just old stuff that lacked translation and had become visible.

These are default user rights assigned to user groups:

autoconfirmed => (
    movestable – user can move pages with stable revisions
)

editor => (
    review – user can review revisions
    autoreview – any new revisions made by the user are automatically marked as sighted
    unreviewedpages – user can view Special:UnreviewedPages
    movestable – user can move pages with stable revisions
)

reviewer => (
    review – user can review revisions
    validate – user can review revisions and can set all tags to all levels
    autoreview – any new revisions made by the user are automatically marked as sighted
    unreviewedpages – user can view Special:UnreviewedPages
    movestable – user can move pages with stable revisions
)

autoreview => (
    autoreview – any new revisions made by the user are automatically marked as sighted
)

All available rights in FlaggedRevs extension:

review – user can review revisions
validate – user can review revisions and can set all tags to all levels
autoreview – any new revisions made by the user are automatically marked as sighted
autoreviewrestore – autoreview of the rollbacks mane by the user.
unreviewedpages – user can view Special:UnreviewedPages
stablesettings – user can changes the settings of stable revisions of any page
movestable – user can move pages with stable revisions

1. Which user groups should be kept and which should be removed from defualt user groups?
2. Which rights should be assigned to existing user groups?

Suggested changes:

Remove 'reviewer' user group.
Assign 'validate' right to 'editor' user group.
Assign 'stablesettings' right to 'sysop' user group.

These changes would not be according to the consensus on nowiki, especially removing the reviewer role would break the current patroller setup at nowiki.

@jeblad that was my suggested configuration, what's yours?

To get feedback from the global community on the FlaggedRevs deployment opportunity, I've launched a RfC on meta.

@jeblad Could you add your arguments in favour of FlaggedRevs at this RfC?

Previous on-site discussions about this change

• Patrol and PendingChanges
• Implementation of PendingChanges
• Patrol and PendingChanges #2
• Details for testing of PendingChanges
• Bug is now updated with details from the discussions about pending changes

Tasks posted as a result of the on-site discusions

• T72458: Ordinary users should be able to tag contagious edits for pending changes
• T72457: Set a limit on pages with forced review when there are too few active reviewers
• T72456: Use Echo to give warnings to reviewers if the number of unreviewed changes goes above a limit
• T72453: Reviewers should be able to hide revisions with contagious content
• T72452: Mark edit as pending review for all users from the same IP-address/range

Is this still alive? What happen with the RfC on Meta? As far as I know the request for enabling FlaggedRevs is not withdrawn, but the issue is not pushed either.

About nowikis suggested config. It is protection setup which is limited to max 2000 protected pages so there should be no problems with pending lag queue and generelly settings are looking ok.

• https://no.wikipedia.org/wiki/Wikipedia:Konfigurasjon_for_FlaggedRevs

I would simplify the groupPermissions and add/removegroup block like this: (i removed the lines which were same as default)

# Group permissions for reviewer
$wgGroupPermissions['reviewer']['stablesettings'] = true;
$wgAddGroups['reviewer'][] = 'editor';
$wgRemoveGroups['reviewer'][] = 'editor';

# Group permissions for sysops
$wgGroupPermissions['sysop']['review'] = true;
$wgGroupPermissions['sysop']['validate'] = true;
$wgGroupPermissions['sysop']['stablesettings'] = true;

Based on fiwikis experiences i would also change the tag settings so that there is clear difference with selecting the level 2 and 3 in the user interface. I would also change the autoreview so that all levels can be autoreviewed.

$wgFlaggedRevTags = array(
    'accuracy' => array( 'levels' => 3, 'quality' => 2, 'pristine' => 3 ),
);
$wgFlagRestrictions = array(
    'accuracy' => array( 'review' => 3, 'autoreview' => 3 ),
);

Also based on current flagged revs enabling guide the next steps are

1. send a patch for the shell request proposed configuration;
2. get a test wiki for the language created on the beta cluster, test the translation and configuration there to ensure it's as intended;

So would somebody make a patch and Jeblad write a ticket for the test wiki.

Note that the consensus leading up to this request is three years old.
Whether there are still any consensus on this is not clear at all.

@Zache We aren't deploying Flagged Revisions on new wikis as long as the
global community (for example though the meta RFC) don't send a strong
signal they still want we deploy this extension.

I've clarified the documentation you've found.

@jeblad, the point wasn't really any more if there was consensus but get things forward. Norwegian wikipedia's request was good as you can get and even so it was declined. Also when requirement is a strong
signal from global community which is not achievable it means that there is no new FR installations any more and question is now what to do with existing ones.