Introduce rcshow=oresreview and similar ones
Closed, ResolvedPublic
Actions

Description

See T122689#1939440

We need to add two cases to "..show" parameters when list=watchlist or recentchanges, or usercontribs (for the sake of consistency between GUI and API). I suggest we add "oresreview" and "!oresreview" which the first one only shows edits that passes a certain threshold [1] and second one only shows good edits. we can simply query from ores_classification table

[1]: This threshold is $wgOresDamagingThreshold and it's determined wiki-wide but my plan is to change it to something users can alter in their preferences.

Details

	Project	Branch	Lines +/-	Subject
	mediawiki/extensions/ORES	master	+730 -10	Action API integration for ORES
	mediawiki/core	master	+102 -12	API: Add hooks for ApiQueryBase's query and row-processing

Customize query in gerrit

Related Objects
Search...

Status	Assigned	Task
Resolved	None	T143895 [Epic] Implement ORES service proxy in api.php
Resolved	Anomie	T143616 Introduce rcshow=oresreview and similar ones
Resolved	Anomie	T147939 Add ability to hook into WatchedItemQueryService and ApiQueryWatchlist

Event Timeline

Ladsgroup created this task.Aug 22 2016, 9:10 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 22 2016, 9:10 PM

Anomie added a subscriber: Anomie.Aug 23 2016, 1:54 PM

Ladsgroup moved this task from Backlog to Prioritized on the MediaWiki-extensions-ORES board.Aug 24 2016, 8:25 PM

Halfak added a parent task: T143895: [Epic] Implement ORES service proxy in api.php.Aug 25 2016, 2:13 PM

Halfak triaged this task as Medium priority.Aug 25 2016, 2:29 PM

Halfak moved this task from Unorganized to New development on the Machine-Learning-Team board.

Bianjiang added a subscriber: Bianjiang.Aug 29 2016, 11:35 PM

Halfak mentioned this in T122689: [Discuss] api.php integration with ORES.Aug 30 2016, 5:31 PM

Anomie updated the task description. (Show Details)Sep 19 2016, 6:31 PM

list=watchlist might be a bit tricky, since it's using WatchedItemQueryService instead of doing the queries directly so it won't be as easy to adjust the query from the extension's hooks. I've asked @Addshore for advice on that since he wrote that code.

One open question is what to do for revisions that don't already have scores saved in the database:

Treat them as needing review (only returned with show=oresreview)
Treat them as not needing review (only returned with show=!oresreview)
Filter them out when either ORES filtering option is used
Don't filter them out (only apply the filtering to revisions that have scores)

Note that #1 or #2 could result in unexpected output, since later fetching the scores for those revisions might reveal they should have been filtered out.

For the sake of consistency with the GUI, I think we should follow #2. Number of revisions not stored in the db is negligible for watchlist and recent changes. What do you think?

I lean towards #3, but that's mainly because the potential for inconsistency really bugs me.

Change 313830 had a related patch set uploaded (by Anomie):
API: Add hooks for ApiQueryBase's query and row-processing

https://gerrit.wikimedia.org/r/313830

Change 313831 had a related patch set uploaded (by Anomie):
Action API integration for ORES

https://gerrit.wikimedia.org/r/313831

Change 313830 merged by jenkins-bot:
API: Add hooks for ApiQueryBase's query and row-processing

https://gerrit.wikimedia.org/r/313830

ReleaseTaggerBot added projects: MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-10-11_(1.28.0-wmf.22)).Oct 7 2016, 5:00 AM

Ladsgroup edited projects, added Machine-Learning-Team (Active Tasks); removed Machine-Learning-Team.Oct 7 2016, 1:13 PM

Ladsgroup moved this task from Backlog to Completed on the Machine-Learning-Team (Active Tasks) board.

Halfak closed this task as Resolved.Oct 11 2016, 11:51 PM

Halfak claimed this task.