Compare commits

..

No commits in common. "master" and "untagged-c0b8ebd636620737bed2" have entirely different histories.

35 changed files with 400 additions and 12243 deletions

6
.gitignore vendored
View File

@ -1,6 +1,4 @@
hackerspace-blueprint.epub
hackerspace-blueprint.pdf
hackerspace-blueprint-booklet-body.pdf
hackerspace-blueprint*.html
hack-the-hackerspace*.pdf
hack-the-hackerspace*.html
test*.pdf
test*.tex

View File

@ -1,28 +1,27 @@
language: r
addons:
apt:
packages:
- poppler-utils
install: tlmgr install mdframed mweights needspace sourcecodepro sourcesanspro collection-fontsextra pdfjam
script: |
# Generate epub
pandoc --verbose pandoc-metadata.yaml README.md [0-9]*.md -o hackerspace-blueprint.epub --metadata date="`date --iso-8601=date`" --toc-depth=2 --epub-embed-font='epub-fonts/*.ttf' --css=epub.css
# Generate PDF
pandoc --verbose pandoc-metadata.yaml README.md [0-9]*.md -o hackerspace-blueprint.pdf --metadata date="`date --iso-8601=date`" --template eisvogel.tex --include-before-body=include-cover.tex --include-after-body=include-back.tex
# Generate booklet
numpages=$(pdfinfo hackerspace-blueprint.pdf | awk '/^Pages/ { print $2}')
pdfbook hackerspace-blueprint.pdf 2-$(($numpages-2)) -o hackerspace-blueprint-booklet-body.pdf
language: R
# addons:
# apt:
# packages:
# - pandoc
# - texlive-xetex
# - texlive-plain-extra
# - texlive-generic-recommended
# - texlive-latex-recommended
# - texlive-latex-extra
# - texlive-fonts-recommended
# - texlive-fonts-extra
# - latex-xcolor
# - dvipng
# - lmodern
install: tlmgr install mdframed mweights needspace sourcecodepro sourcesanspro collection-fontsextra
script: pandoc --verbose pandoc-metadata.yaml README.md [0-9]*.md -o hack-the-hackerspace.pdf --template eisvogel.tex --toc --listings --metadata date="`date +%D`" --include-before-body=include-cover.tex
deploy:
provider: releases
api_key:
secure: cIRIKuDWejK79Kojh2URkQBmQcKDJtH/MmrzgCySQ7ArjbZ6/cPkS014QbNmUft4GiRGZzIiulfkkvLtdT4UVGVXEw7gTK/V5b6bEci6fst4rDPL/hCDeXcLutOxcOwb7vei38V5XhE+1D2UcFQFNJFkeo60WKWR9ybIQ7pAemo=
file:
- hackerspace-blueprint.epub
- hackerspace-blueprint.pdf
- hackerspace-blueprint-booklet-cover.pdf
- hackerspace-blueprint-booklet-body.pdf
file: hack-the-hackerspace.pdf
skip_cleanup: true
on:
repo: "0x20/hackerspace-blueprint"
repo: "0x20/HTH"
if:
tag IS blank
tag IS blank

View File

@ -3,56 +3,25 @@
## 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. A shared chat room or 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.
* 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.
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 and authority are attached 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.**
## Vision behind it
## Why not Democracy or Consensus?
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 attached 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.
Democracy and Consensus suffer from the same issue: everyone has an opinion about something, and most people like giving that opinion. In those systems, a lot of time and energy is put into debating what the best solution or the best compromise is. This results in a number of issues.
Source: http://www.communitywiki.org/en/DoOcracy
* It takes up a lot of time and energy that could be better spent actually doing stuff.
* It's very easy for problems to not get solved because the group doesn't agree on what the best solution is. This is a big issue because **a bad solution is often better than no solution.**
* It puts too much focus on the idea instead of its execution, even though research shows that the execution of a decision is often more important than the decision itself.
* Group decision making often leads to diluted outcomes, that contain elements of everyone's opinion but that nobody fully supports. As a result, people will be less enthusiastic about putting time and energy into actually doing the thing. This will eventually lead to worse outcomes because the impact of a well-executed good idea is a lot better than that of a badly-executed perfect idea.
* It rewards armchair critics and armchair activists. If the only thing you want to contribute is your opinion, you should not force other people to take that opinion into account.
* It encourages long feedback loops: because it takes a long time to make a decision, decisions need to be as perfect as possible. This is because it will take a long time to fix any issues. The fear of a bad decision will cause longer, more elaborate debate which increases the time it takes to make a decision. Modern software development practices such as Agile, Scrum and Kanban all stress the importance of having short feedback loops.
## How?
A do-ocracy naturally emerges when the environment is right. There are a number of important factors.
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.
* **Allow people to fail.** 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 berating 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.
* **Ask for help and help others.**
* **Trust each other.**
* **Focus on what you have in common instead of what you disagree on.**
* **Recognize and reward the people doing stuff.**
## Noncoercive authority
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.
> "Coercive power is the ability to influence someone's decision making by taking something away as punishment or threatening punishment if the person does not follow instructions."
Coercive power plays a big role in modern society. People do what their boss tells them because they're afraid of getting fired. People don't steal because they are afraid of punishment. It is so ingrained into our society that it's sometimes hard to realise that there are other ways to convince people to do something. However, you'll get a lot better results when people are convinced of what they do.
## Boundaries
It is a misconception that, in a do-ocracy, nobody is in charge or nobody has authority. The people doing stuff have authority over that project, although the power they have is non-coercive and they lose that power when they stop doing stuff.
> A do-ocratic example: 30 people are going to Burning Man and camping together. Mary asks, “What if we organize a food pool so we can all cook and eat together?” Others answer, “Sure, Id be a part of that,” or “I can make cake on Friday night.” Soon, Mary is calling campmates to borrow pots, pans and utensils, collating different peoples dietary restrictions, collecting money for food, and organizing trips to the store to buy supplies. At camp, she posts work signup sheets for cooking and cleanup, answers questions, and fills in when others cant (or dont) do their shifts.
A new campmate may grumble, “Jeez, why does Mary get to decide what everyone eats and when they work? Who put her in charge?" The answer is "the do-ocracy put her in charge". The very act of organizing the food pool puts her in charge of the food pool. She can't force you to eat the food or work a certain shift, but you have to respect her authority. This means that if you want to use the pots and pans for something different, or if you want to use the food money to order different food, you have to ask her first. However, if she disappears in the middle of the camp, leaving the food pool in disarray, she looses that authority and anyone else can step in.
## Limitations
Some things are too sensitive to be handled by do-ocracy alone, or are irreversible, like throwing things away. Refer to the Sections on the board, meetings and the guidelines for more information of when strict do-ocracy doesn't apply.
In general, if an action is irreversible, do-ocracy does not apply and you should discuss it with the larger group.
## A do-ocracy is not a ...
* **Democracy** - In a democracy, everyone has a say in what gets done. In a do-ocracy, everyone does jobs that they think need to be done, **without everyones input.**
* **Meritocracy** - In a meritocracy, the most qualified people for a job are selected for that job. In a do-ocracy, whoever does the job gets it, no matter how well theyre qualified.
## Further reading
* The CommunityWiki has [a thorough explanation of do-ocracy](http://www.communitywiki.org/en/DoOcracy).
* Embassy SF talked their experience with [do-ocracy in a shared house](https://medium.com/embassy-network/an-evolving-doocracy-3a6123f9b170).
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.

View File

@ -2,13 +2,13 @@
## 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.**
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 is hard to reverse when people complain.
* 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:
@ -21,25 +21,21 @@ Things you can discuss on a meeting:
Any member can schedule a meeting.
1. Create a pad for the meeting topics and the meeting notes. Use the pad of the previous meeting to see what it should look like.
1. Pick a date (preferably not during the social evening).
1. Announce the meeting in the Main channel and in the Changelog **at least a week in advance**. The announcement should include:
* The url to the pad for that meeting
* The date of the meeting in ISO 8601 format (2021-11-14) and the time of the meeting in 24-hour format local time (20:00).
Important and possibly controversial topics such as membership applications need to be on the pad at least a week in advance. **If you add such a topic after the meeting is announced, you need to add a new entry to the Changelog.**
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 this 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.
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 people 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.
[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://bikeshed.com/): 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.
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
@ -55,8 +51,8 @@ The statutes dictate the following.
You can find the latest version of the statutes in the Government gazette (staatsblad) (Dutch-language).
1. Go to <http://www.ejustice.just.fgov.be/tsv/tsvn.htm>
2. Fill in `0x20` in the "Naam" field and press the "Opzoeking" button. Now you should see a number next to the "Naam" field, this is how many search results there are, press "Lijst" to see them. *"0x20" is the short name for "Hackerspace Gent", previously "Whitespace".*
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.
@ -68,33 +64,33 @@ More important information from the statutes.
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 before the first meeting. During the first meeting, a decision needs 100% consensus. If no decision is made, a second meeting is scheduled 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 scheduled where a decision is made using the "point system", an over-complicated system where a decision will always be made.
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 scheduled 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 scheduled where a decision is made using the "point system", an over-complicated system where a decision will always be made.
| PLAN/TIME | ACTION | DECISION |
| ------------------------------------- |:-----------------------------------------------------------:| --------------:|
| Three or more days before the meeting | Put the topic on the agenda. | |
| 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 |
| 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 meeting and is announced on the Mattermost (chat) server. This needs to be at least 3 days in advance.
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 the group and requires a 100% consensus to reach a group decision. The motivation for striving for consensus is because it comes with characteristics that benefit the hackerspace:
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
* forces listening to opposing ideas that can give new insights
* can bring smarter compromises
* <https://en.wikipedia.org/wiki/Consensus>
* 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 completely because only the first meeting requires a full consensus. This means that the opposers need to use the time between the first and the second meeting to convince their fellow members of their viewpoint.
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 required 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.
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
@ -106,11 +102,11 @@ The point system is a **last-resort** option. This should not be the general pro
**The point system has a few basic rules:**
* Each voter has a certain number of points that they can distribute over the different proposals.
* 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; re-vote.
* **Number of points per voter =** `(#_of_proposals * 2 ) + 1`
* Results should be given to the group in binary format: which proposal won and which lost. This is to strengthen the support of the decision.
* **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:
@ -136,7 +132,7 @@ In the point system, every voter gets some points that they can distribute betwe
| 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.
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 |
| -------------------------- |:------------------------------:| --------------:|
@ -146,7 +142,7 @@ As you can see in this example, a less extreme proposal that, on first sight, ha
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| A | 4 | 1 |
| B | 4 | 1 |
| B | 0 | 5 |
| B | 0 | 5 |
| B | 0 | 5 |

View File

@ -5,7 +5,7 @@ The board exists to make sure the hacker environment survives. The board members
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 neighborhood 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 them and let them know how the group feels.
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.
@ -13,10 +13,10 @@ Both jobs are critically important to the space. Many hackerspaces disbanded bec
## Why is there a board?
There are two reasons why Hackerspace Gent has 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 Gent 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.
- 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?
@ -46,7 +46,7 @@ The board does not have any say about what other members are to do, and you want
- 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 to 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.
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?

View File

@ -2,45 +2,34 @@
## How do I become a member?
1. Fill in [the membership application form](https://wiki.hackerspace.gent/Membership_form) and get two people to sign as sponsors. They will be responsible for making sure you get settled nicely, that you understand how the hackerspace works, and know how you can participate.
2. Announce your membership application on the Changelog. Include in the message who your sponsors are.
3. Attend a meeting and present your application. On this meeting you announce you want to become a member and who your sponsors are. If you want, you can talk a bit about why you're interested in the space. *Note: we won't discuss your membership further on this meeting and will not make any decision about it.*
4. On a next meeting, your membership will be decided upon. It's useful to have you present at that meeting, but this is not a requirement. As a bonus for coming to the meeting, membership is often the first thing to be decided on a meeting. When you get voted in, you can join the rest of the meeting as a member! Membership decisions at a meeting follow the same process as other meeting decisions. See Chapter 3 for more info.
5. Create an automatic bank transfer to transfer the membership fee each month. You will get your key after you made your first payment.
Why this process?
* Step #1 ensures that two people know and trust the applicant enough to vouch for them. It als ensures that the "culture" of the space gets transferred to new members.
* Step #2 ensures everyone knows you want to become a member.
* Step #3 ensures that the applicant understands how meetings are run and that there is some time between the applicant first arriving in the space and the applicant being voted in.
* Step #4 ensures that there is enough support for the applicant. The meeting decision model is used for the same reasons as to why it's used for meetings: a bad solution is better than no solution.
* Step #5 gives the new member an incentive to pay asap.
*Note: If you want more context, see the `HTH_2018-11-17_membership.md` document in "the legacy" for more discussion on the membership procedure.*
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 on a meeting instead of by do-ocracy or individual members.
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.
* Create and patch the hackerspace blueprint.
* Solve problems in the hackerspace when do-ocracy cannot fix them.
* Electing the board during a General Assembly.
- 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.
- 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.
- 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.

View File

@ -1,103 +1,105 @@
# 6. Guidelines
The hackerspace is a shared resource created *by* the community, *for* the community. It only exists because people think it's valuable enough to nourish it. Without the community, the hackerspace would simply not exist, so it is very important that we as a community collaborate and keep it fun for everyone.
**Note:** For now the goal of this page is to collect ideas that YOU think should be part of the guidelines for the space.
We want you to be a part of it, but you need to do three things.
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.
* Use common sense,
* be excellent to others,
* and don't be an asshole.
So the need for guidelines arose, this is an attempt to define these rules.
People have different realities, values and morals, resulting in different ideas for how to do these three things. To get around these differing realities use empathy, not cunning. Continuously convincing others to see things your way will get you what you want in the short run but can breed resentment in the long run. Going out of your way to understand and to accommodate the other person's point of view strengthens the community itself. The guidelines below describe what the hackerspace thinks it means to use common sense, be excellent to others, and not be an asshole.
These guidelines are a practical emanation the two basic rules:
First and foremost, [the golden rule](http://en.wikipedia.org/wiki/Golden_Rule): treat others the way you want to be treated.
* Use common sense
* Be excellent to each other
## Loopholes
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).
The goal of the do-ocracy and these guidelines is to create an awesome community. The do-ocracy gives you a lot of freedom, but you need to use it wisely. People who try to exploit loopholes in this system to do things that damage the community cannot handle the freedom of a do-ocracy and will be pushed out very quickly. Do not read these guidelines like a lawbook, but read it like a cookbook. It doesn't matter if you use a bit more sugar than the recipe says, as long as your goal is to make the cake better.
## 6.1 Projects
## Projects
There is a clear distinction between Personal vs Space projects.
There is a clear distinction between "personal" and "space" projects. Keep this in mind so you know what to expect and what people can expect of you.
### Personal
### Personal projects
* You have full control over how to do the project.
* The project stuff/material is considered your personal property.
* You have full control over what happens to the project.
* 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 projects
### Space
* The do-ocracy decides how to do the project.
* The project stuff/material is considered space property.
* The do-ocracy decides what happens to the end result of the project.
* 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.
## Property and tools
## 6.2 Property and tools
### Personal property
### 6.2.1 Personal Property
* Only members are allowed to have personal property in the space. You get one box (the membership 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).
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.
### Space property
If you break personal property of another member, you have to fully reimburse the member's losses.
#### Using space property
All personal property that is not in a members box has to be labeled (including tools and machines).
### 6.2.2 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 as soon as possible in the same or better condition than when borrowed.
* So when using something, clean it afterwards and put it back in its place.
* If you are not trained to use tool X, don't use tool X but ask an expert to teach you first.
* 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 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 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.
* if you use the printer, please deposit some cash to pay for consumables
#### Damaging or losing space property
##### Space property that requires you to follow a workshop before use
If you damage or lose space property, you have to notice the community immediately in the Changelog or Main channel on mattermost. Explain what happened and if/how you will fix it.
* ~~3D printer~~ (Broken: if you can fix it, you're the new expert!)
* Table saw
#### Taking space property out of the space
#### 6.2.2.2 Damaging or losing space property
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 community immediately, for example in the Changelog or Main channel on Mattermost. If someone disagrees with you taking it out of the space, make that person happy or put it back.
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.
## Space maintenance
#### 6.2.2.3 Taking space property out of the space
### Cleaning
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.
## 6.3 Space maintenance
### 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 desk space 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.
### 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.
### 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, you have to let the community know and give them enough time to object.
* 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.
## Social behavior
## 6.4 Social behavior
* When in doubt if you're doing the right thing, you probably aren't.
* Share your love and passion, but respect people's boundaries.
* Don't hack people without their explicit consent.
* Just try not to be *that* guy.
If you have any issues with other people's behavior, please notify the board. The board will help if you want, but even if you don't; still notify them so they know of the problem.
### 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 X music, but use headphones or keep the volume low.
* If you need to make a lot of noise, ask if you are not intruding/disturbing.
* 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.
### 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's been done before. It's lame.
* 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.

View File

@ -2,9 +2,9 @@
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 hackerspace blueprint repository](https://github.com/0x20/hackerspace-blueprint).
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**](http://phrack.org/issues/69/6.html) 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 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.

View File

@ -1,21 +1,15 @@
# Contributing to the hackerspace blueprint
# Contributing to Hack the Hackerspace
## Building the book
## Building Hack the Hackerspace
First install the build tools.
```bash
sudo apt install pandoc texlive-plain-generic texlive-latex-extra texlive-fonts-recommended texlive-fonts-extra texlive-extra-utils
sudo apt install pandoc texlive-plain-generic texlive-latex-extra texlive-fonts-recommended texlive-fonts-extra
```
Generate the print version using `pandoc`.
```bash
# Generate epub
pandoc --verbose pandoc-metadata.yaml README.md [0-9]*.md -o hackerspace-blueprint.epub --metadata date="`date +%D`" --toc-depth=2 --epub-embed-font='epub-fonts/*.ttf' --css=epub.css
# Generate PDF
pandoc --verbose pandoc-metadata.yaml README.md [0-9]*.md -o hackerspace-blueprint.pdf --metadata date="`date +%D`" --template eisvogel.tex --include-before-body=include-cover.tex --include-after-body=include-back.tex
# Generate booklet
numpages=$(pdfinfo hackerspace-blueprint.pdf | awk '/^Pages/ { print $2}')
pdfbook hackerspace-blueprint.pdf 2-$(($numpages-2)) -o hackerspace-blueprint-booklet-body.pdf
pandoc pandoc-metadata.yaml README.md [0-9]*.md -o hack-the-hackerspace.pdf --template eisvogel.tex --toc --listings --metadata date="`date +%D`" --include-before-body=include-cover.tex
```

View File

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 29 KiB

60
LICENSE
View File

@ -1,4 +1,4 @@
Attribution-ShareAlike 4.0 International
Attribution-NonCommercial-ShareAlike 4.0 International
=======================================================================
@ -33,7 +33,7 @@ exhaustive, and do not form part of our licenses.
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
@ -50,22 +50,22 @@ exhaustive, and do not form part of our licenses.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
Creative Commons Attribution-ShareAlike 4.0 International Public
License
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International
Public License
By exercising the Licensed Rights (defined below), You accept and agree
to be bound by the terms and conditions of this Creative Commons
Attribution-ShareAlike 4.0 International Public License ("Public
License"). To the extent this Public License may be interpreted as a
contract, You are granted the Licensed Rights in consideration of Your
acceptance of these terms and conditions, and the Licensor grants You
such rights in consideration of benefits the Licensor receives from
making the Licensed Material available under these terms and
conditions.
Attribution-NonCommercial-ShareAlike 4.0 International Public License
("Public License"). To the extent this Public License may be
interpreted as a contract, You are granted the Licensed Rights in
consideration of Your acceptance of these terms and conditions, and the
Licensor grants You such rights in consideration of benefits the
Licensor receives from making the Licensed Material available under
these terms and conditions.
Section 1 -- Definitions.
@ -84,7 +84,7 @@ Section 1 -- Definitions.
and Similar Rights in Your contributions to Adapted Material in
accordance with the terms and conditions of this Public License.
c. BY-SA Compatible License means a license listed at
c. BY-NC-SA Compatible License means a license listed at
creativecommons.org/compatiblelicenses, approved by Creative
Commons as essentially the equivalent of this Public License.
@ -108,7 +108,7 @@ Section 1 -- Definitions.
g. License Elements means the license attributes listed in the name
of a Creative Commons Public License. The License Elements of this
Public License are Attribution and ShareAlike.
Public License are Attribution, NonCommercial, and ShareAlike.
h. Licensed Material means the artistic or literary work, database,
or other material to which the Licensor applied this Public
@ -122,7 +122,15 @@ Section 1 -- Definitions.
j. Licensor means the individual(s) or entity(ies) granting rights
under this Public License.
k. Share means to provide material to the public by any means or
k. NonCommercial means not primarily intended for or directed towards
commercial advantage or monetary compensation. For purposes of
this Public License, the exchange of the Licensed Material for
other material subject to Copyright and Similar Rights by digital
file-sharing or similar means is NonCommercial provided there is
no payment of monetary compensation in connection with the
exchange.
l. Share means to provide material to the public by any means or
process that requires permission under the Licensed Rights, such
as reproduction, public display, public performance, distribution,
dissemination, communication, or importation, and to make material
@ -130,13 +138,13 @@ Section 1 -- Definitions.
public may access the material from a place and at a time
individually chosen by them.
l. Sui Generis Database Rights means rights other than copyright
m. Sui Generis Database Rights means rights other than copyright
resulting from Directive 96/9/EC of the European Parliament and of
the Council of 11 March 1996 on the legal protection of databases,
as amended and/or succeeded, as well as other essentially
equivalent rights anywhere in the world.
m. You means the individual or entity exercising the Licensed Rights
n. You means the individual or entity exercising the Licensed Rights
under this Public License. Your has a corresponding meaning.
@ -150,9 +158,10 @@ Section 2 -- Scope.
exercise the Licensed Rights in the Licensed Material to:
a. reproduce and Share the Licensed Material, in whole or
in part; and
in part, for NonCommercial purposes only; and
b. produce, reproduce, and Share Adapted Material.
b. produce, reproduce, and Share Adapted Material for
NonCommercial purposes only.
2. Exceptions and Limitations. For the avoidance of doubt, where
Exceptions and Limitations apply to Your use, this Public
@ -220,7 +229,9 @@ Section 2 -- Scope.
Rights, whether directly or through a collecting society
under any voluntary or waivable statutory or compulsory
licensing scheme. In all other cases the Licensor expressly
reserves any right to collect such royalties.
reserves any right to collect such royalties, including when
the Licensed Material is used other than for NonCommercial
purposes.
Section 3 -- License Conditions.
@ -265,7 +276,6 @@ following conditions.
reasonable to satisfy the conditions by providing a URI or
hyperlink to a resource that includes the required
information.
3. If requested by the Licensor, You must remove any of the
information required by Section 3(a)(1)(A) to the extent
reasonably practicable.
@ -277,7 +287,7 @@ following conditions.
1. The Adapter's License You apply must be a Creative Commons
license with the same License Elements, this version or
later, or a BY-SA Compatible License.
later, or a BY-NC-SA Compatible License.
2. You must include the text of, or the URI or hyperlink to, the
Adapter's License You apply. You may satisfy this condition
@ -297,14 +307,15 @@ apply to Your use of the Licensed Material:
a. for the avoidance of doubt, Section 2(a)(1) grants You the right
to extract, reuse, reproduce, and Share all or a substantial
portion of the contents of the database;
portion of the contents of the database for NonCommercial purposes
only;
b. if You include all or a substantial portion of the database
contents in a database in which You have Sui Generis Database
Rights, then the database in which You have Sui Generis Database
Rights (but not its individual contents) is Adapted Material,
including for purposes of Section 3(b); and
c. You must comply with the conditions in Section 3(a) if You Share
all or a substantial portion of the contents of the database.
@ -404,7 +415,6 @@ Section 8 -- Interpretation.
that apply to the Licensor or You, including from the legal
processes of any jurisdiction or authority.
=======================================================================
Creative Commons is not a party to its public

View File

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

3336
back.pdf

File diff suppressed because one or more lines are too long

BIN
cover.jpg

Binary file not shown.

Before

Width:  |  Height:  |  Size: 376 KiB

BIN
cover.pdf

Binary file not shown.

BIN
cover.tif

Binary file not shown.

View File

@ -1,130 +1,53 @@
%%
% Copyright (c) 2017 - 2019, Pascal Wagler;
% Copyright (c) 2014 - 2019, John MacFarlane
%
% Copyright (c) 2018, Pascal Wagler;
% Copyright (c) 2014--2018, John MacFarlane
%
% All rights reserved.
%
% Redistribution and use in source and binary forms, with or without
% modification, are permitted provided that the following conditions
%
% Redistribution and use in source and binary forms, with or without
% modification, are permitted provided that the following conditions
% are met:
%
% - Redistributions of source code must retain the above copyright
%
% - Redistributions of source code must retain the above copyright
% notice, this list of conditions and the following disclaimer.
%
% - Redistributions in binary form must reproduce the above copyright
% notice, this list of conditions and the following disclaimer in the
%
% - Redistributions in binary form must reproduce the above copyright
% notice, this list of conditions and the following disclaimer in the
% documentation and/or other materials provided with the distribution.
%
% - Neither the name of John MacFarlane nor the names of other
% contributors may be used to endorse or promote products derived
%
% - Neither the name of John MacFarlane nor the names of other
% contributors may be used to endorse or promote products derived
% from this software without specific prior written permission.
%
% THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
% "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
% LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
% FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
% COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
%
% THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
% "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
% LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
% FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
% COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
% INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
% BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
% LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
% CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
% ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
% BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
% LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
% CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
% ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
% POSSIBILITY OF SUCH DAMAGE.
%%
%%
% This is the Eisvogel pandoc LaTeX template.
%
% For usage information and examples visit the official GitHub page:
% For usage information and examples visit the GitHub page of this template:
% https://github.com/Wandmalfarbe/pandoc-latex-template
%%
% Options for packages loaded elsewhere
\PassOptionsToPackage{unicode$for(hyperrefoptions)$,$hyperrefoptions$$endfor$}{hyperref}
\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
\PassOptionsToPackage{dvipsnames,svgnames*,x11names*,table}{xcolor}
$if(dir)$
$if(latex-dir-rtl)$
\PassOptionsToPackage{RTLdocument}{bidi}
$endif$
$endif$
\PassOptionsToPackage{svgnames*,table}{xcolor}
%
\documentclass[
$if(fontsize)$
$fontsize$,
$endif$
$if(lang)$
$babel-lang$,
$endif$
$if(papersize)$
$papersize$paper,
$else$
a4paper,
$endif$
\documentclass[$if(fontsize)$$fontsize$,$endif$$if(lang)$$babel-lang$,$endif$$if(papersize)$$papersize$paper,$else$a4paper,$endif$$if(beamer)$ignorenonframetext,$if(handout)$handout,$endif$$if(aspectratio)$aspectratio=$aspectratio$,$endif$$endif$$for(classoption)$$classoption$$sep$,$endfor$,tablecaptionabove]{scrartcl}
$if(beamer)$
ignorenonframetext,
$if(handout)$
handout,
$endif$
$if(aspectratio)$
aspectratio=$aspectratio$,
$endif$
$endif$
$for(classoption)$
$classoption$$sep$,
$endfor$
,tablecaptionabove
]{$if(book)$scrbook$else$scrartcl$endif$}
$if(beamer)$
$if(background-image)$
\usebackgroundtemplate{%
\includegraphics[width=\paperwidth]{$background-image$}%
}
$endif$
\usepackage{pgfpages}
\setbeamertemplate{caption}[numbered]
\setbeamertemplate{caption label separator}{: }
\setbeamercolor{caption name}{fg=normal text.fg}
\beamertemplatenavigationsymbols$if(navigation)$$navigation$$else$empty$endif$
$for(beameroption)$
\setbeameroption{$beameroption$}
$endfor$
% Prevent slide breaks in the middle of a paragraph
\widowpenalties 1 10000
\raggedbottom
$if(section-titles)$
\setbeamertemplate{part page}{
\centering
\begin{beamercolorbox}[sep=16pt,center]{part title}
\usebeamerfont{part title}\insertpart\par
\end{beamercolorbox}
}
\setbeamertemplate{section page}{
\centering
\begin{beamercolorbox}[sep=12pt,center]{part title}
\usebeamerfont{section title}\insertsection\par
\end{beamercolorbox}
}
\setbeamertemplate{subsection page}{
\centering
\begin{beamercolorbox}[sep=8pt,center]{part title}
\usebeamerfont{subsection title}\insertsubsection\par
\end{beamercolorbox}
}
\AtBeginPart{
\frame{\partpage}
}
\AtBeginSection{
\ifbibliography
\else
\frame{\sectionpage}
\fi
}
\AtBeginSubsection{
\frame{\subsectionpage}
}
$endif$
$endif$
$if(beamerarticle)$
\usepackage{beamerarticle} % needs to be loaded first
@ -137,17 +60,15 @@ $endif$
$if(linestretch)$
\usepackage{setspace}
\setstretch{$linestretch$}
$else$
\usepackage{setspace}
\setstretch{1.2}
$endif$
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
\usepackage[$if(fontenc)$$fontenc$$else$T1$endif$]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{textcomp} % provide euro and other symbols
\else % if luatex or xetex
\usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
$if(mathspec)$
\ifxetex
\usepackage{mathspec}
@ -157,20 +78,19 @@ $if(mathspec)$
$else$
\usepackage{unicode-math}
$endif$
\defaultfontfeatures{Scale=MatchLowercase}
\defaultfontfeatures[\rmfamily]{Ligatures=TeX,Scale=1}
\defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
$for(fontfamilies)$
\newfontfamily{$fontfamilies.name$}[$fontfamilies.options$]{$fontfamilies.font$}
$endfor$
$if(mainfont)$
\setmainfont[$for(mainfontoptions)$$mainfontoptions$$sep$,$endfor$]{$mainfont$}
\setmainfont[$for(mainfontoptions)$$mainfontoptions$$sep$,$endfor$]{$mainfont$}
$endif$
$if(sansfont)$
\setsansfont[$for(sansfontoptions)$$sansfontoptions$$sep$,$endfor$]{$sansfont$}
\setsansfont[$for(sansfontoptions)$$sansfontoptions$$sep$,$endfor$]{$sansfont$}
$endif$
$if(monofont)$
\setmonofont[$for(monofontoptions)$$monofontoptions$$sep$,$endfor$]{$monofont$}
\setmonofont[Mapping=tex-ansi$if(monofontoptions)$,$for(monofontoptions)$$monofontoptions$$sep$,$endfor$$endif$]{$monofont$}
$endif$
$for(fontfamilies)$
\newfontfamily{$fontfamilies.name$}[$for(fontfamilies.options)$$fontfamilies.options$$sep$,$endfor$]{$fontfamilies.font$}
$endfor$
$if(mathfont)$
$if(mathspec)$
\ifxetex
@ -220,85 +140,71 @@ $if(outertheme)$
\useoutertheme{$outertheme$}
$endif$
$endif$
% Use upquote if available, for straight quotes in verbatim environments
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
\IfFileExists{microtype.sty}{% use microtype if available
\usepackage[$for(microtypeoptions)$$microtypeoptions$$sep$,$endfor$]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[$for(microtypeoptions)$$microtypeoptions$$sep$,$endfor$]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
$if(indent)$
$else$
\makeatletter
\@ifundefined{KOMAClassName}{% if non-KOMA class
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}}
}{% if KOMA class
\KOMAoptions{parskip=half}}
\makeatother
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
$endif$
$if(verbatim-in-note)$
\usepackage{fancyvrb}
$endif$
$if(colorlinks)$
\usepackage{xcolor}
\definecolor{default-linkcolor}{HTML}{A50000}
\definecolor{default-filecolor}{HTML}{A50000}
\definecolor{default-citecolor}{HTML}{4077C0}
\definecolor{default-urlcolor}{HTML}{4077C0}
\IfFileExists{xurl.sty}{\usepackage{xurl}}{} % add URL line breaks if available
\IfFileExists{bookmark.sty}{\usepackage{bookmark}}{\usepackage{hyperref}}
$endif$
\usepackage{hyperref}
\hypersetup{
$if(title-meta)$
pdftitle={$title-meta$},
pdftitle={$title-meta$},
$endif$
$if(author-meta)$
pdfauthor={$author-meta$},
pdfauthor={$author-meta$},
$endif$
$if(subject)$
pdfsubject={$subject$},
pdfsubject={$subject$},
$endif$
$if(keywords)$
pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$},
pdfkeywords={$for(keywords)$$keywords$$sep$, $endfor$},
$endif$
$if(tags)$
pdfkeywords={$for(tags)$$tags$$sep$, $endfor$},
$endif$
$if(colorlinks)$
colorlinks=true,
linkcolor=$if(linkcolor)$$linkcolor$$else$default-linkcolor$endif$,
filecolor=$if(filecolor)$$filecolor$$else$default-filecolor$endif$,
citecolor=$if(citecolor)$$citecolor$$else$default-citecolor$endif$,
urlcolor=$if(urlcolor)$$urlcolor$$else$default-urlcolor$endif$,
colorlinks=true,
linkcolor=$if(linkcolor)$$linkcolor$$else$Maroon$endif$,
citecolor=$if(citecolor)$$citecolor$$else$default-citecolor$endif$,
urlcolor=$if(urlcolor)$$urlcolor$$else$default-urlcolor$endif$,
$else$
hidelinks,
pdfborder={0 0 0},
$endif$
breaklinks=true,
pdfcreator={LaTeX via pandoc with the Eisvogel template}}
\urlstyle{same} % disable monospaced font for URLs
breaklinks=true}
\urlstyle{same} % don't use monospace font for urls
$if(verbatim-in-note)$
\VerbatimFootnotes % allow verbatim text in footnotes
\VerbatimFootnotes % allows verbatim text in footnotes
$endif$
$if(geometry)$
\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering,$for(geometry)$$geometry$$sep$,$endfor$]{geometry}
$else$
\usepackage[margin=2.5cm,includehead=true,includefoot=true,centering]{geometry}
$endif$
$if(logo)$
\usepackage[export]{adjustbox}
\usepackage{graphicx}
$endif$
$if(beamer)$
\newif\ifbibliography
$endif$
$if(listings)$
\usepackage{listings}
\newcommand{\passthrough}[1]{#1}
\lstset{defaultdialect=[5.3]Lua}
\lstset{defaultdialect=[x86masm]Assembler}
$endif$
$if(listings-no-page-break)$
\usepackage{etoolbox}
\BeforeBeginEnvironment{lstlisting}{\par\noindent\begin{minipage}{\linewidth}}
\AfterEndEnvironment{lstlisting}{\end{minipage}\par\addvspace{\topskip}}
$endif$
$if(lhs)$
\lstnewenvironment{code}{\lstset{language=Haskell,basicstyle=\small\ttfamily}}{}
@ -310,19 +216,13 @@ $if(tables)$
\usepackage{longtable,booktabs}
$if(beamer)$
\usepackage{caption}
% Make caption package work with longtable
% These lines are needed to make table captions work with longtable:
\makeatletter
\def\fnum@table{\tablename~\thetable}
\makeatother
$else$
% Correct order of tables after \paragraph or \subparagraph
\usepackage{etoolbox}
\makeatletter
\patchcmd\longtable{\par}{\if@noskipsec\mbox{}\fi\par}{}{}
\makeatother
% Allow footnotes in longtable head/foot
\IfFileExists{footnotehyper.sty}{\usepackage{footnotehyper}}{\usepackage{footnote}}
\makesavenoteenv{longtable}
% Fix footnotes in tables (requires footnote package)
\IfFileExists{footnote.sty}{\usepackage{footnote}\makesavenoteenv{longtable}}{}
$endif$
$endif$
$if(graphics)$
@ -336,34 +236,72 @@ $if(graphics)$
% using explicit options in \includegraphics[width, height, ...]{}
\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
$endif$
$if(beamer)$
% Prevent slide breaks in the middle of a paragraph:
\widowpenalties 1 10000
\raggedbottom
$if(section-titles)$
\setbeamertemplate{part page}{
\centering
\begin{beamercolorbox}[sep=16pt,center]{part title}
\usebeamerfont{part title}\insertpart\par
\end{beamercolorbox}
}
\setbeamertemplate{section page}{
\centering
\begin{beamercolorbox}[sep=12pt,center]{part title}
\usebeamerfont{section title}\insertsection\par
\end{beamercolorbox}
}
\setbeamertemplate{subsection page}{
\centering
\begin{beamercolorbox}[sep=8pt,center]{part title}
\usebeamerfont{subsection title}\insertsubsection\par
\end{beamercolorbox}
}
\AtBeginPart{
\frame{\partpage}
}
\AtBeginSection{
\ifbibliography
\else
\frame{\sectionpage}
\fi
}
\AtBeginSubsection{
\frame{\subsectionpage}
}
$endif$
$endif$
$if(links-as-notes)$
% Make links footnotes instead of hotlinks:
\DeclareRobustCommand{\href}[2]{#2\footnote{\url{#1}}}
$endif$
$if(strikeout)$
\usepackage[normalem]{ulem}
% Avoid problems with \sout in headers with hyperref
% avoid problems with \sout in headers with hyperref:
\pdfstringdefDisableCommands{\renewcommand{\sout}{}}
$endif$
\setlength{\emergencystretch}{3em} % prevent overfull lines
\providecommand{\tightlist}{%
\setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
$if(numbersections)$
\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$3$endif$}
\setcounter{secnumdepth}{$if(secnumdepth)$$secnumdepth$$else$5$endif$}
$else$
\setcounter{secnumdepth}{-\maxdimen} % remove section numbering
\setcounter{secnumdepth}{0}
$endif$
$if(beamer)$
$else$
$if(block-headings)$
% Make \paragraph and \subparagraph free-standing
$if(subparagraph)$
$else$
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi
$endif$
$endif$
@ -379,29 +317,33 @@ $for(header-includes)$
$header-includes$
$endfor$
$if(lang)$
\ifxetex
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
\usepackage[shorthands=off,$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=$babel-lang$]{babel}
$if(babel-newcommands)$
$babel-newcommands$
$endif$
\else
$if(mainfont)$
$else$
% See issue https://github.com/reutenauer/polyglossia/issues/127
\renewcommand*\familydefault{\sfdefault}
$endif$
% Load polyglossia as late as possible: uses bidi with RTL langages (e.g. Hebrew, Arabic)
% load polyglossia as late as possible as it *could* call bidi if RTL lang (e.g. Hebrew or Arabic)
\usepackage{polyglossia}
\setmainlanguage[$polyglossia-lang.options$]{$polyglossia-lang.name$}
$for(polyglossia-otherlangs)$
\setotherlanguage[$polyglossia-otherlangs.options$]{$polyglossia-otherlangs.name$}
$endfor$
\else
\usepackage[shorthands=off,$for(babel-otherlangs)$$babel-otherlangs$,$endfor$main=$babel-lang$]{babel}
$if(babel-newcommands)$
$babel-newcommands$
$endif$
\fi
$endif$
$if(dir)$
\ifxetex
% Load bidi as late as possible as it modifies e.g. graphicx
% load bidi as late as possible as it modifies e.g. graphicx
$if(latex-dir-rtl)$
\usepackage[RTLdocument]{bidi}
$else$
\usepackage{bidi}
$endif$
\fi
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
\TeXXeTstate=1
@ -426,25 +368,18 @@ $if(title)$
\title{$title$$if(thanks)$\thanks{$thanks$}$endif$}
$endif$
$if(subtitle)$
$if(beamer)$
$else$
\usepackage{etoolbox}
\makeatletter
\providecommand{\subtitle}[1]{% add subtitle to \maketitle
\apptocmd{\@title}{\par {\large #1 \par}}{}{}
}
\makeatother
$endif$
\providecommand{\subtitle}[1]{}
\subtitle{$subtitle$}
$endif$
$if(author)$
\author{$for(author)$$author$$sep$ \and $endfor$}
$endif$
\date{$date$}
$if(beamer)$
$if(institute)$
\providecommand{\institute}[1]{}
\institute{$for(institute)$$institute$$sep$ \and $endfor$}
$endif$
\date{$date$}
$if(beamer)$
$if(titlegraphic)$
\titlegraphic{\includegraphics{$titlegraphic$}}
$endif$
@ -462,9 +397,7 @@ $endif$
%%
%
% language specification
%
% If no language is specified, use English as the default main document language.
% No language specified? take American English.
%
$if(lang)$$else$
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
@ -475,10 +408,7 @@ $endif$
\else
$if(mainfont)$
$else$
% Workaround for bug in Polyglossia that breaks `\familydefault` when `\setmainlanguage` is used.
% See https://github.com/Wandmalfarbe/pandoc-latex-template/issues/8
% See https://github.com/reutenauer/polyglossia/issues/186
% See https://github.com/reutenauer/polyglossia/issues/127
% See issue https://github.com/reutenauer/polyglossia/issues/127
\renewcommand*\familydefault{\sfdefault}
$endif$
% load polyglossia as late as possible as it *could* call bidi if RTL lang (e.g. Hebrew or Arabic)
@ -490,6 +420,34 @@ $endfor$
\fi
$endif$
%
% colors
%
\usepackage[]{xcolor}
%
% listing colors
%
\definecolor{listing-background}{HTML}{F7F7F7}
\definecolor{listing-rule}{HTML}{B3B2B3}
\definecolor{listing-numbers}{HTML}{B3B2B3}
\definecolor{listing-text-color}{HTML}{000000}
\definecolor{listing-keyword}{HTML}{435489}
\definecolor{listing-identifier}{HTML}{435489}
\definecolor{listing-string}{HTML}{00999A}
\definecolor{listing-comment}{HTML}{8E8E8E}
\definecolor{listing-javadoc-comment}{HTML}{006CA9}
%\definecolor{listing-background}{rgb}{0.97,0.97,0.97}
%\definecolor{listing-rule}{HTML}{B3B2B3}
%\definecolor{listing-numbers}{HTML}{B3B2B3}
%\definecolor{listing-text-color}{HTML}{000000}
%\definecolor{listing-keyword}{HTML}{D8006B}
%\definecolor{listing-identifier}{HTML}{000000}
%\definecolor{listing-string}{HTML}{006CA9}
%\definecolor{listing-comment}{rgb}{0.25,0.5,0.35}
%\definecolor{listing-javadoc-comment}{HTML}{006CA9}
%
% for the background color of the title page
%
@ -498,13 +456,31 @@ $if(titlepage)$
\usepackage{afterpage}
$endif$
%
% TOC depth and
% section numbering depth
%
\setcounter{tocdepth}{3}
$if(numbersections)$
\setcounter{secnumdepth}{3}
$endif$
%
% line spacing
%
$if(linestretch)$
$else$
\usepackage{setspace}
\setstretch{1.2}
$endif$
%
% break urls
%
\PassOptionsToPackage{hyphens}{url}
%
% When using babel or polyglossia with biblatex, loading csquotes is recommended
% When using babel or polyglossia with biblatex, loading csquotes is recommended
% to ensure that quoted texts are typeset according to the rules of your main language.
%
\usepackage{csquotes}
@ -515,6 +491,7 @@ $endif$
\definecolor{caption-color}{HTML}{777777}
\usepackage[font={stretch=1.2}, textfont={color=caption-color}, position=top, skip=4mm, labelfont=bf, singlelinecheck=false, justification=$if(caption-justification)$$caption-justification$$else$raggedright$endif$]{caption}
\setcapindent{0em}
\captionsetup[longtable]{position=above}
%
% blockquote
@ -530,32 +507,13 @@ $endif$
% Source Sans Pro as the de­fault font fam­ily
% Source Code Pro for monospace text
%
% 'default' option sets the default
% 'default' option sets the default
% font family to Source Sans Pro, not \sfdefault.
%
$if(mainfont)$
$else$
\usepackage[default]{sourcesanspro}
\usepackage{sourcecodepro}
% XeLaTeX specific adjustments for straight quotes: https://tex.stackexchange.com/a/354887
% This issue is already fixed (see https://github.com/silkeh/latex-sourcecodepro/pull/5) but the
% fix is still unreleased.
% TODO: Remove this workaround when the new version of sourcecodepro is released on CTAN.
\ifxetex
\makeatletter
\defaultfontfeatures[\ttfamily]
{ Numbers = \sourcecodepro@figurestyle,
Scale = \SourceCodePro@scale,
Extension = .otf }
\setmonofont
[ UprightFont = *-\sourcecodepro@regstyle,
ItalicFont = *-\sourcecodepro@regstyle It,
BoldFont = *-\sourcecodepro@boldstyle,
BoldItalicFont = *-\sourcecodepro@boldstyle It ]
{SourceCodePro}
\makeatother
\fi
$endif$
%
@ -563,7 +521,7 @@ $endif$
%
\definecolor{heading-color}{RGB}{40,40,40}
\addtokomafont{section}{\color{heading-color}}
% When using the classes report, scrreprt, book,
% When using the classes report, scrreprt, book,
% scrbook or memoir, uncomment the following line.
%\addtokomafont{chapter}{\color{heading-color}}
@ -586,20 +544,19 @@ $if(tables)$
\arrayrulecolor{table-rule-color} % color of \toprule, \midrule, \bottomrule
\setlength\heavyrulewidth{0.3ex} % thickness of \toprule, \bottomrule
\renewcommand{\arraystretch}{1.3} % spacing (padding)
\rowcolors{3}{}{table-row-color!100} % row color
% Reset rownum counter so that each table
% starts with the same row colors.
% https://tex.stackexchange.com/questions/170637/restarting-rowcolors
\let\oldlongtable\longtable
\let\endoldlongtable\endlongtable
\renewenvironment{longtable}{
\rowcolors{3}{}{table-row-color!100} % row color
\oldlongtable} {
\renewenvironment{longtable}{\oldlongtable} {
\endoldlongtable
\global\rownum=0\relax}
% Unfortunately the colored cells extend beyond the edge of the
% table because pandoc uses @-expressions (@{}) like so:
% Unfortunately the colored cells extend beyond the edge of the
% table because pandoc uses @-expressions (@{}) like so:
%
% \begin{longtable}[]{@{}ll@{}}
% \end{longtable}
@ -621,43 +578,22 @@ $endif$
%
$if(listings)$
%
% listing colors
%
\definecolor{listing-background}{HTML}{F7F7F7}
\definecolor{listing-rule}{HTML}{B3B2B3}
\definecolor{listing-numbers}{HTML}{B3B2B3}
\definecolor{listing-text-color}{HTML}{000000}
\definecolor{listing-keyword}{HTML}{435489}
\definecolor{listing-identifier}{HTML}{435489}
\definecolor{listing-string}{HTML}{00999A}
\definecolor{listing-comment}{HTML}{8E8E8E}
\definecolor{listing-javadoc-comment}{HTML}{006CA9}
\lstdefinestyle{eisvogel_listing_style}{
language = java,
$if(listings-disable-line-numbers)$
xleftmargin = 0.6em,
framexleftmargin = 0.4em,
$else$
numbers = left,
xleftmargin = 2.7em,
framexleftmargin = 2.5em,
$endif$
backgroundcolor = \color{listing-background},
basicstyle = \color{listing-text-color}\small\ttfamily{}\linespread{1.15}, % print whole listing small
xleftmargin = 2.7em,
breaklines = true,
frame = single,
framesep = 0.19em,
framesep = 0.6mm,
rulecolor = \color{listing-rule},
frameround = ffff,
framexleftmargin = 2.5em,
tabsize = 4,
numberstyle = \color{listing-numbers},
aboveskip = -0.7em,
belowskip = 0.1em,
abovecaptionskip = 0em,
belowcaptionskip = 1em,
aboveskip = 1.0em,
belowcaptionskip = 1.0em,
keywordstyle = \color{listing-keyword}\bfseries,
classoffset = 0,
sensitive = true,
@ -702,24 +638,18 @@ $endif$
%
% header and footer
%
$if(disable-header-and-footer)$
$else$
\usepackage{fancyhdr}
\fancypagestyle{eisvogel-header-footer}{
\fancyhead{}
\fancyfoot{}
\lhead[$if(header-right)$$header-right$$else$$date$$endif$]{$if(header-left)$$header-left$$else$$title$$endif$}
\chead[$if(header-center)$$header-center$$else$$endif$]{$if(header-center)$$header-center$$else$$endif$}
\rhead[$if(header-left)$$header-left$$else$$title$$endif$]{$if(header-right)$$header-right$$else$$date$$endif$}
\rfoot[$if(footer-right)$$footer-right$$else$\thepage$endif$]{$if(footer-left)$$footer-left$$else$$for(author)$$author$$sep$, $endfor$$endif$}
\cfoot[$if(footer-center)$$footer-center$$else$$endif$]{$if(footer-center)$$footer-center$$else$$endif$}
\lfoot[$if(footer-left)$$footer-left$$else$$for(author)$$author$$sep$, $endfor$$endif$]{$if(footer-right)$$footer-right$$else$\thepage$endif$}
\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0.4pt}
}
\pagestyle{eisvogel-header-footer}
$endif$
\pagestyle{fancy}
\fancyhead{}
\fancyfoot{}
\lhead{$title$}
\chead{}
\rhead{$date$}
\lfoot{$for(author)$$author$$sep$, $endfor$}
\cfoot{}
\rfoot{\thepage}
\renewcommand{\headrulewidth}{0.4pt}
\renewcommand{\footrulewidth}{0.4pt}
%%
%% end added
@ -760,11 +690,6 @@ $endif$
\vfill
}
$if(logo)$
\noindent
\includegraphics[width=$if(logo-width)$$logo-width$$else$100$endif$pt, left]{$logo$}
$endif$
\textsf{$date$}}
\end{flushleft}
\end{titlepage}
@ -775,9 +700,6 @@ $endif$
%% end titlepage
%%
$if(has-frontmatter)$
\frontmatter
$endif$
$if(title)$
$if(beamer)$
\frame{\titlepage}
@ -789,25 +711,14 @@ $abstract$
$endif$
$endif$
$if(first-chapter)$
\setcounter{chapter}{$first-chapter$}
\addtocounter{chapter}{-1}
$endif$
$for(include-before)$
$include-before$
$endfor$
$if(toc)$
$if(toc-title)$
\renewcommand*\contentsname{$toc-title$}
$endif$
$if(beamer)$
\begin{frame}
$if(toc-title)$
\frametitle{$toc-title$}
$endif$
\tableofcontents[hideallsubsections]
\tableofcontents[hideallsubsections]
\end{frame}
$if(toc-own-page)$
\newpage
@ -817,7 +728,7 @@ $else$
$if(colorlinks)$
\hypersetup{linkcolor=$if(toccolor)$$toccolor$$else$$endif$}
$endif$
\setcounter{tocdepth}{$if(toc-depth)$$toc-depth$$else$3$endif$}
\setcounter{tocdepth}{$toc-depth$}
\tableofcontents
$if(toc-own-page)$
\newpage
@ -831,21 +742,12 @@ $endif$
$if(lof)$
\listoffigures
$endif$
$if(linestretch)$
\setstretch{$linestretch$}
$endif$
$if(has-frontmatter)$
\mainmatter
$endif$
$body$
$if(has-frontmatter)$
\backmatter
$endif$
$if(natbib)$
$if(bibliography)$
$if(biblio-title)$
$if(has-chapters)$
$if(book-class)$
\renewcommand\bibname{$biblio-title$}
$else$
\renewcommand\refname{$biblio-title$}
@ -853,9 +755,9 @@ $endif$
$endif$
$if(beamer)$
\begin{frame}[allowframebreaks]{$biblio-title$}
\bibliographytrue
\bibliographytrue
$endif$
\bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$}
\bibliography{$for(bibliography)$$bibliography$$sep$,$endfor$}
$if(beamer)$
\end{frame}
$endif$
@ -865,8 +767,8 @@ $endif$
$if(biblatex)$
$if(beamer)$
\begin{frame}[allowframebreaks]{$biblio-title$}
\bibliographytrue
\printbibliography[heading=none]
\bibliographytrue
\printbibliography[heading=none]
\end{frame}
$else$
\printbibliography$if(biblio-title)$[title=$biblio-title$]$endif$
@ -877,4 +779,4 @@ $for(include-after)$
$include-after$
$endfor$
\end{document}
\end{document}

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@ -1,64 +0,0 @@
@font-face {
font-family: OpenSans;
font-style: normal;
font-weight: normal;
src:url("OpenSans-Regular.ttf");
}
@font-face {
font-family: OpenSans;
font-style: normal;
font-weight: bold;
src:url("OpenSans-Bold.ttf");
}
@font-face {
font-family: OpenSans;
font-style: normal;
font-weight: lighter;
src:url("OpenSans-Light.ttf");
}
@font-face {
font-family: Oswald;
font-style: normal;
font-weight: normal;
src:url("Oswald-Regular.ttf");
}
@font-face {
font-family: Oswald;
font-style: normal;
font-weight: bold;
src:url("Oswald-Bold.ttf");
}
@font-face {
font-family: Oswald;
font-style: normal;
font-weight: lighter;
src:url("Oswald-Light.ttf");
}
body {
margin: 1%;
text-align: justify;
font-size: small;
font-family: OpenSans;
line-height: 1.75;
}
code { font-family: monospace; }
h1 { text-align: left; color: #333; }
h2 { text-align: left; color: #555; }
h3 { text-align: left; }
h4 { text-align: left; }
h5 { text-align: left; }
h6 { text-align: left; }
h1, h2, h3, h4, h5, h6 {
font-family: Oswald;
}
h1.title { }
h2.author { }
h3.date { }
ol.toc { padding: 0; margin-left: 1em; }
ol.toc li { list-style-type: none; margin: 0; padding: 0; }

File diff suppressed because one or more lines are too long

View File

@ -1,9 +0,0 @@
% This file contains latex code that should be added at the front of the
% generated latex document. This is done by using the pandoc command line
% option `--include-before-body=include-cover.tex'
%
% Note that, in order for this to work, \usepackage{pdfpages} also
% needs to be added to the header of the latex document. This is done
% in pandoc-metadata.yaml
%
\includepdf[pages=-]{back.pdf} % include the cover PDF

View File

@ -1,331 +0,0 @@
<!--
Original: https://pad.hackerspace.gent/p/HTH_Nov_2018
This version was slightly modified to look better in markdown.
-->
# Hack the hackerspace meeting 2018-11-17T11:00:00+01:00 (Membership)
TQ will be making (American-style) pancakes with yoghurt.
If you have the time, please bring something tasty and breakfasty. If you want to cook something on-site, let TQ know in advance, the kitchen is not very large.
## Attending (to get an estimate for food)
* sasja (homemade applejuice and daddymade cider)
* evils (bringing 4 croissants and 2 chocolate croissant like things)
* Merlijn
* Betty (fresh orange juice)
* Bertrand
* Bloemi
* Gust (bringing whipped cream and blueberries for the pancakes)
## The facts
Please no names here; while this meeting was triggered by a specific situation involving specific people, the point of an HTH meeting is to make sure that the class of issues does not happen again. The specifics are irrelevant. With that in mind, I'll change the names to something generic; let's keep to the fake names to avoid :
```txt
Alice had a concern about the speed with which Bob became a member
This was a procedural concern, not anything specific about Bob.
Nobody had any concerns specifically about Bob; their membership is not in question
Bob had two sponsors: Carol and David.
Alice raised her concern about the timeframe with Carol, who removed Bob's membership from the next meeting
Three weeks later, David put Bob's membership on the agenda.
Alice again raised her concern with Carol, who was not aware of that agenda item
The above incident was raised to the board; they met with Carol to discuss what happened
A board member (Eve) agreed to meet with Alice to discuss the results of the meeting
Three months later, Eve still had not met with Alice.
```
Meanwhile,
```txt
Alice repeatedly added the membership issues to the hackerspace meeting agenda
There were two long, heated discussions (2+ hours each) on the topic for two meetings in a row
The third meeting, it got pushed to the next meeting for time reasons
After that there was another long discussion
During these discussions, many members got frustrated and left the meeting.
```
A year ago
* Alice wants her friend Eve to be able to use the space.
* Several members had a concerns at the speed with wich Eve would become a member.
* nobody has concerns specifically about Eve, but we needed more time to get to know Eve.
* Alice proposes to give her key to Eve and is willing to take full responsibility. While using agressive emotional arguments to force her idea on other members.
* Alice only wanting to follow rules when it suits her, makes members unwilling to listen when Alice does try to enforce rules.
## Agenda
* Brunch
* The facts
* Shared goals
* How do we handle board failures?
* Sometimes people fail (lack of follow-through, reaching out to a non-sympathetic person, etc). The process should be resilient to that
* How do we handle conflicts?
* Member responsibilities
* Membership process
* Pull requests!
## Thoughts
I think part of the frustrations come from the fact that members implicitly have different understandings of the spirit of the membership procedure.
Some members seem to interpret the procedure such that at its core, it was designed to ensure some minimum time / minimum number of visits before being able to join. The idea under this interpretation is that the two signatures are a means to slow down applications so that as many members as possible can get to know a prospective member.
Others seem to interpret the procedure such that it is a trust-based referral system. It really is sufficient if two members can vouch for an applicant. The two members are trusted, so the new member is trusted. Time and number of visits are less important.
It would be good to be more explicit on what the intention of the procedure is and then reach consensus on it.
(My, sp's, personal view is that a trust-based system is just fine. In a club of 20+ people, you are not going to get to know everyone, esp. if prospective members tend to come at different times than you do, e.g. you: Thursdays, they: Sunday.)
Couldnt agree more (bloemi) frequency of visits should not matter, the member decides how much he/she wants to get out of his/her money :p there are members that visit a few times a year (i.e. Mimor), nobody cares and we are happy he still contributes. (he gladly does so)
## Notes of afk Discussion
* Gust: being a sponsor should have more responsibility than just signing the paper; they should vouch for the member. Approval in the meeting should be a formality. You shouldn't block in the meeting. This will make the meeting a positive thing. The whole process should be a safety net. It's not a beauty contest; you should block if you are sure that there is a problem, new members shouldn't be "approved" by everyone. (use the same "provided nobody says no").
* Gust: sponsors should maybe apply the private talk pattern? B: i dont think should, but they should be able to when needed
* Els: but then certain people shouldn't be sponsors or they should improve their mediation skills.
* Gust: Although the MAIN purpose is that they vouch. If the sponsor can't apply the private talk pattern, the sponsor should get help.
* Sasja: we should trust everyone to apply the private talk pattern.
* TQ: IF they feel like they can't apply the private talk pattern then they shouldn't be a sponsor
* TQ: Tangent: we don't agree about what the goal of the membership process is. Should we integrate people in the space, is it simply a coarse filter to keep out super bad people, is it a fine filter to keep out anyone who might have issues. D they need sponsors to get them to talk to the space?
* Bertrand: You can have two sponsors without talking to many people.
* Bloemist: what about scalability? what if we have 50 members, does everyone need to talk to a person before they come a member?
* Gust: scalability is a good question
* Els: Members should actively try to talk to applicants. Applicants should also try to talk to members.
* Sasja: We should optimise the process to make people feel welcome. This won't be perfect, this might let bad people through but we should solve this in another way
* Evils: Mitch said that we shouldn't be afraid of kicking people out.
* Bloemist: With T, I think he should have been a member, but it's good that we kicked him out when the issues became clear. The membership procedure didn't fail in that case.
* Gust: this conversation seems to go to corrective actions. But that is a harder one. Corrective action = kicking them out, telling them they aren't compatible, "here is a behavior of yours that needs to change".
* Merlijn: I find it difficult to pinpoint what the issue is exactly, this makes it harder to coach, this makes corrective actions harder.
* Els: Should one person be able to veto?
* TQ: It can be important, but not always and it's the responsibility of that person to convince the others.
* Els: If we follow the meeting voting procedure then this is forced/implied by the procedure.
* Bertrand: But what if you can't convince people? we have our day jobs and some people don't have many friends in the space.
* Bertrand: If we find it ok that an applicant can become a member even if one member disagrees with that, then we need to make that clear.
* Gust: This is clearly defined in the decision making model. It used to be concensus but that didn't work. This isn't water-tight but a bad decision is better than no decision. If you can't convince anyone then you might be in the wrong group or you need to suck it up. There needs to be trust in the group.
* Merlijn: **should we use normal meeting/voting procedure for membership decisions?**
* Bloemist: as a fallback?
* some people: yes
* Sasja: This might have solved the B issue or made it even worse by dividing the group.
* Gust: It should be clearly defined that meeting system is the default.
* Gust: This might create friction in the group, this might be bad, but this is a scalable solution. What if we have 50 members.
* Els: Hackerspace is like a family, you don't pick everyone.
* Bloemist: Using that process should be an exception, the process is a fallback.
* Gust: it's a sucky model, but it gets shit done.
* Merlijn: as a fallback, who decides when the fallback kick in?
* Bloemist: second meeting is fallback; but that's how the system works.
* Evils: Maybe set date for next meeting on first meeting
* Sasja, * els: but then the people allow it to happen.
* Gust: in the "meeting" chapter, it's already a fallback.
* Bloemist: the fallback is the second meeting.
* Bertrand: There were multiple people who think **anonymous voting** should be possible. Because of peer pressure. Maybe by default make it anonymous.
* Bloemist: if you feel like you won't be able to speak up, you should find someone to do it.
* Bertrand: but this is where we get tired.
* Gust: I hear two things: 1) do we want to have a different kind of voting system for members? 2) do we want to allow anonymous voting.
* Bertrand: I'd just make it a default only for members.
* Gust: We need to think about what are the risks of anonymous voting. risk: accountability. Members need to be accountable for their blocking.
* Bertrand: what happens is that 2 people of 2 sides are vocal and the others are quiet. You don't know what the ideas are of everyone.
* Bloemist: how do you know what the issue is if somebody block anonymously.
* Sasja: what if somebody blocks because they're against gays.
* Evils: then it just goes through the process and next week the person gets voted in. If you can't make an argument.
* Sasja: the system of anonymous voting might lead to popularity contest.
* Gust: it's applied for the government but it's applied nowhere else..
* Evils: blackballing is a method for anonymous voting. anonymous voting is used in gentlemans clubs, freemason and fraternities.
* Bertrand: does anyone use do-ocracy A: yes, hackerspaces and commons
* Bertrand: but what about **peer pressure**, peer pressure implies a popularity contest
* Sasja: peer pressure exists but you need to be able to deal with it.
* Merlijn: so we could use anonymous voting to get a feel of the group but not use it to vote, only to get a sense of who it is.
* Gust: complaints about applicants should be fixed in private talk, not in meeting. Role of sponsor is "are they blocking points in my own judgement. If not blocking then bring it up to the meeting.
* Gust: point system is should be anonymous and removes peer pressure.
* Merlijn: peer presure is important because it creates compromise and harmony.
* TQ: peer pressure smooths over minor issues, but if you think it's worth standing up for then do it. If you really can't then maybe you don't care enough.
* Sasja: standing up is not a free action, and that's good.
* Bertrand: we have this no-brainer; say you have anonymous voting. 1 a balance of one anonymous person blocking. 2 other scenario half half.
* Merlijn: many people don't say their opinion during a meeting but this is what it should do, this is how you make compromises. Everyone in this workshop has kept quiet about stuff they don't like, simply to get the group further. And this is good. You pick your battles.
* Bertrand: is this idea written down in HTH?
* Bloemist: it will never be perfect, but anonymous voting has some downsides that I really don't like it.
* Merlijn: I'm open to the idea for using anonymous voting for membership procedures, although it might incentivize people to block for reasons that are not "super bad" just "worries". We also need a better system to kick people out so "worries" don't have to be blockers.
* TQ: If somebody has an issue that they think is important enough to block something then they should own that issue of convince other people. If they can't find somebody else then that might mean the issue isn't that bad.
* Merlijn: and if only one person has an issue, that issue will not hold up during the 80% voting anyway.
* Els: I have stood up for other members multiple times.
* Gust: If you cant' find anyone to join your opinion then that might be an argument against that.
* Gust: also: it's ONLY a hackerspace.
* Gust: But what if someone is actively trying to suppress an opinion?
* Sasja: during anonymous voting we might have trolls, we've even had them during non-anonymous voting already.
* TQ: if we have issues when we're with 50 people then we can re-discuss this, then we'll have more info about how it fails.
Discussion on **what should be put on a meeting**. The manifest already has an sizeable explanation of this.
* Bloemist: you can use the announcement section for announcements.
* Sasja: you can put project announcements during "the minute".
* Merlijn: But if people "own" something you should discuss it with them but not on a meeting.
* Els and bloemist: we should enforce more of those "rules".
MEETINGS SHOULD BE MORE POSITIVE, they create culture. We should look at meetings like a new person.
* TQ: person went to the meeting and he thought it was a magical place and it really impressed them.
Since we all agree about what should be on a meeting, we're moving on.
Is there anyone who wants to fundamentally change membership procedure?
* Bertrand: big source of drama is that **there is no clear definition for "been enough to the space"** and "is known enough" to be in the space. Solution: give a defined timeframe.
* TQ: change: if somebody has an issue, **they are responsible to take that issue to its conclusion.** If you have an objection it's your responsibility to get to a solution. -> the decision model should fix this It's the responsibility of the member who has the concern, not the sponsors.
* Bertrand: How about you can only become a member two months after you first stept into the space, only if you've been to 5 social evenings.
* Sasja: Who would check that?
* Bloemist: What is considered as "coming to the space". I have fear of bureaucracy.
* Gust: With that rule you exclude people who work on thursday evening.
* Els: What about have them show up on a meeting they aren't membership on and meeting they are membership on.
* Gust: This is what they do in Brussels.
* Els: the applicant has to be in the meeting to say hi, in the next meeting they can be decided upon. They should join a meeting as a non-member because this shows the space asks shared responsibility and transfers culture.
* TQ: These applicants should be part of the meeting, but they don't get voting rights.
* Bertrand: I see the benefits of it. I think it might fix drama by being clear about the timeframe and it removes the fear of the unknown.
PROPOSAL WITH ROUGH CONSENSUS: have an applicant present their application on a meeting, join the discussion on that meeting. During that meeting we don't vote on the applicant and we don't have a voting discussion on the applicant. That is for one of the next meetings. But; it shouldn't be a tribunal because that can lead to power structures. (we need to find a better word for tribunal)
* Sasja comments about discussion; but rough meetings might scare them away.
* Gust: if this happens too much, we need to fix the fact that it happens too much.
BREAK
After break:
* tq: meetings that push new members away will also push existing members away.
* Gust: one of the goals of a meeting is that they attract people to become new members. People who like flat hierarchy might like those meetings.
* Sasja: in theory the space should be able to work without meetings.
* Gust: they are a nessecary evil.
* Bertrand: one of the issues was meetings announced too late and points brought up the meetings too late.
* Gust: this is about how to do an efficient meeting but maybe we shouldn't discuss that.
* Evils: manifesto says stuff should be put on the pad 3 days in advance.
* Gust: is this an issue, should we talk about it?
refocus: requirements to become a member; time.
Proposal:
```txt
step 1: apply
step 2: go to meeting
step 3: on a following meeting, decide on the application.
```
* Sasja: how would this solve past issues?
* Answer: by having it written down what "too fast" means: too fast is the applicant hasn't come to a meeting yet.
* Bertrand: proposal, timestamp.
* Els: Take this rule, applying it, and re-evaluate.
* Bloemist: Voting is still a fallback.
* Sasja: We need to apply the minute more. We need the minute during hard meetings.
* TQ: The minute is amazing.
* Evils: Luke has been in the space since a lot of months.
* Bertrand: Who is luke?
* Bloemist: That's the point. Being in the space for a long time doesn't mean people know you better. It's up to the people who know Luke to vouch for him or say that he's not compatible.
**DECISION! We like the three step proposal.** WHOOOHOOOO \0/
* Bertrand: to be clear, does this mean that a person can become a member 2/3 weeks after getting to the space?
* Answer: yes, this is ok because we have 3 safeguards: sponsors, first meeting, vote meeting.
Next point: Define a sponsor: we should add "what are the responsibilities of a sponsor". In the same vein as the roles of the board. We should discuss corrective actions first.
* Gust: what about doing another meeting for discussing sponsorship and maybe corrective actions.
# Corrective actions
* Gust: Corrective actions vs power tripping.
* TQ: Mediate pattern seems to work well: neutral person to hear both sides out and help them reach common ground.
* Gust: In the E case, did the board implementation fail or did the system fail? It seems as if the implementation failed but the board shouldn't be the end-all be all, they should be applauded, not be given more work. They are in a shitty situation.
* Bertrand: Are we talking about defusing or correcting?
* Merlijn: Defusing works, correcting doesn't seem to work, look at it in the sense of a wrong member being let in.
Tangent: *using noizebridge as an example of how to do something is terrible*
* Gust: What if a member does something completely wrong and another member sees it, not the board? Can that member kick someone out temporarily?
* Els: Someone being a bitch isn't very quantified, hard to kick people out because of it.
* Gust: We have to make sure that people still try to agree instead of simply kicking people out.
* Evils: Determining what the problem is, is very draining. Figuring out "why" people call somebody an asshole. Maybe we need to focus on determining and spotting problems
* Bertrand: We also have the problem were the only tool is banning a person. (and temporarily). Should we have other corrective actions?
* Gust: 1. short ban, 2. long ban, 3. permanent ban.(either banning access or presence)
* Bertrand: **With E we wrote a letter and asked her to change her behavior.** This is a more official stance, it's hard, but it's not banning. As a statement it's powerful, almost as powerful as banning. Maybe we should define this tool? "we won't ban you but you have to do this different".
* Els: We tried this with T and it didn't really work.
* Answer: we didn't really do it this clearly
* Bloemist: "either you change or you're out".
The letter to E contained:
1. What are the causes, what part of your expectations/behaviors are not compatible with the space.
2. What is the effect of those causes, how does the space react to it.
3. What do you need to change.
* Bloemist: it's good that it's summarized.
* Gust: The time period between identifying the issue and acting was way to long, both with T and with E.
* Gust: We need to offload the board as much as possible. For example, the board says 6 months and you got a member.
* Bloemist: That's what they do in revspace and it seems to work.
* Gust: In Belgium we have an assembly, in the netherlands you only have a board, they have all authority.
* Merlijn: I think the burnout came from trying to many different things, not wanting to take big action because we also made mistakes.
* Gust: Keeping the balance between fixing and kicking out, between coaching and bocking is important but this is difficult and takes a lot of energy.
* Gust: With E the boyfriend played a role.
* Merlijn, Bloemist: I don't think that impacted our opinion and decision.
* Merlijn: Tangent: If the goal is to find a compromise, how can you find a compromise with a proxy?
* Gust: Writing a letter is hard, the analysis is time and energy consuming. Banning is a tool with less energy that the board needs to put in.
* TQ: We need a lighter way, "this is a problem, this needs to be fixed".
* Merlijn: Private talk pattern works best for defusing, not for fixing issues.
* Gust: The private talk pattern could also be used to say "this is incompatible behavior, you need to change".
* Merlijn: You have the mediation pattern and the private talk pattern. maybe we should make the distinction clear and write them both down as tools.
* Gust: for mediation you don't even need the board, members can do it, but for corrective action you need it
* Bertrand: Letter is a black and white statement, we can use it as a stick, we can objectively revisit it.
* Bloemist: But then what will happen if they don't follow it?
* Gust: It's a given, it shouldn't be explicitly in the letter.
* Bloemist: Maybe not for these people.
* Bloemist: "Statement of incompatibility" might be a good name for this pattern
* Sasja: The letter should've come earlier.
* Gust: Writing the letter would be a burdon. Can we make the board do that?
* Els: I was writing an email about the incompatibilities to E, I didn't send it because I knew the letter was sent.
* Bertrand: Is it a big burden? yes. Is it easier than banning? yes.
* Gust: I would do a talk much sooner.
* TQ: The hard part is figuring out what the wrong behavior is, you also need to do it for a private talk.
* Gust: For me writing the letter is harder.
* Bloemist: A letter makes it fixed, it's tangible, it's different from "simple" talks.
* Bertrand: This was a very loaded statement, it might be easier if it's sooner; like "don't mess up the back room".
* Gust: In HR, they formalize the process to fire people. Should we do that too?
* Gust: Should we make an archive of these letters? Publish it?
* sasja: Contents should remain between the people writing and the people receiving.
* Sasja: Should there be a statement to the other members that the letter has been sent?
* Gust: Write the letter with the thought that it could be leaked.
* gust: What lowers the burden? It's that the letter isn't a start of a conversation it's the end of one. (one-way letter might be a good name?)
* Gust: A time ban is less of a burden to do than an indefinite ban.
* Bloemist: Members have a responsibility to make clear to the board that a statement of incompatibility needs to be made.
* Gust: Although that risks having a "Service" model where members expect the board to do the work.
* Gust: It shouldn't be a taboo to take hard actions. The board should be allowed to make decisions to solve issues even if they made mistakes in handling issues.
* Gust: It's nice to think about issues as the group, not one person. You're not taking actions against a person but to fix the group.
* Merlijn: name: "statement of incompatibility"
* Gust: name: "acting on incompatibility"
* Merlijn: name: "Request for compatibility"
* Gust and * Merlijn: Side discussion: finding loopholes, stretching the "idea" behind the manifesto is toxic and we should not do it. You cannot expect other people to police you. Just because people didn't police you, doesn't mean what you did is ok with the group.
## What now
1. Merlijn will create a PR for what we decided upon.
2. during meeting we'll say "this is what decided, we'll merge this" if they don't like it, then come to the next HTH meeting.
3. Do next HTH meeting somewhere in the future.
## TODO for Next time
* sponsorships: defining what a sponsor is
* follow-up: what about previous discussion

View File

@ -3,26 +3,16 @@
# This document contains some pandoc-specific metadata.
#
#
#
title: "The Hackerspace Blueprint"
subtitle: "Empowering people to be awesome"
author: [Merlijn Sebrechts, Hackerspace Gent]
tags: [Do-ocracy, Hackerspace, Self-governance, Structureless Organizations]
language: en
rights: CC BY-SA 4.0
toc: true
toc-title: "Table of Contents"
#
# Options specific to Latex (PDF version)
#
book: true
footer-left: "Hackerspace Gent"
links-as-notes: yes
# 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
#
title: "Hack the Hackerspace: empowering people to be awesome"
author: [Hackerspace Gent]
tags: [Markdown, Example]
header-includes: |
\usepackage{sectsty}
\sectionfont{\clearpage}
\usepackage{pdfpages}
---
links-as-notes: yes
---