Hackerspace Design Patterns 2.0: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
(added link abt TMI/Rules-itis)
 
(10 intermediate revisions by 5 users not shown)
Line 2: Line 2:


I submitted a proposal for a talk at [http://events.ccc.de/camp/2015/wiki CCCamp 2015]:  an updated presentation of the '''Hackerspace Design Patterns'''.  It was accepted!
I submitted a proposal for a talk at [http://events.ccc.de/camp/2015/wiki CCCamp 2015]:  an updated presentation of the '''Hackerspace Design Patterns'''.  It was accepted!
'''[https://events.ccc.de/camp/2015/Fahrplan/events/6842.html Hackerspace Design Patterns 2.0 Talk]''' at [https://events.ccc.de/camp/2015/wiki/Main_Page CCCamp2015]<br>
'''When''':  [https://events.ccc.de/camp/2015/Fahrplan/schedule/2.html Day 3], Occurred on Saturday 15-August from 10:30am to 11:00am.<br>
'''Where''': Project 2501 Tent (aka: Tent A)<br>
[https://events.ccc.de/camp/2015/Fahrplan/events/6842.html https://events.ccc.de/camp/2015/Fahrplan/events/6842.html]
Immediately following the [https://events.ccc.de/camp/2015/Fahrplan/events/6842.html Talk], I led a [https://events.ccc.de/camp/2015/wiki/Session:Hackerspace_Design_Patterns_2.0_Workshop Workshop / Discussion].  All were welcome!  If you were just curious, or if you were interested talking about what has worked well (and what has not worked so well) at your space, then let's keep on discussing and distilling out new Patterns to add to the Hackerspace Design Patterns for all hackerspaces (forming, new, and old) to benefit from, far into the future.<br>
'''[https://events.ccc.de/camp/2015/wiki/Session:Hackerspace_Design_Patterns_2.0_Workshop Hackerspace Design Patterns 2.0 Workshop]''' at
[https://events.ccc.de/camp/2015/wiki/Main_Page CCCamp2015]<br>
'''When''': Occurred on [https://events.ccc.de/camp/2015/wiki/Village:Norton%27s_Obscure_Phoggy_Embassy#calendar Day 3], Saturday 15-August from 11:15am to 1:30pm.<br>
'''Where''': [https://events.ccc.de/camp/2015/wiki/Village:Norton%27s_Obscure_Phoggy_Embassy Norton's Obscure Phoggy Embassy (NOPE) Village] (aka: the Noisebridge / Sudo Room Village)<br>
[https://events.ccc.de/camp/2015/wiki/Session:Hackerspace_Design_Patterns_2.0_Workshop https://events.ccc.de/camp/2015/wiki/Session:Hackerspace_Design_Patterns_2.0_Workshop]


== tl;dr: ==   
== 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.<br>
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 continue to share it with others in my future talks.<br>
:''mitch AT CornfieldElectronics DOT com''
:''mitch AT CornfieldElectronics DOT com''


Line 20: Line 32:


== Your Observations Wanted ==
== 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.<br>
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 future talks.<br>
:''mitch AT CornfieldElectronics DOT com''
:''mitch AT CornfieldElectronics DOT com''


== Workshop after the talk at CCCamp 2015 ==
== Workshop after the talk at CCCamp 2015 ==
My 30-minute talk at [http://events.ccc.de/camp/2015/wiki 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.
My 30-minute talk at [http://events.ccc.de/camp/2015/wiki CCCamp 2015] included some old and some new examples.  After the talk, we had a workshop on ''Hackerspace Design Patterns'', and really got into what works well and doesn't work well at hackerspaces.  I took notes, wrote it up, and posted it so that everyone starting or running a hackerspace can benefit from our collective experiences.


Thanks!<br>
Thanks!<br>
Line 36: Line 48:




'''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).
'''Physics Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
Problem: The group makes a lot of rules, but they are often ignored.<br>
'''Solution:''' Instead of creating rules, make it physically impossible to do the wrong thing, e.g. instead of saying "turn the lights out when you're done," put the lights on an automatic timer.




'''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.
'''API Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Hackers don't like unnecessary rules, and rules are often unenforceable. Check out link about [http://theconversation.com/too-much-information-how-a-data-deluge-leaves-us-struggling-to-make-up-our-minds-44674 repercussions of Rule-making overload].<br>
'''Solution:''' Instead of rules, create procedures for solving problems. For example, create a "parking ticket" that members can place on abandoned projects in their way, and a standard way to notify the group about the ticket. Allow anyone to dispose of an abandoned project a certain amount of time after a parking ticket has been issued.




'''Creative Chaos Pattern: The Stage Fright Anti Pattern:'''<br>
'''The Focus-Group Pattern.'''<br>
'''Problem:''' As a group grows and becomes noticed in media and the surrounding
'''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).<br>
local community, its solo, group, and public projects as well as public
'''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.<br>
events are perceived differently. This can lead to higher assumed
'''NB:''' Have these off-site, somewhere nice, like a local restaurant. Around food.
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.<br>
'''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.)'''<br>
'''The Cabin Fever Pattern.'''<br>  
'''Problem:''' A particular resource (soda/beer/h2o2/C3H7OH) is consistently
'''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.<br>
in limited availability and nobody knows who should buy it.<br>
'''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.<br>
'''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.<br>
('''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.'''<br>
'''The Anti-Sponsoring Anti-Pattern.'''<br>
'''Problem:''' Independence is cool, but rent needs to be paid.<br>
'''Problem:''' Independence is cool, but rent needs to be paid.<br>
'''Solution:''' Hackerspaces in big places (like tens of thousands of sqft industrial-zone warehouses)
'''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
can benefit from occasional bumps in funding availability. This doesn't
comma and some zeros" is a weighted decision. Supplement and be in the black for longer when possible.
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
'''The Space-Sharing Pattern:'''<br>
black for longer when possible.
'''Problem:''' Your hackerspace could use with some income $upplementing. A group that some of your members are a part of needs a space to work or hold meetings in.<br>
'''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. <br>
 
'''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.<br>
'''Solution:''' Have a solid mechanism in place for dealing with junk. [https://wiki.pumpingstationone.org/Tidy_Space_Policy PS:One's Tidyspace policy] is good at removing junk in a fair way.




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


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




'''The Who's on First anti-pattern.'''<br>
'''The Who's on First Anti-Pattern.'''<br>
'''Problem:''' Your core workings of the space are dependent on several
'''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."<br>
people being there. The question "Who do I give money to" is greeted
'''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.<br>
with "Uhhhhhhhhhhhhhhhhhhhhhh". The question "How do I become a member"
is answered with "You'd talk to... J. Hacker, who's... not here
tonight."<br>
'''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.<br>
: 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 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.'''<br>
'''Spreadsheet Pledges Funding Pattern:'''<br>
'''Problem:''' A change to the rules has led to outcry from a set of members.
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.
The problem fundamentally hinges around a particular topic (e.g.
 
inclusivity, feminism, etc).<br>
 
'''Solution:''' A meeting is held at regular intervals to discuss the issue
'''The Resource Replenishment pattern. (Extension of the Club-Mate pattern.)'''<br>
by any member who a) effected the change, b) is affected by the change
'''Problem:''' A particular resource (soda/beer/H2O2/C3H7OH) is consistently in limited availability and nobody knows who should buy it.<br>
or c) feels the change is inappropriate.<br>
'''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
'''NB:''' Have these off-site, somewhere nice, like a local restaurant.
and replenish supplies.<br>
Around food.
('''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, hydrogen peroxide, isopropyl alcohol, ...etc. respectively.)
 
 
'''NonexistentKitchenPattern:'''<br>
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:'''<br>
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:'''<br>
'''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.<br>
'''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 th e 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.
 
 
'''Replacement Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Volunteer roles require developing new skills and learning from the successes and failures of past volunteers.<br>
'''Solution:''' Volunteers should start training their replacements as soon as they take on a role. Having more members with the necessary skills will make it easier to find a replacement when the time comes. Also, the more members who understand a particular volunteer role, the easier it will be for the volunteer in that role to communicate with the membership.
 
 
'''Principles Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Members in a large group have different values, making it difficult to make decisions.<br>
'''Solution:''' Early on, create a list of "common principles" or "points of unity" that describe the ideals that were important to the early members. These ideals should be explained to all new members. Debates should be framed in these common principles. Principles can be revised, added, or deleted, but only if there is consensus.
 
 
'''Mentor Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' On-boarding new members is difficult. New members can have trouble finding the resources they need and learning their responsibilities as members.<br>
'''Solution:''' Every new member is assigned an experienced member as a mentor. When the member has a question, they can go to the mentor to find the answer. If the member is acting out of line with the group's principles, the mentor can talk to them.
 
 
'''Caretaker Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' There are a lot of space usage decisions to make, but most are irrelevant to any particular person.<br>
'''Solution:''' Appoint a caretaker for each zone in the space (machine shop, craft room, etc.) The caretaker's contact info is posted publicly in that zone. If a member has a question or a problem in that zone, they can contact the caretaker to fix it. The caretaker gets final say on space usage decisions.
 
 
'''Outreach Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Your space is almost entirely young, middle-class, white men and anyone else feels less comfortable using the space.<br>
'''Solution:''' Actively increase your group's visibility in communities with higher percentages of women and underrepresented minorities. Place more flyers, advertise on mailing lists, and give these groups advance notice of classes and workshops before announcing them to current members and their friends.
 
 
'''Pot-Lock Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Maintenance and cleaning is boring and no one wants to do it.<br>
'''Solution:''' Hold a combination pot luck and lock-in. Everyone works on maintenance and cleaning and takes a break to share home-cooked meals with each other. No one leaves until time is up.
 
 
'''Signage Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Members aren't doing something they should.<br>
'''Solution:''' Put a signs explaining correct procedure as close to the problem as possible, e.g. stencil "Clear off before you leave" on flat surfaces.
 
 
'''Anti-Popularity Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' Conduct complaints turn into popularity contests.<br>
'''Solution:''' When discussing conduct complaints, judge actions instead of character. Be clear about which specific actions were inappropriate and why. This has the benefit of reinforcing behavioral norms for other members.
 
 
'''Dossier Pattern'''
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
'''Problem:''' The board has received a complaint about a member, but the member says they didn't understand the rules. The board members are new and have no way to know whether the member has been a problem before.<br>
'''Solution:''' Keep records of all member complaints in a system that is confidential and searchable. Even if someone doesn't want to make a formal complaint, leaving a note can help establish whether there is a pattern of misbehavior and help future boards follow up.




'''The space-sharing pattern:'''<br>
'''Anti-Kibitzer Pattern'''
'''Problem:''' Your hackerspace could use with some income supplementing. A
([https://elplatt.com/new-hackerspace-design-patterns source])<br>
group that some of your members are a part of needs a space to work or
'''Problem:''' Everyone has an opinion on how a task should be done, but no one shows up to do it.<br>
hold meetings in.<br>
'''Solution:''' Make it so that members have to put some effort in before they get to have input. Have discussions in committee meetings outside of general meetings, and require homework (e.g. email in proposals beforehand). If someone doesn't show up regularly, or doesn't do constructive work, stop inviting them to the meetings.
'''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.  




'''The Cabin Fever pattern.'''<br>  
'''Reboot/Refresh Pattern''':<br>
'''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.  
'''Problem''':<br>
<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:''' The topic may be valid, but it's important to examine the root
'''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.<br>
of the -vigorousness- of the disagreement. Are external/seasonal influences
'''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.<br>
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.
<br>

Latest revision as of 12:11, 6 September 2015

Wanted: your Hackerspace Design Patterns[edit]

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

Hackerspace Design Patterns 2.0 Talk at CCCamp2015
When: Day 3, Occurred on Saturday 15-August from 10:30am to 11:00am.
Where: Project 2501 Tent (aka: Tent A)
https://events.ccc.de/camp/2015/Fahrplan/events/6842.html

Immediately following the Talk, I led a Workshop / Discussion. All were welcome! If you were just curious, or if you were interested talking about what has worked well (and what has not worked so well) at your space, then let's keep on discussing and distilling out new Patterns to add to the Hackerspace Design Patterns for all hackerspaces (forming, new, and old) to benefit from, far into the future.
Hackerspace Design Patterns 2.0 Workshop at CCCamp2015
When: Occurred on Day 3, Saturday 15-August from 11:15am to 1:30pm.
Where: Norton's Obscure Phoggy Embassy (NOPE) Village (aka: the Noisebridge / Sudo Room Village)
https://events.ccc.de/camp/2015/wiki/Session:Hackerspace_Design_Patterns_2.0_Workshop

tl;dr:[edit]

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 continue to share it with others in my future talks.

mitch AT CornfieldElectronics DOT com

Design Patterns[edit]

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[edit]

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[edit]

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[edit]

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

mitch AT CornfieldElectronics DOT com

Workshop after the talk at CCCamp 2015[edit]

My 30-minute talk at CCCamp 2015 included some old and some new examples. After the talk, we had a workshop on Hackerspace Design Patterns, and really got into what works well and doesn't work well at hackerspaces. I took notes, wrote it up, and posted it so that everyone starting or running a hackerspace can benefit from our collective experiences.

Thanks!
Mitch.

New Hackerspace Design Patterns[edit]

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

Please feel free to add your new Patterns here:


Physics Pattern (source)
Problem: The group makes a lot of rules, but they are often ignored.
Solution: Instead of creating rules, make it physically impossible to do the wrong thing, e.g. instead of saying "turn the lights out when you're done," put the lights on an automatic timer.


API Pattern (source)
Problem: Hackers don't like unnecessary rules, and rules are often unenforceable. Check out link about repercussions of Rule-making overload.
Solution: Instead of rules, create procedures for solving problems. For example, create a "parking ticket" that members can place on abandoned projects in their way, and a standard way to notify the group about the ticket. Allow anyone to dispose of an abandoned project a certain amount of time after a parking ticket has been issued.


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


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 Space-Sharing Pattern:
Problem: Your hackerspace could use with some income $upplementing. 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 Viewers Like You Pattern.
Problem: Your hackerspace needs money.
Solution: Run a fundrai$ing campaign, NPR style. Tote-bags and coupon books 'n all.

Converse Anti-Pattern: You run the campaign$ 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**.


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.


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, hydrogen peroxide, isopropyl alcohol, ...etc. respectively.)


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


Replacement Pattern (source)
Problem: Volunteer roles require developing new skills and learning from the successes and failures of past volunteers.
Solution: Volunteers should start training their replacements as soon as they take on a role. Having more members with the necessary skills will make it easier to find a replacement when the time comes. Also, the more members who understand a particular volunteer role, the easier it will be for the volunteer in that role to communicate with the membership.


Principles Pattern (source)
Problem: Members in a large group have different values, making it difficult to make decisions.
Solution: Early on, create a list of "common principles" or "points of unity" that describe the ideals that were important to the early members. These ideals should be explained to all new members. Debates should be framed in these common principles. Principles can be revised, added, or deleted, but only if there is consensus.


Mentor Pattern (source)
Problem: On-boarding new members is difficult. New members can have trouble finding the resources they need and learning their responsibilities as members.
Solution: Every new member is assigned an experienced member as a mentor. When the member has a question, they can go to the mentor to find the answer. If the member is acting out of line with the group's principles, the mentor can talk to them.


Caretaker Pattern (source)
Problem: There are a lot of space usage decisions to make, but most are irrelevant to any particular person.
Solution: Appoint a caretaker for each zone in the space (machine shop, craft room, etc.) The caretaker's contact info is posted publicly in that zone. If a member has a question or a problem in that zone, they can contact the caretaker to fix it. The caretaker gets final say on space usage decisions.


Outreach Pattern (source)
Problem: Your space is almost entirely young, middle-class, white men and anyone else feels less comfortable using the space.
Solution: Actively increase your group's visibility in communities with higher percentages of women and underrepresented minorities. Place more flyers, advertise on mailing lists, and give these groups advance notice of classes and workshops before announcing them to current members and their friends.


Pot-Lock Pattern (source)
Problem: Maintenance and cleaning is boring and no one wants to do it.
Solution: Hold a combination pot luck and lock-in. Everyone works on maintenance and cleaning and takes a break to share home-cooked meals with each other. No one leaves until time is up.


Signage Pattern (source)
Problem: Members aren't doing something they should.
Solution: Put a signs explaining correct procedure as close to the problem as possible, e.g. stencil "Clear off before you leave" on flat surfaces.


Anti-Popularity Pattern (source)
Problem: Conduct complaints turn into popularity contests.
Solution: When discussing conduct complaints, judge actions instead of character. Be clear about which specific actions were inappropriate and why. This has the benefit of reinforcing behavioral norms for other members.


Dossier Pattern (source)
Problem: The board has received a complaint about a member, but the member says they didn't understand the rules. The board members are new and have no way to know whether the member has been a problem before.
Solution: Keep records of all member complaints in a system that is confidential and searchable. Even if someone doesn't want to make a formal complaint, leaving a note can help establish whether there is a pattern of misbehavior and help future boards follow up.


Anti-Kibitzer Pattern (source)
Problem: Everyone has an opinion on how a task should be done, but no one shows up to do it.
Solution: Make it so that members have to put some effort in before they get to have input. Have discussions in committee meetings outside of general meetings, and require homework (e.g. email in proposals beforehand). If someone doesn't show up regularly, or doesn't do constructive work, stop inviting them to the meetings.


Reboot/Refresh 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.