User:Martind

Martin Dittus, martin@dekstop.de, @dekstop, dekstop.de. Long-time member, London Hackspace trustee since late 2011.

Pages

• /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
• /LfmHardwareAuction
• /Spacewarming

The Hidden Laws of Hackspace

Fundamentals

• 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 leadership.
• 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.
• The organisation is designed for minimal overhead. We're not a school, company, or sports club: we don't provide structured guidance and training.
• 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

• We're a community workshop. 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.
• When coordinating group work: Involve your community in larger decisions.
  • This is especially true for projects that have significance for the Hackspace as a whole. Don't turn yourself into a bottleneck; instead allow others to help you whenever you are stuck.
  • Don't just do it all yourself; make sure to tell people about your plans. Otherwise there's a good chance you'll get distracted by silly misunderstandings and oversights.
• 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.)

Recommended reading

• 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
• etc.

Spc Mgmt

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!

Unsolved

• 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.

In Progress

• 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: [1])
• Tool access control linked to member accounts

Done

• (Is anything ever done?)

Signage

• 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
• Classroom
• Quiet room
• Toilets - female
• Toilets - male
• Toilets - mixed
• Toilets - mixed (no ideographs)

Member Manual

Pages I'd include in a member's manual:

Welcome

• Guides/GettingStarted
• Membership
• Subgroups
• Weekly_Open_Evenings
• Laboratory_24/Getting_There
• List_of_mailing_lists, IRC

Howto

• Guides, esp:
  • Guides/Using_the_space
  • Guides/Bringing_items_to_the_space
  • Guides/Planning_an_event
  • Guides/Running_a_pledge
  • Guides/Filming_in_the_space
• Maintenance, Maintenance/Adopt-a-Spanner
• Faceplant

About us

• Organisation
• Organisation/Trustees
• Rules
• Grievance_Procedure

Useful resources/links

• Suppliers

Hackspace culture

• Other_Hackspaces
• Starting a Hackerspace

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.

Trustee Induction

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 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