This project aims to be governed in a transparent, accessible way for the benefit of the community. All participation in this project is open and not bound to corporate affiliation. Participants are all bound to the Code of Conduct.
The contributor role is the starting role for anyone participating in the project and wishing to contribute code.
- Review the coding standards to ensure your contribution is in line with the project's coding and styling guidelines.
- Have a signed CLA on file (see below).
- Submit your code as a PR with the appropriate DCO sign-off.
- Have your submission approved by the maintainer(s) and merged into the codebase.
ƒVDB is part of OpenVDB, a project of the Academy Software Foundation, and follows the open source software best practice policies of the Linux Foundation.
ƒVDB is licensed under the Apache License, version 2.0 license. Contributions to ƒVDB should abide by that standard license.
Developers who wish to contribute code to be considered for inclusion in ƒVDB must first complete a Contributor License Agreement.
ƒVDB uses EasyCLA for managing CLAs, which automatically checks to ensure CLAs are signed by a contributor before a commit can be merged.
-
If you are an individual writing the code on your own time and you're SURE you are the sole owner of any intellectual property you contribute, you can sign the CLA as an individual contributor.
-
If you are writing the code as part of your job, or if there is any possibility that your employers might think they own any intellectual property you create, then you should use the Corporate Contributor Licence Agreement.
The ƒVDB CLAs are the standard forms used by Linux Foundation projects and recommended by the ASWF TAC. You can review the text of the CLAs in the TSC directory.
Every commit must be signed off. That is, every commit log message
must include a “Signed-off-by” line (generated, for example, with
“git commit --signoff”), indicating that the committer wrote the
code and has the right to release it under the
Apache License, version 2.0
license. See the TAC documentation on contribution sign off for more information on this requirement.
In addition to the DCO sign-off above, commits must be cryptographically signed
(git commit --gpg-sign / -S; SSH signing keys are supported). Do not bypass
signing or verification hooks (avoid --no-gpg-sign and --no-verify).
The maintainer role is the equivalent of the "Committer" role in the charter.
This role enables the participant to commit code directly to the repository, but also comes with the obligation to be a responsible leader in the community.
- Show your experience with the codebase through contributions and engagement on the community channels.
- Request to become a maintainer.
- Have the majority of maintainers approve you becoming a maintainer.
- Your name and email are added to the MAINTAINERS.md file for the project.
- Monitor email aliases.
- Monitor Slack (delayed response is perfectly acceptable).
- Triage GitHub issues and perform pull request reviews for other committers and the community.
- Make sure that ongoing PRs are moving forward at the right pace or close them.
- Remain an active contributor to the project in general and the code base in particular.
See docs/release-process.md for the branching model, timeline, and automation scripts used for releases.
This project, just like all of open source, is a global community. In addition to the Code of Conduct, this project will:
- Keep all communication on open channels ( mailing list, forums, chat ).
- Be respectful of time and language differences between community members ( such as scheduling meetings, email/issue responsiveness, etc ).
- Ensure tools are able to be used by community members regardless of their region.
If you have concerns about communication challenges for this project, please contact the TSC.