From b5f8350dffe9d5ce2c44d1ffa9707e84ecff6f4b Mon Sep 17 00:00:00 2001
From: Dev Ojha <ValarDragon@users.noreply.github.com>
Date: Thu, 13 Sep 2018 19:01:30 -0700
Subject: [PATCH] Merge PR #2333: Copy ADR template from Tendermint

* Copy ADR template from Tendermint

* Modify @alexanderbez 's ADR template
---
 docs/architecture/README.md       | 22 +++++++++++++++++++++
 docs/architecture/adr-template.md | 32 +++++++++++++++++++++++++++++++
 2 files changed, 54 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 000000000000..7c669566df6c
--- /dev/null
+++ b/docs/architecture/README.md
@@ -0,0 +1,22 @@
+# Architecture Decision Records (ADR)
+
+This is a location to record all high-level architecture decisions in the cosmos-sdk project.
+
+You can read more about the ADR concept in this [blog post](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.
diff --git a/docs/architecture/adr-template.md b/docs/architecture/adr-template.md
new file mode 100644
index 000000000000..4ff7ad9465f0
--- /dev/null
+++ b/docs/architecture/adr-template.md
@@ -0,0 +1,32 @@
+# ADR {ADR-NUMBER}: {TITLE}
+
+## 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. 
+
+## Decision
+> This section explains all of the details of the proposed solution, including implementation details.
+It should also describe affects / corollary items that may need to be changed as a part of this.
+If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
+(e.g. the optimal split of things to do between separate PR's)
+
+## Status
+> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. 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}
+
+## 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 referrenced for why we made the given design choice? If so link them here!
+
+* {reference link}
\ No newline at end of file