User:Martind: Difference between revisions

From London Hackspace Wiki
Line 30: Line 30:


=== Making Change ===
=== 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.  
* 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: [http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality 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.)
* 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.)


Revision as of 15:25, 17 December 2013

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

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

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

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:

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

Recommended Reading

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

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

Member Manual

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

Welcome

Howto

About us

Useful resources/links

Hackspace culture

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

Obsolete Pages

Retrieved from ‘https://wiki.london.hackspace.org.uk/w/index.php?title=User:Martind&oldid=39348’