Since the hackerspace is mainly a Do-ocracy, there is actually very little that __needs__ to be discussed on a meeting. Do you want something done? Well then, don't talk about it, just do it. Moreover, meetings only have limited power since, even if everyone in the meeting agrees that "A" is something great to do, it will only be done if someone actually does it afterwards. **Therefore, meetings should be primarily focused on convincing people to do something or asking feedback on what you want to do instead of on deciding what should be done.**
* You want everyone to be on the same page about a topic or issue.
* If you want to make sure people will fully support what you want to do, you can hold a meeting to explain what you will do and ask for feedback.
* If you want to do something that requires help from many people, you can use a meeting to convince people to help you.
* If you have issues with the actions of a certain member and you failed to solve it with that member personally or you want the group's opinion on it.
During meetings, the normal decision making model is "provided nobody says no": you discuss a topic and propose an action during a meeting. You ask if anyone objects to that action. If nobody objects, you have the permission to do that thing. When a decision has been made, you need to write down the exact decision in the meeting notes.
Note that this intentionally favors the "yes" vote: there is a slight barrier to speak up and say "no". The thinking behind it is that we want to make the barrier to "doing" as low as possible. We only want people to voice their opinions when they think it's really important or when they are explicitly asked.
## Why not regular consensus?
[Consensus-based decision making](https://en.wikipedia.org/wiki/Consensus_decision-making) aims to involve as many stakeholders as possible in a decision. This is the exact opposite from our system, where we want to involve as few stakeholders as possible in a decision, in order to lower the barrier to "doing" as much as possible. Do-ocracy gives as much power as possible to the person doing it, instead of to the persons who have an opinion on it. When you want to do something, you have to make sure that nobody will hate it, instead of making sure that everyone is pleased.
Having as many people as possible involved in a discussion encourages [Bikeshedding](http://phk.freebsd.dk/sagas/bikeshed.html): long useless discussion about trivial details that don't really matter in the bigger picture. This idea stems from Parkinson's [Law of triviality](https://en.wikipedia.org/wiki/Law_of_triviality), which shows that you can easily get approval for building a multi-million dollar atomic power plant, but if you want to build a bike shed, you will be tangled up in endless discussions about the color of the shed. This is because a power plant is so complicated that people cannot grasp it, while anyone can build a bike shed over the weekend so everyone can comment on it. People enjoy commenting on it because they want to be part of the discussion and they want to add a touch and show personal contribution. Although for the people voicing their opinion this might be enjoyable, it easily kills the passion of the person who wants to get things done, and it slows everything down to a crawl.
A general assembly is different from a normal meeting in that it is governed by the rules in the official statutes of the legal entity "Hackerspace Gent (0x20)". As a Belgian non-profit organization, Hackerspace Gent is required to host a General Assembly each year. During a general assembly, the board is elected.
The statutes dictate the following.
* The General Assembly needs to be announced at least 10 days beforehand.
* 50% of members need to be present during a General Assembly.
* 2/3 of members need to be present in order to change the statutes and/or the board.
* Decisions during the General assembly need a 2/3 majority of the present members.
* The board needs to have at least 3 members.
You can find the latest version of the statutes in the Government gazette (staatsblad) (Dutch-language).
1. Go to http://www.ejustice.just.fgov.be/tsv/tsvn.htm
2. Fill in `0x20` in the "Benaming" field and press the "Opzoeking" button. Now you should see a number next to the "opzoeking" button, this is how many search results there are. *0x20 is the short name for "Hackerspace Gent", previously "Whitespace".*
3. Press the "lijst" button to see all the search results.
More important information from the statutes.
* The hackerspace needs to have at least 4 members.
* New members need to be approved by the board.
## The formal decision making model
Most decisions don't require a rigid structure but we need a rigid structure to fall back on when there is extreme conflict that divides the space or when people don't agree on how a decision is made. In such cases, a consensus-based system is used in order to re-unite the space.
In short; the topic needs to be put on the agenda three days the first meeting. During the first meeting, a decision needs 100% consensus. If no decision is made, a second meeting is scheduled where a decision on a topic only requires 80% consensus, so a decision is made when 20% or less members object. If no decision is made, a third meeting is scheduled where a decision is made using the "point system", an over-complicated system where a decision will always be made.
| Week before meeting | Put the topic on the agenda three days before the meeting | |
| Meeting 1 | Discuss in group, listen, learn and build compromise | 100% consensus |
| Meeting 2 | Discuss in group, listen, learn and build compromise | 80% consensus |
| Meeting 3 | Discuss in group, listen, learn and build compromise | Point system |
### Week before meeting
The topic is put on the agenda of the weekly meeting and is announced on the Mattermost (chat) server. This needs to be at least 3 days in advance.
### Meeting 1
The topic is discussed in group and requires a 100% consensus to reach a group decision. The motivation for striving for consensus is because consensus comes with characteristics that benefit the hackerspace:
The required 100% consensus also means that a very small minority can block a decision. That is a desired feature but it comes with a responsibility. When a small minority or even an individual feels very strongly that a proposed decision is not correct they have the option to block a decision. This does not stop a decision but gives the opposers 1 week of time. During that week the minority has the task to convince fellow members of their viewpoint.
The topic is discussed again but now a rough consensus of 80% is applied to reach a decision (https://en.wikipedia.org/wiki/Rough_consensus). If the small minority of last week was not able to convince enough fellow members the decision will be passed with rough consensus of 80%. When their viewpoint makes enough sense to fellow members, critical mass must be found to reach a new compromise. All members joining the discussion must strive to reach the rough consensus, to build the compromise. Not doing so is not being excellent.
The point system is a **last-resort** option. This should not be the general process of resolving conflicts. If the space is starting to use this too much, that means that there is a structural problem in the group dynamic.
"No decision" is worse than a "bad decision". Conflict has to be solved eventually. That is why there is this last-resort option. However, we want to discourage people from blocking consensus. The point system has the following advantages:
As you can see in this example, a less-extreme proposal that, on first sight, has the minority of the votes, can still win. This gives the minority the incentive to come up with moderate ideas that everyone can agree with.