Hackerspace Design Patterns 2.0: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
m (→‎New Hackerspace Design Patterns: added doublespace for tidiness)
No edit summary
Line 168: Line 168:
Ed Platt's new Patterns:<br>
Ed Platt's new Patterns:<br>
https://elplatt.com/new-hackerspace-design-patterns
https://elplatt.com/new-hackerspace-design-patterns
'''Reboot Pattern''':<br>
'''Problem''':<br>
When the space is brand new, everyone putting their energy into the space is creating something new, and are excited about it, and bond over it.  After a few years, people come and go, and that feeling and energy of new-ness is gone -- and people who are newer to the space have the sense that the space has existed long before them, and will continue on its own.  Also, the culture of the space changes over time.  Some bad behaviors might start creeping in.  And some people who have been putting lots and lots of their time and energy into the space tend to get burned out.<br>
'''Solution''':<br>
When you're OS isn't working so well, turn it off and on again!  This often helps!  So, have a Reboot for your space!  Close the space for a month, and only let in people who are helping fix up the space.  It's very bonding.  It renews the feeling of new-ness, the feeling that each person has that they are creating the space that they are wanting to be a part of.  And don't let in people who don't belong.  After opening again, keep attracting people who belong (i.e., people who both benefit and contribute to the space -- and "contribute" can be in many forms: financial, cleaning, fixing, giving classes/workshops, learning cool things, sharing their positivity, making people at the space feel good, whatever people at the space feel is positive); and keep people out who are bad for the space.  This collective behavior keeps the "cultural immune system" of the space healthy and strong.  Have a mini-Reboot annually to regenerate this year after year.<br>
'''An alternative to a Reboot''': is to have a Big Project that gets a majority (or, ideally, all) of the people at the space psyched to be helping bring to reality.

Revision as of 13:47, 9 August 2015

Wanted: your Hackerspace Design Patterns

I submitted a proposal for a talk at CCCamp 2015: an updated presentation of the Hackerspace Design Patterns. It was accepted!

tl;dr:

Have you observed a Pattern (what works well, and what not so well) at your hackerspace that you think others can benefit from? If so, please share it with me, so I can share it with others in my talk.

mitch AT CornfieldElectronics DOT com

Design Patterns

Design Patterns are generalize-able statements of what works well and doesn't work so well -- so that others can learn what may work well (or not so well) for them.

Hackerspace Design Patterns

The original Hackerspace Design Patterns was presented at CCCamp 2007 and 24C3 when there were only ~40 hackerspaces in the world. Here's the original Design Patterns (which are way worth reading!):
http://events.ccc.de/congress/2007/Fahrplan/attachments/1003_Building%20a%20Hacker%20Space.pdf
These patterns directly inspired the creation of the hackerspace movement. Now that there are over 2,000 hackerspaces listed on hackerspaces.org, it's time to update the Hackerspace Design Patterns to include 8 years of additional collective experience -- and present them at CCCamp 2015.

Somewhat updated Hackerspace Design Patterns

A somewhat updated version (that needs more updating) of the Hackerspace Design Patterns are listed at hackerspaces.org:
https://wiki.hackerspaces.org/Design_Patterns

Your Observations Wanted

Do you have any observations of what works well, and what doesn't work so well at your hackerspace (or any hackerspace)? Can you state it in a way that may be generalized so that people starting (or running) hackerspaces may benefit from your observation? If so, please send me your observation, and I'll incorporate it into my talk.

mitch AT CornfieldElectronics DOT com

Workshop after the talk at CCCamp 2015

My 30-minute talk at CCCamp 2015 will include some old and some new examples. After the talk we will have a workshop on Hackerspace Design Patterns, and really get into what works well, and doesn't work well at hackerspaces. I'll take notes, write it up, and post it so that everyone starting or running a hackerspace can benefit from our collective experiences.

Thanks!
Mitch.

New Hackerspace Design Patterns

The following were provided to me by several people from several hackerspaces:

Please feel free to add your new Patterns here:


Spreadsheet Pledges Funding Pattern: There is a large piece of equipment that several people want, but that your space cannot afford. Create a spreadsheet and have members enter pledges. When the total pledged amount exceeds the cost of the item, call in the pledges and purchase the item. It is important that pledgers understand that they will not be paid back -- they are paying to bring useful equipment into the space. Only pledge what this is worth to you.


NonexistentKitchenPattern: Don’t have a kitchen at your space. Nothing turns a group of diverse individuals into competing cliques like using your hackerspace as shared living quarters. Have a fridge that is cleaned once a week, whether it needs it or not, whether you think food should be thrown away or not (it should).


ApathyByAThousandCutsAntiPattern: Nothing kills community spaces like apathy when bad things happen. Be aware of individuals bringing bad things into the space and address them early. When many such individuals crowd a space, they kill the creative energy of others by swamping them with drama. This in turn causes people to ignore bad behaviors, giving implicit permission and inviting more of the same bad behavior. Community is hard, and you should deal with such issues as they arise, and not let them gather.


Creative Chaos Pattern: The Stage Fright Anti Pattern:
Problem: As a group grows and becomes noticed in media and the surrounding local community, its solo, group, and public projects as well as public events are perceived differently. This can lead to higher assumed expectations that outpace the output of quality, speed, and/or intricacy, and can tie in with some other Hackerspace Design Patterns. This can be affected by the Sine Curve Design Pattern, for instance. This can affect any of the following: new guests who may feel intimidated before even arriving or as a diametric who expect to see robots greet them with 3d printed bon bons, new as well as longstanding guests and members who attempt to discourage projects of perceived lower quality, members and recurring guests who begin to feel pressured into producing higher quality or participating with more effort, the general public, leaders in the community who are not a part of the Hackerspace, local and global media, partners, and sponsors.
Solution: Clearly identify when public projects and programs are low barrier when announcing them, and communicate which skills and experience are needed for activities with higher participant expectations. Also, clearly identify the intended goal of a project or event when promoting it. Encourage members and patrons to embrace an adventurous side without fear of failure, and elect a community welcome wagon that does things like offer constructive criticism particularly for new guests and members. Have clear paths written on how to best perform a public project or event, with specific expectations detailed. Provide one or more contacts to help members add public activities like workshops, and try to schedule frequent new member orientation classes or less frequent smaller classes about how to add public activities to the Hackerspace's promotional queue and the expectations of running public events. Burning out a core group of volunteers is never a good idea, and some sustainability can be procured from the encouragement of members to create their own public programming in activities and resources. Make it clear that there are multiple tracks of different quality and intricacy expectations. For private solo and group projects, there should really be no expectations outside of the group's charter or general ethos of respecting the space, peers, and other projects. Discourage elitist policing and be swift and firm. Remind a frustrated member that they may be incurring this Anti Pattern or helping it along, and ask them to find constructive ways of helping that member with their project instead of berating it, or simply ask them to step away and leave the member and their project alone.


The Resource Replenishment pattern. (Extension of the Club-Mate pattern.)
Problem: A particular resource (soda/beer/h2o2/C3H7OH) is consistently in limited availability and nobody knows who should buy it.
Solution: The person who is most able (supply) and who uses the most (demand) provides replenishment during phases of heavy use. A member of the space who is qualified to handle funds should take allocated funds and replenish supplies.
(common implementation: the Quelab soda fridge is replenished often by people who want a particular soda, which is commonly on sale alongside other sodas. Funds collected from the usage of soda, beer,etc go into buying more soda, beer, etc. respectively.)


The Anti-Sponsoring Anti-Pattern.
Problem: Independence is cool, but rent needs to be paid.
Solution: Hackerspaces in big places (like tens of thousands of sqft industrial-zone warehouses) can benefit from occasional bumps in funding availability. This doesn't mean you should feed off someone else forever as a space; however, the occasional "yes we will take your no-strings-attached dollars with a comma and some zeros" is a weighted decision. Supplement and be in the black for longer when possible.


The Viewers Like You Pattern.
Problem: Your hackerspace needs money.
Solution: Run a fundraising campaign, NPR style. Tote-bags and coupon books 'n all.

Converse anti-pattern: You run them and can't make up on your printed totes, or you're running them every month.


The Who's on First anti-pattern.
Problem: Your core workings of the space are dependent on several people being there. The question "Who do I give money to" is greeted with "Uhhhhhhhhhhhhhhhhhhhhhh". The question "How do I become a member" is answered with "You'd talk to... J. Hacker, who's... not here tonight."
Solution: If a single person is necessary for a single task, there should be several. If that task is common, or involves the running of the space, that person should *be there* when the door is open or *available* more often than not.

The person who takes money should be there every night. At open time. If you're a 24/7 space, there should be some *way* to contact said person *easily* -- and it should be **KNOWN**.


The Focus-Group Pattern.
Problem: A change to the rules has led to outcry from a set of members. The problem fundamentally hinges around a particular topic (e.g. inclusivity, feminism, etc).
Solution: A meeting is held at regular intervals to discuss the issue by any member who a) effected the change, b) is affected by the change or c) feels the change is inappropriate.
NB: Have these off-site, somewhere nice, like a local restaurant. Around food.


The space-sharing pattern:
Problem: Your hackerspace could use with some income supplementing. A group that some of your members are a part of needs a space to work or hold meetings in.
Solution: Pimp the space and offer at a (reasonable) price the usage of the space in off-times by groups. Be willing to be flexible for each group and work out a *signed* agreement -- contract or Notary Public letter to one another. A usage schedule may need to be established for popular tools.
Converse Anti-Pattern: Now there's stuff sitting in the middle of your shop that isn't really the responsibility of any of your members.
Solution: Have a solid mechanism in place for dealing with junk. PS:One's Tidyspace policy is good at removing junk in a fair way.


The Cabin Fever Pattern.
Problem: A contentious disagreement breaks out between a large number of members. The topic varies, but the contention occurs on a semi-regular basis. For example, at the end of January/beginning of February (northern hemisphere). Or every 4 months.
Solution: The topic may be valid, but it's important to examine the root of the -vigorousness- of the disagreement. Are external/seasonal influences affecting the members? Sometimes people start fights to blow off steam. If the time of year or weather is affecting the members, make sure that important decisions aren't being adversely influenced by seasonal concerns. If regular steam-blowing is needed, establish a regular series of group projects/common goals to give people something to focus their energy on, instead of directing it at each other, and set the cycle length to complement the existing cycle of contention.


Ed Platt's new Patterns:
https://elplatt.com/new-hackerspace-design-patterns



Reboot Pattern:
Problem:
When the space is brand new, everyone putting their energy into the space is creating something new, and are excited about it, and bond over it. After a few years, people come and go, and that feeling and energy of new-ness is gone -- and people who are newer to the space have the sense that the space has existed long before them, and will continue on its own. Also, the culture of the space changes over time. Some bad behaviors might start creeping in. And some people who have been putting lots and lots of their time and energy into the space tend to get burned out.
Solution:
When you're OS isn't working so well, turn it off and on again! This often helps! So, have a Reboot for your space! Close the space for a month, and only let in people who are helping fix up the space. It's very bonding. It renews the feeling of new-ness, the feeling that each person has that they are creating the space that they are wanting to be a part of. And don't let in people who don't belong. After opening again, keep attracting people who belong (i.e., people who both benefit and contribute to the space -- and "contribute" can be in many forms: financial, cleaning, fixing, giving classes/workshops, learning cool things, sharing their positivity, making people at the space feel good, whatever people at the space feel is positive); and keep people out who are bad for the space. This collective behavior keeps the "cultural immune system" of the space healthy and strong. Have a mini-Reboot annually to regenerate this year after year.
An alternative to a Reboot: is to have a Big Project that gets a majority (or, ideally, all) of the people at the space psyched to be helping bring to reality.