docs: Architecture Decision Records: home and upkeep #28
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Discussion
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Help Wanted
Status
Need More Info
Prio - Hoog
Prio - Laag
Prio - Middel
styling
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
MinBZK/DAWO-NixOS#28
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Tracking issue for the ADRs landed in #22, split off from #1 so the docs work has
its own home (as asked at the end of #22).
Why
#22 records the series' decisions as ADRs inline in
architecture.md. Two openquestions came up there that outlive that PR:
architecture.md(as now) or a dedicateddocs/adr/tree, one file per record?keeps ADR upkeep visible without overloading #1.
Decision (for now)
Keep ADRs inline in
architecture.md. The reasoning lives next to thearchitecture prose, the count is low, and one file is easy to review. Revisit a
docs/adr/split if/when the records outgrow a single readable section.Scope
newest on top.
docs/adr/question only if the section gets unwieldy.Closes nothing on its own, this is the home for ADR follow-ups.
docs: Architecture Decision Records — home and upkeepto docs: Architecture Decision Records: home and upkeep