Contributing to HEIR
There are several ways to contribute to HEIR, including:
- Discussing high-level designs and questions on HEIR’s discussions page
- Improving or expanding HEIR’s documentation
- Contributing to HEIR’s code-base
- Discuss project direction at HEIR’s Working Group meetings
Ways to contribute
We welcome pull requests, and have tagged issues for newcomers:
- Good first issue
- Contributions welcome
- Research synthesis: determine what parts of recent FHE research papers can or should be ported to HEIR.
Contributing to code using pull requests
Preparing a pull request
The following steps should look familiar to typical workflows for pull request contributions. Feel free to consult GitHub Help if you need more information using pull requests. HEIR-specific processes begin at the pull request review stage.
Fork the HEIR repository by clicking the Fork button on the repository page. This creates a copy of the HEIR repository on your own GitHub account.
See Getting Started to install developer dependencies to build and run tests.
Add the HEIR repository as an upstream remote, so you can sync your changes against it.
git remote add upstream https://www.github.com/google/heir
Create a development branch for your change:
git checkout -b name-of-change
And implement your changes using your favorite IDE. See IDE Configuration for more.
Check HEIR’s lint and style checks by running the following from the top of the repository:
pre-commit run --all
Make sure tests are passing with the following:
bazel test @heir//...
Once you are ready with your change, create a commit as follows.
git add change.cpp git commit -m "Detailed commit message" git push --set-upstream origin name-of-change
Pull request review flow
- New PR:
- When a new PR is submitted, it is inspected for quality requirements, such as the CLA requirement, and a sufficient PR description.
- If the PR passes checks, we assign a reviewer. If not, we request additional changes to ensure the PR passes CI checks.
- A reviewer will check the PR and potentially request additional changes.
- If a change is needed, the contributor is requested to make a suggested change. Please make changes with additional commits to your PR, to ensure that the reviewer can easily see the diff.
- If all looks good, the reviewer will approve the PR.
- This cycle repeats itself until the PR is approved.
- At this stage, you must squash your commits into a single commit.
- Once the PR is approved, a GitHub workflow will
your PR for multiple commits. You may use the
git rebase -ito squash the commits. Pull requests must comprise of a single git commit before merging.
- Pull Ready
- Once the PR is squashed into a single git commit, a maintainer will apply the
- This initiates the internal code migration and presubmits.
- If needed, we may come to you to make some minor changes in case tests fail at this stage. If so, we will request changes from the GitHub UI and the PR must be approved again.
- At times, it may not be your change, but it may be additional internal lints
and layering checks that are not integrated with
bazelor open-source tooling. We will go ahead and fix this.
- Once the internal tests pass, we merge the code internally and externally. You
copybara-botclose the PR and merge your commit directly into main.