First draft of 0001-organization-of-ADR #1
Conversation
|
|
||
| ### Create a decisions folder within each repository, to hold only decisions relevant for that repository. | ||
|
|
||
| * Good, because specific decisions for specific services and applications are contained within the repo for that project |
There was a problem hiding this comment.
I believe we should have both central repo for system wide architecture decisions and project based ADRs for tactical decisions made for that project.
One e.g. of a tactical decision for a project could be about a specific choice made for a domain model applicable only to that project. When ADR is created, the engineer creating it would have to decide if the scope is specific to the service or not specific to the project and decide accordingly.
There was a problem hiding this comment.
That sounds great. I guess we can always create a project view (such as https://github.com/orgs/Greenstand/projects/45/views/1)
pulling from different repros or? That way we can have a centralised view of decentralised ADRs or?
There was a problem hiding this comment.
I agree. A hybrid approach would offer good flexibility, and we always have the option of elevating a project-specific decision to the org-wide repo either during review, or at a later date by quoting/linking the original decision in a new org ADR.
Searchability/discoverability may prove an issue, but I'm sure we could find a good solution.
There was a problem hiding this comment.
I like the idea of making a project for all ADRs, and making adding a new ADR to the project board a standard part of the ADR creation process.
There was a problem hiding this comment.
We could use project boards to manage ADRs that span a couple of repos but not necessarily organization-wide while having individual repos with their own ADR as it pertains to it. I think having a project for all ADRs might possibly get cumbersome? Or the ADR for a particular project could be on the project board of that project as opposed to having its own project board
There was a problem hiding this comment.
@Kpoke If the organization-wide board becomes cumbersome, we can create filtered sub-boards within that board to break out the ADRs more nicely.
We can also investigate automation that takes any new PR that adds a file to the decisions/ folder, and adds that PR to our project board.
|
|
||
| * Good, because all ADRs reside in one location and are easy to find | ||
| * Good, because we can revisit this decision later and split off separate ADR repositories as needed | ||
| * Bad, because ADRs tracking decisions of various scope, large and small, global and very specific, are combined together and thus difficult to search. |
There was a problem hiding this comment.
Perhaps we can tag each ADR with the repositories or project areas affected.
There was a problem hiding this comment.
We can tag the ADR PRs, but once they are merged how would the tags operate?
There was a problem hiding this comment.
Not an ideal solution, but we can still search closed PRs by label.
Perhaps we could use a basic hashtag format within the file for searching, and either add search page links to the README or set up a GitHub action to maintain repo-specific lists.
|
|
||
| * Good, because all ADRs reside in one location and are easy to find | ||
| * Good, because we can revisit this decision later and split off separate ADR repositories as needed | ||
| * Bad, because ADRs tracking decisions of various scope, large and small, global and very specific, are combined together and thus difficult to search. |
There was a problem hiding this comment.
Perhaps we can tag each ADR with the repositories or project areas affected.
No description provided.