Why separate decisions from discussion?

Because they are read by different people at different times. Whoever missed the meeting wants the decisions; whoever disputes one in three months wants the reasoning. Mixed together, the decision gets buried in the argument that produced it.

What makes an action item actually get done?

One named owner and a date. "The team will look into it" has neither and never happens. A table forces both, because an empty cell is visible in a way a missing sentence is not.

Should I write notes during the meeting or after?

During, in this structure, with the decisions and actions filled in as they happen. Confirming the actions out loud before everyone leaves takes a minute and catches the ones two people understood differently.

How do I handle a meeting with no decisions?

Say so explicitly: "no decisions" under the heading is information, not an empty section. A run of them is a useful signal about whether the meeting needs to exist at its current frequency.

Why Markdown rather than a notes app?

Portability and search. A folder of dated .md files opens in anything, greps in a second, and survives the app you used going away. It also means notes about a project can live beside the project rather than in a separate silo.

How should I name the files?

Date first, in ISO order: 2026-08-01-weekly-sync.md. They then sort chronologically in any file listing without any tooling, which is most of what you want from meeting notes six months later.

Meeting notes template in Markdown

Make your meeting-notes.md

The whole file is here. Edit it, then copy it or save it. Nothing is sent anywhere.

meeting-notes.md

# Weekly Sync: 2026-08-01

**Attending:** Ana, Ben, Carla, Dev
**Apologies:** Ellis
**Chair:** Ana · **Notes:** Dev

## Agenda

1. Q3 launch date
2. Support backlog
3. Hiring update

## Decisions

> Decisions go here, not in the discussion notes. If someone reads only one
> section three months from now, this is the one.

- **Launch moves to 14 September.** The 31 August date did not survive the
  security review. Ana to tell the customers already told about August.
- **Support rota becomes two people.** One person cannot cover the European
  morning and the US afternoon.

## Discussion

### Q3 launch date

Ben walked through the security review findings. Two are blocking, both in the
export path, and the fix is roughly a fortnight. Carla noted marketing has
already booked the announcement slot and can move it once without cost.

### Support backlog

Down from 140 to 62 open tickets. The remaining tail is mostly one integration.
Dev suggested a batch fix rather than one-by-one replies.

### Hiring update

Two candidates at final stage. Offer likely next week.

## Actions

| # | Action | Owner | Due |
| :-- | :--- | :--- | :--- |
| 1 | Email affected customers about the new date | Ana | 4 Aug |
| 2 | Fix the two blocking export findings | Ben | 15 Aug |
| 3 | Draft the two-person rota | Carla | 8 Aug |
| 4 | Batch reply to the integration tickets | Dev | 6 Aug |

## Next meeting

**8 August, 10:00.** Standing items plus the rota draft.

# Weekly Sync: 2026-08-01

**Attending:** Ana, Ben, Carla, Dev
**Apologies:** Ellis
**Chair:** Ana · **Notes:** Dev

## Agenda

1. Q3 launch date
2. Support backlog
3. Hiring update

## Decisions

> Decisions go here, not in the discussion notes. If someone reads only one
> section three months from now, this is the one.

- **Launch moves to 14 September.** The 31 August date did not survive the
  security review. Ana to tell the customers already told about August.
- **Support rota becomes two people.** One person cannot cover the European
  morning and the US afternoon.

## Discussion

### Q3 launch date

Ben walked through the security review findings. Two are blocking, both in the
export path, and the fix is roughly a fortnight. Carla noted marketing has
already booked the announcement slot and can move it once without cost.

### Support backlog

Down from 140 to 62 open tickets. The remaining tail is mostly one integration.
Dev suggested a batch fix rather than one-by-one replies.

### Hiring update

Two candidates at final stage. Offer likely next week.

## Actions

| # | Action | Owner | Due |
| :-- | :--- | :--- | :--- |
| 1 | Email affected customers about the new date | Ana | 4 Aug |
| 2 | Fix the two blocking export findings | Ben | 15 Aug |
| 3 | Draft the two-person rota | Carla | 8 Aug |
| 4 | Batch reply to the integration tickets | Dev | 6 Aug |

## Next meeting

**8 August, 10:00.** Standing items plus the rota draft.

Visual

Open in the editor Runs in this tab, nothing is uploaded.

Notes that nobody reads afterwards are a way of appearing to pay attention. This structure exists to make them worth opening again, which mostly means separating what was decided from what was said.

Decisions come before discussion

The section order here is deliberate and slightly counterintuitive: decisions sit above the discussion that produced them. Someone catching up reads top-down and stops when they have what they need, and what they almost always need is the decision. The reasoning is there underneath for the person who wants to reopen it.

Write each decision as a complete sentence that survives without context. “Ana to tell the customers” means nothing in November; “Launch moves to 14 September. Ana to tell the customers already promised August” still does.

The actions table

#	Action	Owner	Due
1	Email affected customers about the new date	Ana	4 Aug
2	Fix the two blocking export findings	Ben	15 Aug

Three columns are load-bearing: the action, one owner, one date. A shared owner is not an owner, if two people are genuinely needed, name the one who is accountable and mention the other in the action text.

The numbers make the meeting itself easier: “item three” is faster than reading the row aloud.

Attendance is not trivia

Recording who was present and who sent apologies answers the question that otherwise derails the next meeting: “was I in the room for that?”. The chair and the note-taker are worth naming for the same reason.

Keep one file per meeting

A single long document accumulating every session becomes unsearchable within a quarter. One dated file per meeting, named 2026-08-01-weekly-sync.md, sorts chronologically anywhere and lets you delete a year without surgery.

Common questions

Why separate decisions from discussion?: Because they are read by different people at different times. Whoever missed the meeting wants the decisions; whoever disputes one in three months wants the reasoning. Mixed together, the decision gets buried in the argument that produced it.
What makes an action item actually get done?: One named owner and a date. "The team will look into it" has neither and never happens. A table forces both, because an empty cell is visible in a way a missing sentence is not.
Should I write notes during the meeting or after?: During, in this structure, with the decisions and actions filled in as they happen. Confirming the actions out loud before everyone leaves takes a minute and catches the ones two people understood differently.
How do I handle a meeting with no decisions?: Say so explicitly: "no decisions" under the heading is information, not an empty section. A run of them is a useful signal about whether the meeting needs to exist at its current frequency.
Why Markdown rather than a notes app?: Portability and search. A folder of dated .md files opens in anything, greps in a second, and survives the app you used going away. It also means notes about a project can live beside the project rather than in a separate silo.
How should I name the files?: Date first, in ISO order: 2026-08-01-weekly-sync.md. They then sort chronologically in any file listing without any tooling, which is most of what you want from meeting notes six months later.