Cleanup and better wording; added rest to overview

pull/31/head
Merlijn Sebrechts 2019-04-14 19:37:48 +02:00
parent dc0440d65f
commit b1fe0a3d91
2 changed files with 17 additions and 12 deletions

View File

@ -51,7 +51,7 @@ The statutes dictate the following.
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
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.
@ -84,13 +84,13 @@ The topic is discussed in group and requires a 100% consensus to reach a group d
* encourages discussion
* forced to listen to opposing ideas that can give new insights
* they can bring smarter compromises
* http://en.wikipedia.org/wiki/Consensus
* <http://en.wikipedia.org/wiki/Consensus>
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.
### Meeting 2
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 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.
### Meeting 3

View File

@ -4,25 +4,30 @@ A hackerspace is a physical place, run by people interested in various aspects o
We are a breeding ground for awesome ideas. We provide a nest where those ideas can become reality. We operate by collaboration and openness. We allow people to fail, and to try again.
## We failed, but we try again
## We learn from our failures
We created our very own Ghent hackerspace. We had two rules: be excellent to each other and decide everything by consensus. We thought normal human interaction and common sense would solve all problems. Sadly, this was not true. When our hackerspace almost died, we decided to "Hack the Hackerspace". We found that the problems could all be traced to the following root causes:
We created our very own hackerspace in Ghent. We had two rules: be excellent to each other and decide everything by consensus. We thought normal human interaction and common sense would solve all problems. Sadly, this was not true: internal conflict almost killed our hackerspace. Instead of giving up, we decided to "Hack the Hackerspace"; we organized a number of workshops to figure out what went wrong and how to build a better hackerspace. We found that the problems could all be traced to the following root causes:
* We cannot rely on common sense because **people have different realities.**
* **People have different, conflicting goals.** Because of that, consensus will never be reached on certain things. Problems will arise and they will not be solved. In most cases, no solution is worse than a bad solution.
* **People have different, conflicting goals.** Because of that, consensus will never be reached on certain things. Problems will arise and they will not be solved.
* **No solution is worse than a bad solution.** Because when problems aren't solved, they pile up until the community falls apart.
We knew that, in order to fix this, we needed a system that gets the best out of everyone and enables us to be awesome! After long late-night discussions, we came up with "the hackerspace blueprint", a document that describes how to run a hackerspace in a way that brings out the best in people. You can download **[the latest PDF version of this document](https://github.com/0x20/hackerspace-blueprint/releases/latest/download/hackerspace-blueprint.pdf).** An [epub version](https://github.com/0x20/hackerspace-blueprint/releases/latest/download/hackerspace-blueprint.epub) is also available for e-readers.
We knew that, in order to fix this, we needed a system that gets the best out of everyone and enables us to be awesome! During many late-night discussions, we fleshed out this system and wrote it down with the working title of "hack the hackerspace". This eventually became "the hackerspace blueprint", a document that describes how to run a hackerspace in a way that brings out the best in people. You can download **[the latest PDF version of this document](https://github.com/0x20/hackerspace-blueprint/releases/latest/download/hackerspace-blueprint.pdf).** An [epub version](https://github.com/0x20/hackerspace-blueprint/releases/latest/download/hackerspace-blueprint.epub) is also available for e-readers.
We have been refining this system for a few years now, tweaking the system when we encounter issues and explaining important parts in more details. This document specifically describes how Hackerspace Gent runs, but it is generic enough so that it can be easily adapted to other hackerspaces and similar organizations. Feel free to use and remix this for your own benefit, learn from our mistakes and let us know what you think of it!
We have been refining this system for many years now, tweaking it when we encounter new issues and explaining important parts in more details. This document specifically describes how Hackerspace Gent runs, but it is generic enough so that it can be easily adapted to other hackerspaces and other self-governing organizations. Feel free to use and remix this for your own benefit, learn from our mistakes and let us know what you think of it!
The goal of this system is to empower people to get the best out of themselves. It stimulates collaboration and enables people to think and solve problems creatively. We know that this system will be flawed from the start. We know that control of people is evil. But a flawed system is better than no system, and we continuously update this system to make it better. That is why [this is on GitHub](https://github.com/0x20/hackerspace-blueprint), in order to make it easy to build on the hackerspace blueprint as a community.
The goal of this system is to empower people to get the best out of themselves. It stimulates collaboration and enables people to think and solve problems creatively. We know that this system will be flawed from the start. We know that control of people is evil, but a flawed system is better than no system. Moreover, we continuously update this system to make it better. That is why [the hackerspace blueprint is on GitHub](https://github.com/0x20/hackerspace-blueprint). We want to make it easy for the community to contribute to it, and for other organizations to use it as a basis for their own system.
# 1. Overview
The main system running the Hackerspace is **the do-ocracy**, explained further in Section 2. In short: If you want something done in the hackerspace, either do it yourself or convince someone else to do it for you. The goal of the do-ocracy is to lower the barrier to contributing as much as possible.
However, when you want to do something that affect a lot of people in the space, or when you want to make sure that people will support what you want to do, discuss it with the other members on a **meeting** as explained in Section 3.
However, when you want to do something that is irreversible or affects the core infrastructure of the space, you can discuss it with members on a **meeting** as explained in Section 3. These meetings can also be used to make sure that people will support what you want to do.
Every organization has a number of unspoken guidelines of how you should behave, we have written down some of ours in Section 6 in order to make it easier for people to get a sense of what to do in certain situations. These **guidelines** are not meant to be strict rules, but they give an overview of what is good and bad behavior in the space.
There are two issues that are hard to fix using do-ocracy and meetings: interpersonal conflict and core infrastructure maintenance. Section 4 explains how **the board** solves these issues as the "custodians" and "counselors" of the space. Unlike many other organizations, the board has no power over what the space should do.
Because every good idea that was once written down has been misinterpreted, we included information that led us to the system and the guidelines. We call it **the legacy**. It is a collection of information that we used to create the hackerspace blueprint, it gives more context to why the system is the way it is. The legacy should by used as a "cipher" to interpret the system and the guidelines correctly and to explain a bit of the rationale behind them.
Section 5 explains how you become a **member** of the space.
Every organization has a number of unspoken guidelines of how you should behave. We have written down some of ours in Section 6 in order to make it easier for people to get a sense of what to do in certain situations. These **guidelines** are not meant to be strict rules, but they give an overview of what is good and bad behavior in the space.
Because every good idea that was once written down has been misinterpreted, we include the information that helped us create this system and the guidelines. We call it **the legacy**. It is a collection of discussions, articles, research and books that we used to create the hackerspace blueprint. It gives more context about why the system is the way it is. The legacy should by used as a "cipher" to interpret the system and the guidelines better and to explain the rationale behind them.