Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
63 lines (43 loc) · 4.11 KB

CONTRIBUTING.md

File metadata and controls

63 lines (43 loc) · 4.11 KB

Contributing to multi-storage-client

If you are interested in contributing to multi-storage-client, your contributions will fall into three categories:

  1. You want to report a bug, feature request, or documentation issue
    • File an issue describing what you encountered or what you want to see changed.
    • Please run and paste the output of the print_env.sh script while reporting a bug to gather and report relevant environment details.
    • The multi-storage-client team will evaluate the issues and triage them, scheduling them for a release. If you believe the issue needs priority attention comment on the issue to notify the team.
  2. You want to propose a new Feature and implement it
    • Post about your intended feature, and we shall discuss the design and implementation.
    • Once we agree that the plan looks good, go ahead and implement it, using the code contributions guide below.
  3. You want to implement a feature or bug-fix for an outstanding issue
    • Follow the code contributions guide below.
    • If you need more context on a particular issue, please ask and we shall provide.

Code contributions

Your first issue

  1. Read the project's README.md to learn how to setup the development environment.
  2. Find an issue to work on. The best way is to look for the good first issue or help wanted labels
  3. Comment on the issue saying you are going to work on it.
  4. Code! Make sure to update unit tests!
  5. When done, create your pull request.
  6. Verify that CI passes all status checks, or fix if needed.
  7. Wait for other developers to review your code and update code as needed.
  8. Once reviewed and approved, a multi-storage-client developer will merge your pull request.

Remember, if you are unsure about anything, don't hesitate to comment on issues and ask for clarifications!

Managing PR labels

Each PR must be labeled according to whether it is a "breaking" or "non-breaking" change (using GitHub labels). This is used to highlight changes that users should know about when upgrading.

For multi-storage-client, a "breaking" change is one that modifies the public, non-experimental, API in a non-backward-compatible way. Backward-compatible API changes (such as adding a new keyword argument to a function) do not need to be labeled.

Additional labels must be applied to indicate whether the change is a feature, improvement, bugfix, or documentation change. See the shared multi-storage-client documentation for these labels: https://github.com/NVIDIA/kb/issues/42.

Seasoned developers

Once you have gotten your feet wet and are more comfortable with the code, you can look at the prioritized issues of our next release in our issue board.

Look at the unassigned issues, and find an issue you are comfortable with contributing to. Start with Step 3 from above, commenting on the issue to let others know you are working on it. If you have any questions related to the implementation of the issue, ask them in the issue instead of the PR.

Branches and Versions

The multi-storage-client repository follows trunk-based development around the main branch.

Branch naming

Branches used to create PRs should have a name of the form <type>-<name> which conforms to the following conventions:

  • Type:
    • fea - For if the branch is for a new feature(s)
    • enh - For if the branch is an enhancement of an existing feature(s)
    • bug - For if the branch is for fixing a bug(s) or regression(s)
  • Name:
    • A name to convey what is being worked on
    • Please use dashes or underscores between words as opposed to spaces.

Attribution

Portions adopted from https://github.com/pytorch/pytorch/blob/master/CONTRIBUTING.md