Skip to content

Latest commit

 

History

History
237 lines (164 loc) · 9.68 KB

CONTRIBUTING.md

File metadata and controls

237 lines (164 loc) · 9.68 KB
Raw

Contributing to KServe

So, you want to hack on KServe? Yay!

The following sections outline the process all changes to the KServe repositories go through. All changes, regardless of whether they are from newcomers to the community or from the core team follow the same process and are given the same level of review.

Working groups

Any feature contribution to KServe should be started by first engaging with the KServe working group.

Code of conduct

All members of the KServe community must abide by the Code of Conduct.

Design documents

Any substantial design deserves a design document. Design documents are written with Google Docs and should be shared with the community by adding the doc to our shared Drive and sending a note to the working group to let people know the doc is there.

When documenting a new design, we recommend a 2-step approach:

  1. Use the short-form RFC template to outline your ideas and get early feedback.

  2. Once you have received sufficient feedback and consensus, you may use the longer-form design doc template to specify and discuss your design in more detail.

To use either template, open the template and select "Use Template" in order to bootstrap your document.

Contributing a feature

In order to contribute a feature to KServe you'll need to go through the following steps:

  • Discuss your idea with the working group on Slack in a discussion thread.

  • Once there is general agreement that the feature is useful, create a GitHub issue to track the discussion. The issue should include information about the requirements and use cases that it is trying to address. Include a discussion of the proposed design and technical details of the implementation in the issue.

  • If the feature is substantial enough:

    • Working group leads will ask for a design document as outlined in the previous section. Create the design document and add a link to it in the GitHub issue. Don't forget to send a note to the working group to let everyone know your document is ready for review.

    • Depending on the breadth of the design and how contentious it is, the working group leads may decide the feature needs to be discussed in one or more working group meetings before being approved.

    • Once the major technical issues are resolved and agreed upon, post a note to the working group's mailing list with the design decision and the general execution plan.

  • Submit PRs to kserve/kserve with your code changes.

  • Submit PRs to kserve/website with documentation for your feature, including usage examples when possible. See here to learn how to write docs for kserve.io.

Note, that we prefer "bite-sized" PRs instead of "giant monster" PRs. It is preferable if you can introduce large features in smaller reviewable changes that build on top of one another.

If you would like to skip the process of submitting an issue and instead would prefer to just submit a pull request with your desired code changes then that's fine. But keep in mind that there is no guarantee of it being accepted and so it is usually best to get agreement on the idea/design before time is spent coding it. However, sometimes seeing the exact code change can help focus discussions, so the choice is up to you.

Setting up to contribute to KServe

Check out this README to learn about the KServe source base and setting up your development environment.

Pull requests

If you're working on an existing issue, simply respond to the issue and express interest in working on it. This helps other people know that the issue is active, and hopefully prevents duplicated efforts.

To submit a proposed change:

  • Fork the affected repository.

  • Create a new branch for your changes.

  • Develop the code/fix.

  • Add new test cases. In the case of a bug fix, the tests should fail without your code changes. For new features try to cover as many variants as reasonably possible.

  • For new features e2e tests should be added here

  • Modify the documentation as necessary.

  • Verify the entire CI process (building and testing) works.

While there may be exceptions, the general rule is that all PRs should be 100% complete - meaning they should include all test cases and documentation changes related to the change.

Make sure to sign off your commits before you submit your PR.

Take a look at the article on Writing Good Pull Requests for additional guidance. And check out the article on Reviewing Pull Requests to learn more about our PR review process.

Issues

GitHub issues can be used to report bugs or submit feature requests.

When reporting a bug please include the following key pieces of information:

  • The version of the project you were using (e.g. version number, or git commit)

  • Setup environment you are using.

  • The exact, minimal, steps needed to reproduce the issue. Submitting a 5 line script will get a much faster response from the team than one that's hundreds of lines long.

Promote your company on kserve.io

If your company supports KServe or uses it in production, you can list it on our adopters page. We have categories for providers (who offer hosted or managed KServe services to their customers), end users (who use and consume KServe) and integrations (commercial or open source products that work with KServe).

Please add your company logo, preferably in SVG format, to here.

Becoming a committer

A committer is a contributor who has gained the privilege to commit code to the project. It also means being committed to the project and the community as a whole. Contributors who aspire to become committers should already be doing most of the activities that are expected to be done by the project's committers.

Responsibilities of a committer:

  • Triage and respond to issues
  • Possess expertise in certain areas and familiarity with the majority of the code base
  • Review pull requests
  • Answer questions on Slack
  • Mentor new project contributors

Contributors who have demonstrated their proficiency to make substantial code contributions and shown their commitment to the projects success over a prolonged period of time are candidates to become committers.

How new committers are chosen:

The KServe Technical Charter outlines the process to become a KServe committer:

  • iii. A Contributor may become a Committer by a majority approval of the existing Committers. A Committer may be removed by a majority approval of the other existing Committers.

For this purpose, the technical steering committee (TSC) shall periodically review the activity of project contributors and propose qualifying contributors to be promoted to become committers.

To help find candidates for promotion, existing committers can use the list-contributors.py script to review recent contributor activity:

$ make list-pr-authors

Contributors to 'kserve/kserve' (PR authors) by number of PRs (>3) since 2023-03-02:

 39  supercoder      [5083, 5077, 5040, 5038, 5035, 5031, 5024, 5016, 5006, 5004, ... ]
 20  kservehacker    [5089, 5061, 5054, 5029, 5020, 5002, 5001, 4998, 4956, 4952, ... ]
  6  code4fun        [5069, 5048, 5027, 5026, 5008, 4867]


$ make list-pr-reviewers

Contributors to 'kserve/kserve' (PR commenters, reviewers) by number of PRs (>3) since 2023-03-02:

 13  reviewchamp     [5089, 5075, 5072, 5047, 5042, 5040, 5038, 5031, 4993, 4969, ... ]
  9  nitpickr        [5079, 5054, 5049, 5040, 4954, 4877, 4782, 4762, 4739]
  4  casualcodr      [5062, 5039, 5025, 4867]

This script should only be used to identify suitable candidates. The actual candidate selection should take more factors into consideration than number of commits or PRs reviewed.

Areas of expertise:

Another criterion to use when selecting new committers is the project area that requires help with reviewing PRs and mentoring new contributors. Contributors that have a lot of expertise in a particular area who have helped review PRs in that area make good candidates to be promoted as committers. The various projects under the KServe umbrella may have a different set of committers and focus areas.

Some of those areas of expertise include:

  • KServe:
    • Python SDK
    • Open inference protocol, data plane
    • Release & testing infra
    • Webapp
    • Website
  • ModelMesh:
    • Controller
    • Runtime adapter
    • Storage adapter
    • Rest proxy