What would be the rule of thumb, which decision size is big enough to worth a DR, what triggers “I have to write a DR for this”?
- Why did we end up not using FIFO queues here?
- Why did we decide to disable users who did x?
- Why did we create a new module rather than updating the existing one?
I say "changes in" because we'd often write an architecture document at the start of a project. That document has the initial assumptions and reasonings. A decision record documents inevitable changes to the plan as we find out more about the problem space.
I also find having a person directly responsible updating the record is the best, if the project doesn't involve too many people.
If not, then start one as that's the easiest way to review what the concerns of the day were back then, and to begin to see where having history starts paying dividends.
Otherwise, something like the principle of https://en.m.wikipedia.org/wiki/Prudent_man_rule -- ie. were you parachuted into this project, which decisions would need rationales?
It's going to be more true of things that are harder to change, more true of things that touch more places in the code, more true when decisions are higher risk, more true when reasoning is less obvious.
I also think we should err on the side of writing too many ADRs, and writing ADRs that are too lightweight. There's some implicit pressure that if we're writing down our reasoning we'd better make sure it's good reasoning, but it's simultaneously true that some decisions don't deserve a lot of deliberation and when a decision didn't get a lot of deliberation we would like to know that down the line. If we capture some number of ADRs that say "decided XYZ because shrug", then down the line when we're inevitably bit by some bad decisions, we can look at whether those were disproportionately the ADRs that got less thought.
Rule of thumb: are we, or someone else, going to second guess this decision in a year or two? If it feels likely an ADR is in place.