On Wed, Aug 22, 2018 at 12:54 PM Ryan Kaldari <rkaldari(a)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