Checklist for new event organizers: how to schedule and get people there

I was talking with @schmichael today and he brought up that it was insane how many different organizing tools are out there, and there’s no handy list of tools for new event organizers to use!

So, here’s my list of helpful tools if you’re trying to run an ongoing tech event:

  • Put your event on a calendar like Calagator.org: This may be pretty Portland specific, but if there’s an event calendar in your area, be sure to put your event on it! Calagator is great also because it shows you a list of venues – possible places for you to hold events. When you need space, its likely best to ask other event organizers. In Portland, we have a special list for event organizers. Get in touch if you are an event organizer, and not already on it!
  • Create a meeting event on something like Meetup.org: So many groups still use this. Several PostgreSQL groups do, and PDX Lean Startup Circle swears by it. There’s also Upcoming.org, but we don’t seem to use that as much
  • Create a google group! Mailing lists are still the best way to keep in touch with people. All the research on electronic communication says this. Tweeting is not enough!
  • Don’t put tons of interested people on CC or personally-managed Outlook lists. This is spam, and the people on the CC list can never unsubscribe! It’s not just annoying, it is rude.
  • Make a twitter account for your group! Twitter is a great way for the always-connected crowd to stay on top of what you’re up to. Easy to search, and quick to post. Try out Cotweet if you have more than one organizer!
  • Tell other event organizers about your event. They likely know other individuals and groups that would be interested and can use their best judgement in passing an email or tweet along. Don’t spam a bunch of unrelated groups!
  • Make an event announcement 2 weeks, 1 week the day-before and day-of your event.
  • Include the following in your announcement: event name, date, time, speaker name(s), talk title and location including zip code of your event (so people can use maps to find you easily!)

What else do you think an event organizer should have in their checklist?

#PDX11: Community as competitive advantage

Here’s an edited version of Thompson Morrison’s presentation about the software industry’s response to a series of surveys. The original presentation is available here. One of the key slides was about what folks here value:

The point I appreciated about this clip is that Portland’s software community *is* our competitive advantage.

I edited the video most for audio coherence. Sorry about the audio being a little out of sync.

PostgreSQL 9.0: contributions!

New releases are opportunities for reflection!

As PostgreSQL grows, I would like to know how many people are contributing at any time. This is difficult to measure, given how many people contribute in ways not visible to the internet – advocating for PostgreSQL at work, sharing information about PostgreSQL offline in any way, or developing code related to PostgreSQL that isn’t shared directly back.

PostgreSQL developers have a habit of mentioning the people involved in the development of features in the commit logs. This includes people who discuss topics on the mailing list, who report bugs, provide test cases or send in patches. I spent a bit of time digging through the commit logs and pulling out unique names that are mentioned. This is a lossy process, as the log files are long, names are not always easy to spot, and I only spent 6 hours going through it.

I’ve made it through the 9.0 (16163 lines of logs) and 8.4 logs (21257 lines of logs) so far.

Here’s some basic information about them:

  • 8.4 logs mention about 230 unique people (11 committers)
  • 9.0 logs mention about 275 unique people (16 committers)
  • 8.4 development contained 2293 commits with commits per author broken down below (click for a bigger version):
  • 9.0 development contained 1703 commits, and the commits per author broken down below (click for a bigger version):

I’m working on graphs about number of lines inserted or deleted by each author, but need more time to work out the information presentation. Some interesting trends emerge about what the role of each committer is – particularly that there are a couple people who seem to be “gardeners” of the code – removing a lot of lines, sometimes more than they are adding. With a project as old as ours (first commit in 1996!), this maintenance work is critical.

I also did some grepping for key words in the commit messages:

word times mentioned
in 8.3
times mentioned
in 8.4
times mentioned
in 9.0
review 24 14 49
cute 29 26 25
tom lane 904 901 635
gripe 37 48 26
hot standby 0 5 48
replication 18 4 52

You’re welcome to explore our git repo at git.postgresql.org. Thanks to all the folks who worked on the git migration over the past few months, and finally made our transition from CVS to git complete last night!

CouchCamp 2010: yay!


Max in a tree! Talking about GeoCouch

I was at CouchCamp last week out at the Walker Creek Ranch – a bit disconnected (no cel service, and spotty internet), but fully immersed in the CouchDB community.

I was there to give a talk on MVCC in PostgreSQL. I forgot to mention it during my talk, but it was a fitting topic given that I first talked with JChris after a talk he gave in Portland, where I basically trolled him about compaction and MVCC in CouchDB. My goal was to show people the benefits of CouchDB’s built-in MVCC, to point out some places where core developers can learn from PostgreSQL and avoid some of the traps we’ve fallen into over the years. I’ve got more to say about the talk some other day, but I wanted to just reflect on CouchCamp for a moment.

One comment a friend made was, “Wow, these people are just so nice!” And it’s true. Every hacker meetup I attend is full of people who are overwhelmingly kind and thoughtful, and CouchCamp was more of the same.

CouchDB is at a critical point in their development – 1.0 is out the door, and developers are already building cool apps on top of it. CouchApps + Evently are an interesting and fun way to get started building things on top of a couch. And replication parties – seriously awesome. Ward Cunningham is rumored to be considering a CouchDB wiki to drive the patterns repository wiki (And here it is! Thanks, Max!), and CouchCamp was overflowing with ideas and implementations (distributed social, a replacement for email, UbuntuOne).

So what did I learn at CouchCamp? I learned how to hack on a CouchApp (Thanks for the help, JChris!). I learned about what Max Ogden is up to, and am so excited for him and the lucky folks that get to work with him. (and he’s running a hack/project night next weekend you should TOTALLY GO TO!)

I heard about the success and tribulations of running CouchDB on the desktop, and the launch of UbuntuOne from Stuart Langridge. During his talk, Stuart brought up the idea of a general replication API – something that I also believe is important to the growth of open source databases and is critical to enabling data freedom. I met a real, live Pick user/admin/developer, and talked about the inability to move to another system but the possibility of interfacing something like CouchDB to it. I got to chat with Rebecca Murphey about Javascript, MVCC and quality booze. I saw bunnies, foxes, deer, raccoons, and tons of bright stars late at night. And, I saw Damien Katz perform a brief interpretive dance.

I also was pointed to a retrospective on Couch 1.0 development by Ted Leung. I don’t know Noah Slater, but wow, what a testimonial. Noah’s comments about why he continues to contribute to CouchDB mirror a recent thread about PostgreSQL contribution — we work on these open source projects because of the incredible community that develops around them.

Thanks, Mikael, JChris, Jan and Damien, and all the CouchDB folks for creating a community that so many people want to contribute and become a part of. I certainly want to be a part of it, and look forward to finding ways of contributing more.

And thanks for bringing us all together in person. From the squirt guns in the welcome bag, to the campfire and sing-alongs, to the very late night Android libc storytelling by Aaron… These are the moments that glue us all together, and make all that work we do to connect up with one another through software completely worth it.

IRC hangouts in Portland, OR

Updated!

A big part of the thriving tech scene in Portland is made up of IRC channels that many groups and projects use to coordinate real-time activity.

Some of the popular channels can be found at the following locations:

Freenode:

#pdxpug
#pdxpython
#pdxpug
#osbridge
#techcoffee
#dorkbotpdx
#pdxfunc
#pdxdjango
##pdxbeer
#pdxwebdev
#pdxscala
#brainsilo

irc.perl.org:
#pdx.pm

irc.personaltelco.net:
#pdxfiber

Tell me about others in the comments!

This town needs…

There was a thread in a walled garden recently asking the question: “Why can’t we all just get along?” This was in response to a difficult parting of ways between organizations in Portland trying to run a couple events cooperatively.

Unfortunately, the thread was deleted, so even if you were to join the group at this point, the conversation is lost. Fortunately, I saved a copy and can quote from it in the future as needed!

The situation, as I saw it described, is that some people think of the grass-roots organized groups as obstinate. As unwilling, and possibly opposed, to compromise. The phrase “stubborn demands of individuality” was used to describe the problem the original poster brought up.

In any growing, functional organization or community, there will be conflict. What matters is how we handle that conflict.

I plan on re-posting my original comments here in my blog because I want the thoughts and conversations that were started inside a closed space to come out into the open.

There’s certainly an opportunity in Portland for the many lovely, energetic and productive volunteer groups to pool our talents and resources. Some of that energy has certainly been pooled to produce Open Source Bridge, for which I am enormously grateful.

So, the question in my mind is should we also be doing something else? And if so, what would that something else be?

And by something — I mean just about anything. I’ve never counted, but I’d guess based on the groups and events that I’ve attended that we have well over 1000 volunteers in our technology communities in Portland. Add in the larger professional organizations, and I’m sure we’ve got over 10,000 people in the Portland area (and Vancouver!) whose involvement we could count on.

Let’s hatch a plan.

There’s a push to look outward, and to speak outward. To get “press attention”, which to some, means success. I don’t agree.

We need a different vision. Our communities are ones of people who *do* things. (I’d even go so far to say we have a ‘do-ocracy‘.) We make things, we share them and then we make more things. Certainly there’s room in our communities for people who help us share what we’re doing. But we can’t talk about things we haven’t done.

Anything that enhances our community, must help us do things. Change must make collaboration easier, sharing better and involvement in our communities even more rewarding than it already is.

So, help me. What does success look like to you? What do you wish that you could get out of our technology groups, but don’t?

User Group Idea: Patch Review Party

On Tuesday, I invited a group of people from PDXPUG over to my house for chili, beer and patch review. PostgreSQL has what we’re calling a ‘commitfest‘ every two months where we buckle down and try to review and commit (or reject) the patches submitted over the last few weeks. Webb and Gabrielle had the original idea to get everyone together for a review party, and they did a fantastic job recruiting people to join in.

Gabrielle gave the details and lessons learned on our PUG site already, so I won’t repeat that.

One thing that occurred to me as we were doing this work was how affirming and *fun* it is to work on patch review with people in person. Several people commented on how they enjoyed doing this work in the company of others, and how the tedious issues around compiling, applying patches and going through all the questions were made so much more enjoyable with a group of good-natured hackers sitting around answering questions.

The atmosphere wasn’t pressured – I gave a little background about commitfest, how it’s been run in the past and what the development group is trying to change about it (mainly, bring in more people, and make patch review faster for people who submit patches, and smoother for the committers). Then we just got down to work in pairs or groups of three.

Working in pairs is a really good idea for this type of event. I certainly learned a few things from John, and over email and in-person again, we were able to wrap our review up a couple days later after the regular user group meeting. Having another person to bounce questions off of was invaluable for the patch that we reviewed, and it was just fun brainstorming variable names, piecing together a test case and then finding a solution to a problem we found.

Another thing that happened was that I had lots of time to chat with people I hadn’t talked with before about projects they’re working on (a really exciting materialized view implementation, and a massive cleanup of our *.bki infrastructure — two very ambitious projects!). Both people are now signed up to give talks at our local user group about their work.

I’ve talked a little bit about the social benefits of commitfest on various mailing lists, and I think the opportunity for user groups to get together and review patches as a team is a great one. I’ll be gathering up some of my other observations about PostgreSQL community and posting those over the next few weeks.

I’ve got a talk about user groups to prepare for (JPUG’s 10th anniversary in November!), so now is the perfect time for me to be gathering my experiences and thoughts from the last three years.

My thoughts about community management

David Eaves wrote about open source contributions recently, and how community managers fit into the picture.

He remixed a graph from Angie Byron, and I wasn’t completely happy with the results. A fairly long twitter thread ensued, between myself, Jeffrey McManus, Emma Jane Hogbin and Peter Krenesky. In the end, David piped up and asked if I’d comment on his blog. So I did. :)

Hi!

I commented via a long twitter thread that I “disagree with putting comm mgmt between user/dev. like @webchick’s ideas better.:)

To flesh that out a bit — my gut reaction to the ultimate diagram you created is that it puts community managers *between* users and developers.. This is a convenient way to demonstrate a process, but ultimately, I have to disagree with the premise behind it.

I work to break down barriers between “users” and “developers”. My ideal world is one where the two overlap to a very large extent. I dislike models of open source community development which seem to promote the idea that there needs to be an intermediary.

I agree that most communities require an interface — it is rarely self-evident how one goes about joining a community if you were on the outside. Many times it is an organic process — your friends invite you, or you run into someone at a conference or bar, or you have to use or work on a piece of software for work. For those who, for whatever reason, are not already on the inside, having a single point of contact (a “community manager”, or in the amusing case of the open source developer group I primarily work with – a “liaison”) can be an invaluable tool.

However, I do not see that role as one that ultimately should belong to just one person. If I do my job right, eventually, people won’t even come to me any more. They will go directly to the individuals inside the community they most want to connect with — because I have managed to open up our community interfaces to the point that they are self-documenting, or easily found with a few clicks on our website.

Possibly, this vision is a bit unrealistic in the near term. But I’ll paraphrase my friend Audrey — it’s way more fun to craft your reality, than it is to passively experience it.

Offline community, PUGs updates

Just before heading off to PgCon, I wrote about offline community and how it has positively impacted the tech community in Portland, OR. Specifically, I talked about the factors I thought encouraged women to participate.

My own experience with Postgres has been incredibly positive and welcoming. I always wish that I had more time to contribute.

I did find a little time this weekend to upgrade the PostgreSQL User Group site to the latest supported version of Drupal. We’re still on version 5.x, and hopefully I’ll be able to upgrade that to version 6.x soon. We’ve had a few problems with spammers, but I added a CAPTCHA that I hope isn’t too annoying for everyone.

If you have ideas for how to display the information on the PUGs site in a better way, please get in touch. I have a couple things I’d like to add soon – like a map of locations, and a better preview of recently posted articles.

Manufacturing Participation

I want to talk about a couple things today during my unfortunately named “architecting participation” session at BarCampPortland. My goals for participation are to get people to an event or be part of an open source group and then to get them to keep coming back.

The three things I’m going to touch on are: inviting in and making people feel welcome, making people feel useful, and making things fun.

With the ultimate goal being world domination of free and open source software.

We’ll see how it goes :)