Stephan Lo 62999b41d0 feat(docs): restructure documentation with new framework and templates

- Archive old docs to docs-old/ for reference
- Create new top-down documentation structure:
  * Platform Overview: purpose, audience, product structure
  * Components: individual platform components (Forgejo, Kubernetes, Backstage)
  * Getting Started: onboarding and quick start guides
  * Operations: deployment, monitoring, troubleshooting
  * Governance: ADRs, project history, compliance
- Add DOCUMENTATION-GUIDE.md with writing guidelines and templates
- Add component template (TEMPLATE.md) for consistent documentation
- Simplify root README and move technical docs to doc/ folder
- Update test configuration:
  * Exclude legacy content from markdown linting
  * Relax HTML validation for theme-generated content
  * Skip link checking for legacy content in test:links
  * Keep 'task test' clean for technical writers (100% pass)
  * Add 'task test:full' with comprehensive link checking
- Update home page with corrected markdown syntax
- Fix internal links in archived content

BREAKING CHANGE: Documentation structure changed from flat to hierarchical top-down approach

2025-11-16 13:32:10 +01:00

2.9 KiB

Raw Blame History

{short title, representative of solved problem and found solution}

Context and Problem Statement

{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}

Decision Drivers

{decision driver 1, e.g., a force, facing concern, …}
{decision driver 2, e.g., a force, facing concern, …}
…

Considered Options

{title of option 1}
{title of option 2}
{title of option 3}
…

Decision Outcome

Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.

Consequences

Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
…

Confirmation

{Describe how the implementation of/compliance with the ADR can/will be confirmed. Are the design that was decided for and its implementation in line with the decision made? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Not that although we classify this element as optional, it is included in many ADRs.}

Pros and Cons of the Options

{title of option 1}

{example | description | pointer to more information | …}

Good, because {argument a}
Good, because {argument b}

Neutral, because {argument c}
Bad, because {argument d}
…

{title of other option}