Not all policy enforcement needs to be automated
I am a big proponent of the “don’t make rules you can’t (or won’t) enforce” maxim. The careful reader will notice that the word “automatically” does not appear anywhere in that advice. Automated policy enforcement is good. It reduces maintainer burden, gives the community a consistent experience, and…you know…makes sure the project’s policies are enforced.
Sometimes automated policy enforcement is easy. There are plenty of tools out there to require a certain degree of password length/complexity, ensure commits have a DCO signoff, and so on. Sometimes the technical implementation is harder. That doesn’t mean the policy can’t go forward.
The Fedora Engineering Steering Committee just decided to require two-factor authentication for members of the provenpackager group (people who have essentially project-wide privileges for package maintenance). In the discussion about whether to adopt such a policy, folks pointed out a few legitimate concerns. The account system can’t require two-factor authentication for only a specific group. Some entry points to the packaging systems are accessible with an SSH key, which limits the protection of a two-factor authentication policy.
These are both good arguments. The counter argument is that such a policy improves the security of the project, even when unevenly followed. Manual audits can check for ongoing compliance.
In general, you can rely on good-faith actors to follow policies that are:
- well reasoned with meaningful benefit to the project or the person
- clearly and obviously communicated
- well documented with a reasonably smooth user experience.
If all of those are true, and you have some way to manually check compliance, then it’s okay if the enforcement can’t be automated. This is especially true when partial compliance is a meaningful improvement over a default of zero compliance.
