-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Open
Description
If you introduce ADRs into a project (or organisation), then the decision to introduce ADRs should be recorded as an ADR.
This ADR context should explain:
- WHY documenation of architectural decisions is required,
- WHY introducing ADRs it is a architectural decision and not a normal decision
- WHY the ADR approach is best for your project (maybe what other approaches you had considered)
To collect some examples as inspiration to others: Please attach to this github issue your ADR, that introduces ADRs to your project. (This may help others to put arguments when introducing ADRs) ;-)
Consequences - e.g.:
- enables the "future me" to recall the old context correctly when reviewing this decision e.g. 12 month in the future (when i hopefully will have gained more knowledge)
- enables your team mates to "review", "accept" and "operate" on this decision (better team knowledge)
- enables team mates to challenge decisions today or in the future (by being able to detect changes in old and latest context)
- enables future team mates to join the project more easyer
- enables to reduce the communication overhead involved when decision is not written down (1:1-chats for knowledge-transfer; imaging team sizes of >10)
- ...your argument here...
Or do you think that ADR is not a AD at all?
benji-york, joelparkerhenderson, mgan59, affonso-rafael, michaelhettmer and 10 more
Metadata
Metadata
Assignees
Labels
No labels