Thanks for your interest in contributing. Please read this guide carefully before submitting a PR.
- Bug fixes with tests that reproduce the issue
- New tests that cover untested code paths (must not duplicate existing tests)
- Typo fixes and factual corrections in documentation
- Build/CI fixes that solve real problems
- New features - Open a Discussion first, then create an Issue if approved
- Refactoring - Must have a clear rationale and maintainer approval
- Architecture changes - Require an Issue with detailed proposal
- Documentation additions - Beyond typo fixes, discuss first
- Check existing Issues and Discussions - Your idea may already be tracked
- Run the tests -
dotnet testmust pass - Format your code -
dotnet csharpier .from the root folder - Keep changes minimal - Only change what's necessary for your fix/feature
- PRs must solve a specific, identifiable problem
- Include tests for bug fixes
- Don't introduce unrelated changes
- Don't add features without prior approval via Issue
- PRs with no clear purpose or rationale
- Bulk formatting/style changes
- "Improvements" nobody asked for
- Features without an approved Issue
- Duplicate tests or tests that don't add coverage
- AI-generated spam PRs with generic changes
See CLAUDE.md for coding conventions. Key points:
- No exceptions - use
Result<T,E> - No classes - use records with static methods
- No interfaces - use
Func<T>/Action<T> - All tests must be integration tests (no mocks)
- Files under 450 LOC, functions under 20 LOC
- Bug fix: Fork, fix, test, PR
- Feature: Discussion -> Issue -> Fork -> Implement -> PR
Questions? Open a Discussion.