Skip to content

Latest commit

 

History

History
49 lines (36 loc) · 3.32 KB

contributing.rst

File metadata and controls

49 lines (36 loc) · 3.32 KB

Contributing

The Flux Framework team welcomes all contributors for bug fixes, code improvements, new features, simplifications, documentation, and more. Please do not hesitate to contact us with any questions or concerns.

This guide details how to contribute to Flux Framework projects in a standardized and efficient manner. Our projects follow the Collective Code Construction Contract (C4.1) which describes an optimal collaboration model for open source projects, based on the GitHub fork+pull model.

Pull Requests

Use a pull request (PR) toward a repository's master branch to propose your contribution, including the specific issue number your PR resolves. If you are planning significant code changes, or have any questions, please open an issue and reference it in your PR. To contribute to a Flux Framework project:

  • Fork the project.
  • Clone your fork. git clone [email protected]:[username]/flux-framework/[project].git
  • Create a topic branch to contain your change. git checkout -b new_feature
  • Create feature or add fix, and add tests if possible.
  • Make sure everything still passes make check.
  • Rebase your commits into meaningfully labeled, easily digestible chunks, ideally without errors.
  • Push the branch to your GitHub repo. git push origin new_feature
  • Create a PR against flux-framework/[project] and describe what your change does and why you think it should be merged. List any outstanding "to do" items.
  • Each PR will be subjected to automated tests under travis-ci.org.

Please note that PRs should be rebased onto the master of the target repository, not merged from the master into your branch. PRs that are a work in progress should have WIP: prefix or work-in-progress label to avoid automerging by mergify.io.

Developer Guidelines

  • Keep the code lean and as simple as possible.
  • Keep the code general and reasonably efficient.
  • Review other issues and PRs to ensure you are not duplicating effort.
  • Update the appropriate documentation or open an issue to do so.
  • Adhere to the coding style guide. The components of Flux written in C follow the Kernighan & Ritchie coding style, with exceptions enumerated in RFC 7. The components of Flux written in Python follow the black code style.
  • Commit etiquette:
    • Avoid merge commits.
    • Separate work so that each commit fixes one problem.
    • Use subsystem: prefix in commit titles.
    • Each commit should have a message with title and body as described in C4.1 (e.g., imperative phrasing).

For more details about C4.1, including commit requirements, see RFC 1.