proofread

2-do-ocracy.md

@@ -6,7 +6,7 @@
 * 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.
 * If somebody complains: Either **revert it**, or work out a solution with the person who is complaining.
 
-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 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.**
+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.**
 
 ## Why not Democracy or Consensus?
 
@@ -14,22 +14,22 @@ Democracy and Consensus suffer from the same issue: everyone has an opinion abou
 
 * 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 on the 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 supports fully. 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 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 causing 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.
+* 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 factors that are important.
+A do-ocracy naturally emerges when the environment is right. There are a number of important factors.
 
-* **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 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.**
 
-## Non-coercive authority
+## Noncoercive authority
 
 > "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."
 
@@ -47,7 +47,7 @@ Some things are too sensitive to be handled by do-ocracy alone, or are irreversi
 
 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 ..
+## 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 everyone’s 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 they’re qualified.

3-meetings.md

@@ -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 it's hard to reverse it when people complain.
+* If you want to do something that affects a lot of people in the space, and is hard to reverse when people complain.
 
 Things you can discuss on a meeting:
 
@@ -29,11 +29,11 @@ Any member can schedule a meeting.
 
 During meetings, the normal decision making model is "provided nobody says no": you discuss a topic and propose an action during a meeting. You ask if anyone objects to that action. If nobody objects, you have the permission to do that thing. When a decision has been made, you need to write down the exact decision in the meeting notes.
 
-Note that this intentionally favors the "yes" vote: there is a slight barrier to speak up and say "no". The thinking behind it is that we want to make the barrier to "doing" as low as possible. We only want people to voice their opinions when they think it's really important or when they are explicitly asked.
+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.
 
 ## Why not regular consensus?
 
-[Consensus-based decision making](https://en.wikipedia.org/wiki/Consensus_decision-making) aims to involve as many stakeholders as possible in a decision. This is the exact opposite from our system, where we want to involve as few stakeholders as possible in a decision, in order to lower the barrier to "doing" as much as possible. Do-ocracy gives as much power as possible to the person doing it, instead of to the persons who have an opinion on it. When you want to do something, you have to make sure that nobody will hate it, instead of making sure that everyone is pleased.
+[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.
 
 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.
 
@@ -79,12 +79,12 @@ The topic is put on the agenda of the meeting and is announced on the Mattermost
 
 ### Meeting 1
 
-The topic is discussed in group and requires a 100% consensus to reach a group decision. The motivation for striving for consensus is because consensus comes with characteristics that benefit the hackerspace:
+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
-* forced to listen to opposing ideas that can give new insights
-* they can bring smarter compromises
-* <http://en.wikipedia.org/wiki/Consensus>
+* 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.
 
@@ -102,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 he can distribute over the different proposals.
+* 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_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.
+* **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:
 
@@ -132,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    |
 | -------------------------- |:------------------------------:| --------------:|

4-the-board.md

@@ -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 the person 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 them and let them know how the group feels.
 
 It's important for the board to communicate openly about what they do.
 
@@ -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 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.
+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?
 

5-membership.md

@@ -20,11 +20,11 @@ Why this process?
 
 *The members create and maintain the hacker environment.*
 
-When a conflict/problem can not be resolved between individuals/via do-ocracy or when it impacts the group, a group decision is required. Any member can request that a decision is made by the Group Of Members instead of by do-ocracy/individual members.
+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 or individual members.
 
 The members should do the following things as a group.
 
-* Creating and patching the hackerspace blueprint.
+* Create and patch the hackerspace blueprint.
 * Solve problems in the hackerspace when do-ocracy cannot fix them.
 * Electing the board during a General Assembly.
 

6-guidelines.md

@@ -51,15 +51,15 @@ There is a clear distinction between "personal" and "space" projects. Keep this
 * 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
 
-If you damage or lose space property, you have to notice the community immediately in the Changelog or the Main channel on mattermost. Explain what happened and if/how you will fix it.
+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" channels on Mattermost. If a somebody disagrees with you taking it out of the space, make that person happy or put it back.
+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 a someone disagrees with you taking it out of the space, make that person happy or put it back.
 
 ## Space maintenance
 
@@ -95,7 +95,7 @@ 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 need to make a lot of noise, ask if you are not intruding/disturbing.
+* If you need to make a lot of noise, 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

README.md

@@ -10,11 +10,11 @@ We created our very own hackerspace in Ghent. We had two rules: be excellent to
 
 * 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.
-* **No solution is worse than a bad solution.** Because when problems aren't solved, they pile up until the community falls apart.
+* **Having no solution is worse than a bad solution.** Because when problems aren't solved, they pile up until the community falls apart.
 
 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 have been refining this system for many years now, 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 so 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 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!
 
 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.