Tag Archives: community management

conference , , , , ,

Reflections on a negotiation workshop: we’re better at it than we know

The Sunday before OSCON, I gathered a group of women who work with open “stuff” to participate in a workshop on negotiation with David Eaves. He talked a little bit about his recent work in open source communities in an interview with Ed Dumbill. I’ve mentioned David a few times in previous posts here, and was excited to finally get to meet him in person.

My goal in bringing people together was to launch an effort among open source communities to recognize negotiation as a core, required skill. I decided to target women in open source as the initial audience.

The day-long training was structured around two simulations, one based on personal experiences, and the other using an entertaining business situation – where two sides come together after about 45 minutes of research to negotiate an agreement.

Much of the “lecture” time was spent identifying key steps in a negotiation, and sharing a framework that helps individuals prepare for difficult conversations. A key feedback loop was:

It’s a very simple loop, but crystalizes much of the core of what negotiation is about. Preparation, execution, targeting a goal and reflection.

Like much of what I covered in the “Mistakes were made” talk, the diagram documents and reveals common sense as a system. Negotiation is a feedback loop, and there’s always opportunity for even better, more collaborative and satisfying deals.

Another revealing point in the workshop was that the goal of a negotiation is not necessarily to come to an agreement, but to find an acceptable resolution. That includes a BATNA (Best Alternative To a Negotiated Agreement). Which is to say – enter into a negotiation with a clear idea of what your alternative is, and what your bottom line is so that you can feel comfortable walking away knowing what your next step is (even if it is not your preferred step).

Finally, during the workshop and simulations, I realized how many of the research and bits of process that were suggested I was already doing! It was very nice to leave with a framework for future negotiation, and a set of questions to ask myself and others.

My reaction to the preparation was to consider how I could share whatever I prepared with my negotiating partner in the future. And then I realized that probably wouldn’t always work, but it was a lovely thought. What if we could develop the strength in more of our relationships to be that open and direct?

I highly recommend attending any workshop that David gives in the future, and will be blogging about some suggested reading as I get through the books.

Leslie Hawthorn has blogged about her experience.

We were able to hold the workshop, thanks to the sponsorships of Mozilla, Wikimedia Foundation, Google, Technocation, Inc and O’Reilly.

postgres, postgresql , , , , , 8 Comments

The importance of doing things badly

Update: added “code review” to the things that we’re doing well below.

There were a couple themes for me from OSCON last week. One is transitions and change. I’ve got a whole slew of thoughts on this, particularly from my experience leaving the management team of Open Source Bridge.

But the other is the importance of doing things badly. In particular, the importance of doing things badly in open source.

Tim Anglade, at about 41:10, says that he thinks the reason why open source companies make money is because open source is kind of shitty (from an interview he did with Cliff Moon last fall). So, on one hand there’s a Money Making Opportunity. Probably not the one that we’d all prefer, but it is what it is.

When he said that, I immediately thought about the other things that we do badly (other than documentation) and the discussions I’d been having with people last week.

Basically, we had a problem in the Postgres community of experienced developers solving every small bug at nearly the moment it was reported. It’s sort of like a cat sitting at the entrance of the only mousehole.

The effect on the code is amazing – we have clearly documented, concise and consistent code. But the effect on the community is that we don’t have mid-level developers, and it is very difficult for inexperienced developers to build up a portfolio of small projects, based on bugs.

I don’t have a ready solution for this problem. And I do not mean this as a criticism of the thousands of hours our core teams have devoted to fixing bugs. We all benefit from the dedication. I am just pointing out that our system had a clear tradeoff – fewer contributors.

What we could do a bit worse (to address the point of this blog post) is lengthen our response time to solving bugs, and let some less experienced developers respond to the bugs queue. This probably involves creating a bug tracker and holding the tension a bit longer on fixes.

Our committers have made efforts toward spreading the load around more – with commitfest – meaning a greater support of code review, with Tom’s recent presentations about the planner, with our wiki-fied Todo list. And there are many more examples of our committers putting real effort into mentoring, tutoring and finding ways of bringing more people in.

The thing that’s missing from all of those efforts, however, is urgency. That’s what bug-fixing is great for. That’s why we have people who remain in operations work even if they hate being woken up at 3am. Urgent work is worthwhile work (mostly).

I’m sure there are other particular areas where we could do things worse, and thus invite more people to contribute. I’ll be thinking about this more in regard to our project event planning, as I think there’s a bit of a disconnect there, and a huge opportunity to involve more people.

I’m reminded again of David Eaves’ talks about how community management is the core competency of open source, not technology. I struggle with that thought every day, but it rings truer the more I try to work on the significant problems facing any particular open source project.

community, open source , , 1 Comment

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.