Owner Documentation
Conventions are described beside the thing that owns them — a directory’s layout in its own README, a command’s behaviour in its module or script.
- Kind
- Convention
- Domain
- Documentation & Metadata
- Applies at
<area>/README.md- Status
- Stable
01 Defines
The practice of documenting each area of a repository in a README.md inside that area, opened by a common header that names the area, describes it in one line, and links to its fuller specification.
02 Applies when
- A directory has a purpose, a layout, or rules a contributor needs before adding to it.
- A command, module, or script has behaviour worth explaining to its callers.
- A convention would otherwise be recorded far from the files it governs.
03 Boundaries
- Repository-wide navigation belongs in the code map, which links to owner documentation rather than repeating it.
- Decisions that no single owner can explain go to a decision record instead.
- Owner documentation describes the area; operating guides and product context live in
docs/.
Expected behaviour
- 01Each top-level area carries a
README.mdexplaining what belongs there and the rules for adding to it. - 02Commands explain their behaviour in
Makefilemodules, scripts, and workflow files. - 03Infrastructure roots and modules document their runtime contract locally.
- 04Area READMEs open with a header table — icon, title, and one-line description — before the body.
- 05Most area READMEs close with a short Rules list that states the area’s conventions in a few lines.
Behaviour#
A reader who opens a directory is already looking at the thing they want to understand. Owner documentation meets them there. The README beside the files says what the area is for, what belongs in it and what does not, and the handful of rules that keep it coherent. Moving or deleting the area takes its documentation with it.
The same principle applies below the directory level. A make module explains itself in its header comment, a script in its usage line, a workflow in its file header. The decision-record guidance lists these owners explicitly and asks for a separate record only when none of them can carry the explanation.
Where documentation lives#
- CODEMAP.md Where to go next; links into each README Code Map
- www/README.md What a site root is Static Websites
- .gitea/README.md How automation is shaped Automation & CI/CD
- workflows/README.md Rules for workflow YAML Workflows
- actions/README.md Rules for composite actions Actions
- docs/pdlc/README.md What durable product context is Product Development Life Cycle
- decisions/README.md When a record is warranted Decision Records
- scripts/build/52-hugo.mk A module documented in its own header comment
The header pattern#
Every area README opens the same way: an HTML table with the area’s icon on the
left and, on the right, a bold title and a one-line description. The icon lives
beside the README in a local .assets/img/ directory and links out — to the
upstream documentation for a tool, or to the area’s page in this library.
A horizontal rule separates the header from the body, which typically runs
through purpose, design, and a closing Rules list.
<table style="width: 100%; border-style: none;">
<tr>
<td style="width: 80px; text-align: center;">
<a href="https://specifications.aureliasrs.ca/catalog-descriptors">
<img width="64px" src="./.assets/img/icon.svg" alt="actions logo" />
</a>
</td>
<td>
<strong>Catalog Descriptors</strong><br />
Repository-owned catalog metadata describing the repository, ownership
information, published artifacts, and related operational references<br />
</td>
</tr>
</table>
Examples#
The decision-record guidance is itself the clearest statement of the pattern:
Prefer expressing repository conventions beside the thing that owns them:
- directories explain their layout in local `README.md` files;
- commands explain behavior in `Makefile` modules, scripts, and workflow files;
- infrastructure roots and modules document their runtime contract locally;
- tests enforce architectural conventions that must survive routine change.
The code map closes the loop from the other side: “Open the local README.md
of an area for detail.”
Connections
How Owner Documentation relates to the library
Relied on by
- Code Map A generated CODEMAP.md that says what each area of the repository is for and which local README …
- Decision Records Architecture decision records are a last resort, written only when the repository’s …
- Tools Repository tooling with stable command entry points and documented contracts — small …