mirror of
https://github.com/gesellix/Bose-SoundTouch.git
synced 2026-08-18 16:46:17 +00:00
The templates were written during the Go-library era and no longer match the project: they asked reporters (mostly speaker owners) for Go versions, library versions, pkg/client pickers, and minimal repro code, while pointing at dead doc links. #478 reported one of those dead links (the troubleshooting guide). Issue templates: - Fix the dead troubleshooting + API-cookbook links (now the published docs site). - Delete the legacy .md duplicates of bug_report/feature_request/device_compatibility (GitHub was showing them alongside the .yml forms). - Rewrite bug_report.yml and feature_request.yml around how people actually run AfterTouch (service/CLI/player/backup); make them short and easy to file, with the encrypted diagnostic export as the headline ask. - Add device_compatibility.yml (slim) and a config.yml chooser that links Discussions, the Survival Guide, and the Troubleshooting Guide. Blank issues stay enabled. Diagnostic-export transparency: instead of claiming the report "contains no readable secrets", state honestly that the raw datastore XML (e.g. Sources.xml) is included as-is and can carry access tokens for linked services (Spotify/Amazon), that there is no datastore-redaction setting, and that users can unlink first or send privately. Point at the same support email the Health tab shows (aftertouch-support@gesellix.net) and note GitHub blocks .age uploads (rename to .age.txt or zip). PR template: cut the library-era ceremony down to summary/issue/type/testing/ checklist, add an "AI-assisted contributions" note (agent code welcome, unreviewed slop rejected), a no-personal-data reminder, and an MIT + Code of Conduct footer. CONTRIBUTING.md: reframe from "Bose SoundTouch API Client / Go library" to the AfterTouch toolkit; fix build paths (./build/) and make targets; drop broken references; point at CLAUDE.md; add the AI stance and the no-personal-data rule. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.5 KiB
1.5 KiB
Summary
What does this PR do, and why?
Linked issue
Refs #
Type of change
- Bug fix
- New feature
- Breaking change
- Documentation
- Refactor / tests / tooling
How was it tested?
make checkpasses (fmt, vet, lint, tests)- Tested against a real SoundTouch device (details below)
Checklist
- My changes are focused, and I have read the diff myself
- No personal data (real LAN IPs, MAC addresses, device IDs, account IDs) in code, tests, or fixtures
- Docs or CLI help updated if behavior changed
A note on AI-assisted contributions
AI and agent-assisted code is welcome, we use it here too. What we cannot accept is
unreviewed "slop": large generated diffs the author has not read, run, or understood.
Keep PRs small and focused, make sure make check passes, and be ready to explain your
changes during review.
By contributing, you agree that your work is licensed under the project's MIT License and that you will follow the Code of Conduct.