Decisions records are a generic version of architecture decision records, a lightweight type of documentation for recording decisions that have a significant impact on a codebase. Decision records can be useful for many types of decisions, not just those relating to software architecture. To enable project teams to easily use decision records in their documentation, publish a template and set of best practices for decision records.
## Research
Research into various templates for decision records
**[Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)**
- Context
- Decision
- Status
- Consequences
//This is the most popular format I saw in my research. It's also the most minimalist. Variations I saw include moving Status to the beginning, making the context the lead section by removing the Context heading, and adding a Rationale section. Similar: [pmerson/ADR-template](https://github.com/pmerson/ADR-template/blob/master/ADR-template.md)//
**[MADR](https://adr.github.io/madr/examples.html)** ("Markdown Any Decision Records")
"Long version":
- Content and problem statement
- Considered options
- Decision outcome
- Positive consequences
- Negative consequences
- Pros and cons of the options
- Option 1 description
- ...
- More information
"Short version":
- Context and problem statement
- Considered options
- Decision outcome
//The extra complexity in the heading adds confusion compared to the Nygard format, and the split into positive and negative consequences is overly prescriptive.//
**[Tyree and Akerman](https://personal.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf)**
- Issue
- Decision
- Status
- Group
- Assumptions
- Constraints
- Positions
- Argument
- Implications
- Related decisions
- Related requirements
- Related artifacts
- Related principles
- Notes
//Not lightweight enough to be easily reusable.//
### See also
- https://en.wikipedia.org/wiki/Architectural_decision#Decision_documentation