@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)

@Tgr was the plan with the protected mode that you would be tracking all the articles but revision displayed on default page view would be latest OR would you also reduced number of articles which you were tracking? Typical Flagged revision protection setup is that there is under 5000 tracked articles.

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

Just for ideas

Still relevant. Current Special:ValidationStatistics is also broken; see bug T163107 .

Problem is most likely related to backend/FlaggedRevsStats.php: getEditReviewTimes() -function.

Some timestamps from the DB

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

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

Even more generic vesion of this would be that we don't want just to show Wikidata items with coordinates on the map, but also SPARQL results with coordinates no matter what the source of the coordinates is. In some cases source is P625, but i think that valid case is that the coordinates are created or modified in the query.

If we just want all trusted users in fiwiki then we can use these three groups: autoreview, editor and reviewer whose edits are automatically reviewed in. Flagged revs.

Thank you!

Least part of the RKY and Muinaisjäännösrekisteri data can be downloaded from here ( I didn't check if the long descriptions were in zip files too or was it just map+metadata). Downloadable datasets itself are finnish only and file "Tietotuotemääritettely_DATASETNAME.pdf" contains information about the content and I think that most useful part is the paragraph "4 Tietosisällön ja rakenteen kuvailu" which contains diagrams about the data in the zip files.

@Jc86035, i meant that Wikidata property would point to OSM tag which would be more stable in context of permanent linking than using id:s directly. In this case i meant to use the wikidata id as a suitable tag.

Sorry, yes i meant Wikidata id:s. and OSM wikidata tags. I tried to clarify my ticket.

It would be nice to get information of OSM link to SPARQL too. Value like Wikidata id can be found in OSM (true/false) value should be enough.

I added some common bad words more from fiwikis abuse filter rules. Though i think that there would be more if the more is better.

Xqbot is now flagged locally as bot

• https://fi.wikipedia.org/w/index.php?title=Toiminnot:Loki&user=Xqbot

Hmm, @Sophivorus seems to work and i added it to the gadgets under "Testattavana olevat pienoisohjelmat" -label (eg under testing category).

Filtering or sorting the input fields when user edits the reference. Eg. by default there could be visible only fields with required flag OR suggested flag OR fields which value is not empty and user could select to see the rest.

Hmm, 've.activate' and 've.activationComplete' seems to be suitable for detecting the switch from wikicode editor to VE. Eg.

@Esanders My guess is that the[[ https://www.mediawiki.org/wiki/VisualEditor/Citation_tool | visual editor citation tool ]] will not be supported in current wikitext editor which will be around least couple of years even if not longer and i think that the main value of Proveit is to get new stuff (like support for autogenerated refs) to current editor. Also in coder point of view the citoid is backend and Proveit editing interface and most likely Proveit when it is developed more will be using Citoid too for getting data for references. Least this is my guess.