On Wed, Aug 22, 2018 at 12:54 PM Ryan Kaldari rkaldari@wikimedia.org wrote:
It should also be noted that there are some existing stop-gap implementations for specific use-cases that could effectively be replaced by JADE such as the PageAssessments extension https://www.mediawiki.org/wiki/Extension:PageAssessments, the page tags system in the PageTriage extension https://www.mediawiki.org/wiki/Extension:PageTriage
Hi, thanks for pointing this out! Here are the workflows we've identified so far, and how JADE might affect them in the long-term:
* Huggle: JADE as a communication backend to indicate which pages have been patrolled, what the damaging/not-damaging conclusion was, and any comments the patrollers might leave. * Recent changes patrol: Similar to Huggle. * New pages patrol: Storage for sharing draftquality and draft topic data. * Articles for creation: Similar to NPP. * en:WP:RATER: Shared storage for articlequality data. * FlaggedRevs: Similar to patrolling. * PageTriage: Similar to patrolling. * Wiki Labels: "blind", write-only store for labelers * ORES training: high-quality data source for human-labeled observations.
and ORES' existing database storage.
This last one is not a good fit, actually. The ores_* tables and service are optimized for bot requirements, for example we'll need to mass purge all scores produced by an old model when an update is deployed. These scores should all be regenerated using the new model. We're planning to leave the ORES runtime architecture almost untouched, with one large exception: JADE data will be provided in parallel, so a request for "all scores on revision 123456" will give ORES scores and JADE data, and we'll recommend that the client prefer JADE data since we expect it to be higher quality.
-Adam