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
Re: RFC Discussion Wednesday - new namespace for collaborative judgments about wiki entities
> 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:
On a cursory look, there's also some affinity between this and what
Wikibase Quality Constraints extension is doing. Though this data is not
human generated but automatic, but still this is quality-related data
which is linked to page content (and different for each revision AFAIU).
Currently if I understand right it has its own storage.