How to take notes at meetings

A group of people with laptops sitting around a rectangular wooden table.

In chapter 6 of Program Management for Open Source Projects, I talk about running useful meetings. I extol the virtues of tools like Debian’s MeetBot for taking notes in online meetings. But what if your meeting is on a video call or in person? Most projects — if they have meetings at all — hold text-based meetings, but video and in-person meetings have higher bandwidth that help with more in-depth discussions. You don’t need them for routine business, but for debating strategy, policy, and the like, the more human connection help.

Before the meeting

Taking good notes during the meeting starts before the meeting. Do as much prep work as you can, including putting the agenda in the file you’ll use to take the notes. This saves you from having to type out stuff that you knew ahead of time. This includes collecting links you know you’ll need (including to documents, issues, et cetera).

You also need to decide who is taking notes. Since you’re reading this post, there’s a good chance it’s you. But if you’re the one leading the meeting, it should not be you. It’s very difficult to facilitate discussion and take notes on that discussion at the same time. But there’s another matter to consider: are you the only note taker or will there be notes-by-committee?

I’m not keen on having multiple people take notes at the same time, but a different note taker for each section can be a good way to spread the load. In that case, you need to assign each person a section and make sure you share your notes document (if it’s in an online tool like Etherpad or Google Docs) with them.

Here’s another factor to consider ahead of time: how will you note confidential information (if at all)? In some contexts, you’ll end up discussing confidential information that shouldn’t go into the public readout. How will you make clear — in the conversation and in the notes — what’s confidential? In Fedora Council meetings, we called confidential information “red text”, even though we ended up recording it in cornflower blue for better accessibility. You might also choose not to record any notes on confidential discussion. That’s the best way to prevent accidentally disclosing it. But the notes may be valuable for later discussions, so there’s some value in recording that information.

During the meeting

Most of the work happens during the meeting. Taking concise-but-understandable notes is a skill you hone with practice. Remember you’re there to summarize key points, not to transcribe the meeting word-for-word. But when people talk faster than you can keep up, ask for a pause. If everyone agrees, you can record the meeting so that you can return to difficult to capture spots later. But in my experience, if you’re summarizing, there’s no need to return to the tape.

For status-type meetings, I often take notes in an outline format. The first level is the topic, then I indent for sub-topics, points on those topics, etc. Each time someone else starts talking, it’s a new line. For discussion and debate meetings, I write paragraphs for each person’s thoughts or interjections. Each new line of thought is a new paragraph.

In both cases, I make sure to indicate who is the person saying the idea. (If you forget someone’s name, ask them.) The format of the notes don’t matter. You won’t share those publicly, in most cases. The important thing is to record the information so that the later readouts are well-informed.

I’m also a fan of keeping a separate document for tracking minutes. These are different from notes and focus on concise detail about topic changes, proposals, and votes. I purposely keep that to myself to make the doc cleaner to work with (although I share it with everyone later, as you’ll see below).

After the meeting

Once the meeting is over, you need to make the notes presentable. This includes writing up minutes to record decisions. You’ll want to publish these in a long-term archive of some type. If the meeting was more toward the strategy or policy side, you should write a narrative readout as well. This explains what decisions were made, the reasoning behind them, and the hoped effect. Of course, if any action items came from the meeting, record those in the place you usually record action items.

This post’s featured photo by Christina @ on Unsplash

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.