These are rough, cribbed from chat notes taken by attendees (thanks, folks!)

We started with a replay of the 5 minute exercise wherein participants dump me in the middle of an open source project I'm clueless about, and watch me think-aloud as I desperately try to figure out what's going on -- basically, "how does an experienced hacker evaluate an open source community?" This time I had 10 minutes, so I got pretty far checking with out Ogre3D (which looks great).

Our first big goal for the session was lurking. You can find projects on a topic by searching the internet for "[topic] open source" (or "[topic] Free Software," or so forth). When you have a few potentials, ask yourself:

  1. Is this project alive? Are code commits recent? Are mailing list messages recent and responded-to in a timely, helpful manner? Are people using this software? (Do you want to use this software? Can you figure out how?)
  2. Is this a community I want to be part of? (Do they treat each other well?) The people are more important than the code; they're the ones who make the code, and with release cycles that average 6 months, the code moves so fast that your relationships are what will really orient you.
  3. Where do they hang out and do their work? (What chatroom -- usually in IRC -- do they use? Do they have a bugtracker or some other giant shared to-do list for the project?) Once you find out where you can overhear things, you can figure out who you're overhearing, and then start contacting them directly: "I've seen you answering questions on X; can you help me navigate X?"

Most projects have communication methods for code and not-code, and for asynchronous and synchronous work. Try to lurk all four. The table below may help.

Synchronous Code: git commits (announced by a bot in chat, sent to a feed, etc)  Synchronous not-code: chat (typically IRC)
 Asynchronous Code: issue/ticket/bug tracker  Asynchronous not-code: mailing lists or forum, AND wiki

Our second big goal for the session was introducing yourself. This usually happens by sending an email introduction to the developers mailing list, then referencing that email (find the URL of your message in the mailing list archives) during initial chat conversations with people. Maggie brought up "submitting a pull request as your intro letter," which is a great idea. What this means is that your introduction email should explain how you are:

  1. already in the middle of doing a specific helpful task
  2. and what you're asking for is help doing that specific helpful task.

This sounds intimidating until you realize "something useful to help" can be very, very small. For example, Rebecca emailed tent saying that she'd been working through their documentation and had ideas for how to improve the clarity of the particular docs at a certain URL (specific helpful task!) and was wondering where to submit her changes (help me do it!). Jade emailed GIMP offering to test patches (specific helpful task!) and asked which branch and patches would be most helpful to verify (help me do it!). None of these tasks involve deep knowledge of the code; that comes later. They involved "writing in English" (not a problem for most Hacker Schoolers) and "compiling C" (not an impossible thing to learn, especially when you're surrounded by programmers eager to teach).

It's helpful to pair with someone and peer-pressure (positively!) each other to ship your intro emails.