adinfinitum
/
hackerspace-blueprint
mirror of https://codeberg.org/tqt/hackerspace-blueprint.git
2
0
Fork 0
Code Issues Releases Wiki Activity

Replacing blueprint contents with the new proposal

pull/47/head
Mike Rosseel 2024-11-14 18:04:59 +01:00
parent 15c77e3de4
commit a686c00c24
5 changed files with 61 additions and 260 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

152
3-meetings.md
View File

@ -1,155 +1,39 @@
# 3. Meetings
## What should I discuss on a meeting?
## What is the goal of 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.
Things you should discuss on a meeting:
The goal of our meetings is to build community and keep everybody informed.
* 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.
## How do we make decisions
Things you can discuss on a meeting:
Do-ocracy! We do things; if you want the table painted blue and somebody else wants it painted red, then the table gets painted blue because that's the color of paint you bought. If you want to try to make a decision as a group, you're welcome to do so, but even then, the final decision is made by the one doing the work.
* You want everyone to be on the same page about a topic or issue.
* If you want to make sure people will fully support what you want to do, you can hold a meeting to explain what you will do and ask for feedback.
* If you want to do something that requires help from many people, you can use a meeting to convince people to help you.
* If you have issues with the actions of a certain member and you failed to solve it with that member personally or you want the group's opinion on it.
Outside of a GA, where binding votes is a legal requirement, we do not have binding votes on proposals. While voting can be a useful tool to make decisions, the results of a vote are not binding. There may also be other, better tools to make the decision.
## How do I schedule a meeting?
## Suggestion: How to run the meeting
Any member can schedule a meeting.
### 60 seconds
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).
We start out with "the minute", where each member gets 60 seconds with which to do absolutely anything they want. Most members talk about the projects they've been working on, but Alice decides that she wants to poll the members on an idea she has, and Bob uses his time to gather everybody (who wants to take part) for a group photo.
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.**
### Practical part
## How do we make a decision during a meeting?
Once everybody has taken their minute, we move on to the practical matters. We need to get new drinks, which Alex volunteers for. Sam announces that they're donating a vacuum to the space to help keep it tidy. Finally, an announcement is made reminding everyone to not leave food trash in the space overnight lest we gain more wireless mice.
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.
### In-depth topics
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.
Jack wants to throw a conference over the weekend, and asks for help running it. Alex agrees that this is a great idea, and offers to find people to give talks. They all agree to meet another day to discuss more, and invite anybody else who is interested to join.
## Why not regular consensus?
### FIN
[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.
At this point, everybody has said their piece, and we close the meeting. It only took 15 minutes.
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.
https://pad.hackerspace.gent/p/Meeting194
## General Assembly and Statutes
A general assembly is different from a normal meeting in that it is governed by the rules in the official statutes of the legal entity "Hackerspace Gent (0x20)". As a Belgian non-profit organization, Hackerspace Gent is required to host a General Assembly each year. During a general assembly, the board is elected.
General Assembly and statutes are required by law, and Hackerspace.gent needs to follow those laws.
The statutes dictate the following.
* The General Assembly needs to be announced at least 10 days beforehand.
* 50% of members need to be present during a General Assembly.
* 2/3 of members need to be present in order to change the statutes and/or the board.
* Decisions during the General assembly need a 2/3 majority of the present members.
* The board needs to have at least 3 members.
You can find the latest version of the statutes in the Government gazette (staatsblad) (Dutch-language).
1. Go to <http://www.ejustice.just.fgov.be/tsv/tsvn.htm>
2. Fill in `0x20` in the "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".*
3. Press the "lijst" button to see all the search results.
More important information from the statutes.
* The hackerspace needs to have at least 4 members.
* New members need to be approved by the board.
## The formal decision making model
Most decisions don't require a rigid structure but we need a rigid structure to fall back on when there is extreme conflict that divides the space or when people don't agree on how a decision is made. In such cases, a consensus-based system is used in order to re-unite the space.
In short; the topic needs to be put on the agenda three days 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.
| 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 |
### 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.
### 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:
* encourages discussion
* forces listening to opposing ideas that can give new insights
* can bring smarter compromises
* <https://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.
### 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.
### Meeting 3
When all has failed, or the problem is too controversial, but a decision is still required, the point system below will be used to reach a decision.
### Point system
The point system is a **last-resort** option. This should not be the general process of resolving conflicts. If the space is starting to use this too much, that means that there is a structural problem in the group dynamic.
**The point system has a few basic rules:**
* Each voter has a certain number of points that they 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.
"No decision" is worse than a "bad decision". Conflict has to be solved eventually. That is why there is this last-resort option. However, we want to discourage people from blocking consensus. The point system has the following advantages:
* The outcome is not always clear because balanced ideas can still win, even if the minority would vote for them.
* The minority will gain from convincing the majority that their idea is not completely ridiculous.
* People have the ability to vote for, and thereby support, multiple ideas.
In the point system, every voter gets some points that they can distribute between the different options.
#### Examples
| Vote without points | Points to proposal A | Points to proposal B |
| ------------------- |:---------------------:| --------------------:|
| A | 3 | 2 |
| A | 4 | 1 |
| A | 3 | 2 |
| A | 3 | 2 |
| A | 4 | 1 |
| A | 3 | 2 |
| B | 2 | 3 |
| B | 0 | 5 |
| B | 1 | 4 |
| B | 1 | 4 |
| TOTAL | 24 | **26** |
As you can see in this example, a less extreme proposal that, on first sight, has the minority of the votes, can still win. This gives the minority the incentive to come up with moderate ideas that everyone can agree with.
| Vote without points | Points to A | Points to B |
| -------------------------- |:------------------------------:| --------------:|
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| A | 4 | 1 |
| A | 5 | 0 |
| A | 5 | 0 |
| A | 4 | 1 |
| B | 0 | 5 |
| B | 0 | 5 |
| B | 0 | 5 |
| TOTAL | **32** | 18 |
However, extreme ideas will not be able to "win". With extreme ideas, the outcome of this model will be the same as with a +50% majority.
For more information, please read: https://www.vsdc.be/nl/downloads/112/vzw-wetgeving

29
4-the-board.md
View File

@ -1,22 +1,23 @@
# 4. The Board
The board exists to make sure the hacker environment survives. The board members are not the leaders of the space, they are the firemen of the space. They make sure the physical space stays available and the members keep loving each other. Apart from that, the board members should be *indistinguishable* from normal members. The board members don't have any more say over the direction of the space or the projects in the space than any other member.
The board exists to make sure the hacker environment survives. The board members are not the leaders of the space, they are the firemen of the space. They make sure the physical space stays available and the members keep loving each other. Apart from that, the board members should be indistinguishable from normal members. The board members don't have any more say over the direction of the space or the projects in the space than any other member.
Specifically, the board has two roles, and for everything that doesn't fall into these roles, the board members are regarded as regular members.
1. *Warden of the physical core infrastructure of the space.* This stems from [the infrastructure pattern](https://wiki.hackerspaces.org/The_Infrastructure_Pattern). Provide a room with power, internet, a bar and [a kitchen](https://wiki.hackerspaces.org/The_Kitchen_Pattern) and the hackers will come. An important aspect of this is keeping a good relationship with the surroundings as said in [the landlord and 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.
1. Warden of the physical core infrastructure of the space. This stems from the infrastructure pattern. Provide a room with power, internet, a bar and a kitchen 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.
2. Mediator of last resort 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. See Conflict Resolution.
It's important for the board to communicate openly about what they do.
Both jobs are critically important to the space. Many hackerspaces disbanded because they were kicked out by their landlord and many hackerspaces fell apart because of internal conflict. It is important to get the right people in the board. **This is why the board has very little power and only in exceptional circumstances: so it doesn't attract people who want to be in power.**
Both jobs are critically important to the space. Many hackerspaces disbanded because they were kicked out by their landlord and many hackerspaces fell apart because of internal conflict. It is important to get the right people in the board. This is why the board has very little power and only in exceptional circumstances: so it doesn't attract people who want to be in power.
## Why is there a board?
There are two reasons why Hackerspace Gent 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.
* 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.
## What power does the board have?
@ -30,12 +31,12 @@ The same applies to the board, talk to them when there is a big issue and check
Here are some examples of when you should check with the board before you do it.
- If you're spending space money.
- If you want to make changes to membership fees, the bar, the space shop, ...
- If you want to make changes to the electricity, and internet.
- If you want to make changes to the space building that affect fire safety, electrical safety, structural integrity or changes that would make the building collapse.
* If you're spending space money.
* If you want to make changes to membership fees, the bar, the space shop, ...
* If you want to make changes to the electricity, and internet.
* If you want to make changes to the space building that affect fire safety, electrical safety, structural integrity or changes that would make the building collapse.
This isn't necessarily to get their approval, more to give them a chance to stop you if they think it's a bad idea. *Note: If something has been decided on a meeting with the board present, you can assume the board doesn't have any objections to it, and you can just do it.*
This isn't necessarily to get their approval, more to give them a chance to stop you if they think it's a bad idea. Note: If something has been decided on a meeting with a board member present, you can assume the board doesn't have any objections to it, and you can just do it.
Moreover, if people are abusing the space, people in the space, or you, then it's best to inform the board. You're free to ask help from anyone you feel comfortable with, but it's best to also inform a board member so that they can intervene when someone harasses multiple people in private.
@ -43,11 +44,11 @@ Moreover, if people are abusing the space, people in the space, or you, then it'
The board does not have any say about what other members are to do, and you want people in the board that like/keep it that way.
- The "warden" role requires people who are responsible and dependable. The kind of people who say "maybe that's not such a good idea, we might get thrown out if we do that".
- The "counselor" role requires people who are open communicators, good listeners, and good at defusing a situation.
* 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 "Mediator of last resort" role requires people who can quickly get to the heart of the matter and are willing to take impartial and if necessary decisive action.
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.
## How does the board get elected and expelled?
During a general assembly, the members vote on electing and expelling the board according to the statutes. For more information, refer to the "Meetings" Section.
During a general assembly, the members vote on electing and expelling the board according to the statutes. For more information, refer to the "Meetings" Section.

33
5-membership.md
View File

@ -2,40 +2,33 @@
## 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.
- Potential member joins mattermost
- Potential member visits the space and find two sponsors to broadcast their sponsorship on the @changelog channel.
- The new membership application is announced in ~Changelog, by a board member or a quicker member.
- If other members have objections, they may express them in @spacemembers during the 7 days following the board's announcement.
- At least 7 days after the announcement, the board schedules a meeting for the new member to be inducted.. If there were objections, the board makes a reasonable effort to ensure that those members can be present.
- At the announced meeting, two things occur:
1. If there were objections, the members with objections have a chance to lay out their concerns. Other members may agree or disagree with these concerns. Then the potential member may speak in their defense, if they so desire. Then the board makes a decision on whether to accept the member
2. The new member is granted full membership, they receive instructions on transferring their membership fees (and, of course, make their first payment), and receive physical access to the space
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.*
The board may decide that deviations from these steps are still acceptable.
## What are the responsibilities of a member?
*The members create and maintain the hacker environment.*
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.
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.
*The individuals have to be excellent.*
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.
* Maintain personal safety and that of others.
* Follow and enforce the Guidelines.
## Non-members
@ -43,4 +36,4 @@ The members should do the following things as a group.
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 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.

96
6-guidelines.md
View File

@ -1,85 +1,8 @@
# 6. Guidelines
# 6. Conflict resolution
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.
## How to avoid conflict
We want you to be a part of it, but you need to do three things.
* Use common sense,
* be excellent to others,
* and don't be an asshole.
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.
First and foremost, [the golden rule](http://en.wikipedia.org/wiki/Golden_Rule): treat others the way you want to be treated.
## Loopholes
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.
## 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 projects
* You have full control over how to do the project.
* The project stuff/material is considered your personal property.
* You decide what happens to the end-result of the project.
### Space projects
* 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.
## Property and tools
### 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).
### Space property
#### 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.
* 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.
#### Damaging or losing space property
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.
#### Taking space property out of the space
Only members are allowed to take space property out of the space. If you take space property out of the space, you have to notify the 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.
## Space maintenance
### 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
* 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
* 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.
## Social behavior
### 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.
@ -98,6 +21,17 @@ People are trying to concentrate in here so:
### Network/security
* Just leave other people's stuff alone, don't post "*funny*" social network status updates on unattended logged in computers.
* 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 congest the network with (legal) torrenting, just behave nicely, so we don't have to write an AUP.
## How conflict gets resolved
If a conflict gets out of hand the board will be forced to resolve the issue.
* The board is the shepherd of the blueprint
* In case of conflict the first approach is to let the group work it out, if this fails or takes too long the board can step in and resolve the issue
Conflicts are inevitable in any group; the challenge is in resolving them. Unfortunately, there is no procedure that we can put in stone and guarantee that all conflicts are resolved to everybody's satisfaction. Instead, we have a simple rule: if you find yourself in a conflict, try to resolve it yourself. Perhaps you might have a Private Talk [insert link]. If this fails, perhaps find a mediator to help you resolve it.
However, if the conflict gets out of hand the board will be forced to resolve the issue. In this case, it must be a very serious issue indeed, and therefore the board will likely respond by temporarily banning one or both members involved, at their sole discretion. Obviously, this is not an outcome that anybody wants, so finding resolutions on your own will be key.

11
7-the-legacy.md
View File

@ -1,11 +0,0 @@
# 7. The Legacy
Because every good idea that was once written down has been misinterpreted, we included information that led us to the system and the guidelines in this repository as The Legacy. This should by used as a "cipher" to interpret the system and the guidelines correctly and to explain a bit of the rationale behind them.
Some of these documents, discussions and comments on them are archived in the `legacy` folder of [the hackerspace blueprint repository](https://github.com/0x20/hackerspace-blueprint).
* [**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 tyranny of structurelessness**](http://www.jofreeman.com/joreen/tyranny.htm) is an essay by American feminist Jo Freeman inspired by her experiences in a 1960s women's liberation group that concerns power relations within radical feminist collectives. The essay looks back on the experiments of the feminist movement in creating organizations that do not have any structure or leadership. Jo Freeman states that leadership and structure did actually exist in these organizations but its existence was denied. This made it hard to hold the leadership accountable for their actions and made it hard for newcomers to figure out how the organization worked. As a solution, Freeman suggests formalizing the existing hierarchies in the group and subjecting them to democratic control.
* [**Dealing with disrespect**](http://dealingwithdisrespect.com/jonobacon-dealingwithdisrespect-1ed.pdf) by the legendary Ubuntu Linux community manager "Jono Bacon" explaining that "Most people are good people". "This book is about helping us to focus on good people creating good things, to preserve that spirit of sharing, and to protect against those whose primary contribution is obstruction and disrespect."