Hackerspace Design Patterns 2.0: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
(→‎New Hackerspace Design Patterns: ApathyByAThousandCuts anti-pattern)
Line 36: Line 36:


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

Revision as of 01:01, 3 July 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

Please add your new Patterns here:

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.