Since my election to the Gentoo Council, I’ve become the de facto meeting chair and secretary. Over the past 6 months or so, I’ve learned a lot about what works well in online meetings (often by virtue of doing the opposite). By no means have I mastered this, but here’s some of my discoveries along the way.
What works well:
- Send out a draft agenda in advance (say, 1 week). This helps avoid confusion and disorganization at the meeting, and it also allows you to have no “open floor” section at all, because all topics should have come up when you posted the draft. Settle on a final agenda a couple of days in advance.
- On the draft, say who should attend the meeting to discuss each topic.
- Be specific about the topic, so you stay focused during the meeting.
- For each topic, have a very specific goal of what will be accomplished at that meeting. If it’s a decision, exactly what will the vote be? If it’s a discussion, what points do we want to get out of it, and why is it happening during the meeting instead of on mailing lists?
- Prepare. All of the information needed to make a decision should be readily available by the time the meeting comes along. To aid this, say on the draft agenda what information will be needed.
- Stay relentlessly on topic. Cut off diverging threads early on, before everyone gets involved.
- During the meeting, get an action plan for each topic: What’s the next step? Who’s responsible for it? When will they have it ready? Make sure the person responsible personally commits to this–don’t just assign it to them.
- Take notes, and post a public summary. This summary informs and reminds people of the progress made and what progress needs to be made next. By being posted publicly, it also allows for discussion, clarification and correction.
- Keep track of unresolved topics, and keep bringing them up over and over so they can’t slip through the cracks.
What works poorly:
- Request topics on a mailing list, but don’t collate them into an agenda until after the meeting’s started.
- Do your best to ensure that people relevant to a topic don’t even know it’s going to be discussed, or don’t tell them what information you need from them.
- Have vague topics, so nobody’s really sure what you’re supposed to be talking about or what you want to get out of it. Feel free to branch out into anything that seems related, or really anything at all.
- If a topic isn’t resolved by the end of the meeting, forget about it. If it’s important, it’ll come up again, right?
- Don’t tell anyone what the results of the meeting were. If you have to release something, make it as hard to comprehend as possible, like an IRC log instead of a summary.
It took a lot of pain and wasted time for me to figure out the value of doing things right, and I’m still working on getting some of the above points right, so I want to save you that same pain.
Do you have any more points to add? Please do so in the comments. Thanks!
Striving for greatness 
In XMMS2’s meetings, we have participants prepare a statement with TODO, BLOCKING, DISCUSS, and DONE fields. When the meeting starts, participants paste their statements and everyone is brought up-to-date on what everyone else is doing.
TODO represents what is to be done, DONE, what the participant has accomplished since last meeting, BLOCKING, what’s preventing TODO from being accomplished, and DISCUSS is anything the participant would like to discuss during the meeting. If the DISCUSS items are not already on the official agenda, they are usually discussed after the official agenda items are exhausted.
With this layout, XMMS2 developers are almost never duplicating each others’ work or submitting conflicting work.
Related to being relentlessly on topic:
It’s good to have a set time length, and someone to act as time keeper. They might chime in periodically to say how much time is left, like “We only have 30 more minutes, and haven’t gotten through half the agenda.”
Great summary!
Stuff I’d add / refine:
* Unresolved topics go into a “bin list” that is reviewed at the end of the meeting for next actions, discarding, or postponement to next meeting. Tell people their idea or issue went on to the bin list to help the group move on.
* Use a collaborative document like Google Docs during the meeting (or insert your favorite multi-user collaborative editing environment here) – adding notes, putting things on the bin list, and letting everyone view (and – depending on the type of meeting, edit!) helps keep things on track. SubEthaEdit is a fun one. Would like to hear from others about what tools they use!
* Come up with a snappy phrase for letting people know they’re going off topic or maybe too mired in details that don’t matter at the moment – “rathole!” is a common one. Using the same phrase that everyone understands helps prevent having a meta-discussion about whether something is off-topic or not.
-selena
Hey Donnie,
I’m flrichar in the #LJ channel on freenode. I think you’re right on target, even for meetings that don’t happen in IRC-space. I’m not a developer, but I am a sr network engineer for a consultant and ASP. Too many of our meetings are inefficient! Not only that, we like to have them on lunch, so it ends up being one person standing in front of everyone else, kinda barking, while everyone else is eating.
For the engineering types obsessed with efficiency, this kinda stuff drives me crazy. Some of the best meetings we’ve ever had consisted of the following:
– everone contributed
– everyone /stood up/ (ie was not seated)
– everyone had a clear idea of what they were bringing to the table and their roles and responsiblities
Plenty of these were “lightning meetings” that happened very quickly, but were extremely efficient.