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 IDs as input
* Filtering these edits based on some internal criteria (e.g. project, namespace)
* Getting the revert risk score for each applicable edit
* Reverting edits 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**
[] How will we monitor new edits?
[] Should this operate on a stream of events? (scalable, expectation that revision gets processed eventually), if so:
[] 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
[] do we need to coelesce Liftwing requests? (eg. add a post-score hook to allow extensions to reuse scores without making additional requests)
[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