Confusion around »Characteristics of good "Consequences" section in an ADR« about architecture-decision-record HOT 4 CLOSED

Yes your question makes sense. How's this rewrite?

Characteristics of good "Consequences" section in an ADR:

• Explain what follows from making the decision. This can include the effects, outcomes, outputs, follow ups, and more.

• Include information about any subsequent ADRs. It's relatively common for one ADR to trigger the need for more ADRs, such as when one ADR makes a big overarching choice, which in turn creates needs for more smaller decisions.

• Include any after-action review processes. It's typical for teams to review each ADR one month later, to compare the ADR information with what's happened in actual practice, in order to learn and grow.

from architecture-decision-record.

Sounds lovely, everything in this rewrite makes perfect sense to me ❤️

Absolutely no confusion here.

When i read though the examples, they don't have a "Consequences" section, but do list implications – things that need to be sorted out as a consequence of the decision.

So my only suggestion could be to add the word "implications" (either next to "Consequences" or in the first bullet point), but in generally i think your rewrite makes a great improvement.

Thanks for your quick response!

from architecture-decision-record.

(keeping this open just in case you want to track the change commit to-do, feel free to close anytime)

from architecture-decision-record.

Even though it doesn't say anything on implications, i can see 28be671 added your suggested improvements, hence closing this issue.

Thanks 👍

from architecture-decision-record.