One of the core components of Automoderator will be the technology for reviewing edits and making reverts based on Automoderator's configuration on this wiki. We need to decide what our approach will be for where this software is hosted, what technologies it will use, and how it will interface with other components.
In T345092 we had some ideas and suggestions, and we'll use this ticket to come to conclusions on this specific topic. For this question see:
* Task description
* T345092#9247596
**Features**
This component will be responsible for:
* Taking revision ID and language-agnostic revert risk score as input
* Filtering based on some internal criteria (e.g. project, namespace)
* Reverting revisions which meet internal/community configurations and revert risk score threshold
* Providing an auditable trail of activity, including
* revert risk probability check
* action ( eg. revert, notify, no op)
**Questions**
[x] How will we monitor new edits?
[x] Should this operate on a stream of events? (scalable, expectation that revision gets processed eventually), if so:
- not at this time, though we should leave ourselves open to the possibility in the future
[] Where should this be hosted? (eg production kube service, toolforge, cloud vps)
[] What technologies will we use? (eg. flink, changeprop)
[x] Or should this operate in a mediawiki extension hook implementation (eg RecentChange_save, RevisionFromEditComplete) like the ORES extension? (simpler design, leverages existing production mediawiki ops support)
- we should start with this approach as our basic implementation; we can start prototyping, easily do local testing, leverage patchdemos, etc
[x] do we need to coelesce Liftwing requests? (eg. add a post-score hook to allow extensions to reuse scores without making additional requests)
- Work is being done in {T348298} to add language agnostic revert risk scores to the ORES extension, which saves the scores and makes them available upon save via the `ORESRecentChangeScoreSaved` hook; we can just take advantage of that to get our scores
[x] where should the code that actually does the reverting go?
- within a mediawiki extension; that will make localization for edit summaries and potentially revision tag labels more convenient. we can expose an API if needed for an external stream-based tool to call if needed
[x] How do we know if we have checked revisions that have not been reverted? (eg. logfile, "autopatrolled" flag)
- we can define and apply revision tags for revisions that we've checked, reverted, etc, with a single revision being able to have multiple tags
[x] How can we implement and support this with limited engineering time?
- moderator tools does not have the capacity to provide ops/sre for this, so it will need to be deployed within services that are supported by other teams; mediawiki is an obvious choice, but another service could be used so long as we can keep in our lane of design, software development, community collaboration, etc