Trimmed AI-flavored structure from docs/contribute.md and CONTRIBUTING.md: removed the Discord vs Documentation comparison table, merged the High Priority / Also Welcome buckets into a single What is Most Useful list, dropped the duplicate closing exhortation that appeared at the bottom of both files. Added a Pull Request Guidelines section to both pages covering: commit prefix convention (docs/fix/feat/chore, no subscope), one logical change per PR, hardware-verified claims, source attribution for non-obvious claims, cross-reference over duplication, and PR title matching the commit subject.
6.0 KiB
How to Contribute
Solutions posted only in Discord get lost. Adding them here makes them searchable, versioned, and easier for the next person hitting the same problem to find.
Easy Ways to Contribute
1. Edit on GitHub (no Git knowledge needed)
- Click the edit icon (✏️) in the top right of any page
- Make your changes in the GitHub editor
- Click "Propose changes" → "Create pull request"
We'll review and merge it.
2. Report Issues
Found incorrect or missing information?
Tell us:
- What's wrong or missing
- What should be there instead
- Any relevant links or sources
3. Share Your Configuration
Got BC250 working well? Share your setup:
Hardware:
- What PSU works for you?
- Which cooler keeps temps good?
- Display adapter compatibility?
Software:
- Your distro setup steps
- Kernel version that works
- BIOS settings you use
- Games you've tested
Add it to the relevant page!
What's Most Useful
Anything that helps the next person fix a problem faster:
- Game compatibility reports (FPS, settings, known issues)
- Troubleshooting solutions you've actually used
- Hardware that works (PSUs, coolers, displays, adapters)
- Distribution guides for distros not yet documented
- BIOS settings for specific use cases
- Benchmark results with your configuration
- Typo fixes, clearer explanations, missing commands
- Screenshots, diagrams, dmesg or sensor captures
Please don't
- Add unverified claims or speculation. If you didn't test it, say "reportedly" and cite the source.
- Copy proprietary BIOS files or copyrighted content.
- Mix unrelated changes in one PR.
Contribution Examples
Example: Add Game Compatibility
Edit docs/gaming/compatibility.md:
### Elden Ring
**Status:** ✅ Playable
**Performance:** 55-60 FPS @ 1080p High
**VRAM:** 512MB dynamic recommended
**Settings:**
- Graphics: High
- Anti-aliasing: Medium
- RADV_DEBUG=nocompute %command%
**Notes:**
- Stuttering in some areas with 8GB/8GB split
- Smooth with 512MB dynamic VRAM
Example: Add Troubleshooting Solution
Edit docs/troubleshooting/boot.md:
### Black Screen After Mesa Update
**Symptoms:**
- System boots but no display
- SSH still works
**Solution:**
Downgrade Mesa to last working version:
```bash
sudo dnf downgrade mesa-vulkan-drivers mesa-dri-drivers
Then report the issue to Mesa GitLab.
### Example: Add Hardware Compatibility
Edit `docs/hardware/power.md`:
```markdown
### Tested PSUs
**Corsair SF450 (450W SFX)**
- ✅ Works perfectly
- Tested with RTX 3060 Ti (TDP mod)
- No stability issues
- Tested by: @username
Advanced: Local Development
Want to preview changes locally?
# Clone repository
git clone https://github.com/elektricM/amd-bc250-docs.git
cd amd-bc250-docs
# Install MkDocs
pip install mkdocs-material
# Preview locally
mkdocs serve
# Open http://127.0.0.1:8000/
Full guide: CONTRIBUTING.md on GitHub
Documentation Structure
Know where to add your contribution:
docs/
├── getting-started/ # First-time setup, prerequisites
├── hardware/ # Specs, power, cooling, displays
├── bios/ # BIOS flashing, VRAM, overclocking
├── linux/ # Distribution-specific guides
├── drivers/ # RADV driver, environment variables
├── system/ # GPU governor, sensors, power
├── gaming/ # Game compatibility, performance
├── troubleshooting/ # Common problems and solutions
└── reference/ # Quick references, cheatsheets
Pull Request Guidelines
A few conventions that keep the docs reviewable and the commit history readable.
Commit messages
Short single-line subject prefixed by type, blank line, then a body explaining what changed and why.
Allowed prefixes, lowercase, no subscope:
docs:documentation add or editfix:correcting an error or outdated informationfeat:new site feature (theme override, plugin, nav change)chore:refactor, dependency bumps, non-functional mkdocs.yml cleanup
Examples:
docs: add Alpine Linux setup guidefix: correct VRAM pages_limit value in Fedora CoreOS guidechore: bump mkdocs-material to 9.5
One change per PR
Keep each PR focused on one logical change. Typo fix and new distro guide should be two PRs. Mixed PRs are slower to review and harder to revert.
Hardware-verified claims
If you add a command, parameter, kernel option, or BIOS setting, run it on a BC-250 first and confirm the outcome. Real output (sensors, dmesg, benchmark scores) is better than paraphrase.
Cite the source
For non-obvious claims (performance numbers, kernel-version requirements, "stable up to X MHz"), say where the information came from: your own bench, a Discord thread, an upstream kernel commit. "Reportedly" is fine for unconfirmed claims as long as it's flagged.
Cross-reference, don't duplicate
If a step is already documented elsewhere (governor setup, BIOS flashing, kernel choice), link to that page instead of copying the steps. Keeps the site maintainable.
PR title matches the commit subject
Use the same line for the PR title and the commit subject. If the PR has multiple commits and we squash-merge, that subject becomes the merged commit.
Review Process
- Submit your PR
- Automated checks verify the site builds
- Maintainer review (usually within 48 hours)
- Feedback if changes are needed
- Merge, automatic publish to https://elektricM.github.io/amd-bc250-docs/
Questions?
- How do I...? Read CONTRIBUTING.md
- Found a bug? Open an issue
- Need help? Ask in Discord, but add the answer here when solved!