Interfaces
The Hackerspace Design Patterns were relevant and good for setting up the hackerspaces we frequent now. They were useful then, for the culture that existed then. Our scene has grown exponentially recently, and much of that old culture has been diluted and lost, including the unspoken wisdoms that were passed down.
We need some new structures and frameworks to help address the inherent problems that have become a mainstay of most hackerspaces:
- harassment
- elitism
- tyranny of the structureless
- personal attacks
- and so many more
What's an Interface?
To carry on the theme of software development they've been named Interfaces, which can be described as 'the ability to defer the implementation of a method', except in this case the method is replaced by a framework or a set of rules.
Participation of the community is key to how effective the implementation is. Often problems arise from societal and cultural biases, and participating in how to implement an Interface can lead to some self reflection as to why they are needed as well as what is needed to implement it.
You may need all of them, or you may not. Add on whichever ones you think are appropriate for your hackspace.
Who are they for?
- spaces with problems
- spaces without problems
Its important to understand that any informal arrangements in your culture/community could change without notice. Formalising, eg with interfaces, can give confidence in persistence of the culture you want.
Interfaces[edit]
Code of Conduct and Grievance Procedure[edit]
A Code of Conduct should seek to remove any discrimination or harassment, with the intention of making your hackspace a safe space environment.
A grievance procedure formalises the process for both reporting and dealing with any violations. Its not perfect, but it will add fairness and transparency.
The No Asshole Zone[edit]
You can add a few hard and fast rules that will keep in check the dominance displays and elitism prevalent in the atmosphere of most hackerspaces. The ones that usually crush any enthusiasm of sparks of participation.
- No feigned surprise
- When someone says “I don’t know what X is”, you don’t say “You don’t know what X is?!” or “I can’t believe you don’t know what X is!”
- No well-actuallys.
- Pedantic corrections that don’t make a difference to the conversation that’s happening.
- No back-seat driving.
Encourage your members to call people out on these transgressions
More detail available on the fsfe.org blog 'four social rules for a no asshole zone'
Subgroups[edit]
A subgroup should:
- be roughly autonomous
- have the option to use its own physical/online infrastructure
- have a person or persons identifiable as responsible for the running of the group, and to communicate with the other members
Creating subgroups allows people to organise without bothering the rest of the community. It removes central points of dependency ie not involving the hierarchies of the space and the inevitable bike shedding/heres-my-opinion-too behaviour.
Examples of Subgroups
- Network Infrastructure
- Woodworking
- Capture the Flag (IT Security) team
- Bio hacking
- Music hackers
- Grounds security and Custodial
- Finances
Supergroups[edit]
Examples of some super-groups (stakeholders outside the organization):
Be Exclusive to be Inclusive[edit]
Excluding toxic or poisonous behaviour, whilst being exclusionary, is often a boon for being inclusive of members who might be minorities or otherwise don't normally frequent your space.
Your community should come up with a set of guidelines/criteria for excluding people. Make sure you not only have input from minority groups, but also have those groups represented in the decision making process. If you're unable to find people, contact other hacker organisations that have done this before for advice.
