From f5aaf3ef523cd5f5df08a94a40401084eb81809b Mon Sep 17 00:00:00 2001
From: Matthew Sevey <mjsevey@gmail.com>
Date: Mon, 17 Apr 2023 15:39:29 -0400
Subject: [PATCH] Make use of the common adr template in the .github repo
 (#1599)

<!--
Please read and fill out this form before submitting your PR.

Please make sure you have reviewed our contributors guide before
submitting your
first PR.
-->

## Overview

<!--
Please provide an explanation of the PR, including the appropriate
context,
background, goal, and rationale. If there is an issue with this
information,
please provide a tl;dr and link the issue.
-->

To unify the ADR structure we added a template in the .github repo. This
PR adds a helpful command to generate new ADRs from that template.

Example:     https://asciinema.org/a/56X6g1bA9NpWq0FxW8wDMRJ3g

Closes #1415

## Checklist

<!--
Please complete the checklist to ensure that the PR is ready to be
reviewed.

IMPORTANT:
PRs should be left in Draft until the below checklist is completed.
-->

- [x] New and updated code has appropriate documentation
- [x] New and updated code has new and/or updated testing
- [x] Required CI checks are passing
- [x] Visual proof for any user facing features like CLI or
documentation updates
- [x] Linked issues closed with keywords

---------

Co-authored-by: Evan Forbes <42654277+evan-forbes@users.noreply.github.com>
Co-authored-by: Rootul P <rootulp@gmail.com>
---
 Makefile                          |  6 +++
 docs/architecture/adr-template.md | 75 -------------------------------
 2 files changed, 6 insertions(+), 75 deletions(-)
 delete mode 100644 docs/architecture/adr-template.md

diff --git a/Makefile b/Makefile
index fbecfcfbc3..6440654cf3 100644
--- a/Makefile
+++ b/Makefile
@@ -127,3 +127,9 @@ test-cover:
 	@echo "--> Generating coverage.txt"
 	@export VERSION=$(VERSION); bash -x scripts/test_cover.sh
 .PHONY: test-cover
+
+## adr-gen: Download the ADR template from the celestiaorg/.github repo. Ex. `make adr-gen NUM=016 TITLE=my-adr-title`
+adr-gen:
+	@echo "--> Generating ADR template"
+	@curl -sSL https://raw.githubusercontent.com/celestiaorg/.github/main/adr-template.md > docs/architecture/adr-$(NUM)-$(TITLE).md
+.PHONY: adr-gen
diff --git a/docs/architecture/adr-template.md b/docs/architecture/adr-template.md
deleted file mode 100644
index 23eb85834b..0000000000
--- a/docs/architecture/adr-template.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# ADR {ADR-NUMBER}: {TITLE}
-
-## Status
-
-> - When an ADR hasn't reached agreement, it should be marked as "Proposed".
-> - When an ADR has reached agreement, it should be marked as "Accepted" or "Declined".
-> - When an ADR is reflected in the code, it should be marked as "Implemented".
-> - When an ADR is no longer relevant, it should be marked as "Deprecated".
-
-{Proposed|Accepted|Declined|Implemented|Deprecated}
-
-## Changelog
-
-- {date}: {changelog}
-
-## Context
-
-> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high-level idea behind the solution.
-
-## Alternative Approaches
-
-> This section contains information about alternative options that are considered before making a decision. It should contain an explanation of why the alternative approach(es) were not chosen.
-
-## Decision
-
-> This section records the decision that was made.
-> It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request to get the needed information.
-
-## Detailed Design
-
-> This section does not need to be filled in at the start of the ADR but must be completed prior to the merging of the implementation.
->
-> Here are some common questions that get answered as part of the detailed design:
->
-> - What are the user requirements?
->
-> - What systems will be affected?
->
-> - What new data structures are needed, and what data structures will be changed?
->
-> - What new APIs will be needed, and what APIs will be changed?
->
-> - What are the efficiency considerations (time/space)?
->
-> - What are the expected access patterns (load/throughput)?
->
-> - Are there any logging, monitoring, or observability needs?
->
-> - Are there any security considerations?
->
-> - Are there any privacy considerations?
->
-> - How will the changes be tested?
->
-> - If the change is large, how will the changes be broken up for ease of review?
->
-> - Will these changes require a breaking (major) release?
->
-> - Does this change require coordination with the SDK or others?
-
-## Consequences
-
-> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
-
-### Positive
-
-### Negative
-
-### Neutral
-
-## References
-
-> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
-
-- {reference link}