Issue: New .NET Foundation Project Application

[sbdevman]

Project Name

Thunderbolt

License

MIT

Contributor

Saeid Babaei

Existing OSS Project?

No

Source Code URL

https://github.com/sbdevman/Thunderbolt

Project Homepage URL

https://sbdevman.github.io/Thunderbolt

Project Transfer Signatories

• Saeid Babaei saeid.babaei@outlook.com

Description

Thunderbolt is a cloud-native, distributed load testing platform built with .NET 10, Akka.NET, and event sourcing. It orchestrates thousands of virtual users across a cluster of worker nodes to simulate realistic traffic patterns against HTTP, gRPC, WebSocket, MQTT, AMQP, and raw TCP/UDP endpoints.

What are you hoping from the foundation

Supporting the project and gain contributors

Name

Saeid Babaei

Email

saeid.babaei@outlook.com

GitHub Profile URL

https://github.com/sbdevman

Committers

Saeid Babaei

Discord Ids

No response

Governance Model

Fork & Branch — Contributors fork the repository, clone it locally, and create a feature branch (e.g., feature/your-feature-name).
Issue First (for features) — New features must be discussed in a GitHub issue before work begins. Bug fixes should also reference an existing or new issue.
Make Changes — Contributors implement the change following the project's coding standards (latest C#, .editorconfig rules, XML doc comments, conventional commit messages like feat:, fix:, docs:, etc.).
Open a Pull Request — The contributor pushes the branch and opens a PR, filling in the PR template completely.
How Changes Are Reviewed
All tests must pass — dotnet test Thunderbolt.slnx must succeed before review.
Documentation must be updated if APIs or behavior changed.
A maintainer reviews the PR — The contributor requests a review from a project maintainer.
Feedback is addressed — The contributor is expected to address review feedback promptly.
How a Decision Is Made to Accept Changes
PRs require 1 maintainer approval before merging.
Once approved, commits are squash-merged to maintain clean history.
Contributions are licensed under the MIT License upon acceptance.
Process for Identifying and Appointing New Committers
The project documentation does not explicitly define a formal process for identifying or appointing new committers. Based on what's documented:
The project currently operates under a single maintainer model (the project maintainer is contactable at saeid.babaei@outlook.com, per the Code of Conduct).
There is no written governance document, MAINTAINERS file, or committer ladder describing how contributors are elevated to committer/maintainer roles.
The existing process implies a trust-based, informal model typical of early-stage open-source projects — consistent high-quality contributions and active review participation would likely be the path to gaining commit access, at the maintainer's discretion.
If the project grows, it would benefit from adding a GOVERNANCE.md documenting the criteria and process for granting committer status.

CLA

• If already an OSS project, was a Contribution License Agreement in place for contributions accepted?

How does the project check who has signed one?

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

CLA Notification Alias

No response

Select the Project Transfer Agreement model

Assignment

Repository Layout

No response

Eligibility Criteria

• The project is built on the .NET platform and/or creates value within the .NET ecosystem.
• The project produces source code for distribution to the public at no charge.
• The project's code is easily discoverable and publicly accessible (preferably on GitHub).
• The project contains a build script that can produce deployable artifacts that are identical to the official deployable artifacts, with the exception of code signing (Exception may be granted for strong name keys, though strongly encouraged to be committed. Exception relies on OSS signing being in the build script for public builds).
• When applicable, project must use reproducible build settings in its toolchain.
• The project uses Source Link.
• The project uses either embedded PDBs or publish symbol packages to NuGet (if applicable).
• The project code signs their artifacts as appropriate.
• The project organization has 2FA enabled. Requiring 2FA must be done as part of onboarding if not already enabled.
• Libraries that are mandatory dependencies of the project are offered under a standard, permissive open source license which has been approved by the .NET Foundation (exceptions include a dependency that is required by the target platform where no alternative open source dependency is available such as the .NET Framework or a hardware specific library).
• Committers are bound by a Contributor License Agreement (CLA) and/or are willing to embrace the .NET Foundation's CLA when the project becomes a Member.
• The copyright ownership of everything that the project produces is clearly defined and documented.
• The project has a public issue tracker where the status of any defect can be easily obtained.
• The project has a published Security Policy.
• The project has a home page which provides high level information about its status and purpose.
• The project has a public communication channel where community members can engage with maintainers.
• The project has a publicly available location where members can review and contribute to documentation.

Describe why you are applying for Project Membership.

I would like to use my code widely and get feedbacks from people

Infrastructure Requirements Summary

No response

Additional Notes

No response