Wikimedia Bugzilla is closed!

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.

«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.

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.

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.

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