Docs: update docs (thanos-io#743)

* Docs: update docs, add diagram, philosopy and ensure proposals are mentioned

* move links

* tweaks

CONTRIBUTING.md

@@ -6,6 +6,21 @@ method with the owners of this repository before making a change.
 
 Please follow the [code of conduct](CODE_OF_CONDUCT.md) in all your interactions with the project.
 
+## Thanos Philosophy
+
+The philosophy of Thanos and our community is borrowing much from UNIX philosophy and the golang programming language.
+
+* Each sub command should do one thing and do it well
+  * eg. thanos query proxies incoming calls to known store API endpoints merging the result
+* Write components that work together
+  * e.g. blocks should be stored in native prometheus format
+* Make it easy to read, write, and, run components
+  * e.g. reduce complexity in system design and implementation  
+
+## Adding New Features / Components
+
+Adding large new features and components to Thanos should be done by first creating a [proposal](docs/proposals) document outlining the design decisions of the change, motivations for the change, and any alternatives that might have been considered.
+
 ## Pull Request Process
 
 1. Read [getting started docs](docs/getting_started.md) and prepare Thanos.

README.md

@@ -6,13 +6,26 @@
 
 ## Overview
 
-Thanos is a set of components that can be composed into a highly available
-metric system with unlimited storage capacity. It can be added seamlessly on
-top of existing Prometheus deployments and leverages the Prometheus 2.0
-storage format to cost-efficiently store historical metric data in any object
-storage while retaining fast query latencies. Additionally, it provides
-a global query view across all Prometheus installations and can merge
-data from Prometheus HA pairs on the fly.
+Thanos is a set of components that can be composed into a highly available metric 
+system with unlimited storage capacity, which can be added seamlessly on top of existing 
+Prometheus deployments. 
+
+Thanos leverages the Prometheus 2.0 storage format to cost-efficiently store historical metric 
+data in any object storage while retaining fast query latencies. Additionally, it provides
+a global query view across all Prometheus installations and can merge data from Prometheus 
+HA pairs on the fly.
+
+Concretely the aims of the project are:
+
+1. Global query view of metrics.
+1. Unlimited retention of metrics.
+1. High availability of components, including Prometheus.
+
+## Architecture Overview
+
+![architecture_overview](docs/img/arch.jpg)
+
+## Getting Started
 
 * **[Getting Started](docs/getting_started.md)**
 * [Design](docs/design.md)
@@ -33,9 +46,20 @@ data from Prometheus HA pairs on the fly.
 * Simple gRPC "Store API" for unified data access across all metric data
 * Easy integration points for custom metric providers
 
+## Thanos Philosophy
+
+The philosophy of Thanos and our community is borrowing much from UNIX philosophy and the golang programming language.
+
+* Each sub command should do one thing and do it well
+  * eg. thanos query proxies incoming calls to known store API endpoints merging the result
+* Write components that work together
+  * e.g. blocks should be stored in native prometheus format
+* Make it easy to read, write, and, run components
+  * e.g. reduce complexity in system design and implementation
+
 ## Contributing
 
-Contributions are very welcome!
+Contributions are very welcome! See our [CONTRIBUTING.md](CONTRIBUTING.md) for more information.
 
 ## Community