JADE/Use cases

End users
An editor is a contributor to a wiki where JADE is available. An editor uses the MediaWiki UIs to build, curate, and maintain content. Editors discuss their views and arrive at consensus decisions.
 * Editors

Patrollers review streams of new content for vandalism, damage, spam, and other types of problematic content. They often use a mixture of Special:Recentchanges and 3rd party tools to do their work.
 * Patrollers

Admins and other users with advanced rights are able to suppress content that is damaging to individuals or otherwise needs to be purged from a wikis history. They are often involved in the resolution of harassment issues (e.g. en:DOXing) and copyright issues.
 * Admins

Dev users
Tool developers are volunteers who build tools for other Wikipedians to use. Their tools may aid in patrolling, in task routing, or otherwise help Wikipedians manage their activities. Tool developers generally apply 5 approaches to delivery of their technologies: gadgets/user-scripts, MediaWiki extensions, robots, 3rd party web tools, and 3rd party stand-alone tools. Tool developers sometimes build secondary services for other tools to use such as APIs and streams.
 * Tool developers

Like tool developers, Wikimedia product teams design tools and systems for Wikipedians to use, but their teams comprise of full time staff with professional experience.
 * Wikimedia Product teams

Data consumers
The term "researcher" is often reserved for a professional researcher, but in this case, it refers to anyone who is trying to build knowledge. See en:WP:OR. Researchers review activities on wiki and use data analysis strategies (e.g. m:Quarry and m:Database dumps) to make sense of what is happening and what should happen. Data quality issues are of great concern to researchers.
 * Researchers

Model builders train artificial intelligences using human judgment as training examples. (Arguably, they are a subset of "researchers".) Model builders are concerned with the representativeness and availability of training data.
 * Model builders

Judge entity

 * Users: All dev users
 * Description: Subjective opinions on wiki entities are recorded. E.g. "This edit is damaging
 * Statement: I want to record the subjective judgments that I make while I'm doing related work.
 * Feature: Either directly or (more likely) using a purpose-built tool, the user can create a judgment. The judgment would include the aspect judged, the opinion of the user, and freeform text that provides further justification.

Disagree with current consensus

 * Users: Editor, Patroller
 * Description: Sometimes users will disagree on the appropriate label for an entity. That disagreement is can be filed as the beginning of a consensus discussion.
 * Statement: I disagree with other users about how an edit should be labeled. I would like to file my disagreement in a productive way.
 * Feature: A user who disagrees has different options. They can post to the talk page to register disagreement or they can propose a new, alternative label. While adding the proposal, the user may also BOLDly change the "preferred" flag.

Signal consensus

 * Users: Editor
 * Description: Editors work together to determine the best label and then flag it as the current best.
 * Statement: When there is disagreement and we're able to identify a consensus, I would like flag the best label for re-use and consideration by others.
 * Feature: At some point, the discussion concludes and an action is decided upon. A user can set the "preferred flag" on the proposal that represents the current consensus.

Describe endorsement

 * Users: Editor, Patroller
 * Description: Users can describe the reasoning behind an endorsement in a flexible, query-able way.
 * Statement: I'd like to explain why I chose to support a proposal. I sometimes have more to say about what criteria I find compelling.
 * Feature: While endorsing a proposal, a user can fill out a rationale explaining their preference. These notes belong to the user who filed the endorsement.

Describe proposed label

 * Users: Editor, Patroller
 * Description: Users can describe the reasoning behind a proposal label in a flexible, query-able way.
 * Statement: I'd like to explain my reasoning for proposing a label. In some cases, a proposal isn't obvious and I want others to know what criteria I applied when proposing a label.  I'd also like to look up labels by the content of their notes.
 * Feature: While proposing a label, a user can fill out a rationale explaining their preference. Other editors can edit this explanation to add more details.

Read judgments for entity

 * Users:Editor, Patroller, Researcher, Model builder
 * Description: Given an entity, are there any judgments? Is there consensus?
 * Statement: I'd like to know if an entity has been judged. I'd also like to know if there is consensus on a specific judgment.
 * Feature:There will be an API that provides judgment data for entities; clients can also fall back on the vanilla MediaWiki API and look up judgments using the page title structure "Judgment:{Page|Revision|Diff}/{page_id|rev_id}". For end users, we are working on areas in the user interface to surface judgment information.

Assess judgment quality

 * Users: Patroller, Researcher, Model builder
 * Description: Quality is captured in process. What kind of process lead to a given judgment?  Given an entity and a judgement, one can determine who agrees with what judgment and what experience level they have.  Who agrees with the consensus? Is the only editor involved currently in good standing (i.e. not banned)?  Do any experienced editors agree with consensus?  How many users agree?  Is there any dissent recorded?  Is there a description?  Does the description match the entity in some way?  Does the description use standard language?
 * Statement: I want to use my own exploratory strategies to determine which judgments are appropriate for my work. Most important to me are the who, where, and why.  Who provided the judgment. Where were they (what were they looking at?) And what is their justification (if any)?
 * Feature:Judgment pages include plenty of information that should help derive context. Users who are using a third-party client integrated with JADE will specify an origin in their judgments, which can be used to filter out (or filter in) particular curation tools, including those that use ORES. Users can also provide rationales and notes with their judgments, which can be analyzed by researchers.

Bulk download

 * Users: Researcher, Model builder
 * Description: In order to analyze trends and gather train/test sets, researchers and model builders will want to gather large sets of judgments for processing and aggregation.
 * Statement: I want to be able to get all of the judgments at once. Sometimes I just want to get judgments for a specific schema, but I can do my own filtering if the dataset isn't too big.  I'll use the smallest bulk dataset I can that serves my purpose.
 * Feature:JADE will offer either a specialized dump created with research in mind, or failing that, JADE data will appear in regular Wikimedia dumps.

API for performing editor/patroller actions

 * Users: Tool developers
 * Description: In order to enable their users to interact with JADE data, tool developers will need to develop integrations with JADE via a programmable interface. This programmable interface must allow 3rd party users to perform basic actions in JADE, but advanced actions may need to happen via the web interface.
 * Statement:I want to be able to let my users submit judgments to JADE. In unusual cases where their judgments are against consensus, I can link them to the advanced UI, but I'd like to do that rarely.
 * Feature:JADE offers an API for interacting with judgment pages. This API should make it possible for tool developers to integrate JADE with their applications.

Suppress changes

 * Users: Admins
 * Description: If you give people the space for it, they will harass and DOX each other. So Admins can suppress and delete historical changes to make sure they are removed from the record.
 * Statement: I need to be able to suppress any changes that are seriously offensive, copyrighted, or otherwise would cause harm to people.
 * Feature: Human-generated content in JADE is treated like any other MediaWiki content and can be suppressed accordingly.

Patrol for damage

 * Users: Editors, Admins
 * Description: People may use JADE to post petty vandalism that doesn't rise to the level of needing to be suppressed. Editors may want to investigate vandalism.
 * Statement: I need to be able to patrol JADE content for vandalism in order to remove it and maintain the integrity of the wiki.
 * Feature: Edits to JADE content appear in recent changes if the Judgment namespace is enabled. This allows integration with other patrolling tools that rely on the recent changes feed.

Revert damage

 * Users: Editors, Admins
 * Description: If petty vandalism is spotted on a JADE page, it should be reverted.
 * Statement: I need to be able to revert vandalism that is posted on a wiki page in order to preserve the integrity of the wiki.
 * Feature: The usual edit, rollback, and undo functionalities in MediaWiki can be used on JADE pages to undo vandalism.

Track user contributions

 * Users: Editors, Patrollers, Admins
 * Description: Looking through a user's contributions is an important way of self-policing in Wikipedia. It also is a great way for users to remember what they have been working on recently.  Collecting activities that a user performed is essential for maintaining and querying a user's reputation.
 * Statement: I want to be able to see what a user is up to. If they are going particularly great work, I might send them a barnstar.  If they are consistently behaving badly, I might warn them or block them.  I'd also like to review all of their activities to make sure I clean up the damage they have caused.
 * Feature:Edits to Judgment pages show up in recent changes, watchlists, etc. Since judgment pages are in their own namespace, it is possible to easily filter them.