Thank you for taking the time to contribute to FANZi! The following guidelines will help you get started quickly and ensure a smooth review process.
- Code of Conduct
- Getting Started
- How to Report a Bug
- How to Request a Feature
- Development Workflow
- Coding Standards
- Commit Message Conventions
- Pull Request Guidelines
- Project Architecture
This project follows the Contributor Covenant Code of Conduct. By participating you agree to abide by its terms. Please be respectful and constructive in all interactions.
| Tool | Version | Notes |
|---|---|---|
| .NET SDK | 10.0+ | Required to build |
| IDE | Any | Visual Studio 2022+, JetBrains Rider, or VS Code |
| OpenRGB | Latest | Optional — needed for RGB testing |
| Windows 10/11 | — | Required for hardware sensor testing |
# Fork via GitHub UI, then:
git clone https://github.com/<your-username>/FANZi.git
cd FANZidotnet build src/Fanzi.FanControl/Fanzi.FanControl.csprojdotnet run --project src/Fanzi.FanControl/Fanzi.FanControl.csproj --configuration Debug- Search existing issues to avoid duplicates.
- Use the Bug Report issue template.
- Include:
- Windows version and architecture
- .NET runtime version (
dotnet --version) - Steps to reproduce
- Expected vs actual behaviour
- Relevant log output or screenshots
- Search existing issues and discussions.
- Use the Feature Request issue template.
- Describe the use-case and the proposed solution clearly.
- Create a branch from
main:git checkout -b feat/my-feature # or git checkout -b fix/issue-42 - Make your changes (see Coding Standards).
- Build and verify:
dotnet build src/Fanzi.FanControl/Fanzi.FanControl.csproj dotnet run --project src/Fanzi.FanControl/Fanzi.FanControl.csproj
- Commit following the convention.
- Push your branch and open a Pull Request.
- Language version: C# 13 (latest features available in .NET 10).
- Nullable reference types are enabled — do not suppress warnings blindly.
- MVVM pattern: business logic belongs in
Services; UI state belongs inViewModels; views must contain no logic. - Naming conventions:
- Types:
PascalCase - Private fields:
_camelCase - Local variables and parameters:
camelCase - Interfaces:
IPrefix
- Types:
- Formatting: use 4-space indentation; keep lines ≤ 120 characters where practical.
- Comments: XML doc comments (
///) on all public members; inline comments for non-obvious logic only. - No magic numbers or strings: use named constants or enum values.
- Keep methods short and focused on a single responsibility.
FANZi uses Conventional Commits:
<type>(<scope>): <short summary>
[optional body]
[optional footer: BREAKING CHANGE or issue refs]
| Type | When to use |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation only |
style |
Formatting, whitespace (no logic change) |
refactor |
Code restructure (no feature / bug change) |
perf |
Performance improvement |
test |
Add or fix tests |
chore |
Build, tooling, dependency updates |
feat(rgb): add Cyberpunk theme preset
fix(hardware): handle null CPU sensor on non-admin run
docs(readme): add RGB connection instructions
chore(deps): upgrade Avalonia to 11.3.12
- Target the
mainbranch. - Give the PR a clear, descriptive title using the commit convention above.
- Fill in the pull request template completely.
- Keep PRs focused — one feature or bug fix per PR.
- Ensure the project still builds cleanly with
dotnet build. - Reference any related issues with
Closes #<number>in the PR body. - Screenshots are highly appreciated for UI changes.
See docs/WIKI.md and docs/FILE-STRUCTURE.md for a detailed description of the codebase layout and architecture.
Thank you for contributing to FANZi! — Ionity Global (Pty) Ltd