Skip to content

Latest commit

 

History

History
82 lines (60 loc) · 3.92 KB

CONTRIBUTING.md

File metadata and controls

82 lines (60 loc) · 3.92 KB
Raw

How to Contribute

We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.

Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.

Code reviews

All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

StableHLO Opset Changes

All changes to the StableHLO opset including new ops, types, or attributes must be reviewed via an RFC. We aim for StableHLO opset changes to take ~2 weeks if feedback is actively addressed. This allows adequate time for the community to review all proposals.

1. Write an RFC

An RFC should outline the proposed spec changes, as well as the rationale, and alternatives considered if relevant. This can be shared as a markdown file in the rfcs/ directory and shared as a PR.

For example, see the collective_broadcast RFC.

2. Notify OpenXLA Discuss

To signal boost your RFC, post on OpenXLA Discuss. This will ensure the proper reviewers see the RFC. While there is no formal process for posts, we tend to recommend keeping RFC discussion on the PR to keep feedback centralized in the repository.

For example, see the collective_broadcast post.

3. Work with project maintainer for final approval

As denoted in governance.md, while we work towards instating StableHLO module maintainers, the interim review process requires approval from Google project maintainers. A member of the StableHLO team will help drive final approval.

4. Send PRs for the opset change

Once an RFC is approved, PRs which implement the approved proposal may be sent, reviewed, and merged.

A few things to consider when adding new features:

  • Spec, Type Inference, Verifiers: Steps for adding to spec.md as well as related op implementation can be found in spec_checklist.md.
  • Verifiers: Steps for modifying or implementing op verifiers can also be found in the spec checklist.
  • Type Inference: Type inference design principles and testing details can be found in type_inference.md.
  • Compatibility: Tips on managing forward/backward compatibility are in vhlo_checklist.md.
  • Reference: Steps for adding interpreter support can be found in reference_checklist.md.
  • Tests: For each of the above modifications, consider positive and negative test cases.

Some examples to help guide changes: