deb/beegfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
beegfs/CONTRIBUTING.md
geos_one c891bb7105 New upstream version 8.1.0
2025-08-10 01:34:16 +02:00

3.5 KiB
Raw Permalink Blame History

Contributing

Thank you for your interest in contributing to beegfs! 🎉

We appreciate that you want to take the time to contribute. Please follow these steps before submitting your PR.

Contents

ThinkParQ Contributor License Agreement (CLA)

Before contributions can be accepted we must have a signed CLA on file for all contributor(s):

Creating a Pull Request

  1. Please search existing issues to determine if an issue already exists for what you intend to contribute.
  2. If the issue does not exist, create a new one that explains the bug or feature request.
    • Let us know in the issue that you plan on creating a pull request for it. This helps us to keep track of the pull request and avoid any duplicate efforts.
  3. Before creating a pull request, write up a brief proposal in the issue describing what your change would be and how it would work so that others can comment.
    • It's better to wait for feedback from the maintainers before writing code. We don't have an SLA for our feedback, but we will do our best to respond in a timely manner (at a minimum, to give you an idea if you're on the right track and that you should proceed, or not).
  4. When ready refer to the guidelines and process for submitting a Pull Request.

Our Commitment

While we truly appreciate your efforts on pull requests and will accept contributions as often as we can, we cannot commit to accepting all PRs. Here are a few reasons why a PR may be rejected:

  • There are many factors involved in integrating new code into this project including:

    • Adding appropriate unit and end-to-end test coverage for new/changed functionality.
    • Ensuring adherence with ThinkParQ and industry standards around security and licensing.
    • Validating new functionality doesn't raise long-term maintainability and/or supportability concerns.
    • Verifying changes fit with the current and/or planned architecture.
    • etc.

    In other words, while your bug fix or feature may be perfect as a standalone patch, we have to ensure the changes also work in all use cases, supported, configurations, and across our support matrix.

  • The BeeGFS development team must plan resources to integrate your code into our code base and CI platform, and depending on the complexity of your PR, we may or may not have the resources available to make it happen in a timely fashion. We'll do our best, but typically the earliest changes can be merged into the master branch is with our next formal release, unless they resolve a critical bug or security vulnerability.

  • Sometimes a PR doesn't fit into our future plans or conflicts with other items on the roadmap. It's possible that a PR you submit doesn't align with our upcoming plans, thus we won't be able to use it. It's not personal and why we highly recommend submitting an issue with your proposed changes so we can provide feedback before you expend significant effort on development.

Thank you for considering to contribute to beegfs!