Gabrielle and Selena presented “Running a Successful User Group” (slides 1.4MB) at OSCON 2008 last Wednesday. Michael Halligan was nice enough to post his notes from the session. We had around 40 people attending, and had great participation from the crowd! Couldn’t have asked for a better audience.

We also created a handout that gets into the nitty-gritty of running a group (PDF 4.2MB). Later, we’ll see what we can do about wiki-fying the content. For now, printing it out double-sided and then stapling it in the middle works pretty well.

We have a stack of index cards from everyone to go through, and looking forward to starting a mailing list for user group leaders. Watch this space for the mailing list announcement!

The first PDX Coders’ Social was such a success, we’re having another one! Hope to see you there!

This week at PDX.pm, chromatic gave an excellent talk about “how not to fail”.  There was quite a bit of discussion of Godzilla attacks and the calculus thereof, which I don’t think I can adequately capture.  “You had to be there”.  Anyway, on to my notes!

The keys:
- Recognize points of failure before the actual failure occurs.  The idea being to prevent the failure.
- Perform root cause analysis.  Your biggest problem may not be the most annoying, obvious, or easiest to solve.
- Do the simplest, fastest thing you can do to ease the problem.  You’re conducting an experiment to see if it has any effect on the problem.

Some examples of places you can get hung up:
- Waiting for a decision from someone else.  That someone else could be you.  Self-awareness is critical.
- Waiting for someone else to do something.  This is usually a sign of a technical bottleneck, such as a complicated process.  “The only person who can ____ is too _____.” (The blanks on this slide had my hopes up for madlibs.)
- Becoming demotivated (which is a word I thought only I used) by tedious or annoying tasks.  (Or people.)  Get rid of the annoying thing.  (Please obey all local laws.)  Motivational tip:  leave something to do tomorrow!  That way you start the day on a high note.  [I do this all the time - in fact, I keep a list on hiveminder of "instant gratification projects" - things I can do in 15 or 30 minutes - and any time I'm frustrated & need to feel like I've accomplished something, I do one of those.]
- Lacking direction.  Try creating a one-sentence problem statement.

Time-based releases force you to get your release process under control – and maybe even automated!  It gets you in to a rhythm.  (My rhythm, since it’s just me and I don’t really have “releases”, is to have “Refactoring Fridays”.)

Tips that especially apply to FOSS projects, where just about everyone is a volunteer:
- Make it easy for people to get involved
- Encourage discussion
- If someone new has contributed something, but it’s not quite up to snuff, tell them (nicely) how they could improve next time

Come hear what we have to say about Building a User Group!

http://en.oreilly.com/oscon2008/public/schedule/detail/2757