What causes bureacracy?
"Bureaucracy", used colloquially, typically means "too much process, that takes too long, forcing people to jump through unnecessary hoops, or preventing what needs to happen from happening".
This can be immensely frustrating, and most people want to avoid it at all possible. Here are some tips for avoiding bureaucracy in your project.
Let's say you want your project to operate by consensus. This means that everyone should agree to the things that happen in the project. But proactively getting everyone's approval for every minor thing would be such a hassle!
You can make the consensus process the backup plan rather than the default. Instead of being used for all decisions, it would only be used when triggered.
Things that might trigger the backup plan include:
For this approach to work, it's important that your community have clearly defined communication channels where people can share what they're planning to do. Otherwise, people won't know what's going on and it'll be hard to see if there's conflict that needs the backup plan to resolve.
It's hard to find the right governance process for your project! You need to be able to try different things, and to revert changes if the process you choose was wrong. That's why it's important that, whatever structure you choose, it has some mechanism for change.
The US constitution has a section on how to ammend the constitution. The Python governance document has a section on how to change the document. Your project's equivalent doesn't have to be nearly so involved - it can be as simple as "if we all agree to change something, we'll change it" - but it's worth thinking about how change will happen.
Sometimes organizations adopt processes that stick around forever even though no one likes them, because people are too busy to go through the process of revoking them.
One way to address this is with sunset provisions. Sunset provisions give an end date to a process (for example "On January 1st 2026" or "One year from when it was adopted").
If you're trying something new, you can always say, "Let's try this for three months and then stop. If folks like it enough to keep going with it, we can have that discussion then." Note that this approach requires that people be enthusiastic about the process enough to have a new discussion about it. If they do, that's a good sign that the process is fit for your project.
Sometimes people misuse processes as a way to slow down changes they don't like. One way to avoid this is to address the conflict directly.
This isn't always easy! It requires community members who are skilled facilitators, a culture of healthy conflict, and/or a specific and easy-to-access conflict resolution process. (You don't need all three, but you need at least one.) If people have other ways to resolve conflict, they will be less likely to take their frustration out on others by making them dot every i and cross every t.
Bureaucracy isn't always a bad thing. Sometimes we need processes to protect us from recklessness, bad actors, and "ideas that seemed good at the time but in retrospect had some obvious flaws". Take, for exampe, the nuclear briefcase which has very strict processes guarding how it can be used. We probably don't want to replace that with a do-ocracy!
If you can appreciate bureaucracy, you can learn to see when it's most useful: in cases where collective buy-in is important and/or when the potential for harm is greatest. That helps you to develop processes where you need them, and comfortably avoid them when you don't.