Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions architectureDecisionRecords/0000Example.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@

Title of the ADR

## Date proposed

01-01-0001

## Context

What is the issue that we're seeing that is motivating this decision or change?
Expand Down
4 changes: 4 additions & 0 deletions architectureDecisionRecords/0001Styling.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@

Styling our html

## Date proposed

08-19-2025

## Context

According to the [state of css 2025](https://2025.stateofcss.com/en-US) the tools that people are the most happy with in 2025 are [css modules](https://github.com/css-modules/css-modules) and [tailwindcss](https://tailwindcss.com/).
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Title

Document architecture decisions

## Date proposed

02-12-2026

## Context

It is unclear to engineers what the expectations are for contributing to this repository. We need a system for making, documenting, and enforcing architecture decisions.

## Decision

We will document our decisions in our repositories as architecture decision records.

We will follow the template provided in 0000Example.md.

Decisions will be made by consensus. If an ADR is agreed upon by at least 2/3 of the engineers on the team, then it can be added to the repository.

Pull Requests with new code that doesn't adhere to the ADRs will not be approved. High-priority urgent production bugs are an exception to this rule. This exception should be immediately followed up with a PR to fix the code, so that it conforms with the ADRs.

When making changes to code that doesn't conform to the ADRs the following steps should be taken:

1. If feasible update the code to conform to the ADRs
1. If updating the code to conform to the ADRs is too large of a scope, then at minimum create a ticket to fix the issue later, and write tests the cover the new code

## Consequences

Engineers will be able to go to a single place to learn the following

1. What architecture decisions were made and why
1. What libraries should be used
1. What coding patterns and style should be used
1. What expectations will need to be met before a PR can be merged

Pull requests will need conform to the ADRs to be approved.
Loading