propose using ADRs

CONTRIBUTING.md

@@ -366,6 +366,10 @@ cabal run db-analyser -- --db <PATH_TO_NODE>/cardano-node/state-node-mainnet/db-
 
 This produces the profiling file `db-analyser.prof`.
 
-### Odds and Ends
+## Architectural Decision Records
+
+See [ADR-1](docs/adr/2022-12-01_001-record-architectural-decisions.md).
+
+## Odds and Ends
 
 See the [wiki](https://github.com/input-output-hk/cardano-ledger/wiki) for some other odds and ends.

docs/adr/2022-12-01_001-record-architectural-decisions.md

@@ -0,0 +1,30 @@
+---
+slug: 1
+title: |
+  1. Record Architecture Decisions
+authors: []
+tags: [Accepted]
+---
+
+## Status
+
+Accepted
+
+## Context
+
+We are in search for a means to describe our technical architecture.
+
+We prefer light-weight documentation methods which accomodate change easily.
+
+The [Hydra team](https://github.com/input-output-hk/hydra)
+has had success with the solution described below.
+See the [Hydra ADR 1](https://github.com/input-output-hk/hydra/blob/master/docs/adr/2021-06-05_001-record-architectural-decisions.md).
+
+## Decision
+
+* We will use _Architecture Decision Records_, as described by Michael Nygard in this [article](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
+* We will follow the convention of storing those ADRs as Markdown formatted documents stored under `docs/adr` directory, as exemplified in Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools). This does not imply we will be using `adr-tools` itself.
+
+## Consequences
+
+See Michael Nygard's article, linked above.