Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
156 lines (111 loc) · 4.39 KB

CONTRIBUTING.md

File metadata and controls

156 lines (111 loc) · 4.39 KB
Raw

Contributing to Thunderbolt

Thank you for your interest in contributing to Thunderbolt! This guide will help you get started.

📋 Table of Contents

Code of Conduct

This project follows the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code.

Getting Started

  1. Fork the repository
  2. Clone your fork: git clone https://github.com/YOUR-USERNAME/Thunderbolt.git
  3. Create a branch: git checkout -b feature/your-feature-name
  4. Make changes and commit
  5. Push and open a Pull Request

Development Setup

Prerequisites

  • .NET 10 SDK
  • Docker & Docker Compose
  • A C# IDE (JetBrains Rider, Visual Studio, or VS Code)

Setup

# Clone the repository
git clone https://github.com/sbdevman/Thunderbolt.git
cd Thunderbolt

# Start infrastructure
docker compose up postgres influxdb kafka -d

# Restore and build
dotnet restore Thunderbolt.slnx
dotnet build Thunderbolt.slnx

# Run tests
dotnet test Thunderbolt.slnx

Running Locally

# Terminal 1 — Coordinator
dotnet run --project src/Thunderbolt.Coordinator

# Terminal 2 — Worker
dotnet run --project src/Thunderbolt.Worker

# Terminal 3 — API
dotnet run --project src/Thunderbolt.Api

# Terminal 4 — Dashboard
dotnet run --project src/Thunderbolt.Dashboard

How to Contribute

🐛 Bug Fixes

✨ Features

  • Discuss the feature in an issue before starting
  • Keep PRs focused — one feature per PR

📝 Documentation

  • Fix typos, improve explanations, add examples
  • Documentation PRs are always welcome

🔌 Protocol Plugins

  • New protocol handlers are a great way to contribute
  • See plugins/Thunderbolt.Protocols.Example for the template
  • Follow the IProtocolHandler interface

Coding Standards

C# Style

  • Use latest C# features (file-scoped namespaces, records, pattern matching)
  • Follow .editorconfig rules in the repository
  • Add XML doc comments to all public APIs
  • Use meaningful names — no abbreviations except well-known ones (VU, RPS, etc.)

Architecture

  • Domain events go in Thunderbolt.Core/Events/
  • Actor messages go in Thunderbolt.Core/Messages/
  • New protocols get their own project under src/Thunderbolt.Protocols/
  • Tests mirror the src/ structure under tests/

Commit Messages

Use clear, descriptive commit messages:

feat: add WebSocket protocol handler
fix: resolve race condition in VirtualUserActor shutdown
docs: update API reference with new metrics endpoints
test: add integration tests for Kafka producer
refactor: extract load profile parsing into dedicated class

Testing

  • Write unit tests for all new logic
  • Use FluentAssertions for assertions
  • Use NSubstitute for mocking
  • Use Testcontainers for integration tests
  • Aim for tests that are fast, isolated, and deterministic

Pull Request Process

  1. Ensure all tests pass: dotnet test Thunderbolt.slnx
  2. Update documentation if you changed APIs or behavior
  3. Fill in the PR template completely
  4. Request a review from a maintainer
  5. Address review feedback promptly
  6. PRs require 1 approval before merging
  7. Squash commits on merge for a clean history

Issue Guidelines

Good Bug Reports Include:

  • Steps to reproduce
  • Expected vs actual behavior
  • Environment details (.NET version, OS, deployment method)
  • Relevant logs or error messages

Good Feature Requests Include:

  • The problem being solved
  • Proposed solution
  • Alternative approaches considered
  • Who benefits from this feature

📜 License

By contributing, you agree that your contributions will be licensed under the MIT License.

Thank you for helping make Thunderbolt better! ⚡