You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
decision: Use ADRs in the `adr` directory of the repo to document architectural decisions
5
+
author: '@jakedoublev'
6
+
deciders: ['@ryanulit', '@jrschumacher']
7
+
---
8
+
9
+
# Use a ADR storage format that make diffs easier to read
10
+
11
+
## Context and Problem Statement
12
+
13
+
We've been using Github Issues to document ADR decisions, but it's hard to read the diffs when changes are made. We need a better way to store and manage ADRs. ADRs sometimes get updated and it's hard to track the changes and decision using the edit history dropdown or the comments section.
14
+
15
+
## Decision Drivers
16
+
17
+
-**Low barrier of entry**: A primary goal of our ADR process is to ensure decisions are captured.
18
+
-**Ease of management**: Make it easy to manage the ADRs.
19
+
-**Ensure appropriate tracking and review**: Make it easy to track and review the changes in the ADRs.
20
+
21
+
## Considered Options
22
+
23
+
1. Use Github Issues
24
+
2. Use Github Discussions
25
+
3. Use a shared ADR repository
26
+
4. Use an `adr` directory in the repo
27
+
28
+
## Decision Outcome
29
+
30
+
It was decided to use an `adr` directory in the repo to store ADRs. This approach provides a low barrier of entry for developers to document decisions and ensures that the decisions are tracked and reviewed appropriately.
31
+
32
+
Additionally, this change does not impact other teams or repositories, and it is easy to manage and maintain. We can experiment with this decision and if it works promote it to other repositories.
33
+
34
+
### Consequences
35
+
36
+
-**Positive**:
37
+
- Low barrier of entry for developers to document decisions.
38
+
- Easy to manage and maintain.
39
+
- Ensures appropriate tracking and review of decisions via git history and code review.
40
+
-**Negative**:
41
+
- Requires developers to be aware of the ADR process and where to find the ADRs.
42
+
- May require additional tooling to manage and maintain the ADRs.
43
+
- May require additional training for developers to understand the ADR process and how to use it effectively.
# Consistent output format for printing JSON and pretty-print
10
+
11
+
## Context and Problem Statement
12
+
13
+
We need to develop a printer that can globally determine when to print in pretty-print format versus JSON format. This decision is crucial to ensure consistent and appropriate output formatting across different use cases and environments.
14
+
15
+
## Decision Drivers
16
+
17
+
-**Consistency**: Ensure uniform output format across the application.
18
+
-**Flexibility**: Ability to switch between pretty-print and JSON formats based on context.
19
+
-**Ease of Implementation**: Simplicity in implementing and maintaining the solution.
20
+
21
+
## Considered Options
22
+
23
+
1. Keep existing code as is
24
+
2. Move the printing into a global function that has context about the CLI flags to drive output format
25
+
26
+
## Decision Outcome
27
+
28
+
It was decided to encapsulate printing to ensure there is consistent output format. This function will have context about the CLI flags to drive the output format. This approach provides the flexibility to switch between pretty-print and JSON formats based on the context.
29
+
30
+
### Consequences
31
+
32
+
-**Positive**:
33
+
- Provides flexibility to switch formats without changing the code.
34
+
- Ensures consistent output format across different environments.
35
+
- Simplifies the implementation and maintenance process.
36
+
37
+
-**Negative**:
38
+
- Requires careful management of configuration settings.
39
+
- Potential for misconfiguration leading to incorrect output format when developers use `fmt` directly.
0 commit comments