Skip to content

Wiki Maintenance

Jump to bottom
ecamacho edited this page Jul 10, 2026 · 2 revisions

Wiki Maintenance

How this wiki is kept current. This is the owner-friendly recurring procedure.

Golden rule (non-optional)

Whenever a new release tag is created, the wiki MUST be updated in the same release work unit, before the release is considered done. This applies to maintainers and to any contributor performing release work. It is not a follow-up task.

Rationale: a release with a stale wiki causes user confusion (wrong versions, missing features, broken install steps) and undermines trust in an alpha app.

Wiki repo

  • Remote: https://github.com/netcraker01/jellyx-player.wiki.git
  • Local clone path used by this writer: /tmp/opencode/jellyx-wiki (scratch; can be re-cloned).
  • GitHub Wikis are separate repos from the main repo, at <org>/<repo>.wiki.git.
  • If cloning returns "Repository not found", the wiki has no initial page yet — push the first page to initialize it.

Page inventory

Page Purpose
Home Landing
Installation Download and install
Building from Source Prereqs and build scripts
Features What Jellyx does
User Guide Workflows and settings
Architecture Workspace, audio pipeline, IPC
Platform Support OS packaging matrix
UI Design Screens and visual modes
Release Process Release checklist
Packaging Guide Per-platform packaging
Contributing How to contribute
Engineering Process Conventions and workflow
Privacy and License Privacy, AGPL, CLA
Screenshots Visuals
Release History Past releases
Wiki Maintenance This page

Release-update procedure (recurring)

Run this in the same work unit as creating the release tag.

1. Bump and tag

  • Confirm the three version files match (jellyx-desktop/Cargo.toml, jellyx-desktop/tauri.conf.json, ui/package.json).
  • If they don't match, fix them before tagging. (See the v0.3.2 Known note in Release History.)
  • Tag vX.Y.Z and push.

2. Update release-facing pages

  • Release History — add a ### vX.Y.Z entry with tag, title, status, notes, and any Known issues.
  • Installation — update asset list and the About/known-version note if needed.
  • Platform Support — update artifact matrix if changed.
  • Packaging Guide — update artifact/build details if changed.

3. Update feature/UX pages if user-facing behavior changed

4. Update internals pages if architecture changed

5. Cross-cutting

6. Publish

  • Commit and push the wiki to origin.
  • Verify pages render on GitHub (no broken [[links]]).
  • Only after the wiki is updated, mark the release as done.

Link conventions

  • Use [[Page Name]] for wiki-internal links (GitHub Wiki auto-resolves to Page-Name.md).
  • Use full URLs for external links.
  • Keep page names human-readable; the wiki handles spaces vs dashes.

Style

  • Neutral professional English. Some source docs are Spanish; the wiki is English-only.
  • Lead with the answer; details after (see cognitive-doc-design patterns).
  • Prefer tables and checklists over long prose.
  • Scannable over complete.

When NOT releasing

Between releases, wiki updates are still welcome for fixes (typos, clarifications, screenshots). Open a PR or push directly to the wiki repo per team preference.

Known issue to carry forward

The v0.3.2 version-sync bug (tag says 0.3.2, files say 0.3.1) must be reflected on Release History and Installation until a release actually bumps all three files. Once a release does, remove the Known note from those pages and note the fix here.

Next step

Clone this wiki locally