Occasionally writes things in Python
Fri, Sep 21
Tue, Sep 18
Fri, Sep 14
Tue, Sep 11
Mon, Sep 10
As JADE develops it is moving closer to a model where multiple people can collaborate on a single judgment for a given entity. This goes against the requirements that Wikilabels (a) allow different people to make multiple judgments on the same entity and (b) treat judgments as immutable actions. As such, it makes sense to recognize JADE and Wikilabels as separate products with separate purposes.
Fri, Sep 7
I think we can defer on articlequality for the time being. Let's get JADE out the door first, then we can worry about this.
I like option b the best, but I think then we would need a new/adjusted name, since "tool" in common parlance does not include "MediaWiki extension" (although we agree both are ways of fulfilling business requirements).
Thu, Sep 6
Wed, Sep 5
The extension is ready to be reviewed, having since been moved to Gerrit.
In the event of missing fields, the error should be handled through an error message generated by MediaWiki. It should not result in PHP-level exceptions.
Wed, Aug 29
Alternatively we could call the datatype strict-boolean.
Tue, Aug 28
Sun, Aug 26
Aug 23 2018
Aug 22 2018
Aug 21 2018
Aug 16 2018
Aug 14 2018
I generally agree that it would be better to build bits of JADE into the interface, rather than create a monolithic editing interface.
Aug 13 2018
Aug 8 2018
I've worked with @awight on a document describing JADE's requirements and possible implementation strategies. https://www.mediawiki.org/wiki/JADE/Implementations
Aug 3 2018
Wouldn't this be an ORES feature rather than a JADE feature?
Aug 2 2018
Jul 31 2018
Jul 30 2018
Thank you for the summary, @mark. I am interested in this perspective that we can get the same user experience (i.e. a new content namespace) but with a different backend. One of the benefits of wiki pages is that researchers and other data consumers can benefit from the same APIs and tooling from other wiki pages. And because they are still wiki pages, the wiki communities can interact with them as they would interact with other wiki pages. This includes the ability to revert edits, delete judgments, suppress them – all functions that they need to be able to do. Would these affordances still be available with a new storage backend? Would it be possible to do this without spending years of engineering time fully abstracting storage from other pieces of logic?
Jul 28 2018
Jul 25 2018
We did recently just rename the namespace from Jade to Judgment since Judgment is better semantics (namespaces describe the thing they are, not the name of the software implementing them), but I am open to additional names as well. Personally I like Review or Score.