amd-bc250-docs/CONTRIBUTING.md

Contributing to BC250 Documentation

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.

Quick Start (No Git Knowledge Required)

Method 1: Edit Directly on GitHub (Easiest)

1. Browse to the page you want to edit on GitHub: https://github.com/elektricM/amd-bc250-docs/tree/main/docs
2. Click the pencil icon (✏️) in the top right
3. Make your changes using the editor
4. Scroll down and click "Propose changes"
5. Click "Create pull request"

Done! We'll review and merge your contribution.

Method 2: Report Issues

Found incorrect information or missing content?

1. Go to https://github.com/elektricM/amd-bc250-docs/issues
2. Click "New Issue"
3. Describe what's wrong or what's missing
4. Submit

We'll fix it or add the missing information.

What's Most Useful

Anything that helps the next person fix a problem faster:

• Tested hardware (power supplies, cooling, displays, adapters)
• Game compatibility (FPS, settings, issues, workarounds)
• Troubleshooting solutions you've actually used
• Distribution-specific setup steps
• 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.

Documentation Structure

docs/
├── getting-started/     # First-time setup
├── hardware/           # Specs, power, cooling, displays
├── bios/              # BIOS flashing, VRAM, overclocking
├── linux/             # Distribution setup guides
├── drivers/           # RADV, environment variables
├── system/            # Governor, sensors, power management
├── gaming/            # Game compatibility
├── troubleshooting/   # Common problems and solutions
└── reference/         # Quick references

For Advanced Contributors (Using Git)

Setup Local Environment

# Clone the repository
git clone https://github.com/elektricM/amd-bc250-docs.git
cd amd-bc250-docs

# Install dependencies
pip install mkdocs-material

# Preview your changes locally
mkdocs serve
# Open http://127.0.0.1:8000/ in your browser

Making Changes

# Create a new branch
git checkout -b fix-something

# Edit files in docs/ directory
# Preview changes with: mkdocs serve

# Stage your changes
git add docs/

# Commit with a clear message (see Pull Request Guidelines below for the prefix)
git commit -m "fix: correct Fedora setup instructions for Mesa 25.1"

# Push to your fork
git push origin fix-something

# Create pull request on GitHub

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 edit
• fix: correcting an error or outdated information
• feat: new site feature (theme override, plugin, nav change)
• chore: refactor, dependency bumps, non-functional mkdocs.yml cleanup

Examples:

• docs: add Alpine Linux setup guide
• fix: correct VRAM pages_limit value in Fedora CoreOS guide
• chore: 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.

Writing Guidelines

Style:

• Use clear, concise language
• Write for beginners but include advanced details
• Use code blocks for commands
• Add warnings for risky operations

Markdown Format:

# Page Title

Brief introduction explaining what this page covers.

## Section Heading

Content here.

### Subsection

More specific content.

!!!warning "Important Warning"
    Use admonitions for critical information.

!!!tip "Pro Tip"
    Helpful hints for users.

```bash
# Code blocks with syntax highlighting
sudo dnf install mesa-vulkan-drivers

Links:

[Relative link to another page](../bios/flashing.md)
[External link](https://example.com/)

**Testing:**
- Test all commands you document
- Verify links work
- Check formatting with `mkdocs serve`

## Contribution Examples

### Example 1: Adding Game Compatibility

Edit `docs/gaming/compatibility.md`:

```markdown
### Cyberpunk 2077

**Status:** ✅ Playable
**Performance:** 45-60 FPS @ 1080p Medium
**VRAM:** 512MB dynamic or 8GB/8GB split
**Settings:**
- RT: Off (too demanding)
- FSR: Quality mode
- RADV_DEBUG=nocompute %command%

**Issues:**
- Occasional stuttering in crowded areas
- Fixed with kernel 6.13+

Example 2: Adding Troubleshooting Solution

Edit docs/troubleshooting/boot.md:

### Black Screen After Kernel Update

**Symptoms:**
- System boots but no display output
- Fans running normally

**Solution:**
1. Boot into recovery kernel from GRUB
2. Downgrade to previous kernel version:
   ```bash
   sudo dnf downgrade kernel

3. Report kernel version that failed on GitHub Issues

### Example 3: Adding Distribution Guide

Create new file `docs/linux/gentoo.md`:

```markdown
# Gentoo Setup

Step-by-step guide for setting up BC250 on Gentoo.

## Prerequisites
- Gentoo installation media
- Basic Gentoo knowledge

## Installation
[...]

Then add to mkdocs.yml:

- Linux Setup:
    - Gentoo Setup: linux/gentoo.md

Review Process

1. Submit your PR
2. Automated checks verify the site builds
3. Maintainer review for accuracy and clarity
4. Feedback if changes are needed
5. Merge, automatic publish to https://elektricM.github.io/amd-bc250-docs/

Questions?

• Documentation issues: Open an issue on GitHub
• General BC250 discussion: Join Discord (but please document solutions here!)
• Pull request help: Ask in the PR comments

License

By contributing, you agree your contributions will be licensed under CC BY-SA 4.0 for documentation and MIT for code examples.