Far-flung Team Communication

February 11, 2010

This post is part of the Editorial Calendar Plugin for WordPress team series. We take a first-hand look at a far-flung open source team as it forms, communicates, resolves problems, and (hopefully) succeeds. Stay up to date with the whole series.

can telephones

The first task of every new distributed team is learning how to communicate with each other. Some teams plan out their communication ahead of time while others let it grow organically. The editorial calendar project is a little of each.

Email

Our communication starts with initial planning emails. They’re full of are you interested and how should this work. We feel each other out and see what type of collaboration we want.

Our emails are loosely managed. We don’t have a mailing list and sometimes people get missed. The stresslimitdesign team is deciding if they want to work with Bob at the same time they decide if they want to work with me.

These emails have a bit of an us and them feeling since the team hasn’t really formed yet. They go off to discuss and figure out what to tell me. This is typical of transitioning from customer to collaborator.

The emails enevitably lead to a conference call.

Conference calls

We start with a quick-hit call with Justin, Colin, and I. We don’t make any decisions, but we reassure each other of our commitement to the project and set up the next call with the rest of the team.

Our first full team conference starts with a role call. Great to virtually meet you. I’m really excited.

This is a classic leader contention call. Justin and I trade back and forth on the leadership position and everyone else mostly listens.

Subversion

WordPress.org provides a Subversion repository where programmers can share source code. I checked all the code into our repository. Everyone can read it, but I haven’t given anyone else permission to make changes.

Most open source projects make members earn the right to contribute new code. Potential contributors submit patches and do small projects until they’ve proved they’ll benefit the project. Then they’re promoted to contributor status.

I’ve never worked with the other coders on the project and I want to make them earn the right to make changes. I need to assess their skills and working style before giving them the freedom to make big changes. I’m worried that will make them feel like I want too much control. We’ll see if that becomes an issue.

Basecamp

Subversion helps us share code and Eric Craven set up a Basecamp for us to share documents, TODOs, and a calendar. I started by adding all of our documents and many notes. I also added our bug bounties. The rest of the team hasn’t been using it much yet.

Coming up: Next week we’ll look at the issues of managing a project team with some paid members and some volunteers.

Previous post:

Next post: