better adr template

docs/architecture/adr-template.md

@@ -1,19 +1,36 @@
-# ADR 000: Template for an ADR
-
-Author:
+# 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}