add Architectural Decision Record: Release Policy (opendatahub-io#224)

* ✨ add ADR

add ADR documentation to keep track of architectural decisions

Signed-off-by: Christoph Görn <[email protected]>

* 🐛 fix a nano typo

Signed-off-by: Christoph Görn <[email protected]>

* 🐛 fix one more nano typo

Signed-off-by: Christoph Görn <[email protected]>

docs/adr/0000-odh-release-policy.md

@@ -0,0 +1,39 @@
+# Open Data Hub Release Policy 
+
+* Status: proposed
+* Deciders: vpavlin 
+* Date: 2020-Nov-03 
+
+Technical Story: As an Open Source project, we want to document the policies and guideline on how we create a new
+release.
+
+## Context and Problem Statement
+
+The Open Data Hub itself consists of many components all having their own release cycles. ODH users might decide to
+update individual components such as container images used by JupyterHub. Nevertheless it is required to create
+releases of ODH as a whole.
+
+## Considered Options
+
+* do a monolithic, coordinated release of all components of ODH by creating a tag within the odh-manifests repository
+* have a rolling release, and no tags on odh-manifests repository 
+
+## Decision Outcome
+
+Chosen option: we do a monolithic, coordinated release, because it will enable us to have a release at the
+project/product level while maintianing freedom of others to update.
+
+### Positive Consequences <!-- optional -->
+
+* Operators of ODH have a clear base line of versions, these versions have been tested with each other and have
+  undergone ODH integration testing.
+* Operators of ODH can update individual components, they could maintain a repository analog to odh-manifests declaring
+  the exact versions (container image tags, git repository tags) of components they want to deploy.
+* Operators can mix in their builds of container images following the method mentioned above.
+
+### Negative Consequences <!-- optional -->
+
+* An ODH release (a tag in the odh-manifests repository) might not contain the latest versions of components, for example
+  security updates might have forced the build of a S2I image used with JupyterHub component of ODH.
+
+<!-- markdownlint-disable-file MD013 -->

docs/adr/README.md

@@ -0,0 +1,9 @@
+## Architectural Decisions
+
+We keep track of architectural decisions using a lightweigh architectural decision records. More information on the
+used format is available at https://adr.github.io/madr/. General information about architectural decision records
+is available at https://adr.github.io/ .
+
+### Architectural Decisions
+
+* [ADR-0000](0000-odh-release-policy.md) - The Open Data Hub Release Policy

docs/adr/template.md

@@ -0,0 +1,74 @@
+# [short title of solved problem and solution]
+
+* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
+* Deciders: [list everyone involved in the decision] <!-- optional -->
+* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->
+
+Technical Story: [description | ticket/issue URL] <!-- optional -->
+
+## Context and Problem Statement
+
+[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]
+
+## Decision Drivers <!-- optional -->
+
+* [driver 1, e.g., a force, facing concern, …]
+* [driver 2, e.g., a force, facing concern, …]
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* [option 1]
+* [option 2]
+* [option 3]
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+
+### Positive Consequences <!-- optional -->
+
+* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
+* …
+
+### Negative Consequences <!-- optional -->
+
+* [e.g., compromising quality attribute, follow-up decisions required, …]
+* …
+
+## Pros and Cons of the Options <!-- optional -->
+
+### [option 1]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 2]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+### [option 3]
+
+[example | description | pointer to more information | …] <!-- optional -->
+
+* Good, because [argument a]
+* Good, because [argument b]
+* Bad, because [argument c]
+* … <!-- numbers of pros and cons can vary -->
+
+## Links <!-- optional -->
+
+* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
+* … <!-- numbers of links can vary -->
+
+<!-- markdownlint-disable-file MD013 -->