Related issues, PRs or discussions
https://adr.github.io
What is the current state of the codebase?
We often run into "late debates", where a PR is opened with architectural decisions already made without being discussed. This can cause the contributor to have to rewrite the PR in full on review.
This could be avoided by more clear design requests for more complex changes.
Our existing issues are user story focused, and generally avoid focusing on implementation details.
That means, once an issue is triaged, the approach is not considered or approved until implementation stage at a PR.
Why are changes required?
to improve planning when writing complex changes, and reduce frustrations/issues around late rewrites
What technical changes are required?
ADRs are a form of proposal for making code changes. They create a way to write a plan for architecture changes, and give the opportunity for review and discussion. More on ADR philosophy and templates.
We can implement this by creating issue templates for complex code changes.
When an issue is triaged, but the approach is uncertain, an ADR may be requested.
Complex code changes without user stories should be submitted via ADRs.
We may want to consider tweaking/replacing this template (developer facing changes) for the ADR model.
Are the proposed technical changes API breaking?
No
Are there potential risks or issues with the proposed implementation?
no
Related issues, PRs or discussions
https://adr.github.io
What is the current state of the codebase?
We often run into "late debates", where a PR is opened with architectural decisions already made without being discussed. This can cause the contributor to have to rewrite the PR in full on review.
This could be avoided by more clear design requests for more complex changes.
Our existing issues are user story focused, and generally avoid focusing on implementation details.
That means, once an issue is triaged, the approach is not considered or approved until implementation stage at a PR.
Why are changes required?
to improve planning when writing complex changes, and reduce frustrations/issues around late rewrites
What technical changes are required?
ADRs are a form of proposal for making code changes. They create a way to write a plan for architecture changes, and give the opportunity for review and discussion. More on ADR philosophy and templates.
We can implement this by creating issue templates for complex code changes.
When an issue is triaged, but the approach is uncertain, an ADR may be requested.
Complex code changes without user stories should be submitted via ADRs.
We may want to consider tweaking/replacing this template (developer facing changes) for the ADR model.
Are the proposed technical changes API breaking?
No
Are there potential risks or issues with the proposed implementation?
no