A month later, saying we already discussed this is rarely enough. What was discussed, which option was rejected and what information was available then? I use a decision log to preserve those answers.
Keep the record compact
Date, decision, rationale, owner and conditions for reconsideration are often sufficient. A full meeting transcript is not a decision record. The discussion needs to be distilled into something understandable later.
An illustrative entry might say that the first release will contain two languages because editorial capacity for a third is unavailable, name the publication owner and specify that the decision will be reviewed when a reliable translation resource is secured. This records the boundary as well as the choice.
Explain rejected alternatives
When an idea returns, the previous assessment can be consulted. That does not make the old decision permanently correct. Changed circumstances may make another option appropriate.
I avoid recording only unsuitable. Was the concern time, resources, scope or reader need? The reason helps people recognise which changed condition might justify reopening the discussion.
Separate decisions from tasks
Opening a new topic page is a decision. Preparing its draft by Friday is a task. They can be linked, but they are not the same record. When decisions disappear into a task list, their reasoning becomes difficult to recover.
A decision without an implementation step also risks remaining abstract. Linking the relevant task or deliverable makes the relationship visible.
Log meaningful changes
I do not record every spelling correction. Changes to direction, scope, priority, timing or responsibility deserve more attention. The approval workflow should make clear which decisions require a record.
The purpose is not to defend the past, but to reduce future guesswork. If a new collaborator can find an answer to why the work is organised this way, the log is doing something useful.