- /LondonSpaces -- a list of misc other hackerspace-type organisations in London
- /Broken -- perceived LHS problems people currently complain about at the Hackspace.
- EMF 2012 (wiki archive, archived user page, old meeting minutes)
- Propaganda: The Cost of Hacking (github)
- Bitcoin Weekend 2011
- Pachube/Nanode evening at London Hackspace
- /Young Hackspace
- /Document Log Discovery Platform
The Hidden Laws of Hackspace
- A little bit of passion goes a long way. Most work at the Hackspace happened because someone was curious.
- We're a social space that is heavily shaped by its interpersonal relationships. The hackspace does not work through processes or documentation, but through a critical mass of people who want to hang out with each other.
- We generally make decisions about shared resources by informal consensus. However we're not dogmatically democratic, there is no steering committee, and generally little formal leadership.
- Although nobody is being paid to help fix your problems, some individuals may be surprisingly eager to help you out. Don't take this for granted, don't misunderstand this as an invitation to be lazy, and make sure to thank them afterwards!
- It is wrong to say: "there's no-one in charge". You're in charge. If you are unable, then find someone who can take over. And if that fails the trustees will take over; they would prefer you do it instead.
Learning at the Hackspace
- The organisation is designed for minimal overhead. We're not a school, company, or sports club: we don't provide much structured guidance and training. Some of our members might run training workshops, but these are often infrequent and usually informal.
- We heavily rely on the self-motivation of our members. Your best first experience is when you come with a project in mind, and need a little bit of help or access to tools we may have.
- If you come here unprepared: be patient and make time for a long learning experience. Observe, and talk to the people around you.
- Don't be annoyed if you don't understand right away. Sometimes there's a good reason, sometimes it's simply a large group's path of least resistance.
- We don't focus much on outreach, structured introductions, presentation. Consequently our "induction experience" sucks.
- We have made many simple and complex plans to change this, but so far have failed to implement most of them.
- I don't know exactly why this is the case; it's certainly not out of ignorance, ill-will, protectionism, elitism, ...
- (This maybe already tells you everything you need to know about the abilities and limitations of the Hackspace.)
The Hackspace Community
- The mailing list may seem like a scary place at first, but it is also one of our greatest assets: the community hivemind. It can have great intensity but also often is a source of great wisdom. A place where many voices build on each other, but also a source of many irreconcilable contradictions. Becoming familiar with it this is one of the key rites of passage for new members.
- Strong recommendation: always remain polite, and assume good faith. You're not being helpful if your own replies serve to escalate rather than clarify. See also: our Code of Conduct.
- Good work usually makes more change happen than good opinion. Instead of solving a problem by throwing demands at it you will likely be more successful by handing it over to a group of people who get along well and then letting them take charge. If you don't show up and contribute then it'll be hard for you to influence the outcome.
- Making change is hard: it involves lots of initiative, and the patience to try again until you find the right way to make it work. It may entail having to change the habits of many people who have no reason to listen to you. This is by design. (And yes, it's not always good.)
This is especially true for projects that have significance for the Hackspace as a whole:
- When coordinating group work: Involve your community in larger decisions.
- Don't be too protective of your work and turn yourself into a bottleneck; instead allow others to help you whenever you are stuck.
- Make sure to tell people about your plans. Otherwise there's a good chance you'll get distracted by silly misunderstandings and oversights, and lots of redundant labour.
- Hacker ethics, which inform many of our key values: decentralisation as default organisation principle, the hands-on imperative, merit before status, mistrust of authority, etc.
- Jo Freedman's The Tyranny of Structurelessness, on the practical implications of running a structureless organisation
- Elinor Ostrom's design principles for common-pool resources, on means of managing and protecting a shared limited resource: the community, the space, and its materials
- A Group Is Its Own Worst Enemy, on the need for barriers to entry and controlled community growth.
- Joseph Reagle, “Free as in sexist?” Free culture and the gender gap, which argues that: "(a) some geek identities can be narrow and unappealing; (b) open communities are especially susceptible to difficult people; and, (c) the ideas of freedom and openness can be used to dismiss concerns and rationalize the gender gap as a matter of preference and choice."
- Running a Hackerspace Tumblr
There's a need for better tools to manage your highly successful hackerspace. Here are some free ideas. Get in touch if you end up building one of these!
- Poster-making website: a layout template with basic customisations. Cf http://www.keepcalm-o-matic.co.uk
- Pledge drive automation (it's possible to use Semantic MediaWiki and Wiki forms for this, see pledge drives at Technologia Incognita for an example)
- Registration and announcements for training sessions (e.g. Lasercutter_Training)
- Component ordering tool. E.g. a simple tool for re-ordering things we want to keep on stock (see consumables), a collaborative components shopping list for larger projects, a tool to group purchases of individuals to reduce shipping cost, etc.
- Member decision-making tools: discourse and consensus testing (lots of people are working on such software atm, and there's our own OneClickOrgs. See also: )
- Tool access control linked to member accounts
- (Is anything ever done?)
- Recycling bins
- Under construction
- Wireless network
- Please clean up after yourself
- Please clean up after yourself (workshop)
- Exit door: last to leave?
- Leaving the workshop?
- Please close the lift door when done
- Quiet room
- Toilets - female
- Toilets - male
- Toilets - mixed
- Toilets - mixed (no ideographs)
Pages I'd include in a member's manual:
- List_of_mailing_lists, IRC
- Guides, esp:
- Maintenance, Maintenance/Adopt-a-Spanner
I don't think it's worth including pages like Infrastructure, Projects, OneHundredThings, Training_Directory, Equipment, Project:100_Paper_Cuts -- they're useful resources but very badly maintained and always out of date.
Things to go over with new trustees.
- Set up IRC with bouncer, add to directors channel
- Add to trustees@ email
- Share Dropbox
- Create OCO account
- Add their keys to the passwords file
- Have them read the Rules, the Code of Conduct, the Grievance_Procedure, and at least skim the constitution
- Review current issues: member warnings, recent/current mediation efforts
- Let them participate in a few day-to-day tasks (e.g. member disputes)
- Add them to the mailing list moderators list (if desired)
- Add them to the uk-hackspace-organiser-comms list
- If available: hand over keys from predecessor