Flux is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted.
We gratefully welcome improvements to issues and documentation as well as to code.
If you like Flux and want to get involved in the project, a great way to get started is reviewing our blocked-needs-validation issues.
The idea here is that new issues are confirmed, which might require asking
for more information, testing with a fresh Flux environment. Once confirmed,
blocked-needs-validation label is removed, and the issue can be worked
Please talk to us on Slack, if you should get stuck anywhere. We appreciate any help and look forward to talking to you soon!
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. No action from you is required, but it’s a good idea to see the DCO file for details before you start contributing code to Flux.
The Flux developers use a mailing list to discuss development as well. Simply subscribe to flux-dev on cncf.io to join the conversation.
Agenda and minutes of previous Flux Dev meetings can be reviewed in this Google doc.
Meeting recordings can be viewed in this Youtube playlist.
This is a rough outline of how to prepare a contribution:
Refer to the building doc to find out how to build from source.
Refer to the Get Started Developing guide for a walkthrough on developing Flux locally.
You can run the unit tests by simply doing
These things will make a PR more likely to be accepted:
In general, we will merge a PR once one maintainer has endorsed it. For substantial changes, more people may become involved, and you might get asked to resubmit the PR or divide the changes into more than one PR.
For Flux we prefer the following rules for good commit messages:
The following article has some more helpful advice on documenting your work.