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)
[] 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), if so:
[] do we need to coelesce Liftwing requests? (eg. add a post-score hook to allow extensions to reuse scores without making additional requests)
[] How do we know if we have checked revisions that have not been reverted? (eg. logfile, "autopatrolled" flag)
[] How can we implement and support this with limited engineering time?