We have a MediaWiki extension for storing and validating JADE judgments. Our plan is to burn-in for a short time on the beta cluster, to be sure that there aren't any unexpected side-effects of our ContentHandler and so on.
|operations/mediawiki-config : master||[DNM] Enable Extension:JADE on all beta cluster wikis|
|operations/mediawiki-config : master||Enable Extension:JADE on all beta cluster wikis (take 2)|
|mediawiki/tools/release : master||Add new extension JADE to the branch config|
|operations/mediawiki-config : master||Enable Extension:JADE on all beta cluster wikis|
|Resolved||None||T176324 Scoring platform team FY18 Q2|
|Resolved||awight||T176333 Deploy JADE prototype in Beta Cluster|
|Resolved||Keegan||T170954 Set up working group for JADE|
|Resolved||Keegan||T174685 Create list of ORES collaborators (focus on language asset helpers)|
|Resolved||Halfak||T181098 Implement basic path structure for JADE (judgements)|
|Resolved||awight||T187216 Build prototype JADE extension|
|Resolved||Bawolff||T188308 Security review for Extension:JADE|
|Resolved||awight||T199750 JADE pages on beta no longer render|
This is great, thanks for roughing out the MVP!
A few things come to mind,
- An archive of events using versioned event schemas sounds like a much more difficult migration problem than a database that evolves with our project. Reprocessing old events requires that we preserve the code to parse the old event into some intermediate form, then transform that into the most current event schema, or that we maintain code to parse all old schemas into the current storage schema. Comparing it to the alternative, we import events into our database and treat that as the authoritative store, then our migration problem is just to update the data as it exists in our system, and the oldest schema we need to care about is the previous revision.
- postgresql is a joy to work with, +1 to that suggestion if we end up with an RDBMS.
- Let me plug my PR for review here, https://github.com/wiki-ai/ores-diagrams/pull/2 . The data flow diagram might help our discussion.
- We can't have a MVP supporting free text, but without admin suppression. We probably don't want an MVP without free-form text.
Regarding the comment suppression concerns, it might be fair to have our service create Flow posts from the comments, then store the URL in our database. This might even be acceptable in the medium-term, beyond MVP.