From d6b7be3875a58aa37711265dec0a1b50aebc358b Mon Sep 17 00:00:00 2001 From: Zaven Arra Date: Wed, 11 May 2022 10:57:37 -0700 Subject: [PATCH 1/2] First draft of 0001-organization-of-ADR --- 0001-organization-of-ADRs.md | 67 ++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 0001-organization-of-ADRs.md diff --git a/0001-organization-of-ADRs.md b/0001-organization-of-ADRs.md new file mode 100644 index 0000000..c2707fa --- /dev/null +++ b/0001-organization-of-ADRs.md @@ -0,0 +1,67 @@ +# Initial plan for organization of ADR files + +* Status: proposed +* Deciders: @ZavenArra {list everyone involved in the decision using github handle} +* Date: 2022-05-11 {YYYY-MM-DD when the decision was last updated} + + +## Context and Problem Statement + +We have many decisions to make when building the treetracker platform, and we will use Architectural Design Recores (ADRs) to make more and more of these decisions. (https://adr.github.io/madr/) ADRs could be organized in a few different ways - should all decisions to be tracked in one central ADR repository, or should they be split up by teams or project areas? ADRs are assumed to be stored in a github repository or several repositories. + +## Decision Drivers + +* Ease of locating ADRs for developers +* Ease of finding ADRs relevant to a particular microservice, cloud service, or project focus +* Clarity of where to create a new ADR for a particular microservice, cloud service, or project focus + +## Considered Options + +* Place all ADRs in one repository, organization-wide. +* Create ADR respositories for aggregate project areas - cloud, frontend, and backend. +* Create a decisions folder within each repository, to hold only decisions relevant for that repository. +* … + + + +* {e.g., improvement of quality attribute satisfaction, follow-up decisions required, …} +* … + +### Negative Consequences + +* {e.g., compromising quality attribute, follow-up decisions required, …} +* … +--> + +## Pros and Cons of the Options + +### Place all ADRs in one repository, organization-wide + +This is the initial status quo. https://github.com/Greenstand/treetracker-decisions + +* 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. + +### Create ADR respositories for aggregate project areas - cloud, frontend, and backend + +* Good, because ADRs are separated by areas of concern +* Bad, because combining all frontend, or all backend, ADRs is only a marginal improvement in findability +* Bad, because some decisions will span cloud, frontend, and backend, making a fourth global ADR repo still necessary + +### 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 +* Bad, because ADRs are spread apart in many different repositories, making them hard to review en masse + + + +* {Link type} {Link to ADR} +* … +--> From f64b87e56f9263ac56ce3087e9f723252e15606e Mon Sep 17 00:00:00 2001 From: zaven Date: Wed, 11 May 2022 13:26:48 -0700 Subject: [PATCH 2/2] Update 0001-organization-of-ADRs.md --- 0001-organization-of-ADRs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/0001-organization-of-ADRs.md b/0001-organization-of-ADRs.md index c2707fa..e77abce 100644 --- a/0001-organization-of-ADRs.md +++ b/0001-organization-of-ADRs.md @@ -7,7 +7,7 @@ ## Context and Problem Statement -We have many decisions to make when building the treetracker platform, and we will use Architectural Design Recores (ADRs) to make more and more of these decisions. (https://adr.github.io/madr/) ADRs could be organized in a few different ways - should all decisions to be tracked in one central ADR repository, or should they be split up by teams or project areas? ADRs are assumed to be stored in a github repository or several repositories. +We have many decisions to make when building the treetracker platform, and we will use Architectural Decision Records (ADRs) to make more and more of these decisions. (https://adr.github.io/madr/) ADRs could be organized in a few different ways - should all decisions to be tracked in one central ADR repository, or should they be split up by teams or project areas? ADRs are assumed to be stored in a github repository or several repositories. ## Decision Drivers