Getting Involved / Contributing

[kevin85421]

Join KubeRay community

• Join Ray's Slack workspace, and search the following public channels:
  • #kuberay-questions (KubeRay users): This channel aims to help KubeRay users with their questions. The messages will be closely monitored by the Ray/KubeRay maintainers.
  • #kuberay-discuss (KubeRay contributors): This channel is for contributors to discuss what to do next with KubeRay (e.g. issue, pull request, feature request, design doc, KubeRay ecosystem integration). All KubeRay maintainers & core contributors are in the channel.

Have KubeRay questions?

• Ask the question in the #kuberay-questions slack channel.
• Ask the question in the #ask-raybot (A ChatGPT-like chatbot) slack channel.
• Open an issue in this GitHub repository. Issues with detailed reproduction instructions will be given priority in resolution. The following points are good for reproduction scripts:
  • Make sure the script is the minimal reproduction script.
  • It will be great if the issue can be reproduced on a local Kind cluster.

Want to contribute code to KubeRay?

1. Document fix

Open a PR to fix it (example: #1046).

2. Simple bug fix

The definition of a "simple bug" is a bug that has only one solution and is easy to understand (example: #1039). Open a GitHub issue to describe the issue, and open a PR to fix it.

3. Complex bug fix

The definition of a "complex bug" is a bug that has multiple solutions and each has different tradeoffs.

• Case 1: If there is a solution that is significantly better than all the other solutions, you can open an issue to describe the bug and draft a pull request that includes a comparison of the solutions in the PR description (example: #1043).

• Case 2: If there is no clear standout solution among the available options, open an issue to describe the bug and discuss the possible solutions with the maintainers before drafting a PR.

  • Take #874 as an example, the community decided to close this PR and in favor of another solution, #1040. By staying in touch with the community, you can often prevent such situations from occurring in the first place.

4. New features for existing components

Open an issue to describe the feature and its use cases. It would be great to work on it after discussing it with maintainers.

5. New component

Open a REP (Ray Enhancement Proposal) PR to the ray-project/enhancements repository to propose your idea.

6. KubeRay ecosystem integration

• Case 1: If no code change is needed for the KubeRay repository, you can choose either:

  • Add a document in the Kubernetes component repository, and open a PR to add the document link to the KubeRay ecosystem section (link1, link2).
  • Add a document in the KubeRay repository (example: Prometheus & Grafana).

• Case 2: If a code change is needed for the KubeRay repository, please open an issue and discuss it with maintainers before drafting a PR. This will make the process much faster.

• Tip for implementation: In general, KubeRay does not allow 3rd-party component-specific code leaks. However, there may be exceptions in cases where industry standards require it. For instance, KubeRay includes some Prometheus-specific code.

• Tip for documentation: Users with basic Kubernetes experience and without any context with KubeRay and the 3rd-party component should be able to follow the document and reproduce the result on their local Kind clusters.

How to get the PRs to be reviewed?

• Pick a good GitHub issue: Make sure whether this issue is needed for the community or not.

• Is it a good time?: KubeRay will have a 1-week feature freeze for each release. During that time, all pull requests for new features will not be reviewed. In addition, if the KubeRay/Ray communities plan to refactor some components recently, the related pull requests may not be reviewed in a timely manner. Join the Slack channel and keep in touch with the community!

Testing Kubernetes operators can be challenging, and even though KubeRay has unit tests, Kubernetes control plane simulation tests, configuration tests, and end-to-end tests, it can still be difficult to ensure full coverage. In many cases, maintainers may need to manually clone a contributor's fork and test the pull request during the review process, which can be time-consuming. The following tips can help make your pull request easier to review.

• PR description: A detailed pull request description can help maintainers understand why this change is needed, why you made certain decisions, and which aspects you took into consideration (example: #938).

• Test: Please add tests for the PR, and make sure the tests will not introduce flakiness. If you also manually test the PR, please provide detailed instructions for maintainers to test on their environments.

• Implementation: Developing an open-source project is very different from developing an in-house product. KubeRay needs to fulfill all use cases for tens of companies and their Kubernetes distributions. Hence, the philosophy for KubeRay is:

  • Empower users to configure the feature and provide them with good default values.
  • Enforce a configuration only when considering backward compatibility, different use cases, and different Kubernetes distributions.

[tedhtchang]

Tagging issues with a good first issue label may help the new contributors to get started. For example, documentations are usually good first issues.

[anyscalesam]

@kevin85421 can we port this into a readme on the main kuberay page and than close this issue?