Merge pull request #12 from galgalesh/pandoc

book+website, updated meeting and statutes explanation

.gitignore

@@ -0,0 +1,4 @@
+hack-the-hackerspace*.pdf
+hack-the-hackerspace*.html
+test*.pdf
+test*.tex

2-do-ocracy.md

@@ -1,4 +1,4 @@
-# Do-ocracy
+# 2. Do-ocracy
 
 ## In short
 
@@ -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.

3-meetings.md

@@ -0,0 +1,151 @@
+# 3. Meetings
+
+## What should I discuss on a meeting?
+
+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.**
+
+Things you should discuss on a meeting:
+
+* 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.
+
+Things you can discuss on a meeting:
+
+* 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.
+
+## How do I schedule 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 main channel and put a link in the changelog.
+
+## 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 enjoyable, 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
+* they can bring smarter compromises
+* 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.
+
+### 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.
+
+### Point system
+
+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.
+
+**The point system has a few basic rules:**
+
+* Each voter has a certain number of points that he can distribute over the different proposals.
+* The proposal with the most points wins.
+* In case of tie; revote.
+* **Number of points per voter  =** `(#_of_options * 2 ) + 1`
+* Results should be given to the group in binary format: what proposal won and what lost. This is to strengthen the support of the decision.
+
+"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:
+
+* The outcome is not always clear because balanced ideas can still win, even if the minority would vote for them.
+* The minority will gain from convincing the majority that their idea is not completely ridiculous.
+* People have the ability to vote for, and thereby support, multiple ideas.
+
+In the point system, every voter gets some points that they can distribute between the different options.
+
+#### Examples
+
+| 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             |
+
+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.

4-the-board.md

@@ -1,4 +1,4 @@
-# The board
+# 4. The Board
 
 The board exists to make sure the hacker environment survives. The board members are not the leaders of the space, they are the firemen of the space. They make sure the physical space stays available and the members keep loving each other. Apart from that, the board members should be *indistinguishable* from normal members. The board members don't have any more say over the direction of the space or the projects in the space than any other member.
 
@@ -37,7 +37,7 @@ Here are some examples of when you should check with the board before you do it.
 
 This isn't necessarily to get their approval, more to give them a chance to stop you if they think it's a bad idea. *Note: If something has been decided on a meeting with the board present, you can assume the board doesn't have any objections to it, and you can just do it.*
 
-Moreover, if people are abusing the space, people in the space, or you, then it's best to inform the board. You're free to ask help from anyone you feel comfortable with, but it's best to also inform a board member to prevent so that they can intervene help when someone harasses multiple people in private.
+Moreover, if people are abusing the space, people in the space, or you, then it's best to inform the board. You're free to ask help from anyone you feel comfortable with, but it's best to also inform a board member so that they can intervene when someone harasses multiple people in private.
 
 ## Who should be in the board?
 
@@ -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.

5-membership.md

@@ -0,0 +1,35 @@
+# 5. Membership
+
+## How do I become a member?
+
+1. Come to the space a few times so people get to know you.
+2. Fill in a membership form and get two people to sign as sponsors. They will be responsible for making sure you get settled nicely, and they will be responsible for making sure that you understand how the hackerspace works, and how you can be a part of it.
+3. Put your membership application on the agenda for the next meeting. *During that meeting you will have a chance to explain who you are, and why you want to become a member. After this, the other members will decide on your membership by asking if anyone objects. Did no-one object? Congrats! You are now a member!*
+4. Create an automatic bank transfer to transfer the membership fee each month.
+
+## What are the responsibilities of a member?
+
+*The members create and maintain the hacker environment.*
+
+When a conflict/problem can not be resolved between individuals/via do-ocracy or when it impacts the group, a group decision is required. Any member can request that a decision is made by the Group Of Members instead of by do-ocracy/individual members.
+
+The members should do the following things as a group.
+
+- Creating and patching Hack the Hackerspace.
+- Solve problems in the hackerspace when do-ocracy cannot fix them.
+- Electing the board during a General Assembly.
+
+*The individuals have to be excellent.*
+
+- Organize workshops, events, lectures.
+- Follow do-ocracy.
+- Actively try to fix problems.
+- Maintain personal safety and that of others.
+- Follow and enforce the Guidelines.
+
+## Non-members
+
+Non-members are also an important part of the space. They can contribute to the hacker environment and they can be potential members. However, non-members have less privileges than members.
+
+- Non-members are only allowed in the space when they are in company of a member. That member is responsible for the actions of the non-member.
+- Non-members have to follow the guidelines. A non-member is not allowed to challenge a decision made by the group. If the non-member disagree with a decision made by the group, then they should become a member and bring the topic forward on a meeting.

6-guidelines.md

@@ -1,7 +1,6 @@
-# Guidelines
+# 6. Guidelines
 
-**Note:** For now the goal of this page is to collect ideas that YOU think should be part of the
-code of conduct for the space. Each of the points will be agreed upon using [group decision model](../system/decision.md#members-group).
+**Note:** For now the goal of this page is to collect ideas that YOU think should be part of the guidelines for the space.
 
 Basically we've come the observation that "*use common sense*" and "*be excellent*" don't always suffice as a *code of conduct*. This is because different people have different realities, values and morals. We think this diversity is a good thing. However in a communal context where these realities clash with each other it creates friction and conflict.
 
@@ -14,25 +13,25 @@ These guidelines are a practical emanation the two basic rules:
 
 Members are encouraged to apply the two basic rules to the best of their abilities. *Be excellent to each other* implies treating others the way you want to be treated, which is considered by almost all moral systems as [the golden rule](http://en.wikipedia.org/wiki/Golden_Rule).
 
-## 1 Projects
+## 6.1 Projects
 
 There is a clear distinction between Personal vs Space projects.
 
 ### Personal
 
 * You have full control over what happens to the project.
-* The property of the project is considered personal property and 2.1 applies to it.
+* The property of the project is considered personal property and 6.2.1 applies to it.
 * You decide what happens to the end-result of the project.
 
 ### Space
 
-* Decisions go through the [Flow](../system/flow.md).
-* The property of the project is considered space property and 2.2 applies to it.
+* Decisions go through the [Flow](flow.md).
+* The property of the project is considered space property and 6.2.2 applies to it.
 * The Group decides what happens to the end result of the project.
 
-## 2 Property and tools
+## 6.2 Property and tools
 
-### 2.1 Personal Property
+### 6.2.1 Personal Property
 
 Only members are allowed to have personal property in the space. You get one box where you can leave your stuff. If you need more space for your projects, bring it up in a group meeting.
 
@@ -40,15 +39,15 @@ If you break personal property of another member, you have to fully reimburse th
 
 All personal property that is not in a members box has to be labeled (including tools and machines).
 
-### 2.2 Space Property
+### 6.2.2 Space Property
 
-#### 2.2.1 Using space property
+#### 6.2.2.1 Using space property
 
 * When you are using tools/infrastructure from the space, you are effectively borrowing that item from the community.
 * Return borrowed items promptly in the same or better condition than when borrowed.
-* If you borrow it, return it. If you damage or lose it: follow 2.2.2.
+* If you borrow it, return it. If you damage or lose it: follow 6.2.2.2.
 * So when using something, clean it afterwards and put it back in it's place.
-* If you  are not trained to use tool $FOO, don't use tool $FOO but ask an expert to teach you first.
+* If you  are not trained to use tool X, don't use tool X but ask an expert to teach you first.
 * If you use one of the public workstations, please shut it off when you are done.
 * if you use the printer, please deposit some cash to pay for consumables
 
@@ -57,49 +56,49 @@ All personal property that is not in a members box has to be labeled (including
 * ~~3D printer~~ (Broken: if you can fix it, you're the new expert!)
 * Table saw
 
-#### 2.2.2 Damaging or losing space property
+#### 6.2.2.2 Damaging or losing space property
 
 If you damage or lose space property, you have to notice the Group Of Members immediately via the mailing-list. In the mail, you say what happened and if/how you will fix it. If the Group Of Members do not agree to this, they will have to put it forward on the next meeting.
 
-#### 2.2.3 Taking space property out of the space
+#### 6.2.2.3 Taking space property out of the space
 
 Only members are allowed to take space property out of the space. If you take space property out of the space, you have to notify the Group Of Members immediately via the mailing-list. In the mail, you have to include when you'll return it. If any other member disagrees, you put it back.
 
-## 3 Space maintenance
+## 6.3 Space maintenance
 
-### 3.1 Cleaning
+### 6.3.1 Cleaning
 
 * Keep the dishes clean: when using the dishes, clean your dishes and any dishes that are standing there. When you see other people using the dishes, and they forget cleaning them, give them a gentle reminder.
 * Keep the desks clean, feel free to use the deskspace for your stuff, you can leave your stuff on the desk when you just 'pop out for some food', but leave a note stating when you'll be back. _Do Not_ leave it there until the next morning.
 * Remove empty packaging, from food or beverages.
 * Every once in a while there will be a cleaning day in the space, as a good upstanding member of the community you should attend one of these at least once quarterly. Many hands make light work.
 
-### 3.2 Exit space
+### 6.3.2 Exit space
 
 * If you are the last person to leave the space, it's your responsibility to clean up. If you see people leaving, please alert them if they have left their trash in the space.
 * Switch off all power consuming things
 * Close the roof
 * Read and follow the checklist at the door.
 
-### 3.3 Throwing things away
+### 6.3.3 Throwing things away
 
 * Some things that seem a useless waste of space to you, might be very valuable to other people. When you throw things away, it has to be decided upon by the group, via the decision model of the group.
 
-## 4 Social behavior
+## 6.4 Social behavior
 
 * When in doubt if you're doing the right thing, you probably aren't.
 * Just try not to be *that* guy.
 
-### 4.1 Noise
+### 6.4.1 Noise
 
 People are trying to concentrate in here so:
 
 * Mind your voice, volume. If you are talking to someone on the other side of the space, everyone in between can hear you; move closer.
-* We know you like $FOO music, but use headphones or keep the volume low.
+* We know you like X music, but use headphones or keep the volume low.
 * Don't be afraid to ask if you are not intruding/disturbing.
 * Some moments are 'louder' than others, so it's not always easy to follow. Sometimes library/office-rules apply, sometimes workshop-rules and sometimes bar-rules. When in doubt, check with the other members.
 
-### 4.2 Network/security
+### 6.4.2 Network/security
 
 * Just leave other people's stuff alone, don't post "*funny*" social network status updates on unattended logged in computers.
 * Don't sniff the network / no ssl-strip /  rogue dhcp / random script-kiddo stuff. It been done before, it's lame.

7-the-legacy.md

@@ -0,0 +1,11 @@
+# 7. The Legacy
+
+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, discussions and comments on them 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) makes the claim that it is becoming rare for creativity to arise from groups or teams. Even though the technological advances should make it easier to create and maintain hacker groups, they are becoming increasingly rare. The author poses the theory that this is because the same technological revolution bombards us with a constant flow of information and fear, and because we dread the thought of being alike, of sharing multiple views and opinions. As such, we are turning progressively judgmental of who we should be partnering with, on the basis that "they do not understand".
+
+* [**The tyranny of structurelessness**](http://www.jofreeman.com/joreen/tyranny.htm) is an essay by American feminist Jo Freeman inspired by her experiences in a 1960s women's liberation group that concerns power relations within radical feminist collectives. The essay looks back on the experiments of the feminist movement in creating organizations that do not have any structure or leadership. Jo Freeman states that leadership and structure did actually exist in these organizations but its existence was denied. This made it hard to hold the leadership accountable for their actions and made it hard for newcomers to figure out how the organization worked. As a solution, Freeman suggests formalizing the existing hierarchies in the group and subjecting them to democratic control.
+
+* [**Dealing with disrespect**](http://dealingwithdisrespect.com/jonobacon-dealingwithdisrespect-1ed.pdf) by the legendary Ubuntu Linux community manager "Jono Bacon" explaining that "Most people are good people". "This book is about helping us to focus on good people creating good things, to preserve that spirit of sharing, and to protect against those whose primary contribution is obstruction and disrespect."

CONTRIBUTING.md

@@ -0,0 +1,15 @@
+# Contributing to Hack the Hackerspace
+
+## Building Hack the Hackerspace
+
+First install the build tools.
+
+```bash
+sudo apt install pandoc
+```
+
+Generate the print version using `pandoc`.
+
+```bash
+pandoc --toc pandoc-metadata.yaml README.md [0-9]*.md -o hack-the-hackerspace.pdf
+```

README.md

@@ -11,20 +11,18 @@ We created our very own Ghent hackerspace. We had two rules: be excellent to eac
 * 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.
 
-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 HTH. *This git repository contains the organizational structure of our hackerspace. This is intended to be place-agnostic information so it can be used by other hackerspaces around the world.*
+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 "Hack the Hackerspace" (HTH), a document that describes how to run a hackerspace in a way that brings out the best in people.
 
-This is divided into 3 parts.
+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!
 
-### [1. The System](./system)
+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, in order to make it easy to build Hack the Hackerspace as a community.
 
-This is a description of the system that will run our hackerspace. You will find the different decision processes and the different entities of the organization.
+# 1. Overview
 
-The system should empower people to get the best out of themselves. It should stimulate collaboration, and enable people to think creatively and to 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 will continuously patch this system to make it better. That is why this is on GitHub. So we can learn from our past mistakes and other people can stand on our shoulders to see further than anyone else.
+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.
 
-### [2. The Guidelines](./guidelines)
+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.
 
-This is the Code of Conduct. This is intended to be a very broad guideline of how members should behave.
+Every organisation 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.
 
-### [3. The Legacy](./legacy)
-
-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.
+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 Hack the Hackerspace, 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.

legacy/README.md

@@ -1,7 +0,0 @@
-# The Legacy
-
-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.
-
-* [**The fall of the hacker groups.**](The_Fall_of_Hacker_Groups)
-
-* [**The tyranny of structurelessness**](http://www.jofreeman.com/joreen/tyranny.htm) is an essay by American feminist Jo Freeman inspired by her experiences in a 1960s women's liberation group that concerns power relations within radical feminist collectives. The essay looks back on the experiments of the feminist movement in creating organizations that do not have any structure or leadership. Jo Freeman states that leadership and structure did actually exist in these organizations but its existence was denied. This made it hard to hold the leadership accountable for their actions and made it hard for newcomers to figure out how the organization worked. As a solution, Freeman suggests formalizing the existing hierarchies in the group and subjecting them to democratic control.

legacy/The_Fall_of_Hacker_Groups.md

@@ -1,9 +1,10 @@
-# Disclaimer #
+# The Fall of Hacker Groups - article and comments
 
 We do not own this content or its copyright. The original article is hosted on http://phrack.org/papers/fall_of_groups.html
 
-# Article #
+## Article
 
+```
 |=-----------------------------------------------------------------------=|
 |=--------------------=[ The Fall of Hacker Groups ]=--------------------=|
 |=-----------------------------------------------------------------------=|
@@ -178,14 +179,11 @@ times exhibitionist and needy.
 B) It is arguably the case, though, that the globalizing aspect of the
 Internet has brought the feeling of upsetting commonality to the citizens
 of even the more unpopulated places.
+```
 
+## Discussion
 
-
-
-
-# REPLIES #
-
-## Mimor ##
+### Mimor (April 2014)
 
 Indeed, interesting and relevant :)
 
@@ -213,9 +211,9 @@ But to get back to the point... :)
 I wonder whether there are still enough people that have it in them to
 withstand this crap and turn the space in a thriving creative environment.
 
-- - Mimor
+-Mimor
 
-## Merlin ##
+### Merlijn (April 2014)
 
 The observations made in the article are very true, and the "dangers" are very real. However, I think we have to be careful about what message we get from this.
 
@@ -225,7 +223,7 @@ Secondly, there is the question of what to do with this problem. The hacker cult
 
 We will not be able to change the people. At least not in the short run. What we can do is make a system that gets the best out of all these flawed people. A system that minimizes our flaws and enables us to be excellent.
 
-## Djef ##
+### Djef (April 2014)
 
 @Mimor the title is 'The Fall of Hacker Groups', a bit broader then hackerspaces
 but indeed the described trend can probably be seen broader.
@@ -252,10 +250,11 @@ http://0x20.be/Hack_the_hackerspace_v0.3
 
 On a positive note, I did the exercise of trying to think of active groups of the
 last couple of years that created an impact:
-console hacking https://fail0verflow.com/
-open whispersystems https://whispersystems.org/
-ccc - the impact of their conferences/camps is still growing http://events.ccc.de/
-iphone hacking http://blog.iphone-dev.org/
-free art and technology (f.a.t.) - http://fffff.at/
+
+* console hacking https://fail0verflow.com/
+* open whispersystems https://whispersystems.org/
+* ccc - the impact of their conferences/camps is still growing http://events.ccc.de/
+* iphone hacking http://blog.iphone-dev.org/
+* free art and technology (f.a.t.) - http://fffff.at/
 
 Somebody can add more to keep the inspiration going? :)

pandoc-metadata.yaml

@@ -0,0 +1,14 @@
+---
+#
+# This document contains some pandoc-specific metadata.
+#
+#
+# This is an inline yaml metadata code block that specifies custom headers and footers
+# using latex. Pandoc will probably be the only interpreter that does something useful with it.
+#   source: https://tex.stackexchange.com/questions/139139/adding-headers-and-footers-using-pandoc
+#
+header-includes: |
+    \usepackage{sectsty}
+    \sectionfont{\clearpage}
+links-as-notes: yes
+---

system/README.md

@@ -1,19 +0,0 @@
-# The System
-
-An explanation of the structure of the hackerspace.
-
-## [Roles](roles.md)
-
-Defines the roles of the different entities that are present in the space.
-
-## [Decision Making Model](decision.md)
-
-A description of the decision making models used in the different entities of the space.
-
-## [Work Flow](flow.md)
-
-The flow of how decisions are made in the space.
-
-## [Do-ocracy](do-ocracy.md)
-
-The definition and boundaries of the Do-ocracy.

system/decision.md

@@ -1,103 +0,0 @@
-# Decision making models
-
-For each layer there is a specific decision making model. This page describes them.
-
-## The board
-
-The decision making model can be decided at runtime by the current board. The board is supposed to be a group that is sync'ed so the decision making process should be a natural flow. The below is outlined as a backup in case a decision can not be made.
-
-* voting with a 2/3 majority.
-* therefore the board must consist of an uneven amount of members: 3, 5, 7, ...
-
-## Members group
-
-Below outlines the decision making model to be used by this group.
-
-| 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    |
-
-### week 0
-
-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.
-
-### week 1
-
-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:
-
-* encourages discussion
-* forced to listen to opposing ideas that can give new insights
-* they can bring smarter compromises
-* 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.
-
-### week 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.
-
-### week 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.
-
-### Point system
-
-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.
-
-**The point system has a few basic rules:**
-
-* Each voter has a certain number of points that he can distribute over the different proposals.
-* The proposal with the most points wins.
-* In case of tie; revote.
-* **Number of points per voter  =** `(#_of_options * 2 ) + 1`
-* Results should be given to the group in binary format: what proposal won and what lost. This is to strengthen the support of the decision.
-
-"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:
-
-* The outcome is not always clear because balanced ideas can still win, even if the minority would vote for them.
-* The minority will gain from convincing the majority that their idea is not completely ridiculous.
-* People have the ability to vote for, and thereby support, multiple ideas.
-
-In the point system, every voter gets some points that they can distribute between the different options.
-
-#### 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**   |
-
-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   |
-
-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.
-
-## Individual
-
-* Every individual has their own responsibilities as a member of the group, and thus requires their own decision model.
-* An individual is free to choose their own decision model, but keep in mind that you are part of a group.

system/roles.md

@@ -1,34 +0,0 @@
-# The Roles
-
-## The Board
-
-The role of the board is explained in detail in [the board document](board.md).
-
-## Group Of Members
-
-*The members make and maintain the hacker environment.*
-
-When a conflict/problem can not be resolved between individuals/via do-ocracy or when it impacts the group, a group decision is required.  Any member can request that a decision is made by the Group Of Members instead of by do-ocracy/individual members.
-
-They are responsible for
-
-- Creating and patching the guidelines and the system.
-- Solve problems when do-ocracy cannot fix them.
-- Elect board, validate membership decisions made by the board.
-- Organize workshops, events, lectures.
-
-## Individual members
-
-*The individuals have to be excellent.*
-
-- Follow [Do-ocracy](do-ocracy.md)
-- Actively try to fix problems
-- Maintain personal safety and that of others
-- Follow and enforce the [Guidelines](../guidelines/README.md).
-
-## Non-members
-
-Non-members are also an important part of the space. They can contribute to the hacker environment and they can be potential members. However, non-members have less privileges than members.
-
-- Non-members are only allowed in the space when they are in company of a member. That member is responsible for the actions of the non-member.
-- Non-members have to follow the guidelines. A non-member is not allowed to challenge a decision made by the group. If the non-member disagree with a decision made by the group, then they should become a member and bring the topic forward on a meeting.