Change Details

This is an epic task. We'll add some subtasks as they become apparent. ## An API * indicate how a human would provide a judgement (e.g. "damaging" is a boolean and has translatable messages) * indicate some sort of grouping between "damaging" and "goodfaith" / "drafttopic" and "draftquality" * provide access to judgements (based on entity identification) ## A state database Could be postgres like wikilabels. Doesn't need to represent any sort of "final" form. This will be the primary back-end for queries from the API. This state database should be populated and maintained using "events". ## An event generation system and master log This should be able to hook into eventbus. It doesn't need to actually hook into eventbus because eventbus probably can't take events from labs at the moment. Storing a history of logs in a large file or a DB table is perfectly acceptable. The idea is that the state database can always be re-created by processing the event logs in order. ## Explicitly left for future work * curation/moderation * mediawiki integration * any reference UI

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.

This is an epic taskWe have a MediaWiki extension for storing and validating JADE judgments. We'll add some subtasks as they become apparent. ## An API * indicate how a human would provide a judgement (e.g.Our plan is to burn-in for a short time on the beta cluster, "damaging" is a boolean and has translatable messages) * indicate some sort of grouping between "damaging" and "goodfaith" / "drafttopic" and "draftquality" * provide access to judgements (based on entity identification) ## A state database Could be postgres like wikilabels. Doesn't need to represent any sort of "final" form. This will be the primary back-end for queries from the API. This state database should be populated and maintained using "events". ## An event generation system and master log This should be able to hook into eventbus. It doesn't need to actually hook into eventbus because eventbus probably can't take events from labs at the moment. Storing a history of logs in a large file or a DB table is perfectly acceptable. The idea is that the state database can always be re-created by processing the event logs in order. ## Explicitly left for future work * curation/moderation * mediawiki integration * any reference UIto be sure that there aren't any unexpected side-effects of our ContentHandler and so on.