From 39c34900a312e311eaf92c87233ad9daf96e8632 Mon Sep 17 00:00:00 2001
From: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
Date: Thu, 24 Sep 2020 17:36:29 +0200
Subject: [PATCH] docs: ADR template (#536)

* docs: ADR template

* update
---
 docs/architecture/README.md       | 40 +++++++++++++++++++++++++++++++
 docs/architecture/adr-template.md | 40 +++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 docs/architecture/README.md
 create mode 100644 docs/architecture/adr-template.md

diff --git a/docs/architecture/README.md b/docs/architecture/README.md
new file mode 100644
index 00000000..8d9101d7
--- /dev/null
+++ b/docs/architecture/README.md
@@ -0,0 +1,40 @@
+<!--
+order: false
+parent:
+  order: false
+--->
+
+# Architecture Decision Records (ADR)
+
+This is a location to record all high-level architecture decisions in Ethermint.
+
+You can read more about the ADR concept in this blog posts:
+
+- [GitHub - Why Write ADRs](https://github.blog/2020-08-13-why-write-adrs/)
+- [Reverb - Documenting architecture decisions, the Reverb way](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t)
+
+An ADR should provide:
+
+- Context on the relevant goals and the current state
+- Proposed changes to achieve the goals
+- Summary of pros and cons
+- References
+- Changelog
+
+Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
+justification for a change in architecture, or for the architecture of something
+new. The spec is much more compressed and streamlined summary of everything as
+it stands today.
+
+If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
+
+Note the context/background should be written in the present tense.
+
+Please add a entry below in your Pull Request for an ADR.
+
+## ADR Table of Contents
+
+<!--
+Add an entry in the following format: 
+- [ADR XXX: ADR Title](./adr-XXX-adr-title.md)
+-->
diff --git a/docs/architecture/adr-template.md b/docs/architecture/adr-template.md
new file mode 100644
index 00000000..aa6f8434
--- /dev/null
+++ b/docs/architecture/adr-template.md
@@ -0,0 +1,40 @@
+# ADR {XXX}: {TITLE}
+
+## Changelog
+
+- {date}: {changelog}
+
+## Status
+
+> A decision may be "proposed" if the project stakeholders haven't agreed with it yet, or "accepted" once it is agreed. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
+> {Deprecated|Proposed|Accepted} {Implemented|Not Implemented}
+
+## Context
+
+> This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts.
+> {context body}
+
+## Decision
+
+> This section describes our response to these forces. It is stated in full sentences, with active voice. "We will ..."
+> {decision body}
+
+## Consequences
+
+> This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.
+
+### Positive
+
+{positive consequences}
+
+### Negative
+
+{negative consequences}
+
+### Neutral
+
+{neutral consequences}
+
+## References
+
+- {reference link}