Keeping track of decisions made #1408
Replies: 1 comment
-
Sounds great, I think it would be good to align on how we conduct discussions pushing them to be public by default where possible. Most likely continuing to use GitHub's Issues, PR or Discussions feature. I am wary of adding too much process overhead at this stage for a comparatively small group of people. Do you think there are enough stakeholders in this project to warrant something as formal as Architectural Decision Records or Request for Comments? The backstage project you reference has distinct interest groups; for example Spotify as the original author and Roadie.io as a SaaS reseller. In my mind it will introduce one more place that decisions will be made and need to be rediscovered in the future. I am already worried that we have too many discussions deferred to a monthly development call, which given the global distribution of contributors with busy lives, does not often seem to have people present who can enable a decision to be made. |
Beta Was this translation helpful? Give feedback.
-
Quite a lot of core decision-making happens a bit in isolation, usually on the dev call but also sometimes via github discussions/issues or slack messages. I think it might be useful to have some means of better capturing more of these decisions in the hopes that it can
I quite like how backstage.io go about documenting their Architecture Decisions, and would propose we go about in a similar format (but open to any thoughts suggestions).
I'd be really keen to hear what other people think about the idea so that we can then discuss it on the Feb 7th dev call .
A couple example initial proposed decisions docs:
D001 - use of decision docs to cover larger decisions (e.g. what types of decision? process for deciding and what to include in summary docs)
D002 - summarise recent proposal and planned implementation for conventional commits
Beta Was this translation helpful? Give feedback.
All reactions