JADE/Use cases

User/roles

End users

Editors

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.

Patrollers

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.

Admins

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 wiki's history. They are often involved in the resolution of harassment issues (e.g. en:DOXing) and copyright issues.

Dev users

Tool developers

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.

Wikimedia Product teams

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.

Data consumers

Researchers

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.

Model builders

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.

Use cases

Label entity

Users: All end 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.

Signal consensus

Users: All end users
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.

Disagree with current consensus

Users: All end users
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.

Describe endorsement

Users: All end users
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: All end users
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 labels for entity

Users: All users
Description: Given an entity, are there any judgments? Is there consensus?
Statement: I'd like to know if an entity has been labeled. What are the consensus labels? Are there alternative labels with substantial support?
Feature: There will be an API that provides judgment data for entities entitydata={"type": "diff", "id": 123456} and will allow filtering based on "facet" and whether or not any proposals beyond the featured proposal are needed. Clients can also fall back on the vanilla MediaWiki API and look up judgments using the page title structure "Jade:{Page|Revision|Diff}/{page_id|rev_id}" and processing the whole document.

Assess label 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 label, 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: All dev users
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 using a simple interface. 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 single endpoint that attempts to do the right thing regardless of the current state of a Jade entity page. This endpoint will throw warnings in cases where followup action might be appropriate.

Suppress changes

Users: Admins
Description: If you give people the space for it, they will harass and DOX each other. So Admins need to be able to 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 Jade namespace is enabled. This allows integration with other patrolling tools that rely on the recent changes feed.

Revert damage

Users: All end users
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 Jade activity

Users: All end users
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 Jade pages show up in recent changes, watchlists, and user contributions, etc. Jade pages appear in their own namespace, so it is possible to easily filter them.

Search Jade labels

Users: All end users and data consumers
Description: When auditing ORES models, it would be helpful to search Jade entities by labeldata and proposal notes (hashtags and/or wikilinks).
Statement: I want to be able to find goodfaith, damaging edits quickly and easily. I'd also like to be able to narrow my search to proposals with notes referring to a specific policy (e.g., "WP:OWN").
Feature: Flags from the most recent version of a Jade entity are indexed inside Elastic search. E.g. "jadedatadamaging:true jadedatagoodfaith:true linksto:'Wikipedia:Ownership'"

Use Jade data to filter changes

User: Patrollers
Description: Jade data is useful as a filter. Patrollers will want to make sure they don't duplicate work by reviewing edits that have already been review. We can use Jade to track which edits have been reviewed and allow patrollers to filter based on a review.
Statement: When patrolling edits, I want to know what edits have already been reviewed so that I can filter them out of Special:Recentchanges or Huggle. I also want to check that other patrollers are doing a good job, so I might review edits that are labeled as damaging or badfaith to make sure I agree with their assessment.
Feature: Special:Recentchanges and Special:Watchlist will include filters for edits with a Jade "editquality" label and for filtering based on specific data behind that label. E.g. damaging:true, goodfaith:true.