Contributing

The wiki is maintained as Git-backed Markdown. Small factual edits may be made in Forgejo; larger page sets are easier to review through the separate wiki Git repository.

Choose the right home

Information	Location
Durable overview, runbook, confirmed finding	Wiki
Active bug, investigation, task, discussion	Forgejo Issue
Manager code, tests, schemas, automation	Main source repository
Public-safe machine-readable artifact metadata	Catalog repository/folder
Large or restricted bytes	Preservation artifact store
Credentials and keys	Approved secret store only

Adding a server/client pair

1. Create a server profile from Template — Server Profile.
2. Create client metadata from Template — Client Snapshot.
3. Mirror the upstream repository and record it with Template — Repository Mirror.
4. Add both to the catalog and declare their current maturity level.
5. Open issues for missing artifacts, build failures, legal/access questions, and baseline work.
6. Create a pinned baseline and define a measurable smoke test.
7. Link compatibility evidence and backup/restore status.

Findings

Use Template — Finding. Preserve controls, exact versions, negative results, and confidence. A hypothesis is welcome when labeled; do not present it as a confirmed fact.

Bugs

Use Template — Bug in Forgejo Issues and apply the taxonomy from Bug Tracker. Security-sensitive reports and personal data must not be placed in public issues.

The main repository now provides Forgejo issue templates for bug, finding, and preservation-gap reports under .forgejo/issue_template/; use them from the New Issue page so labels and evidence fields are applied consistently.

Review checklist

• Links and page names resolve.
• Exact versions/commit IDs replace ambiguous “latest” language.
• Claims distinguish observation, inference, and confirmation.
• No credentials, keys, personal data, or restricted binary content are present.
• Artifact IDs, hashes, and provenance are linked when relevant.
• Destructive operations include backup and rollback notes.
• New pages are added to the sidebar or an appropriate index.
• Profiles and catalog maturity agree.
• Machine-readable YAML passes the preservation schema validator.
• Owner and review date are present and not stale.

Writing style

Use stable internal IDs, ISO 8601 dates, full Git commit IDs in evidence, and concise headings. Keep procedures executable and expected results observable. Update durable pages after an issue is resolved so knowledge is not trapped in a discussion thread.