Initial template setup

This commit is contained in:
2026-05-09 16:41:16 +02:00
commit e481bcf70f
12 changed files with 245 additions and 0 deletions
+9
View File
@@ -0,0 +1,9 @@
root = true
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = false
indent_style = space
indent_size = 2
+26
View File
@@ -0,0 +1,26 @@
---
name: Bug Report
about: Something is broken or behaves unexpectedly
title: "[Bug] "
labels: ["bug"]
---
## What happened
<!-- Describe the bug. What did you do, what did you expect, what happened instead? -->
## Steps to reproduce
1.
2.
3.
## Environment
- Version:
- OS:
- Anything else relevant:
## Logs / Screenshots
<!-- Paste relevant log output or attach screenshots. Use ```code blocks``` for logs. -->
+22
View File
@@ -0,0 +1,22 @@
---
name: Feature Request
about: Suggest an idea or improvement
title: "[Feature] "
labels: ["enhancement"]
---
## The problem
<!-- What are you trying to do? What's missing or annoying? -->
## Proposed solution
<!-- How would you solve it? Concrete behavior, not implementation details. -->
## Alternatives considered
<!-- What else did you think about? Why didn't that work? -->
## Additional context
<!-- Screenshots, examples from other tools, related issues. -->
+22
View File
@@ -0,0 +1,22 @@
## Summary
<!-- What does this PR do? 1-3 bullet points. -->
-
## Why
<!-- Linked issue, motivation, or context. "Fixes #N" if applicable. -->
## Testing
<!-- How did you verify this works? -->
- [ ]
## Checklist
- [ ] Code builds without warnings
- [ ] Tests pass (or N/A)
- [ ] Documentation updated (or N/A)
- [ ] No secrets or credentials committed
+14
View File
@@ -0,0 +1,14 @@
# OS
.DS_Store
Thumbs.db
# Editors
.vscode/
.idea/
*.swp
*.swo
# MkDocs / Docusaurus build output (uncomment if you add a generator)
# site/
# build/
# .docusaurus/
+8
View File
@@ -0,0 +1,8 @@
# CODEOWNERS — automatic review-assignment for PRs.
# Syntax: <pattern> <user-or-team-handle>
#
# More: https://docs.gitea.com/usage/code-owners
#
# Default owner for everything in the repo.
# Replace with the appropriate user/team for the new repo.
* @JonKazama-Hellion
+21
View File
@@ -0,0 +1,21 @@
MIT License
Copyright (c) 2026 Florian Wathling / Hellion Online Media
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
+68
View File
@@ -0,0 +1,68 @@
# Docs Template
A starting point for Markdown-only documentation repos on the [Hellion Forge](https://gitea.hellion-forge.cloud/).
Use this for:
- specs and design documents
- architecture decision records (ADRs)
- runbooks and post-mortems
- internal wikis
This template is plain Markdown. If you want a rendered site, add MkDocs or Docusaurus on top — the structure here works as input for either.
---
## How to use this template
1. Click **"Use this template"** on the Forge.
2. Replace this README with one that describes your specific docs repo.
3. Drop content into the appropriate folders:
- `specs/` — feature specs, requirements, design proposals
- `decisions/` — ADRs (one file per decision, prefix `ADR-NNNN-`)
- `runbooks/` — operational guides, post-mortems, troubleshooting
If a folder doesn't fit your use case, delete it.
---
## Conventions
- **One topic per file.** No mega-docs. Cross-link instead.
- **Filename = title slug.** Lowercase-kebab-case (`backup-strategy.md`, not `Backup Strategy.md`).
- **Index files** at folder roots (`specs/INDEX.md` etc.) link to all files in the folder.
- **Frontmatter** for status / dates if you use a generator that needs it. Plain Markdown otherwise.
- **No screenshots in the repo unless they're load-bearing** — link to external assets if possible.
---
## ADR template
Architecture Decision Records: one file per decision, append-only.
```markdown
# ADR-0001: Title
**Date:** 2026-05-09
**Status:** accepted | superseded by ADR-NNNN | deprecated
## Context
What's the problem we're solving? Constraints, history.
## Decision
What did we decide. Concrete and short.
## Consequences
What changes because of this. Both positive and negative.
```
See `decisions/ADR-0001-example.md` for a worked example.
---
## License
MIT — see `LICENSE`. (For docs that include third-party content, override accordingly.)
+18
View File
@@ -0,0 +1,18 @@
# ADR-0001: Example ADR
**Date:** 2026-05-09
**Status:** accepted
## Context
This is an example to show the ADR shape. Replace with your real first decision and renumber the file accordingly.
## Decision
Use the ADR pattern from Michael Nygard's article ("Documenting Architecture Decisions"): short, context-then-decision-then-consequences, one decision per file, append-only.
## Consequences
- Decisions are searchable and history-stable
- Old decisions stay readable even after they're superseded
- New contributors can read the ADR folder to understand "why is this the way it is"
+7
View File
@@ -0,0 +1,7 @@
# Architecture Decision Records
One file per decision, append-only. Status flows: `proposed``accepted` → optionally `superseded`/`deprecated`.
| ID | Title | Status | Date |
|---|---|---|---|
| [ADR-0001](ADR-0001-example.md) | Example ADR | accepted | 2026-05-09 |
+15
View File
@@ -0,0 +1,15 @@
# Runbooks
Operational guides, troubleshooting, post-mortems.
## Operations
- _(add runbooks for routine operations here — backup, restore, deploy, rollback)_
## Troubleshooting
- _(add diagnostic guides for common failure modes)_
## Post-mortems
- _(one file per incident, prefix `YYYY-MM-DD-`)_
+15
View File
@@ -0,0 +1,15 @@
# Specs
Feature specs, requirements, and design proposals.
## Active
- _(none yet)_
## Implemented
- _(none yet)_
## Archived
- _(none yet)_