## Answers to a few questions per email

1

Got a request to answer the following questions from @Harej (WMF):

• Regarding the wiki(s) you edit, how familiar are you with how anti-vandalism patrollers coordinate their activity? Might there be interest in a system for better coordination? I don't think that vandal patrol is coordinated, really. Only thing is that regular users report vandals that don't respond to warnings to administrators and these block/protect/delete as appropriate.
• How concerned are you, personally, about the potential for AI to become biased and perpetuate bias on the Wikimedia projects? Would you be interested in helping us identify patterns of bias or inaccuracy in ORES? I'd be a bit wary of homophobia mainly, as "gay" is a common vandal term.
• Do you know who else I should talk to? I'd be tempted to suggest User talk:Iridescent; they often have insightful stances on such projects.

## Wiki entity types: Splitting revision into "edit" and "version"

3

Where we decide to use "page", "revision", and "diff" as the target wiki entities for judgment.

Hey folks. In order to attach judgments to wiki things, we needed to formalize the concept of "wiki thing". Originally, we came up with the name "wiki artifact" but it turns out that the EventBus people already came across this problem and decided to call them "wiki entities". So in the spirit of conformity, I think we should use "entity" and "wiki entity" from here forward.

OK onto types. Right now, the first thing we want to target is a revision. In the future, we'll likely want to target users, pages, and other wiki entity types.

I've recently realized that "revision" is ambiguous with regards to judgement. We've been using the term to refer to two types of things. In the case of ORES' article quality models, "revision" refers to a specific version of a page while for the edit quality models, "revision" actually refers to a diff (or more specifically an edit action). An edit has different metadata than a version of a page. E.g. an edit has a parent revision and that contains a lot of essential meaning.

So, I've been thinking that we should split "revision" into "version" and "edit" to remove the ambiguity. This is really cool because interfaces that are trying to automatically discover what to render next to a judgement will know that a "edit" judgement should be shown next to a diff and a "version" judgement should be shown next to a full rendering of a page.

These things are encoded into m:Wiki labels as "views". E.g. "PageAsOfRevision" and "DiffToPrevious".

I like "edit".

There's something fishy about "version". I'd like it to be more obvious, like "article snapshot".

+1 "wiki entity", but only because it already exists :-)

hmm maybe re "version" we can stick with "revision" since it's common language in MediaWiki.

## Thematic and quant analysis of judgements

4

Judgments and comments should be available for analysis from Quarry, and joinable against wiki entities. Comments should be full-text searchable.

A common pattern when discussing ORES mistakes is to do a en:Grounded theory analysis (as seen here: it:Progetto:Patrolling/ORES) where misclassifications are grouped by what was going in the edit. This is a really cool and useful bit of work because it helps me understand the trends in a machine learning model's mistakes and work to address them.

I'd like to see JADE support this pattern. Obviously, people should be able to link to judgments on Wiki pages. But I think we can get more out of having judgments query-able via m:Quarry and other types of public analytics systems. So we should be able to use our event-based system to route judgement data to LabsDB (probably soon to be renamed to CloudDB or maybe ForgeDB) so that people can query it via Quarry's online interface.

I'd like to run queries like: "Give me all of ORES false positives for 'damaging' where the editor is anonymous and the page was longer than 30KB before they saved their edit." This would involve joining judgments with MediaWiki's internal databases.

Yes! I think you solved this with EventBus, where we provide a Kafka consumer that ingests messages into a MediaWiki database.

This would mirror only the public data. For the type of analysis you're describing we probably want the full history of judgments, minus redactions. Seems like the discussion threads should be included as well, which is a scary challenge to our plan to offload this complexity. Maybe the MVP will just have aggregate discussion stats like number of posts, number of participants, and a link to the Flow thread?

Seems like we should store these basic stats in a table in MediaWiki so that people can query it, flow, etc. via quarry.

Something that came up in IRC: Our current design materializes JADE data in MediaWiki MariaDB as JSON blobs under the JADE namespace. This is pretty unusable from Quarry, to my knowledge.

Reply to "Thematic and quant analysis of judgements"

## Judgments, Endorsements, and Preference

4

I've been reviewing some of the pages of ORES' mistakes (e.g. it:Progetto:Patrolling/ORES and some of our review of anomalies in training data (e.g. Phab:T171497). I think we'll need a nice pattern by which multiple judgments can be submitted about a single wiki entity (revision, page, user, etc.), a conversation can take place and consensus recorded. In order to manage all of this in the JADE/Schema, we've split up the notion of a "judgement" from an "endorsement" and we've borrowed the concept of "preference" from Wikidata.

Let me illustrate with an example. Let's say that I want to judge the quality of en:Special:Diff/327645238. I'd create a new "judgement" with damaging=true and file an "endorsement" of the judgement with my comment "Removing cleanup tags without fixing the problems." Because (in this example) I was the first person to submit a judgement/endorsement, that judgement would be marked "preferred".

At a later date, Awight is reviewing some anomalies in our training set and comes across this judgement. He reviews the diff and comes to a different conclusion. So he creates a new "judgement" damaging=false and files an "endorsement" of that judgement with the comment "Good removal of cleanup tags". He's feeling pretty confident, so he moves the "preference" to his non-damaging judgement and starts a new discussion thread tied to this wiki entity titled "Cleanup was performed in past edits" where he points out that the cleanup had already occurred before the edit in question.

I get a notification that an entity I judged has a new discussion thread. After reviewing the edit again and seeing Awight's reasoning, I still disagree, but I don't feel strongly enough to dispute the new preferred judgement. I could change my endorsement and edit my comment to reflect Awight's, but I don't want to. So I leave my endorsement on damaging=true and leave the "preference" alone (so it's still pointing to damaging=false)

Does this make sense? Should it be possible to have two different "preferred" judgments or should we limit it to just one that captures consensus? Does it make sense to allow individuals to keep their endorsements where they like and set the preference bit separately? What do you think?

I'd like to see the judgment and comment more tightly coupled, for a few reasons:

• It's meaningful to distinguish between a comment left during judgment, a comment added later, and a comment left during judgment but edited later.
• We should be encouraging tool authors to always provide the free-form input field during judgment, because we think it's a best practice and results in more thoughtful and higher-quality labeling. The easiest way to do this is to make it a field on "create judgment".
• What is an endorsement without a judgment, if not a discussion thread? I'm interested in keeping discussion threads out of our model and keeping that in pure Flow-land.

Good question about multiple preferred rankings. I would follow Wikidata's lead, but their documentation is deliciously ambiguous about this. Looking at how their data is used in practice, https://en.wikipedia.org/wiki/Template:Wikidata#Configuration_flags, I'd guess most tools will query our data using an equivalent of "rank=best". If a preferred judgment exists, only return that. If several rank=normal judgments are present, return them all... What if we leave it to consensus to set zero, one, or multiple preferred judgments? We're already in a plural paradigm in which we're going to return a machine judgment along with a human judgment, might as well allow multiple human judgments e.g. in the case of "zero preferred judgments but multiple unranked human judgments".

"What is an endorsement without a judgment" such a thing should be impossible. I agree that discussions should stay in flow land. A comment with an endorsement serves another purpose. It supports an endorsement. It's a special kind of statement. In Wikipedia, !votes take the form where endorsements have comments that directly support the endorsement, but comments are made orthogonality. Given, discussion threads will spawn from Endorsements, but I believe this is an anti-pattern since these discussions get messy quickly and much work is done to re-summarize and recover.

In other venues, we decided to drop endorsements for now. Instead, free-form discussion can happen on the talk page. Disagreements about judgments can also follow the bold-revert-delete workflow, where the judgment is simply replaced by a new, proposed judgment.

Reply to "Judgments, Endorsements, and Preference"

## Free text comments and suppression

31
Summary by EpochFail

There's one thing that's very clear from reading through ORES' mistake reports online: People want to include freetext comments with their judgements.

However, there's a problem where any time you open up a new freetext field on the internet, someone's going to use it to Dox someone else or otherwise cause harm. So we're going to need some mechanism for curation and suppression. There are two options we're kicking around.

### First class suppression support

Text fields would be stored within JADE and a full suite of suppression tools would be made available. Integrations with MediaWiki would allow patrollers to see JADE comments appear in the RecentChanges feed on their local wiki.

Upside
Text is part of the system and any analysis users will want to do.
Downside
Way more work to implement and easy to get wrong.

### Outsource to Flow

Flow already integrates with MediaWiki's RecentChanges feed and has the capacity for suppression events. If we store freetext comments in a Flow post, then we don't need to re-implement the same suppression mechanisms that Flow already has.

Upside
Much easier to implement
Downside
Analyses will need to join to flow tables (??) to search text comments. A flow post is also a little overboard for our goals.

I was just re-reading Risker's checklist. If we want first class suppression support, it looks like we'll want to have some direct MediaWiki integration so that judgements/endorsements show up in RecentChanges for the relevant wiki.

We should be able to also accept suppression actions from within that wiki. E.g. a user clicks on "delete" or "suppress" and the JADE API is hit with a request, the user's credentials/rights are checked, and if the check passes, JADE's API responds positively and the integrated MediaWiki UI signals success. None of this sounds too crazy to me.

Implementing a first-class suppression system is a huge undertaking. I'd like to see how many times this has been done successfully. As far as I understand, this means that our JADE text will have to be a first-class wiki entity. Being text, there are already two ways to store the data that will enable existing suppression mechanisms: article or structured discussion post. I think that our only realistic options are:

• Store the comments as one of these two types of entity, and allow JADE users to access as that native entity type publicly, i.e. edit using VisualEditor and linking to the "page" logs.
• Store as an existing entity, but hide the fact that we've done this and only allow access through JADE APIs. Admins would be able to access as the native MediaWiki entity type.

The first option makes more sense to me. Either way, we do provide a thin layer on top of the native entities, to implement our basic API actions. If we go the latter route, I expect we'll eventually end up having to implement the entire suite of MediaWiki actions in JADE.

I agree about the requirement to make the text available for analysis. Maybe our schema includes both an URL to the native entity (e.g. Flow topic or post), and a primary key into the table used to store the text.

I don't think an page or a discussion post make sense as a comment/summary. I don't see the difficulties involved in implementing a curation/suppression system if we can leverage recentchanges (and why not). Further there are other things to suppress -- not just comments (like usernames and a judgement content).

It seems to me that, given risker's recommendations, we can integrate with recentchanges be mostly done.

P.S., the question about Search for flow was in the "Flow integration" thread.

A text content system is big and heavily interconnected wheel that should not be reinvented. Discussion and similar content should be on wikipages any time it's possible.

It's not just recent changes. Will everything show up in user contribution history? Will a blocked user be able to take any actions / submit any content? Are you building a history for it? Non-public logs and tables for CheckUser and suppression? Will it run through abuse filter? Is anything going to fail or blow up if a username has to be suppressed or a user account is renamed, or whatever other corner cases exist?

I worry that the "variant" you are proposing is not all that far off from what we saw on other alternative editing systems. These were extremely problematic, in that they didn't show up in most of the logs, it wasn't real suppression but a jury-rigged system that inaccurately mimicked it. And perhaps most importantly, the volume of work was overwhelming to oversighters. Keep in mind that enwiki has roughly 8-10x the number of oversighters of any other project (including many of the largest ones), and we have enough work right now, with about 350-500 suppressions a month. In the past, some extensions (since disabled) were running us up over 1000 suppressions a month, mostly because nobody really understood the potential for inappropriate comments. It wasn't that long ago that we had to have a whole extension/namespace shut down because it was just a nightmare waiting to happen. People who've been suppressing material for a couple of years can tell you horror stories about the imaginative ways that people can manage to include inappropriate/private/potentially libelous/truly scary material when given the chance. (Example: credible bomb threat against a head of state visiting Canada - I had a lovely chat with the RCMP about that...) Sure, JADE should only be used by experienced users - but it may be difficult to prevent others from using it, including those with malicious intent. (And you'd be surprised at how often we wind up suppressing "accidental" edits by longtime users.) So I keep going back to...will it show up in the user's contribs, will it be showing up in recent changes, will it show up in the Checkuser tables, will the normal suppression tools work on it, will they show up in the suppression logs, etc. If it is easily accessible and uses the standard interface, we can probably live with it. Outside of that...things get complicated. Incidentally, suppressing on Flow is an absolute nightmare.

will it show up in the user's contribs, will it be showing up in recent changes, will it show up in the Checkuser tables, will the normal suppression tools work on it, will they show up in the suppression logs, etc.

Yes. That is part of the plan.

Ping JMatazzoni_ re. Flow's suppression nightmare. I don't think I understand what's bad about Flow's suppression system. Did they not do what you perscribed in the quoted block above?

Why Flow? Most editors hate it. It's been uninstalled from EnWiki, uninstalled from Meta, and Commons currently has RFC with most editors wanting it uninstalled. The WMF ran a global survey which was canvassed/votestacked with as many Flow-enthusiasts as possible and it still came out heavily against Flow.

Hi @Alsee, I'm reading through some of the debates you mention here. I found the survey, https://meta.wikimedia.org/wiki/Collaboration/Flow_satisfaction_survey/Report, but cannot find a related Commons RFC at https://commons.wikimedia.org/wiki/Commons:Requests_for_comment nor https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2015/08#Flow. Can you post a link?

We're open to looking at alternatives to Flow. Our technical requirements are simple, that the platform we choose will allow for discussion and curation, that we can link to a discussion thread via URL, and that a discussion thread can include an URL linking to the JADE judgments about the wiki entity being discussed. And we're not going to implement a new structured discussion platform.

Ping JMatazzoni re. Flow's suppression nightmare. I don't think I understand what's bad about Flow's suppression system. Did they not do what you perscribed in the quoted block above?

We are scheduled to make improvements on the Structured Discussion (formerly Flow) moderation system this year. I'm going to ping @Mattflaschen-WMF, who understands these issues much more fully than I. Matt, can you comment on the state of the SD suppression system?

I know some of the things that are lacking in SD's suppression system, but I'd be interested to hear why @Risker says "suppressing in Flow is an absolute nightmare". Not because I disagree, but because she's an experienced oversighter and it's highly likely I'd learn something from it.

There are (different) limitations in both the standard deletion/suppression system and in SD's. Some of the SD limitations are major. Note, the following three links are all security bugs. Adam, Aaron, Risker, I have added you. However, please do not discuss them in public channels. https://phabricator.wikimedia.org/T103616 , https://phabricator.wikimedia.org/T94779 , https://phabricator.wikimedia.org/T116301 .

However, SD mostly solves all of the items Risker mentioned:

• "will it show up in the user's contribs" - Yes (Special:Contributions), though not in the API yet (T88753)
• "will it be showing up in recent changes" - Yes, though again not in the API (T88753)
• "will it show up in the Checkuser tables" - Yes, SD has CheckUser support.
• "will the normal suppression tools work on it" - There is deletion and suppression support, though it doesn't have full feature-parity.
• "will they show up in the suppression logs" - Yes

Thanks @Mattflaschen-WMF, this is a sobering look at how complex it is to support suppression. It also led me to Manual:RevisionDelete, which is clear and will help us.

It's a bit off-topic, but the RevisionDelete page reveals one more place where we should be coercing our data structures to map 1:1 to wiki concepts. We're already mapping judgment->page content, and judgment author->editor username/IP address, but we could also map freeform justification->edit summary. Edit summaries will finally be freed from the 255-char limitation as part of multi-content revision work (https://phabricator.wikimedia.org/T6715), so technically such a mapping would work just fine for us.

@Halfak (WMF) this also makes me wonder how well MCR will be integrated with suppression, or whether we'll be confronted with edge cases for the next few years... We should probably do the drudge work of defining all of the suppression scenarios in Cucumber or something, to make it easier for editors to review in the pre-implementation phase.

Does it make sense to edit a free-form justification (e.g. to clarify it, or even change the justification in a meaningful way)? If so, edit summaries might not be a good fit (summaries are not editable).

Or would that always be considered an entirely new judgement?

Oh, of course... Thanks for noticing. Edit summaries should be editable :-)

Also, we'll want to have VE for justifications, and render any wiki markup.

IMO, I do think it would be great if edit summaries are editable, but I don't think that's a blocker for us. It'll certainly be familiar to Wikipedians to have non-editable summaries. If further justification is necessary, one could employ talk pages or structured discussion (flow).

Some months ago there was a discussion somewhere (I don't recall where), where someone suggested/requested making edit-summaries editable. My recollection of the prevailing view was that it was undesirable due to messy extra layer of meta-history it would entail.

After doing a bit of research and talking to the folks on the MW Platform Team, I think it makes the most sense to try to map JADE's structure of Judgements into page content and build a content handler for it.

This diagram is a little bit backwards. After reviewing false positive reports and considering consensus discussion patterns, I settled on shape C as a good way to represent "current good" as well as "disagreement". A is how I see the shape of page/revisions. B is me trying to cram JADE into the page/revision shape.

There are a few patterns from C that would need to be abstracted on top of page histories. E.g. changing the "preference" in shape C would be a revert in shape B. Signalling support for a judgement is possible in shape C but not in shape B. Rather, signalling support would need to be done in an unstructured way.

By seeking to formalize this via a page/revision structure, we also address a bit of the problem with *choosing* Flow vs. talk pages ahead of time. If we were to use the page/revision structure, we could set up a namespace for JADE and have the judgement for a entity_type/identifier exist as a content page. Either a talk page or a Flow board could be behind that content page. From JADE's point of view, I'm not sure it matters.

I think this is a good option. If you're just creating talk pages (old-style talk pages or StructuredDiscussion talk pages) in e.g. a Judgement_talk namespace, you have flexibility (you don't even need all talk pages in the namespace to be the same kind), and will benefit from existing work.

For the record, I do not agree with "I don't see the difficulties involved in implementing a curation/suppression system if we can leverage recentchanges (and why not)." I could go into more detail why, but it seems we're already on the same page.

I have a two-part proposal for just the free-form text aspect of our MediaWiki integration:

• We store judgment comments (justifications) as the edit summary on the revision where the judgment is added.
• We store discussion as a single URL pointing to any type of talk thread, be it Wikitext or Structured Discussion.

@Adamw If there is an entirely separate talk page (e.g. Judgement_talk:123) for every judgement, this might not be an issue.

However, I wanted to note that for long-running old-style talk pages (e.g. Village_pump_(technical)), there is no way to permalink to an active thread. If you just link to a section, it will be archived away (e.g. to Wikipedia:Village_pump_(technical)/Archive_161). If you link to an oldid, you are not linking to the active version of a thread. You can only link to it reliably after it has been archived.

If the talk page is short, and will never be archived, this is not an issue.

SD solves this issue through the Topic namespace.

My first point about using the edit summary is a bad idea, thanks for the feedback in the earlier thread.

Our working theory is that JADE discussions are not 1:1 with specific judgments, but are 1:1 with the wiki entity being discussed. Since a topic on the entity's talk page would be the most natural place to have such a discussion, I think your critique is correct, and the lack of permalinks might be fatal to using wikitext and the Talk namespace for discussions.

However, I've been thinking that we need a reverse link from the discussion pointing to the JADE context. It's wacky, but do you think we could use the "what links here" table to maintain a map from JADE-subject wiki entity to the discussions about judging it?

To answer the WhatLinksHere question, I think I need to understand the proposed setup better (e.g. to know if we're talking about cross-wiki). If it's within a single wiki, and judgements are stored in a restricted Judgement namespace (meaning there is no free-form text), it could work.

Are you envisioning something like (I'm assuming for all, the discussion would just be on the talk page of the mentioned page):

1. Entity:Page:Earth on the regular wiki, e.g. en.wikipedia.org. And Entity:Revision:1234 ?
2. Entity:Page:Earth on a special jade.wikimedia.org wiki
3. Earth (the actual Earth article) on en.wikipedia.org, with the JADE discussion(s) on Talk:Earth with everything else. If so, what are you doing about revision entities?
4. Something totally different

If I understand right, there would be one discussion page (e.g. Entity_talk:Page:Earth) for each entity, but there could be multiple topics within the page. Each judgement/justification could have its own topic then.

If more then one judgement shares the same topic, the reverse link(s) would have to go to multiple judgements.

If you're worried about people losing the context, another option is to embed the UI into JADE, so (regardless of where the discussion is technically stored), you see (and can even reply to) the discussion on the same UI page as the judgement. SD has robust APIs, so this is doable.

Sorry that this is such a moving target! My current thoughts are,

• Main:Earth on en.wikipedia.org is the article being judged.
• Jade:Earth on en.wikipedia.org is the structured judgment, which has some kind of restrictions on editing, at least that you can't save if you broke the schema, and is normally edited via the JADE API and always through our custom ContentHandler.

I think that solves the context questions, since we can rely on the ordinary talk page relationship, and the Jade: namespace correlates to the Main: namespace in a similar way.

One minor note. We'll probably need to name that page something like: Jade:Page/Earth. Or better yet, Jade:Wikidata item/Q2 since judgments at the page level address the "concept" more than the content. Regardless, we'll need to save space for something like Jade:Revision/1234567 and Jade:Diff/1234567.

Oops, that's a major oversight on my part! I think your suggestion of Jade:(Revision|Diff)/1234567 is the sanest way to go.

If we decide to get fancy, Jade:Page/Earth could use the JADE API to generate an index of all judgments on Earth revisions, but then we're straying into UI territory, which we probably don't want to do. Unless you had something else in mind for what this URL would contain?

Jade:Page/Earth would be great for labeling the concept space of "Earth". E.g. geography, astronomy, etc. We do this for the draft topic model. We could apply it to the first revision of the article, but it really represent the concept as a whole.

I like it! It does feel a bit asymmetrical to use page name rather than ID, since the revision and diff paths will be canonical by ID, but better for humans. If MediaWiki allows it, maybe we can think about providing a few aliases to be more friendly, e.g. Jade:Revision/Earth/1234567. I keep wanting to put the article name first, i.e. "Jade:Earth/Revision/123456", but that falls apart if Earth happens to have a subpage "Revision"...

## Judgment Bold-Revert-Discuss vs. optional consensus

6

@Halfak (WMF) and I identified a design assumption in IRC last week, which has been implicit in a few of the other threads here, especially in "Judgments, Endorsements, and Preference" below, but is worth surfacing as its own issue. I'd like to open this for more comments.

In the current design of JADE, there can only be one "correct" judgment per wiki entity. Most entities will simply have one editor making one judgment, but in the cases that multiple editors supply a judgment, the second, third, etc. editors will be overwriting each other's judgments as the "correct" answer. This follows the BOLD,_revert,_discuss_cycle on English Wikipedia. @Halfak (WMF) has pointed out that this is the best process for the problem domain, that we want to encourage consensus.

An alternative workflow would be something like the Wikidata model, in which multiple judgments on a wiki entity default to having equal "rank", and it would be optional to go through a consensus process. Any editor could mark one or more of the judgments as "preferred", with or without discussion, or the editors could leave all judgments as "normal" rank and we would consider the set of judgments to be unresolved and equally valid.

I think there are two questions here: what is the preferable workflow for the various use cases in which editors add JADE judgments, and what are the best requirements on the data in order to support algorithms and reasoning using the judgments?

I think this discussion of the "Wikidata" model misses that it has BRD as well. In this case, "rank" is part of the data model itself. There's still one true representation that is identified via a consensus process. But with "rank" a more accurate reflection of a messy reality is represented in the data model itself. If we wanted to represent messiness like this, it might be better captured in JADE's schema itself -- depending on the type of judgement.

E.g. if a user decides that one judgement should be ranked "preferred" while another should be ranked "normal", they are essentially marking one as best and another as "safe to ignore". You might show up and disagree with how they have ranked and revert them. Preferably, you'd then discuss your differences in ranking.

I think when it comes down to it, I want to know why having ranks makes any sense. What information does it capture that we need to capture here? In what case, do we want one judgement to be "preferred" when another is simply "normal"?

BTW, I'm Halfak (WMF) accidentally made this edit through my volunteer account.

Is there a compelling user story that would have a ranking/preference system? How likely is this to be encountered in the wild?

I think the simple BRD approach is fine, with the one "true" judgement that can be revised further by others. If I could think of an imperfect analogy, it'd be kind of like File History on Commons. The latest upload is always displayed as the canon version, but previous revisions are still visible/available. Does that make sense?

Good Q. Here's the thread where I originally brought up the proposal for "preference": Tzw0uv2bucrdprm4 It discusses a use-case.

I think that generally, we should allow people to disagree with consensus -- much like what happens in a straw poll.

I can buy this argument. I was thinking it would be more simple to a user to "make a judgment, ignore what else is there as you wish" rather than "make a judgment, yours will be the new authoritative judgment and will overrule the others". But I know I haven't had my fill of wiki Kool-Aid yet ;-)

In that case, I still think limiting it to one preferred judgement is what we'd want to go for. People are welcome to discuss it, but splitting it off into rankings and separate judgements seems unnecessary IMHO.

Reply to "Judgment Bold-Revert-Discuss vs. optional consensus"

## language specificity

4

ORES needs to support more languages.  +1 for Swahili support.

My experience with ORES was not encouraging. I had applied for ORES to be initiated on sw:wp. At the preliminary step of creating a blacklist, the algorithm identified predominantly English words rather than unacceptable Swahili ones. And then, I had too many other (more?) worthwhile projects on my hands (and no other enthusiastic cooperators to go through stuff manually) ... Despite all the rhetoric about supporting small, local, indigenous, vernacular, minority, under-represented and/or endangered languages, internet technology is still largely anglocentric :(

Hi Baba Tabita. I'm sorry you seem to be having a bad time with ORES. I remember reaching out to you to ask for help with alternative means of getting blacklists for ORES to work with. We've had to do that for a few languages. As far as I know, we've been waiting on that. FWIW, our BWDS system picked up English Words for Swahili because much of the damaging edits in Swahili wiki add English language content. So that's not really a bug but rather a limitation in our process for auto-detecting badwords using wiki edits. It does however tell us that an English language dictionary would be useful for damage detection in Swahili wiki.

Regardless, I'm not sure that you could accuse of not matching our rhetoric to work with anyone who will work with us. I believe we have been quick to respond to your questions and to make suggestions about next steps. Also, FWIW, we're not focused on small, local languages. We're focused on supporting growing communities -- small language or not! See m:Community Engagement/Defining Emerging Communities.

In the end, there's only two of us who are staffing the team that does something Wikimedia has never done before so I hope you'll understand that we need your help in order to support your wiki. I have lots of other wikis and operational concerns to track and I put in a lot of volunteer time to make this experiment in community AI resources work at all.

Currently, we have support for 34 languages -- at least 11 of which are not heavily used in the en:western world -- so I think we're doing OK in most other instances.

And sorry if I came over as accusing or complaining, none of which was intended. I think you *are* doing a great job. It's just that circumstances are so much more favourable for European languages than, say, for African ones. I'm not a tech guy, so that adds to my frustration of not being able to do what I would like for Swahili localization in the little time available to me. Definitely not your fault! Still, just saying ...

Best wishes, and please keep up the good work!

Thanks Baba Tabita. Maybe I could look up some supposed bad word lists to help get us started. I'll ping on the ticket.

## Should we integrate JADE with Structured Discussions?

11

Judgments and discussions are rooted at wiki entities. We need more discussion before committing to using Structured Discussions, it's not the perfect fit. Having ORES and JADE entities available when reading or editing these threads would be great.

See Phab:T153147 for the relevant task.

Structured Discussion provides a well supported, wiki-integrated environment in which we can hold threaded discussions. In Judgments, Endorsements, and Preference, I described a JADE workflow that involved a "discussion post" between two users. I'm imagining that we can mint a Structured Discussion board as needed for discussions about judgments. These will help users use a central location to negotiate whether or not an edit was damaging or likely to have been saved in good-faith -- or if an article is C-class or B-class.

My two big questions are (1) can we mint a new Structured Discussion board for an arbitrary wiki entity and (2) will people find having a whole Structured Discussion board for discussing Judgments about a wiki entity intuitive?

Put me down as someone who doesn't find Flow intuitive or user friendly.

All lab studies we have run have suggested that people find Structured Discussion much more user friendly and intuitive than, for example, talk pages. The big benefits seem to be auto-threading, "reply" buttons that work, and not needing to manage signatures.

I can certainly see how Structured Discussion doesn't have explicit functionality for many talk page hacks we've gotten used to, but in this case, I think we are actually targeting threaded discussion -- something that Structured Discussion does very well.

My experience was that it was hard to search a Flow talk page, has that changed?

@Ebernhardson brought up one consideration, that we need to attach the Flow board to an existing wiki page. Since Flow is only enabled on some wikis, it's probably impossible to have this page be on the wiki where the artifact lives. We would have to make a strange structure like, "mediawiki.org/wiki/Talk:JADE/Judgments/enwiki/", and maybe even have another directory level to group into hundreds of posts or so.

I'm not sure I understand the groupings, but I think that having all JADE discussions focused on a single wiki could work just fine. In the end, I imagine, we'll have topic Ids/URLs that people can be directed to through any UI that shows JADE stuff.

One more thing I was thinking... It would be really cool if our MediaWiki integration allowed judgement information to be rendered as part of a Flow topic/board page.

At the very least, it has to be possible to navigate from a topic to the judgment.

Maybe, when a topic is first created, it contains an introductory template like "{{JADE/Judgment | jid = 123}}" which keeps the glue on-wiki and makes it easy to refine collaboratively. This could in turn be wrapped in a div, making it easy to find and hide when displaying the topic from places this info would be redundant, such as the JADE UI.

I'm suddenly doubtful about one of our assumptions: are discussion threads only useful on a judgment, or would we also want to attach to a score? Consensus discussion would make the most sense at the score- or wiki-entity-level, perhaps?

Scores change when we deploy new models. I feel like the proposals for attaching a judgement to a score do not account for this fact. E.g. false-positives turn to true-negatives as we refine a model. Further, we'll want judgments for scores that don't exist yet. So what would we do in that circumstance? I think it would make much more sense to attach judgements to wiki-entities and merely present the current score (if available) in the UI for reflection & discussion.

+1 let's do that.

So then, discussions always begin with a judgment comment, or can they begin at a wiki entity?

Wiki entity IMO. We should have a nice way to attach a historical score to a discussion. E.g. {{subst:ores|revision|2131211|damaging}}

## FYI: An implementation discussion

1
Reply to "FYI: An implementation discussion"

## Metrics for ORES usage

2

Request for more ORES metrics.

Do you have metrics for ORES usage, and specifically:

1. How many users or how often users enable RC filters of ORES compared to other RC Filters? (project level) [wondering does ORES play well in some projects and doesn't predict well in others?]
2. How many edits could be driven by ORES, how many skipped? (e.g for edits with high score for damaging ${\displaystyle |DAMAGING\cap ROLLBACK|}$ and ${\displaystyle |DAMAGING\cap \neg {ROLLBACK}|}$ )
3. Wouldn't it be better to evaluate ORES bad predictions based actions (such as high damaging not reverted) compared to more strict feedback. While somewhat more dirty to use it, it is and will always be much richer DB compared to judgments

Hey!

1. We don't develop RC filters. That's the Collaboration team folks. They probably do have stats. Ping Roan Kattouw.
2. For this, I would use our test statistics. E.g. https://ores.wikimedia.org/v2/scores/enwiki/damaging?model_info=test_stats shows that you could auto-revert 8% of damaging edits if you're OK with 99% precision.
3. In some ways yes, but in a lot of ways, no. The biggest problem with doing that is that we don't know how often ORES was right to *not* flag something since people won't be directly reviewing those things. The second problem is that revert != damage != vandalism, so the action is often ambiguous. The third problem is that ORES affects your judgement. Just by having something flagged as "likely to be bad", your view of it changes. This is well documented in the research lit. So I think it is best to evaluate ORES by specific judgements (is this edit damaging? Is it intentionally damaging?) over a random sample of edits. That's what the test statistics linked above report.
Reply to "Metrics for ORES usage"