BTW, any help for the tooling is welcome! If you've got plugin configuration files or scripts we could reuse (with an appropriate license) or even tips on how to best set this up, please feel free to share these.
The Chromium Gerrit has an owners-enforcement system but I'm not familiar with how exactly they set it up. I think they're using this plugin https://gerrit.googlesource.com/plugins/find-owners/+/refs/heads/master and this is where it's integrated into Gerrit submission rules: https://chromium.googlesource.com/chromiumos/+/refs/meta/config/rules.pl . It works by having a file called OWNERS in certain directories which sets the owners for the subtree below it, so we would have to rewrite the current code owner list in that format if we wanted to use it.
There also seems to be this completely separate plugin that claims to do roughly the same thing, I have no idea where the difference is between the two: https://gerrit.googlesource.com/plugins/owners/+/refs/heads/master
One option as you say would be to allow code owners to self-review their patches but I am not convinced we would gain anything out of this. It sounds like a tick-box exercise to me, an admin overhead just to get the patch through the system and I would like to avoid that as much as possible. It is likely that a patch submitter has already self-reviewed his code before posting a patch anyway. The alternative we've been discussing in the team is to call out another reviewer in these situations. I think that there is still value in having a second fresh pair of eyes on a patch. Even if the reviewer has no particular expertise on this specific module, they can still catch potential logic problems or structural issues in the code.
I definitely did not mean to suggest that these patches should not be reviewed at all -- I was just talking about the Code-Owner-Review label. There would still be a maintainer review, of course, and it seems like a good idea to get additional reviews from other people too. They just couldn't set the COR+1 bit once we start ACLing it.
Basically, each of these bits have their own purpose, and I would see the purpose of the COR+1 bit to be that the person most familiar with that particular piece of code has made sure that it fits in and doesn't cause unexpected problems with certain quirky configurations or something like that. That's important when, say, I make a generic refactoring that touches a platform I'm unfamiliar with, but if the code owner adds to their own platform that's probably already a given and they are likely still the best person to judge that, even for their own code.
That all code gets reviewed by people other than the author I would see as a somewhat orthogonal concern that should be checked independently. So maybe the rule could be that if the code owner sets COR+1 for themselves, there needs to be at least one Code-Review+1 (if we reintroduce that label) from another person (who is also not the one setting Maintainer-Review+1) to make sure the minimum amount of reviews stays the same. Or maybe these should all be completely independent checks so every patch needs a Code-Owner-Review+1 (can be from the author), a Maintainer-Review+1 (not from the author) and at least two Code-Review+1 from people other than the author -- with the normal expectation that when a maintainer or code owner reviews a patch, they would also set Code-Review+1 (as a general sign that they reviewed the patch) in addition to their special meaning flag.