Change Details

This is an epic task. We'll add some subtasks as they become apparent. * JADE MVP in Labs (@awight ) * 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" * a state database (could be postgres like wikilabels) * a event generation system (could hook into eventbus) * Explicitly left for future work * curation/moderation * mediawiki integration * any reference UI

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

This is an epic task. We'll add some subtasks as they become apparent. * JADE MVP in Labs (@awight ) * a## 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. * a state database (could be postgres like wikilabels) 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. * a event generation system (could 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