Thanks for the suggestion! Sounds like a reasonable change.
No one is actively working on patrol functionality at the moment but this seems easy enough for an interested volunteer to do.

Hey, I would love to work on this Issue if possible.

Hi @Homewardgamer! The constants mentioned by @MisterSynergy are RecentChange::PRC_UNPATROLLED / RecentChange::PRC_PATROLLED / RecentChange::PRC_AUTOPATROLLED. An IDE with decent static analysis capabilities will tell you where those constants are used, you just need to find the place that's rollback-related.

https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker might be helpful if you are new to MediaWiki development.

Hi there, I would like to work on this issue, if the other person hasn't contributed yet.

Anyone is very welcome to provide a patch in Gerrit - thanks in advance!

Hi @Matej_Orlicky I made the changes as you suggested in both RollbackPage.php and tests/phpunit/integration/includes/page/RollbackPageTest.php, but running phpunit test failed with an error.

Here is the error message:

php phpunit.php integration/includes/page/RollbackPageTest.php 
Using PHP 7.2.34-18+0~20210223.60+debian10~1.gbpb21322+wmf2
PHPUnit 8.5.25 #StandWithUkraine

......F........                                                   15 / 15 (100%)

Time: 1.95 seconds, Memory: 42.25 MB

There was 1 failure:

1) MediaWiki\Tests\Page\RollbackPageTest::testRollback
rc_patrolled
Failed asserting that '2' matches expected 1.

/var/www/html/w/tests/phpunit/integration/includes/page/RollbackPageTest.php:180
/var/www/html/w/tests/phpunit/MediaWikiIntegrationTestCase.php:457

Could you provide some suggestions here? I'm familiar with PHP but not all that familiar with the testing portion.

In T302140#7795717, @matej_suchanek wrote:

Could you provide some suggestions here? I'm familiar with PHP but not all that familiar with the testing portion.

Apparently, the test suite needs to be updated as well. The test correctly asserts that the reverted revisions are "autopatrolled", but this is what is supposed to change.

In fact not. The test actually asserts the status of the newest revision, not the reverted one(s). So line 178 should not be changed.
The test should probably assert the status of the reverted one(s) anyways.

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

In T302140#7795751, @matej_suchanek wrote:

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

Why so?

The rc_patrolled status of autopatrolled edits (i.e. rc_patrolled=2) should never be changed. These edits have been made by experienced users, thus they do not need to show up in the pipeline of patrollers. 0 -> 1 should be the only possible path.

In T302140#7799871, @MisterSynergy wrote:

In T302140#7795751, @matej_suchanek wrote:

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

Why so?

The rc_patrolled status of autopatrolled edits (i.e. rc_patrolled=2) should never be changed. These edits have been made by experienced users, thus they do not need to show up in the pipeline of patrollers. 0 -> 1 should be the only possible path.

I'm describing what the code does now / would do and I wonder if it really should...

In T302140#7795751, @matej_suchanek wrote:

In T302140#7795717, @matej_suchanek wrote:

Could you provide some suggestions here? I'm familiar with PHP but not all that familiar with the testing portion.

Apparently, the test suite needs to be updated as well. The test correctly asserts that the reverted revisions are "autopatrolled", but this is what is supposed to change.

In fact not. The test actually asserts the status of the newest revision, not the reverted one(s). So line 178 should not be changed.
The test should probably assert the status of the reverted one(s) anyways.

It makes me wonder now whether all reverted changes should be marked as manually patrolled if they were autopatrolled...

The above was resolved in rMW5e5c879be276: RollbackPage: Make rollback not overwrite manual RC patrol status.
If appropriate, the requested change should now be trivial.

Change 876366 had a related patch set uploaded (by OwenR; author: OwenR):

[mediawiki/core@master] Mark rollbacked edits as manually patrolled instead of automatically patrolled.

https://gerrit.wikimedia.org/r/876366

Tagging Product-Analytics to check if there are any concerns with us approving this patch - this would change how some data is stored in the Recent Changes table, so I wanted to check if any documentation or pipelines needed updating that might use this data.

@Samwalton9-WMF, should we wait until we hear back from Product Analytics before we continue to review/merge the patch? If so, we should mark it as stalled until we have an answer.

Thanks! Checking in with the team now.

We're using the field to calculate unpatrolled recent changes daily metrics (generate_moderation_unpatrolled_recentchanges_daily.sql?ref_type=heads#L16). I don't think any change is necessary for the pipeline, but we will need to document this update as we might see a change in the metrics. I will do it in DataHub once the change is in production.

@Samwalton9-WMF Please wait a bit longer. @jwang needs to investigate because

The reverts and rollbacks data in Temp Accounts / IP Masking data pipelines are staged from wmf.mediawiki_history table. I will investigate whether the recentchanges table is the up stream of the wmf.mediawiki_history to understand the impact of T302140#10313116.

I don't think the change will impact the reverts and rollbacks metrics in Temp Accounts / IP Masking data pipelines, as the recentchanges table is not the up stream of the wmf.mediawiki_history.

Change #876366 merged by jenkins-bot:

[mediawiki/core@master] Mark rollbacked edits as manually patrolled instead of automatically patrolled.

https://gerrit.wikimedia.org/r/876366

We checked this testwiki today, and found that rolledback edits were still showing up as autopatrolled. This looked good in database inspection back in december, so we'll have to do some more local testing to see if we inadequately tested or if there is another factor at play

@matej_suchanek we probably shouldn't announce yet since we discovered it's not working in this release

That's probably because the reverted edit had been autopatrolled when saved. It was discovered (T302140#7795751) when this task had been created that rollback would change the patrolling status retrospectively, and this was fixed in 5e5c879be2.

In T302140#10463643, @matej_suchanek wrote:

That's probably because the reverted edit had been autopatrolled when saved. It was discovered (T302140#7795751) when this task had been created that rollback would change the patrolling status retrospectively, and this was fixed in 5e5c879be2.

You are correct, I didn't think about my testwiki account being autopatrolled; I retested with a temp account and it works as expected.

For Tech News, please confirm (or correct/rewrite) if this is an accurate summary to use?
Also, is there a second sentence that we could add to this, perhaps to explain why this change is beneficial (beyond just "more accurate"!), or perhaps how editors might want/need to change any of their workflows to adapt to this? Thanks!

• When the rollback feature is used to revert an unpatrolled page revision, that [revision? edit?] will now be marked as "manually patrolled" instead of "autopatrolled".

I guess the primary reason was to stop claiming that the reverted revisions were autopatrolled (done by autopatrolled users) when they in fact were (indirectly) "patrolled" manually.
As for the workflows, this changes behavior of the modern filters for recent changes, and some users might need to update their bookmarked filter sets (or bookmarks in general).
Also, bot users of recent changes API might be affected (but not those listening to recent changes in real time).
Note that this change concerns only wikis with UseRCPatrol on.

@matej_suchanek much thanks for the details! I've added it as:

• On wikis that use the Patrolled edits feature, when the rollback feature is used to revert an unpatrolled page revision, that revision will now be marked as "manually patrolled" instead of "autopatrolled", which is more accurate. Some editors that use filters on Recent Changes may need to update their filter settings. [2]

If you/anyone thinks that needs adjusting, please let me know (or edit directly) within the next 2 hours, after which it will be frozen for translation.