User:Martind

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

Pages

• /OpenWorkshopsLondon -- a fast-growing list of other communal workshop spaces in London

See end of page for old/obsolete pages.

The Hidden Laws of Hackspace

Fundamentals

• The organisation is designed for minimal overhead, and 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 job roles, 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. (Russ summarised this well on the a mailing list.)
• 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 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.)

Hackspace Online

• The mailing list (and IRC) 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.

Posting Requests to the Mailing List

To store things, to borrow tools, ...

• I think we’ve generally made the experience that the nature of a request makes a difference in how it is received. This maybe hasn’t been made as clear (it’s not explicitly stated in the rules), but it’s worth bearing in mind.
• These kinds of requests require us to strike a tricky balance — they’re almost always requests for special treatment, for a little bit of privilege. If we allowed all 800 members every little additional bit of freedom/space/... that someone asked for on the list the system would break down.
• If you’re asking for more, or if you’re posting a last-minute request, then be prepared for people to be sceptical. This is equally about making sure we keep the right balance, as it is about preventing an expectation that it’s OK to send large last-minute requests. With that in mind it maybe becomes clear why sometimes people’s first reactions tend towards declining.
• And yes, when we then also take into account people’s very different personalities, there sometimes can be a general tendency by some people to post moody replies too quickly — but generally I think we’re quite good at then dampening their impact later. As in all matters with large groups, it’s important to acknowledge that there will be opinions that are surprisingly negative, but it’s equally important to realise that these may not be very representative. (Also note that our code of conduct requests that people always be polite.)
  • SamLR provides a great example of an email reply that points out LHS rules in a way that is both polite *and* friendly.
• I think our experience also shows that a person’s engagement in the community can greatly affect how their requests for privilege will be received: people will be much more open towards special requests if they know you well, if they’ve seen and been impressed by your work, if they maybe even benefitted from your work or your knowledge. If they’ve seen how much you contribute in other ways.

Making Change

• Good work usually makes more change happen than good opinion. You don't solve a problem by throwing demands at it, especially if you then have no intention to participate in the work.
  • See also: bikeshedding
• You will likely be more successful by handing the problem over to a group of people who get along well and then letting them take charge. Accept that 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.)

Infrastructure Projects

You can assume that most work at the Hackspace is purely self-motivated, and this generally works well. However in the context of infrastructure projects for the Hackspace as a whole (tool maintenance, access control, renovations, ...) this approach can become problematic. A great way to stop *any* progress is to announce a fancy project that addresses key shared concerns, and then stop working on it without telling anyone. This happens surprisingly often.

Experience shows that some adjustments can prevent problems later on:

• 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. Strictly speaking you should probably also inform yourself about what other initiatives came before yours, and build on them.
• Don't be too protective of your work and turn yourself into a bottleneck; instead allow others to help you whenever you are stuck. Find the local specialists. When coordinating group work: Involve your community in larger decisions.
• And most importantly: make a habit of handing over your work to others once you realise you don't have the time/patience/resources any more to support it. Don't just drop it and run away.

These suggestions reflect the nature of infrastructure work: others may be relying on you to actually finish. However taken together these suggestions may make your spare-time experiment feel like tedious "work": depending on your personality type and mood you may feel like the overhead is tar-sanding your project, and it becomes hard to stay motivated. So in the interest of progress it is sometimes best to keep quiet; apply your best judgment whether this applies to you, and avoid creating needless bottlenecks for others while you play.

Informal Authorities

(this needs work, and intersects with a few other topics here)

• Frequently a change proposal will not only be judged on its own merits, but also by who the proposer is. (This is not a hard rule, but happens frequently enough to make it noteworthy.)
  • This reflects our particular political culture: we often place a stronger emphasis on interpersonal relationships than purely democratic values.
  • In other words: there still are informal lines of authority in our unstructured organisation, these are based on soft factors ("seniority", conduct, past interactions, personal preference, ...)
  • These informal lines of authority likely have similar functions to more formal lines of authority (job titles etc) in more structured organisations. E.g. people may use these as cognitive shortcuts when they form judgments.
• It's not entirely clear to me yet whether this is a good thing, or to what degree it's important that this takes place.
  • It can be a good decision-making shortcut: it can simplify the social problem-solving process from having to perform the full argument with a large group to being able to "delegate" certain decisions to others based on a degree of trust.
  • It reflects our reliance on self-motivation instead of more formal means of control: it allows motivated people to take charge without having to justify every step.
  • However it also introduces an inequality: it restricts the degree to which "new" members can take charge without being questioned.
    • We've had some clear cases where exemplary ("competent") new members managed to gain great trust by a large number of informal authorities quickly.
    • We've had many more examples where "imperfect" initiatives of new members resulted in tar-sand debates and impasses, sometimes at the cost of burning their enthusiasm, or even turning them away.
  • I.e., we're not good at encouraging initiative, at fostering new authority figures: the ones that "succeed" were already a good cultural fit before they joined. The others are eaten by lions.
• It is not clear to me how to change this (provided we wanted to change this), particularly considering our least-effort approach to community facilitation.
  • Is there a least-effort equivalent to a guided induction? E.g. safe zones where people can be active participants in our culture without having to feel tested?
  • How can we reveal existing intangible bias in our decision-making, make it tangible without being confrontational about it?

Recommended Reading

Key Hackspace texts:

• UK Hackspace Foundation wiki: Starting a hackerspace
• Russ Garrett: Starting a Non-Profit in the UK
• UK Hackspace Foundation wiki: Charitable status
• Mailing list discussions: LHS won't benefit from reduced business rates
• UK Hackspaces mailing list: Access to under-18s, Health & Safety, Insurance

Inspirational:

• Running a Hackerspace Tumblr

Literature:

• 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.
• Toxicity, Inclusivity, and Community Size, on the practical limitations of inclusivity in volunteer-run hackerspaces.
• 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."
• A Group Is Its Own Worst Enemy, on the need for barriers to entry and controlled community growth.
• 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
• etc.

Managing Growth

(This section is still new, will be refined over time.)

Mistakes as Precondition for Learning

I think it's important to make mistakes, and to allow newcomers to "screw up". These are often key steps in the long process of becoming familiar with our culture, and there's no need to shout at people for having transgressed once. Put your rule hammer away!

Instead a perceived "transgression" should be an opportunity for a conversation; a chance to provide context, to explain our expectations, to convert ("de-program") a newcomer. And also an opportunity to realise that maybe it was all a mis-understanding.

So I'm thinking…

• Maybe there should be a cost to rule hammer use: "don't moderate without explaining"

(I my personal opinion you'd be actively harming community renewal by being overly aggressive. You scare away newcomers by reinforcing the (wrong) notion that this is an old-boys club of people who are happy enough with what they have, will gladly take your money, but don't really want to share.)

Subgroups as Growth Mechanism

I'm quite interested in moving towards a "federated/syndicated" model of operations: to foster the formation of subgroups (meetups, special-interest groups, regular workshops, …) within the LHS that manage their own space/resources. This doesn't have to be very formal.

• It has become harder to get to know people as the org grows, and as our physical space expands. Topical group settings attract newcomers, and topical meetings/workshops/mailing lists may make for a less daunting introduction to the LHS.
• It has become harder to uphold our "everyone's in charge" governance model: with growth (and age) comes a sense of a loss of ownership. It stops being "your" space, and becomes a space owned and managed by an invisible group of hundreds, most of whom you'll never meet.
  • I'm interested in fostering a stronger culture of group-maintained infrastructure, as opposed to our previous "we all are responsible" (i.e., nobody feels responsible) model.
  • Subgroups can be interested in keeping particular infrastructure in a working state, and can develop the skills/resources to maintain it.

I'm particularly curious about means of federating "maintenance work" that aren't super-formal (e.g. without explicit commitments/requirements/ownership claims), because:

• we've not actually had *that* many subgroups that lasted more than a few months; the ones that do often have rotating membership and little continuity. That's in the very nature of these informal activities.
• don't want to prevent subgroup growth by placing too many demands on them early
• instead would simply like to rely on a subgroup's ability to come up with their own little maintenance rituals, e.g. a cleaning session after every meetup; and then have these rituals spread organically

Etc.

I think it's also useful to recognise that certain kinds of maintenance will be very hard to provide continuously; and to then ponder if that's the point where a) the org starts paying for a service or b) the org decides the activity is not worth supporting.

Limits to Heterogeneity?

Atm there's an implicit assumption that the LHS is a space to practice a particular shared culture (hacker/maker/open source/sharing/...) As we grow more newcomers have not been exposed to this culture. (These are: short-term users, newcomers, purely self-interested users, ...)

• I think there's great value in building safe teaching spaces to learn the culture; pledge drives and social nights work well I think, and I'm still hoping the Hack the Space Day will become more popular
• but of course: can't expect that everyone *wants* to learn the culture.

There's an open question in this: how do we want to handle with people who don't want to learn the culture? (Because they don't know better, haven't learned yet; or because they disagree/refuse)

• do we still want to support them?
• is our (limited) energy best spent on converting them?
• are there systematic means of still letting them interact in productive ways, somehow channeling their self-interest into things that benefit the org?
• when do they become a liability?

Misc

(Not sure yet if this is actually important.)

How can we address the concerns of newcomers, "absent" supporters, and casual users when considering "policy" changes, e.g. when refining our code of conduct, or when discussing our minimum payment amount? They're (almost by definition) never around when we discuss such fundamental matters, but they will be affected by it in different ways than more active users!

• we could consider proxies (people who frequently engage with newcomers and can empathise)
• or even panels (invited groups of newcomers) when discussing policy changes
• of course that's hard to reconcile with our very informal approach to policy-making...

Recommended Reading

• "The Rise and Decline of an Open Collaboration Community: How Wikipedia's reaction to sudden popularity is causing its decline". A great discussion of Wikipedia's struggle to deal with growth and simultaneously retain new users. The similarities to LHS growth patterns are striking:
  • Automated reversion tools help reduce spam, but users employing them on newcomers' edits don't often explain why edits are reverted, which alienates new people. (LHS: the "rule hammer" and "ban hammer")
  • there's a great barrier to entry when formulating policy changes, hard for newcomers to engage, and newcomer considerations are consequently not included well
• "The (In)compatibility of Diversity and Sense of Community" (PDF), simulations suggest group diversity is in conflict with group cohesion -- another argument for forming interest groups within large diverse communities to maintain overall cohesion (commentary)

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
• Code of Conduct
• 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
  • Needs a registered nick (see e.g. here for instructions)
  • Invite to channel: /invite your_nick #london-hack-space-directors
  • Make channel op: /msg chanserv flags #london-hack-space-directors your_nick +o
• Add to trustees@ email
• Share Dropbox, Trello
• 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, see Keyholders

Obsolete Pages

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