Architectural Decision Records
We document our architectural and design decisions for all of our components. In order to do that, there is practice called architectural decision records (“ADR”), that we can integrate into our workflow. An architectural decision record (ADR) is a document that captures an important architectural decision made along with its context and consequences.
The goals are:
making decisions transparent to internal/external stakeholders and contributors.
getting feeback on decisions that we’re about to make or have made
providing external contributors a framework to propose architectural changes
providing a big picture of all major decisions that were made
The general process for creating an ADR is:
cloning the repository
creating a new file with the format <ADR_NUMBER>-<TITLE>.rst in the directory doc/adr
adding the ADR in the table of content tree of the Readthedocs
committing and pushing to the repository
- ADR 1: Record architectural decisions
- ADR 2: Repository Standardization
- ADR 3: Move Marconi into a separate repository
- ADR 4: PAB and indexing component integration
- ADR 5: Common Contract API
- ADR 6: Support reference inputs in constraint library
- ADR 7: Support inline datums in constraint library
- ADR 8: Support reference scripts in constraint library
- ADR 9: Support return and total collateral when building transactions
- ADR 10: Commit to data types in cardano-api
- ADR 11: Transaction validity time range fix
- ADR 12: Time conversion semantic change
- ADR 13: Self-contained cardano-node emulator component
- ADR 14: End-to-end testing strategy for Plutus, cardano-ledger-api and cardano-node-client