upstream-mirrors/OpenTracks
1
0
Fork 1
mirror of https://codeberg.org/OpenTracksApp/OpenTracks.git synced 2026-10-26 11:04:46 +01:00
Code Issues Packages Projects Releases Wiki Activity

Revert "docs: refine README presentation with banner and fork overview"

Browse Source 
This reverts commit 3670bb853e.
This commit is contained in:
karol
2026-10-24 12:53:55 +02:00
parent 3670bb853e
commit e26f102946
3 changed files with 23 additions and 90 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README-STYLE.md
+2 -18
View File
@@ -1,12 +1,12 @@
# Repository README standard
Version: 1.1. Documentation language: English.
Version: 1.0. Documentation language: English.
A README should explain the project, help a new reader start it, and point to detailed references. Keep project-specific instructions and existing attribution when applying this standard.
## Original projects
Start with one `# Project name` heading and a short description of what the project does and who it serves. An optional local screenshot or banner may follow. Follow with a compact project facts table and three or four primary navigation links. Put the complete section navigation inside a `Browse all sections` disclosure.
Start with one `# Project name` heading and a short description of what the project does and who it serves. An optional local screenshot or banner may follow. Then add a navigation line linking to the level-two sections present in the document.
Use these level-two headings in this order. Omit sections that do not apply; do not add empty sections or filler just to match the template.
@@ -69,22 +69,6 @@ Borrowing a component or taking inspiration from another project does not by its
- Preserve existing technical instructions, screenshots, credits, and license notices when reorganizing. Move long references into `docs/` when useful and update links relative to their new location.
- Never infer a license from a badge, framework, dependency, or a different repository. License choices require an explicit project decision.
## Presentation
Use the same visual hierarchy for original projects and forks:
1. A plain H1 with the project name.
2. An optional repository-local SVG banner or real product screenshot, with meaningful alt text. Use a short, factual tagline and a simple product-specific illustration. Keep text readable at narrow widths, and preserve an existing project logo or identity.
3. A one-paragraph description with a bold opening sentence.
4. A compact facts table with one row and three or four columns, such as project type, platform, deployment, storage, or license. Include only verified facts.
5. Three or four primary action links, optionally centered with `<p align="center">`. Use real destinations such as Getting started, Releases, Configuration, and Usage. Do not imply a download exists unless one is available.
6. A short fork-identity callout for forks, linking to both this repository and upstream and distinguishing their downloads.
7. A `<details>` block labeled `Browse all sections` with links to every level-two section.
Use short two- or three-column tables for grouped capabilities, station/platform support, fork changes, and documentation links. Keep ordinary prose for explanations. Put long file trees, diagnostic references, and platform-specific details in `<details>` blocks with descriptive summaries. Leave installation prerequisites, required configuration, important limitations, and primary commands expanded. Include blank lines around Markdown inside HTML disclosure blocks so Gitea renders it correctly.
Keep the header compact. Banners should use repository-local assets and render without scripts, external fonts, or network dependencies. Do not add decorative status badges or unverified build/test claims. A banner is optional for small repositories; the facts table, clear primary links, and content hierarchy should still work without one.
## Maintenance
Update the README alongside changes to installation, configuration, commands, supported hardware, or release behavior. Check local links, navigation, and Markdown structure before committing. Run a command only when its effects are appropriate; a documentation check must not flash hardware, publish a release, send messages, or start an import.