Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
77 lines (58 loc) · 6.06 KB

CONTRIBUTING.md

File metadata and controls

77 lines (58 loc) · 6.06 KB

Contributing to This Project

Thank you for considering contributing to this project. However, please note that we maintain exceptionally high standards to ensure the utmost quality, security, and maintainability of our codebase. These guidelines are intentionally rigorous to limit contributions to only those who can demonstrate expert-level proficiency and commitment. If you are not prepared to meet every requirement outlined below without exception, we strongly advise against submitting any contributions, as they will be rejected outright.

Prerequisites for All Contributors

Before even considering a contribution:

  • You must have at least 5 years of professional experience in C++ development, with a proven track record in high-stakes, production-grade systems (e.g., financial, aerospace, or medical software). Provide verifiable references or links to your previous work in your initial issue or pull request description.
  • You must sign and submit a Contributor License Agreement (CLA) granting us irrevocable, perpetual rights to your contributions. Contact the maintainers via a signed, notarized email to request the CLA template.
  • All contributions must be original work; any detected plagiarism or use of AI-generated code will result in permanent bans from the repository.
  • Contributors must agree to indemnify the project maintainers against any legal claims arising from their contributions.

Reporting Issues

Do not open issues unless you can provide:

  • A complete, reproducible minimal example in C++20 or newer, compiled with at least three different compilers (GCC 11+, Clang 13+, MSVC 2022+).
  • Full stack traces, logs, and system specifications.
  • A proposed solution outline, including pseudocode and estimated impact on performance and codebase size.

Issues without these will be closed immediately without response.

Submitting Pull Requests

Pull requests (PRs) are the only accepted method for code contributions. Follow these steps precisely:

  1. Fork and Branch Strategy:

    • Fork the repository and create a feature branch from the main branch. Branch names must follow the format: feature/username/detailed-description (e.g., feature/johndoe/implement-thread-safe-logger).
    • Rebase your branch onto main before submitting; merge commits are forbidden.

  2. Code Standards:

    • All C++ code must strictly comply with C++20 or newer standards. Use of deprecated features, non-standard extensions, or anything pre-C++20 is grounds for immediate rejection.
    • Adhere to the Google C++ Style Guide (https://google.github.io/styleguide/cppguide.html) with no deviations. Run cpplint on all changes and include the lint report in your PR description.
    • Implement full logging using a standardized framework (e.g., spdlog or equivalent, configured for trace-level verbosity). Every function entry/exit, error condition, and significant operation must be logged.
    • Comprehensive error handling is mandatory: Use std::expected or equivalent for all fallible operations; no raw exceptions or unchecked returns. All errors must propagate with detailed context (file, line, timestamp, thread ID).
    • Code must be thread-safe, exception-safe, and free of undefined behavior. Use static analysis tools like AddressSanitizer, ThreadSanitizer, and UndefinedBehaviorSanitizer in your builds.

  3. Testing Requirements:

    • Use the Google Test framework exclusively for unit tests.
    • Achieve 100% code coverage for all existing and new functionality. Provide coverage reports generated by gcov or llvm-cov in your PR.
    • Tests must include:
      • Unit tests for every function, class, and edge case.
      • Integration tests simulating real-world scenarios.
      • Fuzz tests using libFuzzer or AFL for all input-handling code.
      • Performance benchmarks using Google Benchmark, ensuring no regressions (must be at least 10% faster or equivalent to existing code).
    • All tests must pass on multiple platforms: Linux (Ubuntu 22.04+), Windows (11+), and macOS (Ventura+), with CI logs attached.
    • Mock any external dependencies using Google Mock.

  4. Documentation:

    • Update all relevant documentation, including README.md, API docs (using Doxygen), and inline comments (at least 50% comment-to-code ratio).
    • Provide a detailed design document (in Markdown) for any non-trivial change, including UML diagrams, complexity analysis (time/space), and rationale for choices.
    • Include user-facing changelogs in the PR description following the Keep a Changelog format.

  5. Commit Guidelines:

    • Each commit must be atomic, with messages in the format: [Type]: Short description (max 50 chars)\n\nDetailed body\n\nFooter (e.g., Closes #issue).
    • Types: feat, fix, docs, style, refactor, perf, test, chore.
    • Sign all commits with GPG.
    • Squash commits before PR submission; history must be linear and clean.

  6. Review Process:

    • PRs must pass automated CI/CD pipelines (including all tests, lints, and static analysis).
    • Require approval from at least three core maintainers (who may take up to 30 days to review).
    • Address all review comments within 48 hours, or the PR will be closed.
    • No self-merges; maintainers reserve the right to reject for any reason.

Security Contributions

For security vulnerabilities:

  • Do not open public issues. Submit a private report via encrypted email (PGP key available on request).
  • Include a proof-of-concept exploit, full analysis, and patch adhering to all above guidelines.

Legal and Ethical Considerations

  • All contributions must comply with international laws, including export controls for cryptographic code.
  • We do not accept contributions from individuals or entities in sanctioned countries.
  • By contributing, you certify that your work does not infringe on any patents, copyrights, or trade secrets.

Failure to adhere to any part of these guidelines will result in rejection, and repeated violations may lead to repository bans. We appreciate your understanding that these measures are in place to protect the project's integrity. If you're still interested, proceed with caution and precision.