I totally agree, and I saw some success myself by introducing ADRs as a collaborative decision process instead of a documentation methodology.
Because documentation "is for the future", whereas using ADRs in pull requests to take decisions is "for the present". It's a lot easier to sell a methodology that is useful now, instead of being possibly useful in the future ;)
And also, I am trying to create a nice tooling for ADRs, especially to be able to communicate on them, with my new open-source project: github.com/thomvaill/log4brains
This is a CLI + web UI that lets you manage and publish your ADRs from Markdown to a static website, with search, flow graph and other useful features.
This is a beta, so your feedback is very welcome!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree, and I saw some success myself by introducing ADRs as a collaborative decision process instead of a documentation methodology.
Because documentation "is for the future", whereas using ADRs in pull requests to take decisions is "for the present". It's a lot easier to sell a methodology that is useful now, instead of being possibly useful in the future ;)
And also, I am trying to create a nice tooling for ADRs, especially to be able to communicate on them, with my new open-source project: github.com/thomvaill/log4brains
This is a CLI + web UI that lets you manage and publish your ADRs from Markdown to a static website, with search, flow graph and other useful features.
This is a beta, so your feedback is very welcome!