wbrawner/thunderbird-android
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
thunderbird-android/docs/architecture/adr
History
Wolf-Martell Montwé 61af35b9a0
Merge pull request #7805 from thunderbird/add-adr-whitelabel-architecture 
Add ADR white label architecture
2024-05-03 14:35:53 +00:00
..
0000-adr-template.md Change to headlines for consequences as nested list cause some formatting issues 2024-05-03 12:24:27 +02:00
0001-switch-from-java-to-kotlin.md Add issue and pull request links to ADR template to keep track of relevant discussions 2024-05-02 17:02:22 +02:00
0002-ui-wrap-material-components-in-atomic-design-system.md Add issue and pull request links to ADR template to keep track of relevant discussions 2024-05-02 17:02:22 +02:00
0003-switch-test-assertions-from-truth-to-assertk.md Add issue and pull request links to ADR template to keep track of relevant discussions 2024-05-02 17:02:22 +02:00
0004-naming-conventions-for-interfaces-and-their-implementations.md Add issue and pull request links to ADR template to keep track of relevant discussions 2024-05-02 17:02:22 +02:00
0005-central-project-configuration.md Add ADR for the central project configuration 2024-05-03 11:42:00 +02:00
0006-white-label-architecture.md Add ADR for the white label architecture 2024-05-03 16:24:38 +02:00
README.md Add issue and pull request links to ADR template to keep track of relevant discussions 2024-05-02 17:02:22 +02:00

README.md

Architecture Decision Records

This folder contains the architecture decision records (ADRs) for our project.

ADRs are short text documents that serve as a historical context for the architecture decisions we make over the course of the project.

What is an ADR?

An Architecture Decision Record (ADR) is a document that captures an important architectural decision made along with its context and consequences. ADRs record the decision making process and allow others to understand the rationale behind decisions, providing insight and facilitating future decision-making processes.

Format of an ADR

We adhere to Michael Nygard's ADR format proposal, where each ADR document should contain:

  1. Title: A short descriptive name for the decision.
    1. Link to Issue: A link to the issue that prompted the decision.
    2. Link to Pull Request: A link to the pull request that implements the ADR.
    3. Link to Tracking Issue: A link to the tracking issue, if applicable.
  2. Status: The current status of the decision (proposed, accepted, rejected, deprecated, superseded)
  3. Context: The context that motivates this decision.
  4. Decision: The change that we're proposing and/or doing.
  5. Consequences: What becomes easier or more difficult to do and any risks introduced as a result of the decision.

Creating a new ADR

When creating a new ADR, please follow the provided ADR template file and ensure that your document is clear and concise.

Directory Structure

The ADRs will be stored in a directory named docs/adr, and each ADR will be a file named NNNN-title-with-dashes.md where NNNN is a four-digit number that is increased by 1 for every new adr.

ADR Life Cycle

The life cycle of an ADR is as follows:

  1. Proposed: The ADR is under consideration.
  2. Accepted: The decision described in the ADR has been accepted and should be adhered to, unless it is superseded by another ADR.
  3. Rejected: The decision described in the ADR has been rejected.
  4. Deprecated: The decision described in the ADR is no longer relevant due to changes in system context.
  5. Superseded: The decision described in the ADR has been replaced by another decision.

Each ADR will have a status indicating its current life-cycle stage. An ADR can be updated over time, either to change the status or to add more information.

Contributions

We welcome contributions in the form of new ADRs or updates to existing ones. Please ensure all contributions follow the standard format and provide clear and concise information.