@kmccormick @braden We discussed this topic during the contributors meetup, and there was a consensus that this should be addressed. We ran a quick show of hands, and everyone involved in code reviews agreed.
The approach you’re suggesting @braden seem good to me – we need to be able to trust that the reviewers follow the project decisions and guidelines for what gets merged in the project. We could also likely make the linter or automation more strict, but it often comes with side effects (more false positives, and could probably be circumvented). On something obvious like the lack of a proper PR description, the responsibility is clearly on the reviewer to not let it pass.
It’s definitely important to start by discussing - I’m guessing most of the reviewers who don’t enforce this don’t know that this is a requirement of the project, nor why it is important for the project. Communicating and explaining would be important imho, and I’m sure most reviewers would understand and agree to it.
At the same time, since the project direction is moving from a single actor to a community, it will be important to be able to draw clear limits to what is accepted by the project – and it would be important to tie continued elevated rights within the project to respecting the project’s rules. (And it is actually a good incentive to participate in the elaboration of those rules.)