Social Engineers

From Noisebridge
Revision as of 04:03, 31 May 2012 by Malaclyps (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

On hiatus until 22nd March 2012[edit]

Technical Solutions to Social Problems[edit]


"You cannot apply a technological solution to a sociological problem." - Edwards' Law

"Every time I hear Edwards' Law, I reach for my gun" - the Noisebridge Secretaribot

There are lots of fascinating challenges to running a hackerspace using the purest anarchist collective principles, many of which we appear (from the outside) to talk about endlessly. Some of them are actually *about* the need to talk endlessly.

Noisebridge's Social Engineering group's motto is "A little less talk, a lot more evidence-based semi-autonomous behaviouralist actions."

We brainstorm and implement new software, hardware, and architecture that can support Noisebridge's unique social contract in the same way that almost all of the rest of our culture works to support _its_ definition of normality.

You can meet with us on Thursday from 6.30pm onwards in the Library, or join the socialengineering mailing list

Current facilitator for the Social Engineers is Danny.

Meeting 2012-05-30[edit]

This week's agenda:

  • Introduction to Consenso!
  • Building a questionnaire for Noisebridge membership
  • Field trip to machine learning gang

Previous meeting archive[edit]

Meeting 2012-02-09[edit]

So social engineering this evening concentrated on trying to define the problem we've been discussing on nb-discuss these past few aeons, listed the challenges, listed the aspects of Noisebridge we wanted to preserve, and then went through the classes of proposed solutions, and how much we liked them.

What was the winner? The proposal we liked the most was putting into place a keycode system (probably Kelly's hot-tub matrix), but not losing the key and the buzzer for now -- and indeed a general encouragement to create as many interesting ways of getting into the place as possible. Once we see how those go as a temporary plan and see what the uptake is, the goal would be to turn off the buzzer, but that would only be after more discussion and experimentation.

I'll pass over to Kelly who I think is going to lead this as a spun-off project.

I'm not around for soceng next week, so feel free to use that meeting for this, though I think it's big enough to spin out on its own.

The problem space[edit]

We seem to be worried about:

  • Crazy people who come up and want to shoot everyone
  • Burglars with swag bags
  • Increased entropy in general (messiness, slacking instead of hacking)
  • The public image of Noisebridge as not safe and a bit skeevy
  • Some sort of uncool disaster

Challenges to any solution

  • We are structure minimalists
  • No clear dividing line between good crazy and bad crazy
  • "Noisebridge is self-trolling and games ours own solutions"
  • Hard to disseminate knowledge
  • Hard to to enforce rules

Proposed solutions[edit]

(Pluses and minuses are strawpoll votes, D = doacratically doable, C = would require consensus in meeting)

D Improving self-policing through education ++++--

(ie having more direct explanation and role-playing of throwing people out, to get over our natural reticence to do so)

C A blanket access fee ++------

(ie $10 to get in the place)

D Always locking the top door ++-

(people seemed to think this was okay in combination with something else)

D Access code as supplementary system ++++++++-

(Kelly's system was discussed in detail, but this applied to any access system.)

C Access code as only system ++------

(We really didn't want to depend on a high-tech system. Wanted the keys to stay)

C Cutting the buzzer +++----

(Maybe in the future, once another access system had emerged.)

C Closing down at night ++----

(That's to say, NB ends at 11PM say)

C Members only at night ++++-

C Cellphone entry only +----

(Ie some sort of phone-door-opening triangle)

D Temporary versions of all above +++++

(Lots of support for trying stuff out, seeing what sticks)

D Concentrating on individual +++++

(Some support for working on preventing certain people, rather than just raising bar on access)

C Greylists/Blacklists ++++

(Some support for raising enforcement of Noisebridge's somewhat moribund greylits/blacklist proposal)

Previous Meeting[edit]

  • Magnetic walls!
  • Re-invigorating Horsy.
  • Front door screen!
  • Mutant AI!

Meeting on 2011-12-13[edit]


  • Talking about
  • Getting a basic issue tracker up
  • Maybe hacking on getting an API to work for the Big LED board
  • A Noisebridge MUD?

Meeting on 2011-12-06[edit]

Just me and Kaya, so I worked on getting the gate buzzer to work.

Meeting on 2011-11-29[edit]

We talked about the shop walls, and what worked and what didn't. In the end, it turned out to be more of a planning session for the next stage: Miloh planned to work with others on finishing up the classrooms (mudding + putting primer on it) so the electrics can go in next.

We brainstormed the needs for the issue tracker (or basically the things that online tools might be able to help with in the space). We also listed stuff that was and working with the wiki and mailing list.

What Works[edit]

The Wiki works fairly well in the following ways:

  • generic repository for information
  • a historical archive
  • something with a reasonably low barrier to entry


  • Triage and priorisation of issues and tasks.
  • "Rolling consensus" (Miloh's term) outside of the meeting.
  • To stop projects going stale
  • Store institutional knowledge
  • Create recurring todos
  • Easy process for creating new prjects
  • A point of contact for events/projects
  • Defining long term projects
  • "Impending doom" highlighting -- fire safety, that the sink is going to fall off the walls at some point, earthquake prep
  • Anticipating crises (maybe the same as above)
  • Keeping noise off noisebridge-discuss
  • Broadcasting to all our users
  • Linking the online world to the realworld space, and vice versa
  • Fundraising
  • Encouraging new members
  • Growing Noisebridge
  • Providing an online identity for members
  • Getting input from the space

Meeting on 2011-11-16[edit]

Will talked about the cleaning experiment, and this was moved to the meeting.

We talked about soundproofing the shops and classes, and decided to do it Thanksgiving weekend

We talked about the next six months of soceng, and decided to concentrate on one project, to whit a karma and issue tracker for Noisebridge written in Ruby on Rails.

Incomprehensible notes at Social Engineers/2011-11-16

Meeting on 2011-07-26[edit]

Scribbled notes at Social Engineers/2011-07-26

Meeting on 2011-07-19[edit]

Deeper (incomprehensible) notes here: Social_Engineers/2011-07-19