divided into chapters

pull/12/head
Merlijn Sebrechts 2018-05-18 17:11:07 +02:00
parent 28967f46bd
commit c5126922de
10 changed files with 36 additions and 70 deletions

View File

@ -1,4 +1,4 @@
# Do-ocracy
# 2. Do-ocracy
## In short

View File

@ -1,17 +1,8 @@
# Decision making models
# 3. Meetings
For each layer there is a specific decision making model. This page describes them.
## The desicion making model
## 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.
Below outlines the decision making model to be used during meetings.
| PLAN/TIME | ACTION | VOTE |
| ------------------------------- |:------------------------------:| --------------:|
@ -96,8 +87,3 @@ As you can see in this example, a less-extreme proposal that, on first sight, ha
| 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.

View File

@ -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.

View File

@ -1,8 +1,4 @@
# The Roles
## The Board
The role of the board is explained in detail in [the board document](board.md).
# 5. Membership
## Group Of Members
@ -24,7 +20,7 @@ They are responsible for
- 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).
- Follow and enforce the [Guidelines](guidelines.md).
## Non-members

View File

@ -1,7 +1,7 @@
# Guidelines
# 5. 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).
code of conduct for the space. Each of the points will be agreed upon using [group decision model](decision.md#members-group).
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.
@ -26,7 +26,7 @@ There is a clear distinction between Personal vs Space projects.
### Space
* Decisions go through the [Flow](../system/flow.md).
* Decisions go through the [Flow](flow.md).
* The property of the project is considered space property and 2.2 applies to it.
* The Group decides what happens to the end result of the project.

View File

@ -1,7 +1,9 @@
# The Legacy
# 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 are archived in the `legacy` folder of the Hack the Hackerspace repository.
* [**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.

15
CONTRIBUTING.md 100644
View File

@ -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 -V links-as-notes README.md [0-9]*.md -o hack-the-hackerspace.pdf
```

View File

@ -11,36 +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!
### The 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. Introduction
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.
#### Roles
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.
Defines the roles of the different entities that are present in the space.
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.
#### Decision Making Model
A description of the decision making models used in the different entities of the space.
#### Work Flow
The flow of how decisions are made in the space.
#### Do-ocracy
The definition and boundaries of the Do-ocracy.
### The Guidelines
This is intended to be a very broad guideline of how members should behave.
### 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.
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.

View File

@ -1,15 +0,0 @@
\usepackage{pdfescape}
\makeatletter
\let\saved@hyper@linkurl\hyper@linkurl
\renewcommand*{\hyper@linkurl}[2]{%
\saved@hyper@linkurl{#1}{#2}%
\footnote{\protect\url{#1}}%
}
\let\href@original\href
\renewcommand*{\href}{\protect\href@original}
\makeatother

Binary file not shown.