Great work on Extension:AutoModerator. I'm really happy to see the foundation invest in patrolling and review workflows.
I looked around a bit to see how it works, and how communities configure it. I noticed something small that might benefit you a lot in the long run to change slightly.
The AutoModeratorSkipUserGroups setting is currently based on user groups, rather than user rights. We usually map things in software or other automation to user rights. Groups vary across communities, change over time, come and go, change names, change scopes, etc. User rights on the other hand have stable identifiers native to the software (not user-defined).
By using user rights:
- Equity and inclusion: Communities can't forget to add groups that are functionally similar in practice but separate for social reasons ("do what I mean"). For example, they might include "bot" and "sysop", but miss out on "steward", "gadget admin", "interface admin", "flood". Or they might add "reviewer" but forget about "image reviewer", "patroller", and "rollbacker".
- Cross-wiki collaboration: Communities have to coordinate across wikis to account for global groups (e.g. a "global sysop" is not a local "sysop", we als also have "global interface admin", and "global bot" as distinct groups). MediaWiki core has a built-in abstraction for user rights that automatically works for the global group concept (via the CentralAuth extension). With groups, you'd likely need to develop custom support, integration, and testing with the CentralAuth extension.
- Save time: Communities can focus on reviewing content instead of perfecting the "skip" list of user groups to encompass dozens of local and global groups, and for volunteers to lobby for this on each of 900 wikis.
- An even better first experience: The current default is skip groups=['bot', 'sysop'] which is pretty good, and probably covers 90% of use cases on a given wiki. But, on no wiki would this be the ideal configuration, so everybody has to override and change at least a little. A default like skip rights=['bot', 'autopatrol', 'editprotected'] would likely be a workable default on a majority of wikis, regardless of local groups, global groups, and their own unique division of social roles.
- Easy to understand: If you can do "X" (a right that you can see and experience), then you get "Y" (auto moderator).
The "autopatrol" right is very topically appropiate as it marks those people's edits as needing no review, such as most typical local "reviewer", "patroller", "autopatrolled", and "rollbacker" groups that many wikis have and the global rollbackers group. The "bot" right helps make sure "global bots", "flood", and any other bot-related group is covered. These two cover most administrator roles, but adding "editprotected" makes sure the other high trust and administrator roles are also covered, even if in communities that don't use patrolling (some wikis disable this), or opt-ed out of bot rights, such as global sysop, and global interface editors. There are other rights that you might want to use instead. Have a look at some of the above global groups to see what rights they contain, and compare them to MainConfigSchema#GroupPermissions in mediawiki/core.git. Perhaps other rights would fit better.
A few years ago we spent a good amount of effort converting AbuseFilter rules on many wikis to be based on user rights instead of user groups, because the group model often caused collateral damage on smaller user groups on large wikis, and smaller wikis in their entirety. It is then often awkward and difficult to find out whether or not you can complain about it, to whom, where, how, whether it was intended and you have to convince someone or it's a minor mistake. I'm raising this as something similar might happen with Automoderator. As a developer I knew there was no reason for AbuseFilter to exclude a certain user group, but most affecteds user in a social context, would be quite intimidated in trying to convince an admin to allow them to be included. In particular, global users (who appear "new" on each wiki) which often run into this issue and then go through a language barrier to try to change or improve local configuration.
We do have a few other things based on user groups, so it's not wrong per-se, but I thought it was worth raising in case it makes sense for your case. The transition should be fairly straight-forward, i.e. no breaking change.