adinfinitum
/
hackerspace-blueprint
mirror of https://codeberg.org/tqt/hackerspace-blueprint.git
2
0
Fork 0
Code Issues Releases Wiki Activity

more info on meetings

pull/12/head
Merlijn Sebrechts 2018-05-20 18:18:57 +02:00
parent e11062cd82
commit d0040fea15
5 changed files with 117 additions and 66 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
2-do-ocracy.md
View File

@ -14,6 +14,14 @@ Doing a task is in itself justification for you being the person who does that j
Source: http://www.communitywiki.org/en/DoOcracy
People need to feel safe knowing that they are allowed to try, and to fail. Thus, when people fail, we need to be kind and help them get better instead of berate them. The hackerspace gives everyone room to grow, and failure is part of that. For more information, read up on the idea of "blameless post-mortems" in the IT operations and DevOps communities.
Tight feedback loop: It's easy to do something, so it's very easy to try something, see what the result is, and then use that information to try something different.
## Boundaries
Some things are too sensitive to be handled by do-ocracy alone, like throwing things away. The guidelines define what the boundaries are of the Do-ocracy. Any member can request that a decision is discussed in the group.

167
3-meetings.md
View File

@ -1,23 +1,85 @@
# 3. Meetings
## The decision making model
## What should I discuss on a meeting?
Below outlines the decision making model to be used during meetings.
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. **Therefor, meetings should be primarily focussed on convincing people do do something or asking feedback on what you want to do instead of on deciding what should be done.**
| PLAN/TIME | ACTION | VOTE |
| ------------------------------- |:------------------------------:| --------------:|
| Week 0 | Put problem on agenda 3 days before meeting | no vote |
| Week 1 | Discuss in group, listen, learn and build compromise | 100% consensus |
| Week 2 | Discuss in group, listen, learn and build compromise | 80% consensus |
| Week 3 | Discuss in group, listen, learn and build compromise | Point system |
Things you should discuss on a meeting:
### week 0
* Before using money of the hackerspace, discuss it on a meeting and make sure the board knows about it.
* When organizing big events in the space.
* If you want to do something that affects a lot of people in the space, and it's hard to reverse it when people complain.
The point is put on the agenda of the weekly meeting and is announced on the mailing-list. This needs to be at least 3 days in advance.
Things you can discuss on a meeting:
### week 1
* 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.
The point 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:
## How do I shedule a meeting?
Any member can shedule a meeting.
1. Create a pad for the meeting topics and the meeting notes.
2. Pick a date (preferably not during the social evening).
3. Put the meeting in the calendar with a link to the meeting notes, announce it in the changelog and announce it in the main channel.
## How do we make a decision during a meeting?
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 enjoyeable, it easily kills the passion of the person who wants to get things done, and it slows everything down to a crawl.
## General Assembly and Statutes
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 sheduled 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 sheduled where a decision is made using the "point system", an over-complicated system where a decision will always be made.
| PLAN/TIME | ACTION | DECISION |
| ------------------------------- |:-----------------------------------------------------------:| --------------:|
| 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:
* encourages discussion
* forced to listen to opposing ideas that can give new insights
@ -26,11 +88,11 @@ The point is discussed in group and requires a 100% consensus to reach a group d
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.
### week 2
### Meeting 2
The point 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 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.
### week 3
### Meeting 3
When all has failed, or the problem is too controversial, but a decision is still required, the point system below will be used to reach a decision.
@ -56,57 +118,34 @@ In the point system, every voter gets some points that they can distribute betwe
#### Examples
| Vote without points | Points to A | Points to B |
| ------------------------------- |:------------------------------:| --------------:|
| A | 3 | 2 |
| A | 4 |1 |
| A | 3 | 2 |
| A | 3 | 2 |
| A | 4 | 1 |
| A | 3 | 2 |
| B | 2 | 3 |
| B | 0| 5 |
| B | 1 | 4 |
| B | 1 | 4 |
| TOTAL | 24 | **26** |
| Vote without points | Points to proposal A | Points to proposal B |
| ------------------- |:---------------------:| --------------------:|
| A | 3 | 2 |
| A | 4 | 1 |
| A | 3 | 2 |
| A | 3 | 2 |
| A | 4 | 1 |
| A | 3 | 2 |
| B | 2 | 3 |
| B | 0 | 5 |
| B | 1 | 4 |
| B | 1 | 4 |
| TOTAL | 24 | **26** |
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.
| Vote without points | Points to A | Points to B |
| ------------------------------- |:------------------------------:| --------------:|
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| B | 4 | 1 |
| B | 0| 5 |
| B | 0 | 5 |
| B | 0 | 5 |
| TOTAL | **32** | 18 |
| Vote without points | Points to A | Points to B |
| -------------------------- |:------------------------------:| --------------:|
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| B | 4 | 1 |
| B | 0 | 5 |
| B | 0 | 5 |
| B | 0 | 5 |
| TOTAL | **32** | 18 |
However, extreme ideas will not be able to "win". With extreme ideas, the outcome of this model will be the same as with a +50% majority.
## General Assembly and Statutes
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.

4
4-the-board.md
View File

@ -47,3 +47,7 @@ The board does not have any say about what other members are to do, and you want
- The "counselor" role requires people who are open communicators, good listeners, and good at defusing a situation.
Both roles require people who are trusted by the members, are open for feedback, and who communicate openly about what they're doing. Since a position with power is controversial (rightly so) in the hacker community, it's incredibly important that the members trust the people in the board. The board will make difficult decisions and the members need to trust that these decisions are the right ones for the space, not just the right ones for the people in the board.
## How does the board get elected and expelled?
During a general assembly, the members vote on electing and expelling the board according to the statutes. For more information, refer to the "Meetings" Section.

2
5-membership.md
View File

@ -8,7 +8,7 @@ When a conflict/problem can not be resolved between individuals/via do-ocracy or
They are responsible for
- Creating and patching the guidelines and the system.
- Creating and patching Hack the Hackerspace.
- Solve problems when do-ocracy cannot fix them.
- Electing the board during a General Assembly.
- Organize workshops, events, lectures.

2
7-the-legacy.md
View File

@ -2,7 +2,7 @@
Because every good idea that was once written down has been misinterpreted, we included information that led us to the system and the guidelines in this repository as The Legacy. This should by used as a "cipher" to interpret the system and the guidelines correctly and to explain a bit of the rationale behind them.
Some of these documents are archived in the `legacy` folder of the Hack the Hackerspace repository.
Some of these documents are archived in the `legacy` folder of [the Hack the Hackerspace repository](https://github.com/0x20/HTH).
* [**The fall of the hacker groups.**](The_Fall_of_Hacker_Groups)