Talk:ORES review tool

Hey folks,

Recently, I've been working with the mw:Collaboration/Team at the Wikimedia Foundation. They are working on improving reviewing interfaces in Wikipedia. ORES and the ORES review tool are obvious allies in this work. :)

Anyway, as a first step, they are designing and engineering an improved filtering interface for Special:RecentChanges. I'd like to invite them to incorporate this new review interface into the ORES review tool directly. That means all who have this the ORES beta feature enabled will suddenly get a new filtering interface once they are ready to deploy it (still TBD at this point). As this tool focuses on improving RecentChanges in ways that the ORES review tool does and beyond, you might think of merging these projects for some future deployment as the next major iteration on the ORES review tool.

While a change to RecentChanges filters might be a bit jarring to you, I think that integrating their work into ours as soon as possible is a good idea. My team (m:R:Revision scoring as a service) doesn't have that many resources to devote to the ongoing development and maintenance of the ORES review tool, while the Collaboration Team has designers and professional engineers working on this problem. By integrating with their work and handing off new development to them, we can spend more time focusing on making ORES predictions as good as they can be.

So, what do you think? Any concerns we should discuss? Regardless, there'll be announcements before we make any major changes.

Here's a working prototype of the new interface. Give it a try if you'd like to get a hands-on feel for the new filtering tools.

Remember, this is only a mockup. The search results are all canned, and filtering properties were applied to them semi-randomly. So this won't let you test whether the search technology is working properly.

It will, however, give you a good sense of the new look and feel. Presentation of the ORES-based filters (“Quality” and “User intent”) was a particular focus: they have to be understandable by a broad audience, but flexible enough to meet different types of reviewers' varied needs. What do you think?

Looks nice! Are the filters filtering in or out? Couldn't quite figure that bit. Thanks

Thanks @Iadmc. The new filters are all "include" instead of the old-style hide filters. Logically, the new arrangement is an "AND of ORs," meaning that within each filter grouping, the filters have an OR relationship, while different groupings are connected by ANDs—which should enable users to more accurately isolate the properties they're interested in.

We've been talking about how the Recent Changes filtering scheme demonstrated above will affect current ORES beta feature users. Here's what we're thinking: when this new filtering system rolls out as part of the beta, it will replace the current ORES display on the Recent Changes page. That means the automatic color coding, the red “r” symbol and the “hide probably good edits” filter will go away, to be replaced by the new, more nuanced set of filters and user-defined color coding.

All other pages that have ORES features, like Watchlist and Related Changes, will remain as they are now. We expect those pages could also benefit from the new filtering system. But at present we're thinking we'll wait to see how users (meaning you) react the beta test first—and make any necessary changes—before we start spreading the new UI around.

That's the plan as it currently stands. As always, please let us know if you have any thoughts.

its very useful

\o/ I'm very glad to hear that.

"If you reviewed an edit and realized it's not vandalism, you can simply mark it as patrolled and the highlighting and flag will be removed." – On enwiki individual edits are not patrolled, if that's what this is referring to. I am seeing a lot of false positives, not just constructive edits from new users but also those from trusted long-time users with additional user rights. I want to help by reviewing them but it's unclear how. Thanks!

I agree with MusikAnimal. There are too many legitimate edits being identified by the tool. Not really that useful at this stage in development.

Also you can change the ORES sensitivity to have less false positives. In your preferences

I added also this note to the main page. Worth repeating here: "Note that we deliberately set the default threshold so low to capture all vandalism cases so false positives are expected unlike anti-vandalism bot that set the threshold so high to capture only vandalism cases (and don't have false positives). If you don't want to see the flag for most edits, you can simply change ORES sensitivity (see below)."

OK, this thing looks interesting, but how can I mark edits as 'patrolled'?

Great question. In order to be patrol an edit you need to enable it in enwiki (like most of wikis). It just requires a RfC.

+1 MusikAnimal.

another example: if an edit has already been reverted then there's a good chance that no further review is needed. but there's no way to remove that "r" or give future patrollers a quick flag to indicate already done.

So, it's true there is no way to edit the 'needs review' status and I have been looking in vain?

The New Filters for Edit Review beta feature is already available on some wikis and is coming soon to remaining wikis. A previous post described some of the changes this will bring for ORES users. This note updates that announcement.   

Quite simply, ORES will be promoted to an on-by-default feature and New Filters for Edit Review will be taking it’s place in your beta preferences.

New Filters for Edit Review brings a lot of improvements, but it's still in development (beta), so we’ll be making adjustments and fixes for the next couple of months before turning our attention to new features again. To have the most impact, please have a look sooner rather than later at the new filters and let us know your ideas for improving them.

Here are the details about how this release will affect ORES users.

• ORES will be turned on by default: Once the New Filters for Edit Review beta is released for a given wiki, ORES will be turned on by default on that wiki (and the old ORES beta will disappear). That in itself  shouldn’t change much, and the new preferences,described below will help you manage any impacts.  
• On Recent Changes, the ‘New Filters for Edit Review’ beta replaces ORES shading for users who opt-in: As announced previously, user-defined highlighting and a suite of new ORES filters will replace automatic ORES shading on Recent Changes. To get these new features—along with a simpler and more powerful filtering interface and many other improvements—you must turn on the New Filters for Edit Review beta feature once it is released.  

• On Watchlist and Contributions, ORES shading will be a preference: ORES shading of probably damaging edits on Watchlist and Contributions will be controlled via a Watchlist preference, “Highlight likely problem edits with colors and an “r” for “needs review.” All current ORES beta users will be automatically opted in to this preference.  As the name suggests, this option also controls the little “r” signifying “needs review”  (which, at users’ request, will now be displayed in black instead of red).
• On Recent Changes, a new preference controls the “r”: New Filters for Edit Review arguably makes the “r” for “needs review” redundant on Recent Changes. However, this marker will still be available as a preference. It will be turned on by default for existing ORES users. To turn if off, uncheck the new preference, “Mark likely problem edits with an ‘r’ for ‘needs review.’"
• Newly standardized ORES levels:  ORES shading on Watchlist will shift somewhat to match newly standardized ORES filter levels. These have been optimized for usability and to account for differences among wikis in ORES performance. For example, ORES performs particularly well on Polish Wikipedia and Wikidata. For this reason, fewer colors of shading are required on these wikis. 

Hey folks, we've been working with JMatazzoni and the rest of the Collaboration Team throughout the development process of these new filters. I hope you'll give the new filters a careful test and consider adopting them. I think that we will all share in the benefits of having better reviewing tools and these efforts by the Collaboration Team are really pushing the state of the art.

If you find bugs or want to request different behavior, see Help talk:New filters for edit review.

This tool seems to have a bias against IP editors, and it often marks undamaging edits as damaging. Many vandalizing edits are also unmarked. Is anyone else seeing this problem?

Could you clarify in which wiki you tested? (ORES uses a different model for each wiki)

I'm using enwiki. It only seems to apply to IP addresses with the occasional registered user. However, I've been doing recent changes patrol for a few weeks and have only seen a handful of bluelinked users.

@He7d3r, it's on enwiki. It's mostly IPs and redlinked users. I've only seen a few actual devoted users and even then it's usually a mistake.

@Halfak: do you know anything about this?

Hey He7d3r and UNSC Luke 1021. We know that this is a problem. It turns out that newcomers and IPs are the only ones who regularly vandalize, so the prediction is strongly weighted in that way. We addressed a substantial part of the problem in some past work. See m:Research_talk:Automated_classification_of_edit_quality/Work_log/2016-04-14 and https://www.youtube.com/watch?v=rsFmqYxtt9w#t=28m10s for a relevant talk that I gave on the subject.

Essentially the status is this: We minimized the bias using a new modeling strategy, but really what we need to do now is find new sources of signal for the prediction. I have two promising new strategies that I'm working to get implemented (PCFGs and Feature hashing). We have some operational issues with getting those deployed.

If you can share some examples of false positives/negatives and what you think is unusual/unfair about them, I can look into those examples specifically to make sure its a known issue and not something weird.

Ok, I'll go through recent edits later and show you.

Send some examples

@Halfak (WMF): - I have an example: check diff (its the edit to the right that was marked as damaging)

It looks like this one right on the threshold of "damaging" but it does look like it will be reverted.

https://ores.wikimedia.org/v2/scores/enwiki/?revids=766011830&models=damaging%7Creverted

      "damaging": {
        "scores": {
          "766011830": {
            "prediction": false,
            "probability": {
              "false": 0.5047296304050086,
              "true": 0.4952703695949914
            }
          }
        }"
      },
      "reverted": {
        "scores": {
          "766011830": {
            "prediction": true,
            "probability": {
              "false": 0.2585393975879935,
              "true": 0.7414606024120065
            }
          }
        }
      }

OK. My hypothesis is that ORES is being weird about the excessively long comment. Let's experiement with changing that.

https://ores.wikimedia.org/v2/scores/enwiki/damaging/766011830?datasource.revision.comment=%22/*%20Crime%20*/%20Proper%20comma%20placing!%22

      "damaging": {
        "scores": {
          "766011830": {
            "prediction": false,
            "probability": {
              "false": 0.5047296304050086,
              "true": 0.4952703695949914
            }
          }
        }
      }

Hmm. That had no effect at all. OK let's check what would happen if this edit was saved by an editor who had registered a week ago.

https://ores.wikimedia.org/v2/scores/enwiki/damaging/766011830?feature.temporal.revision.user.seconds_since_registration=604800&feature.revision.user.is_anon=false

      "damaging": {
        "scores": {
          "766011830": {
            "prediction": false,
            "probability": {
              "false": 0.6003384342419845,
              "true": 0.3996615657580155
            }
          }
        }
      }

Yeah. That makes a big difference.

OK so here's what I think is going on. ORES' setting for catching most of the vandalism and other damage flags edits "for review" because it *might* be damaging. It's designed to help reviewer look at as little as possible for catching all of the damage. It seems that small edits (remove 2 ","s and add "as") performed by IP editors need review in order to make sure we catch all of the damage -- even though they often are just fine. I think this is what ORES is signalling and that it's not bad though it definitely could be better. In order to be able to differentiate good edits like this from bad, we need some natural language signal for the model. I'm hopeful our work with PCFGs will reduce the need to review these types of edits.

I know this doesn't really solve the problem for you now, but I hope it helps you understand why these false positives happen, and hopefully, it gave you a bit of insight into how ORES works and how you can experiment with its predictions. I often make use of this "feature injection" pattern to try to figure the "reason" behind the problematic judgements that ORES makes.

Aren't this tool doing the same thing the automated bots do?

If yes, then why is their target called vandalism while this one's not?

If no, what is the difference? The earlier explanation must then gloss over the issue, since it basically says it's just a difference of degree (accepting many vs few false positives) but still doing the same job. If this tool catches "damage" and the automated tools catch something else, they are not doing the same job, and the difference ought to be explained in more detail. ~~~~

This is a tool that helps people to review. "ORES review tool" tries to collect as much as vandalism as possible. On the other hand, an anti-vandalism bot tries to be as accurate as possible and a very tiny fraction of total vandalism.

CapnZapp, "vandalism" is just a subset of what we want to catch when we're doing RC Patrolling. "vandalism" implies bad-faith intent. We also want to catch good-faith mistakes. In this vein, we decided to build a model for detecting "damage" generally. We also have a model that focuses on the good-faith/bad-faith distinction. It'll be easier to take advantage of that when we deploy the next major change to filtering on the RC page for the review tool. See the Including new filter interface in ORES review tool topic.

Thank you. Please add that explanation. ~~~~

Does this edit help?

Like the tool. But I am , seeing about a third of the revisions flagged in my recent changes as good faith, and for the most part good, changes to the articles from IPs. Is there any chance we could do two things:

First, since the work is not garunteed bad, but very likely to be damaging: can we please include the confidence in the edit as damaging -- as someone who would like to help refine the model, it would be rewarding to be able to give feedback on individual instances when I feel like the machine is very, very far off in prediction.

Secondly, the red in my watchlist screams "red alert!" big problem! Lots of likilhood of it being terrible" Wheras my experience so far has been more in a warmer colour (orange, or something), where the change is of need for attention but not screaming at me.

This is a solid feature request. It's something we have thought about a lot, but we didn't have a phab task for it, so I made one. See Phab:T144922.

The biggest reason we don't have this yet is that working within MediaWiki is really tricky. The ORES extension is largely based off of ScoredRevisions, which does implement this confidence-based coloring and tooltips. The gadget can much more easily modify the visual representation of the RC Feed without worrying about the underlying complexity. We have different constraints with the extension.

Brilliant! And thank you for the context!ft Nd that

User:I wanted to help not hurt since 2011 I just created this account 2016, thanks for your feedback. We definitely don't intend for ORES to be flagging these edits. In all honesty, ORES doesn't have a good grasp on neutrality yet. But it would be good to have some examples of the kind of edits you are talking about for our tests. Could you give a few examples?

@I wanted to help not hurt since 2011 I just created this account 2016

-Super Personal Backstory...Check

-Something about not doing anything this year, but in previous..Check

I just don't understand the point behind this, EpochFail never said anything to trigger this...so this happened.

It's merged and deployed to the second group of wikis (All websites except Wikipedia). So you can see the result in Wikidata. (You need to enable ORES as a beta feature). It'll go to English Wikipedia tomorrow.

Sadads see ^. Thanks for your post about this issue.

@EpochFail & @Ladsgroup Thats brilliant! Thanks for the ping! That colour is much healthier (waiting for the enwiki deploy :D)

This is very useful for finding vandalism in recent changes and my watchlist (English Wikipedia) as edits likely to be problematic jump out at you in red... My issue is that the bar is perhaps a bit too low: half the screen is red sometimes and when I check an entry it is often simply an IP copy-editing or a new account (like mine) correctly adding info to an article.

First, am I right in assuming that the tool highlights mostly edits by IPs and new accounts?

Second, if so, is this because they are IPs/new? Or is it because those edits are more often actually problematic?

Third, I still haven't had my edits reviewed. I asked a couple of admins to do it but am still waiting for them to get back to me. I'll report back once they do get back.

Thanks and keep up the good work.

A series of changes to help out this issue got merged and deployed to the second group of wikis (All websites except Wikipedia). So you can see the result in Wikidata. (You need to enable ORES as a beta feature). It'll go to English Wikipedia tomorrow. Please give us feedback about it once it's deployed :) Thank you for using this tool.

Thanks. Will do

Could we have a brief explanation of the review and patrolling processes (or links) for newbies and returning oldbies like myself? Thanks.

Hi Ladmc! That review process depends on the wiki you're doing the reviewing from. Is it English Wikipedia? If so, en:Wikipedia:Recent changes patrol seems to be a good reference.

Yes it is and thanks!

Great!  :D