User:Martind

From London Hackspace Wiki
Revision as of 12:37, 17 July 2017 by Martind (talk | contribs) (→‎Obsolete Pages)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

Pages

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

Inspirational:

Other spaces:

Literature:

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
  • Encyclopedia Frown on Slate: "“The encyclopedia that anyone can edit” is at risk of becoming, in computer scientist Aaron Halfaker’s words, “the encyclopedia that anyone who understands the norms, socializes him or herself, dodges the impersonal wall of semiautomated rejection and still wants to voluntarily contribute his or her time and energy can edit.” An entrenched, stubborn elite of old-timers, a high bar to entry, and a persistent 90/10 gender gap among editors all point to the possibility that Wikipedia is going adrift.”"
  • "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)
  • "OpenStreetMap ten years on, and why it's time for a fresh slate", Richard Fairhurst on the role of the board in OSM: to supply the 5% of work that won't otherwise happen in an all-volunteer driven organisation.

Hackerspace diversity

When you're pondering questions of diversity in tech: remind yourself that an interest in technology for technology's sake is highly unusual. Most people care more about the rest of life. Instead of trying to cater your own tech activities to "minority groups", appreciate that there are many other hacker/maker activities where technology only plays a tangential or supportive role. Often these are the most interesting and potent applications of tech!

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, see Keyholders

Obsolete Pages

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