How to take meeting notes

Even in an open source project, you can’t escape meetings. But meetings don’t have to be pointless. If you know how to take meeting notes, you can help make the meeting useful. This post is just about the notes, though. For more about useful meetings, see chapter six of Program Management for Open Source Projects or the meetings tag on this site.

Before the meeting

Good note taking starts before the meeting.

• Build the agenda. Your meeting needs an agenda. This not only helps keep the meeting focused and gets the right people in the room, but it gives you a starting point for your notes. Part of building the agenda is collecting the action items from the previous meeting for follow up.
• Pick a medium. Before you can take notes, you have to know how you’ll do it. Research suggests that taking notes on pen and paper helps retention, but that’s not easy to share or search. If your meeting is in a text format (like IRC or Matrix), then something like Debian’s MeetBot is ideal. Otherwise, a group-editable online document (like Etherpad or Google Docs) works well.
• Choose a secretary. This should not be the person running the meeting. It’s hard to take notes and also focus on the flow of the conversation enough to steer it. Designate a person before (or at the start of) the meeting to be the note taker.
• Set expectations. If you have a shared notes doc, how should people interact with it? Can they add their own notes as the meeting progresses? Should they ask for permission to add something during the meeting. Can they make clarifications and edits after the fact? You should also decide if there are certain things (e.g. confidential information) that won’t be included in the notes or will be excluded from the published version.

During the meeting

When the meeting begins, you should ensure there’s a secretary and remind attendees of the expectations. Then the fun starts!

• Record the vital information. Note the meeting name, date, and the venue. This helps put the notes in the appropriate historical context.
• List attendees. Noting the attendees makes it easier to understand later who was in the room for the discussion. Many “how to take meeting notes” articles will suggest also recording absences, but that’s less valuable in this context. Meetings in an open source project are generally public or semi-public, so it’s hard to list everyone who isn’t there.
• Take notes. Obviously. The following subsection has more details.
• Note major items. There are a few items that you should clearly label in the notes:
  • Proposals. When someone makes a proposal, note what the proposal is and who said it.
  • Decisions. (Sometimes called “agreements”.) What did the group agree to? If a vote was taken, record the count (or a full roll call listing).
  • Todo items. Meetings are great at generating action items. Record who is responsible for what by when.
  • Help requests. If someone makes a call for help, note it so that others can see what’s needed.

Take notes

Up until this point, I’ve glossed over a distinction between meeting notes and meeting minutes. Meeting notes are less structured and more dense. Meeting minutes are a formalized version of notes, effectively. Which approach you take will depend on context. Well-structured meetings that focus on updates and coordination can jump straight to minutes. Broader strategy and brainstorming meetings often benefit from a notes style.

To make meeting minutes, my favorite approach is to use a list. Unordered works, but ordered gives you a way to quickly refer to other items. Either way, you use an outline format. Each topic is a top-level list entry, with important items and key notes nested underneath. When adding notes, be sure to indicate who said what.

Notes are a little more challenging. You want to record what happens with enough fidelity that the notes are useful later, but you can’t make a word-for-word transcript. Despite what I’ve told you before, acronyms and initialisms are your friends here. Abbreviate when you can sensibly do it. As with minutes, you’ll want to be clear on who is speaking.

I typically try to condense every three sentences or so to one. That’s a very loose rule, though. You’re trying to summarize peoples’ thoughts on the fly, so do your best to synthesize what’s said and then drop it from memory so you can move on. This is the big reason why it’s hard to chair and secretarialize a meeting a the same time. You’ll only get better at this by practicing, but don’t be afraid to ask for a pause in conversation so you can catch up.

After the meeting

Just because the meeting ended, that doesn’t mean the notes are done.

• Create minutes. If you took notes in a meeting minutes style, then there’s nothing to do here. If you used the notes style, condense your notes to minutes.
• Publish minutes. Take your minutes and put them in the place where your community publishes minutes. Again, this is where MeetBot makes life a little easier, since it can be used to auto-publish minutes.
• Update tickets, bugs, etc. If the meeting involved discussion of tickets, bugs, or other trackable things, add a comment with the results of the meeting. You should also close, reassign, or make whatever other adjustment is necessary. Sometimes that will be none, because the meeting did not bring the item to a resolution.
• Create issues for todo items. If new action items were generated, open an issue in the appropriate tracker. This helps make sure the action item doesn’t become an inaction item.

This post’s featured photo by Aaron Burden on Unsplash.