Pages

/LondonSpaces -- a list of misc other hackerspace-type organisations 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.

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

Making Change

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

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?

Infrastructure Projects

This is especially true for projects that have significance for the Hackspace as a whole:

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

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" may get applied to newcomers' transgressions too quickly without always explaining well what just happened

there's a great barrier to entry when formulating policy changes, hard for newcomers to engage, and newcomer considerations are consequently not included well

So I'm thinking...

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

re newcomer representation for policy changes:

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

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?

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!