Table of Contents

Contributing Guide

Thank you for your interest in contributing to Blueprintr!

๐Ÿš€ Quick Start

  1. Fork the repository
  2. Clone your fork: git clone https://github.com/rafitajaen/blueprintr.git
  3. Create a branch: git checkout -b feat/my-feature
  4. Make your changes
  5. Add tests
  6. Commit: git commit -m "feat: my new feature"
  7. Push: git push origin feat/my-feature
  8. Open a Pull Request

๐Ÿ“ Commit Message Convention

This project follows Conventional Commits.

Format

<type>(<scope>): <description>

[optional body]

[optional footer]

Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • test: Adding or updating tests
  • refactor: Code refactoring
  • perf: Performance improvements
  • ci: CI/CD changes
  • chore: Maintenance tasks

Examples

feat: add validation middleware
fix: resolve null reference in endpoint handler
docs: update API examples
test: add tests for error scenarios
refactor: simplify endpoint registration

Breaking Changes

feat!: change endpoint registration API

BREAKING CHANGE: EndpointRegistration method signature changed

๐Ÿงช Testing

Required

  • All new features must include tests
  • All tests must pass before submitting PR
  • Aim for high code coverage

Run Tests

# All tests
dotnet test

# With coverage
dotnet test --collect:"XPlat Code Coverage"

# Specific project
dotnet test tests/Blueprintr.Tests/

๐Ÿ“‹ Pull Request Process

  1. Ensure tests pass

    dotnet test
    
  2. Update documentation if needed

    • XML comments for public APIs
    • README.md for significant changes
    • docs/ for new features
  3. Follow code style

    • EditorConfig is configured
    • Format on save in VS Code
    • Follow existing patterns
  4. Create descriptive PR

    • Use the PR template
    • Explain what and why
    • Link related issues
  5. Wait for CI

    • All checks must pass
    • Address review feedback
    • Squash commits if requested

โœ… Code Standards

  • Use C# and .NET conventions
  • Enable nullable reference types
  • Document public APIs with XML comments
  • Keep methods small and focused
  • Follow SOLID principles
  • No warnings (warnings = errors)

๐Ÿ“– Resources

๐Ÿ†˜ Getting Help

  • Questions: Open a GitHub Discussion
  • Bugs: Open a GitHub Issue
  • Documentation: See CLAUDE.md

๐ŸŽ‰ Thank You!

Every contribution, no matter how small, is appreciated!


For complete development guide, see CLAUDE.md