This is a bit naive. People write emotional rules and laws all the time. They may even work for a little while. Then one of two things happens, maybe even both at the same time.

First other people poke at the gray areas of the rules which leads to the "you accepted x, but not y, this must be favoritism when allowing AI posts". Things degrade into insane rule lawyering.

Or, you end up with insane sets of rules and enforcement that kill the project. We've seen a lot of project leaders recently just act kind of mental. Quite often it will lead to the project forking and falling apart.

Well written rules for a project matter even more than well written code.

This is why I prefer very loosely written rules in a pseudo-common-law system :)

i.e. have few, generic rules, and have their boundaries be constrained by implementation. The important part is consistency. There is a boundary, it's just unstated. If you're enforcing stuff arbitrarily, this won't work, but if you're mostly consistent this can make things smooth by eliminating the space for rules lawyering, drama and schemes by getting everyone in the community to "sign up" to the status quo.

When you're new you don't know where you're at so you join, observe and listen. After some time, you're familiar with the norms so you can engage with them, advocate for changes, etc.

Of course, the alternative is codified rules for everything, but the moral hazard there is that the more rules you add, the more they're likely to be contradictory, leading to the possibility of arbitrary enforcement nonetheless despite the pretence that the rules are specific and clear so the enforcement isn't arbitrary at all.