docs ADR (#2828)

* wip

* use same ADR template as SDK

* finish docs adr

* lil fixes

docs/architecture/adr-035-documentation.md

@@ -0,0 +1,40 @@
+# ADR 035: Documentation
+
+Author: @zramsay (Zach Ramsay)
+
+## Changelog
+
+###  November 2nd 2018
+
+- initial write-up
+
+## Context
+
+The Tendermint documentation has undergone several changes until settling on the current model. Originally, the documentation was hosted on the website and had to be updated asynchronously from the code. Along with the other repositories requiring documentation, the whole stack moved to using Read The Docs to automatically generate, publish, and host the documentation. This, however, was insufficient; the RTD site had advertisement, it wasn't easily accessible to devs, didn't collect metrics, was another set of external links, etc.
+
+## Decision
+
+For two reasons, the decision was made to use VuePress:
+
+1) ability to get metrics (implemented on both Tendermint and SDK)
+2) host the documentation on the website as a `/docs` endpoint.
+
+This is done while maintaining synchrony between the docs and code, i.e., the website is built whenever the docs are updated.
+
+## Status
+
+The two points above have been implemented; the `config.js` has a Google Analytics identifier and the documentation workflow has been up and running largely without problems for several months. Details about the documentation build & workflow can be found [here](../DOCS_README.md)
+
+## Consequences
+
+Because of the organizational seperation between Tendermint & Cosmos, there is a challenge of "what goes where" for certain aspects of documentation.
+
+### Positive
+
+This architecture is largely positive relative to prior docs arrangements.
+
+### Negative
+
+A significant portion of the docs automation / build process is in private repos with limited access/visibility to devs. However, these tasks are handled by the SRE team.
+
+### Neutral

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}