Difference between revisions of "User:Martind"

From London Hackspace Wiki
Jump to navigation Jump to search
Line 19: Line 19:
 
* 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'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 [http://en.wikipedia.org/wiki/Consensus_decision-making informal consensus]. However we're not dogmatically democratic, there is no steering committee, and generally little formal leadership.  
 
* We generally make decisions about shared resources by [http://en.wikipedia.org/wiki/Consensus_decision-making informal consensus]. However we're not dogmatically democratic, there is no steering committee, and generally little formal 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.
 
 
* 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!
 
* 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 [[Organisation/Trustees | trustees]] will take over; they would prefer you do it instead.
 
* 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 [[Organisation/Trustees | trustees]] will take over; they would prefer you do it instead.
Line 36: Line 35:
 
* 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.
 
* 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 [http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith assume good faith]. You're not being helpful if your own replies serve to escalate rather than clarify.
 
** Strong recommendation: always remain polite, and [http://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith assume good faith]. You're not being helpful if your own replies serve to escalate rather than clarify.
−
* When coordinating group work: [http://wiki-archive.emfcamp.org/2012/articles/m/a/r/User:Martind/Induction.html#Making_Important_Decisions 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.
+
=== Making change ===
−
** 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.
+
* 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.)
 
* 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 ===
 +
This is especially true for projects that have significance for the Hackspace as a whole:
 +
* When coordinating group work: [http://wiki-archive.emfcamp.org/2012/articles/m/a/r/User:Martind/Induction.html#Making_Important_Decisions 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 ===
 
=== Recommended reading ===

Revision as of 18:00, 7 October 2013

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

Pages

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

  • The organisation is designed for minimal overhead. 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.

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

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

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
  • 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
Retrieved from ‘https://wiki.london.hackspace.org.uk/w/index.php?title=User:Martind&oldid=38198’