mirror of
https://github.com/zkldi/Tachi.git
synced 2026-09-26 00:47:57 +03:00
zk
e363bd2532
* docs: migrate from mkdocs to mdbook - Rename old mkdocs docs/ to old-docs/ for reference - Set up new docs/ with mdbook (book.toml + src/ tree) - Mirror full nav structure from mkdocs.yml into SUMMARY.md - Add Justfile-docs with docs-serve, docs-build, docs-check, docs-install recipes - Import Justfile-docs from root Justfile - Rewrite .github/workflows/docs.yml: build step uses taiki-e/install-action to install mdbook, split into separate build + deploy jobs, PR builds run the check step too * ci(docs): pin actions to SHAs, install mdbook via release binary * ci(docs): install mdbook from apt instead of curling a release binary * dev: replace mkdocs python stack with mdbook in dev image * ci(docs): apt only works on Debian; restore release binary install for Ubuntu CI * docs: fix duplicate file entries in SUMMARY.md * docs: remove docs-install recipe * docs: remove site-url from book.toml to fix asset loading * dev: install mdbook from upstream release binary, not Debian apt The Debian package (0.4.x+ds) strips bundled font assets, leaving the built site without fonts/fonts.css. Use the upstream tarball (same as CI) so the theme is complete. Handles x86_64 and aarch64. * docs: vendor mdbook tarballs in dev/mdbook/, install from there Dockerfile.dev uses COPY + tar to install the right arch at build time. CI extracts the x86_64 tarball directly from the checkout. No network access required for either — and no stripped-fonts Debian package. * fix: unwritten
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# GitHub Issues Guide
|
|
|
|
This isn't really a Tachi component, but it's important enough to have a guide.
|
|
|
|
We use GitHub issues for all of our issue tracking and feature planning, if you're looking to request a feature or report a bug, good etiquette is defined here.
|
|
|
|
## Etiquette
|
|
|
|
Be nice.
|
|
|
|
If you're reporting a bug, **be as explicit as possible**. If something crashed, what were you doing at the time of the crash? Remember that a human has to read your post and attempt to diagnose the issue.
|
|
|
|
For the same reasons that you wouldn't go to a doctor and just say "It hurts", you can't just report a software issue as "It's broken". Low effort and ambiguous bug reports will be closed.
|
|
|
|
## Large Feature Requests
|
|
|
|
If you've came up with an idea for a new large feature, that's awesome! Before you post it though, think it through for a while.
|
|
I personally find it very helpful to think on ideas in the shower, but basically anything where you can think about an idea undistracted is useful (like a walk or something).
|
|
|
|
This will help you shape up the feature, and makes it easier for maintainers to implement said feature (Especially if it's major).
|
|
|
|
Regardless, once you've posted a large feature request, expect there to be discussion in the thread. You should check your emails!
|
|
|
|
## Existing Issues
|
|
|
|
Search for existing issues before opening a new one. There might already be one open with a similar thing.
|
|
|
|
## That's it!
|
|
|
|
Don't fret too much about writing perfect issues, but put some effort into them. The development team look at everything that comes through, and will tidy up bits of your issue for you if you make a mistake.
|