Merlijn Sebrechts
GitHub
commit
7d3a82aa5d
31
README.md
31
README.md
|
|
@ -4,36 +4,27 @@ 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 failed, but we try again
|
||||
|
||||
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 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 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.*
|
||||
|
||||
This is divided into 3 parts. Because [naming things is very hard](http://xkcd.com/910/) we decided to use the names from the ["Silo" series of Hugh Howey](http://en.wikipedia.org/wiki/Silo_%28series%29). The series follows the life of several people living in underground silo's in a post-apocalyptic society.
|
||||
This is divided into 3 parts.
|
||||
|
||||
### [1. The System](./system)
|
||||
|
||||
#### [1. The Order](https://github.com/0x20/HTH/tree/master/order)
|
||||
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.
|
||||
|
||||
*In the series, the order is a book that describes how the silos should be managed. The order is clearly "bad" because all control is an infringement to the freedom of the people. Still, if you progress further in the series, you see that the order is still a good way to manage the people.*
|
||||
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.
|
||||
|
||||
In the series, the order is used to control the people, and to limit their ability to progress. They want to keep the people dumb, so they're easy to manage. However, in our hackerspace, we want to do the exact opposite. Our order should empower people to get the best out of themselves. Our order should stimulate collaboration, and should 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.
|
||||
|
||||
#### [2. The Pact](https://github.com/0x20/HTH/tree/master/pact)
|
||||
|
||||
This is the Code of Conduct. This is intended to be a very broad enforced guideline of how members should behave.
|
||||
|
||||
*In the series, the pact is "The law".*
|
||||
|
||||
Unlike in the series, our pact will be made by the group, and enforced by the group. The group can change the pact as they see fit.
|
||||
|
||||
#### [3. The Legacy](https://github.com/0x20/HTH/tree/master/legacy)
|
||||
Because every good idea that was once written down has been misinterpreted, we included all the information that led us to the Order and the Pact in this repository as The Legacy. This should by used as a "cipher" to interpret these correctly and to explain a bit of the rationale behind them.
|
||||
|
||||
*In the series, the legacy is a collection of all the information that remains in the old world. It serves as a warning for the people questioning the order. The legacy is only available to a selected number of people, just like the order. The legacy does not include all of history, only certain parts chosen by the people who built the silo.*
|
||||
### [2. The Guidelines](./guidelines)
|
||||
|
||||
This is the Code of Conduct. This is intended to be a very broad guideline of how members should behave.
|
||||
|
||||
### [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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,105 @@
|
|||
# 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).
|
||||
|
||||
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.
|
||||
|
||||
So the need for guidelines arose, this is an attempt to define these rules.
|
||||
|
||||
These guidelines are a practical emanation the two basic rules:
|
||||
|
||||
* Use common sense
|
||||
* Be excellent to each other
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
* 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.
|
||||
* The Group decides what happens to the end result of the project.
|
||||
|
||||
## 2 Property and tools
|
||||
|
||||
### 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.
|
||||
|
||||
If you break personal property of another member, you have to fully reimburse the member's losses.
|
||||
|
||||
All personal property that is not in a members box has to be labeled (including tools and machines).
|
||||
|
||||
### 2.2 Space Property
|
||||
|
||||
#### 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
|
||||
* 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 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
|
||||
|
||||
##### Space property that requires you to follow a workshop before use
|
||||
|
||||
* ~~3D printer~~ (Broken: if you can fix it, you're the new expert!)
|
||||
* Table saw
|
||||
|
||||
#### 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
|
||||
|
||||
Only members are allowed to take space property out of the space. If you takes space property out of the space, you have to notice 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
|
||||
|
||||
### 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* When in doubt if you're doing the right thing, you probably aren't.
|
||||
* Just try not to be *that* guy.
|
||||
|
||||
### 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.
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
* Don't congest the network with (legal) torrenting, just behave nicely, so we don't have to write an AUP.
|
||||
|
|
@ -0,0 +1,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.
|
||||
|
||||
* [**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.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Disclaimer #
|
||||
|
||||
We do not own this content or it's copyright. The original article is hosted on http://phrack.org/papers/fall_of_groups.html
|
||||
We do not own this content or its copyright. The original article is hosted on http://phrack.org/papers/fall_of_groups.html
|
||||
|
||||
# Article #
|
||||
|
||||
|
|
@ -235,11 +235,11 @@ they shift around over time (and will continue shifting).
|
|||
The author describes the shifting, at least for hacker groups, as the focus
|
||||
has changed from group to solo.
|
||||
|
||||
The author makes a difference between collaboration (many, many successful
|
||||
The author makes a difference between collaboration (many, many successful
|
||||
open-source projects) and collectives.
|
||||
Are we as a hackerspace a collective, working together to achieve a common
|
||||
Are we as a hackerspace a collective, working together to achieve a common
|
||||
objective, to have an impact?
|
||||
Or are we more a collaboration with the sole goal of having a shared roof above
|
||||
Or are we more a collaboration with the sole goal of having a shared roof above
|
||||
our head with electricity + internet connection?
|
||||
|
||||
I think defining this can help us in allocating what roles and responsibilities at
|
||||
|
|
@ -250,7 +250,7 @@ Btw, tomorrow 'hack the hackerspace v0.3' workshop starts at 19u30!
|
|||
The setup is a circle of chairs instead of couches to aid active participation.
|
||||
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
|
||||
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/
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
# [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 how decisions are made in the space.
|
||||
|
||||
# [Do-ocracy](do-ocracy.md)
|
||||
|
||||
The definition and boundaries of the Do-ocracy
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Do-ocracy
|
||||
|
||||
## In short
|
||||
* If you want something done: **Just do it!**
|
||||
* Have you done something? **Great!, now tell others about it.** Tell them what you did, and why you did it. The mailing-list is a great place to do so. Telling other people about your actions lets them know who to thank and will give you more support.
|
||||
* If somebody complains: Either **revert it**, or work out a solution with the person who is complaining.
|
||||
|
||||
## Vision behind it
|
||||
|
||||
A do-ocracy is an organizational structure in which individuals choose to pick up roles and execute tasks by themselves, rather than getting them appointed by others.
|
||||
Responsibilities are attach to people who do the work, rather than to the elected/selected officials.
|
||||
Doing a task is in itself justification for you being the person who does that job.
|
||||
|
||||
Source: http://www.communitywiki.org/en/DoOcracy
|
||||
|
||||
# Boundaries
|
||||
|
||||
Some things are to sensitive to be handled by do-ocracy alone, like throwing things away. The Pact defines what the boundaries are of the Do-ocracy. Any member can request that a decision is discussed in the group.
|
||||
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
# Core group
|
||||
|
||||
*The core group exists to enable the hacker environment to exist. Apart from that, they should be indistinguishable from normal members.*
|
||||
|
||||
In the current legal structure (VZW) the board members carry the end-responsibility. So the core group can only contain the same people that are appointed board-member during the general assembly. This way the people taking the decision are also liable and vice-versa,
|
||||
no people can take decision without needing to take responsibility for it.
|
||||
|
||||
The core group is responsible for
|
||||
|
||||
* Finance
|
||||
* Core infrastructure (including safety of core infrastructure)
|
||||
* Extreme conflict between members such as harassment
|
||||
* Communication about these things with Group Of Members
|
||||
|
||||
This does not mean that the core group has to do everything themselves. They can "outsource" tasks to other people. However, the core group has to check if these tasks are done properly.
|
||||
|
||||
The core group can temporarily ban people from the space as a means of enforcing their responsibility. If they do that, however, they have to send a notice to all members, explaining what they did and why. In the next meeting, the problem has to be discussed so the group can decide upon a permanent solution.
|
||||
|
||||
In certain sensitive cases, like harassment and conflict between individual members, it is advised that the core group sits down with the concerning parties and tries to find a resolution. When a resolution is found, and it concerns the Group Of Members, the core group proposes the resolution to the Group Of Members. The Group Of Members then has to approve the proposal.
|
||||
|
||||
# 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 decision is required by the group. 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 Pact and the Order (in general assembly)
|
||||
- Solve problems when do-ocracy cannot fix them
|
||||
- Elect board, validate membership decisions made by the board.
|
||||
- Organize workshop, 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
|
||||
- To follow and enforce the [Pact](../pact/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 Pact. A non-member is not allowed to challenge a decision made by the group. Does the non-member disagree with a decision made by the group, then he/she should become a member and bring the topic forward on a meeting.
|
||||
105
pact/README.md
105
pact/README.md
|
|
@ -1,105 +0,0 @@
|
|||
# Pact Proposal
|
||||
|
||||
The pact == code of conduct.
|
||||
|
||||
**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](../order/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, different 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.
|
||||
|
||||
So the need for basic rules arose, this is an attempt to define these rules.
|
||||
|
||||
These basic rules are a practical emanation the two basic rules:
|
||||
* Use common sense
|
||||
* Be excellent to eachother
|
||||
|
||||
Members are encouraged to apply the two basic rules to the best of their abilities. *Be excellent to eachother* 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
|
||||
|
||||
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.
|
||||
- You decide what happens to the end-result of the project
|
||||
|
||||
**Space**
|
||||
- Decisions goes through the [Flow](../order/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
|
||||
|
||||
## 2 Property and tools
|
||||
|
||||
### 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.
|
||||
|
||||
If you break personal property of another member, you have to fully reimburse the member's losses.
|
||||
|
||||
All personal property that is not in a members box has to be labeled (including tools and machines).
|
||||
|
||||
### 2.2 Space Property
|
||||
|
||||
#### 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
|
||||
* 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 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
|
||||
|
||||
**Space property that requires you to follow a workshop before use**
|
||||
|
||||
* ~~3D printer~~ (Broken: if you can fix it, you're the new expert!)
|
||||
* Table-saw
|
||||
|
||||
#### 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
|
||||
|
||||
Only members are allowed to take space property out of the space. If you takes space property out of the space, you have to notice 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
|
||||
|
||||
### 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 an good upstanding member of the community you should attend one of these at least once quarterly. Lots of hands make light work.
|
||||
|
||||
### 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
|
||||
|
||||
* 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
|
||||
|
||||
* When in doubt if you're doing the right thing, you probably aren't.
|
||||
* Just try not to be *that* guy.
|
||||
|
||||
### 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 a headphone or keep the volume low.
|
||||
* Don't be afraid to ask if you are not intruding/disturbing.
|
||||
* Some moments are more 'loud' 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
|
||||
|
||||
* Just leave other peoples 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.
|
||||
* Don't congest the network with (legal) torrenting, just behave nicely, so we don't have to write an aup.
|
||||
|
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 29 KiB |
|
|
@ -0,0 +1,19 @@
|
|||
# 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.
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
# 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.
|
||||
|
||||
Specifically, the board has two roles, and for everything that doesn't fall into these roles, the board members are regarded as regular members.
|
||||
|
||||
1. *Warden of the physical core infrastructure of the space.* This stems from [the infrastructure pattern](https://wiki.hackerspaces.org/The_Infrastructure_Pattern). Provide a room with power, internet, a bar and [a kitchen](https://wiki.hackerspaces.org/The_Kitchen_Pattern) and the hackers will come. An important aspect of this is keeping a good relationship with the surroundings as said in [the landlord and neighbourhood pattern](https://wiki.hackerspaces.org/The_Landlord_and_Neighbourhood_Pattern).
|
||||
2. *Counselor for the people in the space.* When conflict happens that can't be resolved in the group, the board is responsible for resolving the conflict. A great way to do this is [the private talk pattern](https://wiki.hackerspaces.org/The_Private_Talk_Pattern): go talk to the involved parties in private, listen to the person and let them know how the group feels.
|
||||
|
||||
It's important for the board to communicate openly about what they do.
|
||||
|
||||
Both jobs are critically important to the space. Many hackerspaces disbanded because they were kicked out by their landlord and many hackerspaces fell apart because of internal conflict. It is important to get the right people in the board. **This is why the board has very little power and only in exceptional circumstances: so it doesn't attract people who want to be in power.**
|
||||
|
||||
## Why is there a board?
|
||||
|
||||
There are two reasons why Hackerspace Ghent has a board:
|
||||
|
||||
- A Belgian non-profit organization (VZW) requires a board which is legally liable in case something goes wrong. In the past, we had a board on paper, but the space was completely run by consensus. This caused a bunch of issues since the board was legally liable, but it didn't actually have any power to prevent bad things from happening.
|
||||
- People don't like conflict and confrontation. If nobody speaks up and nobody actively tries to resolve conflicts, people just ignore it until it explodes, taking down half the space with it. Hackerspace Ghent almost disbanded after such an explosion and we vowed to never have it again. Thus, the board is responsible for speaking up and fixing conflicts, even if that is really uncomfortable.
|
||||
|
||||
## What power does the board have?
|
||||
|
||||
The board can temporarily ban people from the space if they think it's necessary for resolving conflict and protecting the space. If they do that, they need to let the members know who is banned and why. In the next meeting, the problem has to be discussed so the members can decide on a permanent solution.
|
||||
|
||||
## When should I talk to the board?
|
||||
|
||||
When there's a fire, you call the fire department to come help you. When you want to light a huge 50 meter bonfire, you check with the fire department to see if they think it's safe.
|
||||
|
||||
The same applies to the board, talk to them when there is a big issue and check with them when you do something that's part of their role (warden and counselor).
|
||||
|
||||
Here are some examples of when you should check with the board before you do it.
|
||||
|
||||
- If you're spending space money.
|
||||
- If you want to make changes to membership fees, the bar, the space shop, ...
|
||||
- If you want to make changes to the electricity, and internet.
|
||||
- If you want to make changes to the space building that affect fire safety, electrical safety, structural integrity or changes that would make the building collapse.
|
||||
|
||||
This isn't necesarily 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.
|
||||
|
||||
## Who should be in the board?
|
||||
|
||||
The board does not have any say about what other members are to do, and you want people in the board that like/keep it that way.
|
||||
|
||||
- The "warden" role requires people who are responsible and dependable. The kind of people who say "maybe that's not such a good idea, we might get thrown out if we do that".
|
||||
- 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.
|
||||
|
|
@ -2,12 +2,15 @@
|
|||
|
||||
For each layer there is a specific decision making model. This page describes them.
|
||||
|
||||
## Core Group
|
||||
## 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 |
|
||||
|
|
@ -17,39 +20,48 @@ Below outlines the decision making model to be used by this group.
|
|||
| 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 benefits the hackerspace:
|
||||
* encourages discussion
|
||||
* forced to listen to apposing ideas that can give new insights
|
||||
* they can bring smarter compromises
|
||||
* http://en.wikipedia.org/wiki/Consensus
|
||||
### 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 make 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 below point system will be used to reach a decision.
|
||||
### 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.
|
||||
|
||||
|
||||
* 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 he can distribute between the different options.
|
||||
|
||||
* 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
|
||||
|
||||
|
|
@ -87,5 +99,5 @@ However, extreme ideas will not be able to "win". With extreme ideas, the outcom
|
|||
|
||||
## Individual
|
||||
|
||||
* Every individual has his/her own responsibility's as a member of the group, and thus requires his/her own decision model.
|
||||
* 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.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
# Do-ocracy
|
||||
|
||||
## In short
|
||||
|
||||
* If you want something done: **Just do it!**
|
||||
* Have you done something? **Great!, now tell others about it.** Tell them what you did, and why you did it. The mailing-list is a great place to do so. Telling other people about your actions lets them know who to thank and will give you more support.
|
||||
* If somebody complains: Either **revert it**, or work out a solution with the person who is complaining.
|
||||
|
||||
## Vision behind it
|
||||
|
||||
A do-ocracy is an organizational structure in which individuals choose to pick up roles and execute tasks by themselves, rather than getting them appointed by others.
|
||||
Responsibilities are attach to people who do the work, rather than to the elected/selected officials.
|
||||
Doing a task is in itself justification for you being the person who does that job.
|
||||
|
||||
Source: http://www.communitywiki.org/en/DoOcracy
|
||||
|
||||
## Boundaries
|
||||
|
||||
Some things are to sensitive to be handled by do-ocracy alone, like throwing things away. The guidelines defines what the boundaries are of the Do-ocracy. Any member can request that a decision is discussed in the group.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
# The flow
|
||||
|
||||
|
||||
|
||||
To edit the diagrams please use [draw.io](https://www.draw.io/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fqwaxys%2FHTH%2Fmaster%2Forder%2FHTH-flow.svg). After editing export as SVG and select "Include a copy of my diagram".
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
# 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.
|
||||
Loading…
Reference in New Issue