Confirmed in fiwiki's WLM campaing too.

Is there some reason why this is stalled?

Currently both goodfaith and damaging are giving weighted scores (to good end). For example, goodfaith is pretty much always 0.95 or better. Same is true with the damaging too but weighting seems not to be that bad.

beefed-up version of MW core's patrolling feature

@Liuxinyu970226 if I understand correctly it is not just flagged revs which doesn't work but the version history is broken too. It just shows up with FR more easily. So mapframe and graph needs to be fixed anyway.

Thank you very much, the data was very useful and I was able to read what needed from monthly files of Pagecounts-ez.

For request #3, the whole timespan of the dataset but I would like to get the specific end and start dates with the result.

Hi, I am perfecly happy for doing the manual cleanup :) It is 5000 because i need additional data if i need to pick specific topics like most readed scientist, most readed women articles etc.

Currently if you edit the stable version (https://test2.wikipedia.org/w/index.php?title=VE-flaggedrevs&stable=1 )

@matmarex There is wgStableRevisionId if that helps.

This should be confirmed, but my guess is that log_type "review" have always missed the keynames, but the log_action "autopatrol" which was triggered by review action had it. Would be nice if this would be fixed though.

Btw. By disabling the logging we lose the ability do stats/graphs how much of the edits were patrolled/autopatrolled/not patrolled if needed outside of the 30 days recentchanges table window.

@Liridon In Finnish Wikipedia we have a bot which retroactively approves the edits after the bot flag or autoreview flag is added. We have also a ORES support so it can approve the edits based on that, but I think that using ORES to detect who should be added to autoreviewed usergroup is the main thing for us.

In T151665#4113725, @jmatazzoni wrote:

The wikis where Flagged Revs is a problem are those that hide the latest version by default ($wgFlaggedRevsOverride = true). Right? See if you agree with the updated breakdown now in T191583. Thanks!

@jmatazzoni, I can confirm that in fiwiki which have been using the flagged revs and mapframe some time and combination seems to work fine.

Reason for the |lang=fi is that the filter doesn't match to change but to the full content of the page. Eg the concept is that if there is visible wikicode to the reader then the filter will trigger. However the reason for the visible wikicode doesn't need to be the edit, but the error can already be in the article.

@Perhelion The relevant (local) abuse filter (61) seems still imperfect and in the beginners' phase.

Hi, the triggering filter is abuse filter 61 and it tries match if there is "{{{", "}}}" , "[[", "]]" strings in the article. It is triggering pretty easily but it has not caused any visible problems because it is tagging only and it helps to pick up the problematic edits.

https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Proposal_to_include_non-CC0_licenses_for_the_Data_namespace

@Yurik In example there is old borders in OSM version history and there is borders where we know that they will be obsoleted because some reason. In example in Finland there is couple municipal mergers per year which effects to the boundaries. Anyway it doesn't need to be 1:1 reuse but if you are doing derivative work based on OSM data then OSM licence matters.

Second real life use case wast that in WLM we had ~1500 RKY area's which borders are under CC-BY (by default). However for WLM we got borders only to some samples under CC0.

• https://commons.wikimedia.org/w/index.php?title=Special%3APrefixIndex&prefix=Rky%2F&namespace=486

@Yurik Sure, my use case would be more like if you want to make derivative maps / layers based on OSM . Static historical boundaries could be one real life use case.

Not directly related, but it seems that huwiki moves to $wgFlaggedRevsOverride = false; mode (T121995) for a 6 month testing period. Currently in huwiki all edits are reviewed before being visible. After changes they will be directly visible like in fiwiki so there is bigger need to find bad edits. Also they don't have ORES goodfaith/damaging model labeling done ( http://labels.wmflabs.org/stats/huwiki/ )

Thank you for remembering this and it is important .

Propagated 'Wikidata edits' with Experience level filters are using local wiki editcount/activity for experience level and so propagated edits are marked as newcomer edits. It would be more useful to use source wikis (eg. Wikidata) editcount/activity for getting the experience level.

Yes, you can create or rewrite the Wikidata item in one edit. Example

• https://www.wikidata.org/w/index.php?title=Q29968431&action=history

Fix for the empty space could be floating the remaining rcfilters in fieldset box to the right side of the screen so it would be leveled at the same level than the new recent changes box.

@awight , after toying with the .json.bz2 i would say that we can be pretty sure that edits aren't damaging. I didn't find any clear vandalism and in context of damaging the biggest problem seems to be rather high level of unsourced (goodfaith) edits. However i personally don't see unsourced goodfaith edits a problem.

Sorry about the delay. Just too many things to do. I am trying to do thist today.

A couple of questions:

In T166235#3482194, @Halfak wrote:

Nice work on this. I'm starting to think that we're going to want some tuning to get this working better. @Zache, can you confirm that we should treat all "approved" edits as non-damaging/goodfaith?

Visual editor saves dates in yyyy-mm-dd format.

Citoid and VE will use ISO dates

First update message done

• https://fi.wikipedia.org/w/index.php?title=Wikipedia%3AKahvihuone_%28tekniikka%29&type=revision&diff=16646108&oldid=16645879

Purge seems to change the load order so that one can edit the page. "Unknown dependency: wikibase.mobile Error" is still there after purge and if debug-mode is used then add/edit links are missing again.

Confirmed. I raised the priority to high because this prevents the editing of the wikidata if bug hits before property edit buttons are added.

As you said, the approved query is only taking the first diff, and there can be multiple edits per approval. I'm wondering if we want to ignore these multi-diff approvals, or take all the included diffs as approved?

I'm unsure whether the reverted query is getting what we intended. When does "rv" get added to the ChangeTags, and is it specific to pages using flaggedrevs?

Follow up actions.
There is a bot based stabilization now which does a 24 hour stabilization to the page after a problematic edit. The bot follows the EventStrean and stabilization is triggered if the score of the edit is high enough. In fiwiki the score is based on how many rules like ORES, Abuse filter, graylisted ip range etc edit triggers and least two rules need to be triggered for stabilization.

• approve, approve2 = reviewing the pending changes
• approve-i, approve2-i = articles first approve
• approve-a, approve2-a = autoreviewed
• approve-ia, approve2-ia = autoreviewed first approves (articles created by users with autoreview right)
• unapprove, unapprove2 = removing the approval

My guess is that the best use cases would plwiki and ruwiki. Both have advanced ORES support enabled and strong technical community for running and modifying the bot if they want to do so. Next after that would be huwiki which is currently doing ORES advanced support labeling. Ukwiki would be also interesting choice if Bunyk who was at the hackathon is interested for participating.

Here is a proof-of-concept style pywikibot script for reviewing the Flagged Revs backlog which also works in other Wikipedias apart from the Finnish Wikipedia.

• https://github.com/zache-fi/PendingChangesBot

Notes copied from: https://etherpad.wikimedia.org/p/flaggedhack17

@Trizek-WMF did you think that automatic review based on ORES would be realtime like current autopatrol / autoreview is OR something which is like cronjob which checks the review backlog periodically and reviews if there is something new which can be reviewed OR both?

I tested the idea little bit. It would work with registered users pretty nicely, but least in fiwiki scores for ip-editors scores are generally lower than what they should be and it would need some help with that. In pl wiki if the scores are reliable it would work well.

The code of Commons upload bookmarklet can be found here. It is currently Commons beta because it will need OAUTH support and some kind community approval from Commons.

In wikis where the backlog is very long the backlog will need to be reseted somehow before it will work because one problem is that the there is old pending change and new edits will be pending too because that even if they were normally autoreviewed. Basic case is like this where there is trivial change blocks the automatic reviewing in newer edits.

"for breakout sessions: 25 seats around tables in U-shape, fixed projector and screen, flip chart", description is incorrect and there is no tables in Wiaschtl. Most likely this means that presentation is short and we are moving to somewhere we can talk, eat pitsa and beer.

It is today 19-20 in room Wiaschtl

Finna (Finlands national digital library) could be added to the list

• https://www.kiwi.fi/pages/viewpage.action?pageId=53839221
• https://www.finna.fi/?lng=en-gb

For the comparison there is Flickr URL upload in Upload Wizard

• https://commons.wikimedia.org/wiki/Commons:Upload_Wizard/Flickr
• https://commons.wikimedia.beta.wmflabs.org/wiki/Special:UploadWizard

I can see also the third use case for the "upload this to Wikimedia Commons" which is that it can be used for linking to the image in commons if it already exists.

In fiwiki we are tracking couple key numbers.

• maximum pending lag.
• number of pending changes

Database table is same that FlaggedRevs uses but queries are my own and i didn't check the FR code when i made them.

That also raises the question of whether we should have a filter to show only edits that need review

@WTM Quick temporary fix for recent changes list is to add link to recent changes list with hideReviewed=1 in sidebar (see diff)

This is also mentioned in phab:T164068 (Pending edits are not visible in recent changes page in ar.wiki) and related to phab:T164049

Confirmed in fiwiki too in this discussion:

In example for tracking the effects of phab:T164049 some crosswiki stats would be nice.

Some stats how bug is effected to reviews using Quarry

• Rewiews per day (quarry: 18306)
• Reviewers per day (quarry: 18307)

Confirmed in finnish Wikipedia too. Same regression exists in watchlist and Recentchangeslinked page too.

Thanks for the stats, i think too it was pretty Wow that it was so fast. Biggest thanks goes s to the Ejs-80 it seems :)

Btw, is it possible to get a list for a users who did reviews? We could give a barnstars to reviewers.

@Catrope ''(it sounds to me like all reviewed edits are also patrolled, but some things can be patrolled without being reviewed?''

If user have autoreview user right for FlaggedRevs but not autopatrol for patrolling then his/her edits will be only autoreviewed for Flagged Revs. This is the case in the Portuguese Wikipedia where autoconfirmed users have autoreview and patrol user rights but they don't have autopatrol use right.

Flagged revs documentation: "$wgUseRCPatrol is enabled with the extension. Patrolling of reviewable pages is disabled, but flagged revisions are marked as patrolled in Recent Changes. This will mean that the only way to patrol a reviewable revision is to flag it. Non-reviewable pages still behave as normal (depending on site patrol settings)."

Fiwiki uses Flagged revs and there is also patrolling enabled for patrol flag support in API. Setup is that the autopatrollers are also autoreviewed and users in editor user group are also in patroller user group. (T144817)