Merge pull request #36 from mrosseel/patch-1
|8 months ago|
|epub-fonts||1 year ago|
|legacy||1 year ago|
|.gitignore||1 year ago|
|.travis.yml||1 year ago|
|2-do-ocracy.md||1 year ago|
|3-meetings.md||1 year ago|
|4-the-board.md||1 year ago|
|5-membership.md||10 months ago|
|6-guidelines.md||8 months ago|
|7-the-legacy.md||1 year ago|
|8-acknowledgements.md||2 years ago|
|CONTRIBUTING.md||1 year ago|
|LICENSE||2 years ago|
|LICENSE.freepik||2 years ago|
|README.md||1 year ago|
|back.pdf||1 year ago|
|cover.jpg||1 year ago|
|cover.pdf||1 year ago|
|cover.tif||1 year ago|
|eisvogel.tex||1 year ago|
|epub.css||1 year ago|
|flow.md||2 years ago|
|flow.svg||1 year ago|
|hackerspace-blueprint-booklet-cover.pdf||1 year ago|
|include-back.tex||1 year ago|
|include-cover.tex||2 years ago|
|pandoc-metadata.yaml||1 year ago|
A hackerspace is a physical place, run by people interested in various aspects of constructive & creative hacking. From finding ways to make your beer cold in a matter of seconds to building a do-it-yourself sms-voting-system with an old android phone.
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 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 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. An epub version is also available for e-readers.
We have been refining this system for many years, 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 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. Moreover, we continuously update this system to make it better. That is why the hackerspace blueprint is on GitHub. 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.
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 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.
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 “wardens” and “counselors” of the space. Unlike many other organizations, the board has no power over what the space should do.
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.