One quick note: the patoller is not an extension. It's integrated with mediawiki core. It's only a mediawiki config called $wgEnableRCPatrolling

In T143791#2579072, @Ladsgroup wrote:

One quick note: the patoller is not an extension. It's integrated with mediawiki core. It's only a mediawiki config called $wgEnableRCPatrolling

wgUseRCPatrol

The English Wikipedia had a discussion in January 2005 to disable that: https://en.wikipedia.org/wiki/Wikipedia_talk:Checked_edits_brainstorming

That has been disabled cluster-wide to be opt-in.

@Halfak You probably need to start a https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment according English Wikipedia usage.

Is there a permission that will prevent a user's edits from being flagged by ORES? I would guess autopatrol but I recall seeing an autopatrolled user showing up in red, I think.

I'm just wondering that if there is a new user right, we'll need to create and monitor a new "requests for permissions" page. If there's an existing user right we'll need to rethink criteria for granting it. E.g. autopatrolled is currently only for mainspace articles.

@Dereckson, I'm aware of that, thanks. The feature was requested by someone else. I just filed the bug. So I recommended that Nthep start the RFC.

In T143791#2581143, @MusikAnimal wrote:

Is there a permission that will prevent a user's edits from being flagged by ORES? I would guess autopatrol but I recall seeing an autopatrolled user showing up in red, I think.

I'm just wondering that if there is a new user right, we'll need to create and monitor a new "requests for permissions" page. If there's an existing user right we'll need to rethink criteria for granting it. E.g. autopatrolled is currently only for mainspace articles.

There is no need for additional user rights. The existing "autopatrol" should work fine as-is. Let me explain :)

ORES intentionally does not have a way to whitelist specific words or user names. If you ask ORES to score a revision, it will score it the best it can, based on its training. Even if we include the autopatrol status of a user alongside the diff and other meta data for ORES to consider, it will not guarantee a positive score for edits by auto-patrolled users. However, this is not actually a problem. The problem is not what the ORES score. The problem is whether we ask ORES to score the revision at all.

You can filter Recent Changes by patrolled status. Which I suspect would give a better result then to show all edits but with neutral scores alongside all the autopatrolled edits. Keeping these features separate seems desirable.

In other words, edits by autopatrolled users are automatically marked as patrolled. As such, viewing recent changes with both "Hide patrolled edits" and "Show ORES scores" enabled, naturally results in not seeing (negative) ORES scores for edits by autopatrolled users. Similarly, it will also not show edits you (or someone else) has previously patrolled.

Just wanted to add that old ORES filters even exclude patrolled edits but the new filters don't (which I thought they do until several days ago: T187337: ORES extension highlights edits that are patrolled)

This will be extremely useful, anyone from collab wants to take this on?