|
1 |
| -# How to Contribute |
| 1 | +# How to contribute |
2 | 2 |
|
3 |
| -We'd love to accept your patches and contributions to this project. There are |
4 |
| -just a few small guidelines you need to follow. |
| 3 | +We'd love to accept your patches and contributions to this project. We do have |
| 4 | +some guidelines to follow, covered in this document, but don't be concerned |
| 5 | +about getting everything right the first time! Create a pull request (discussed |
| 6 | +below) and we'll nudge you in the right direction. |
5 | 7 |
|
6 |
| -## Contributor License Agreement |
| 8 | +## Before you begin |
7 | 9 |
|
8 |
| -Contributions to this project must be accompanied by a Contributor License |
9 |
| -Agreement (CLA). You (or your employer) retain the copyright to your |
10 |
| -contribution; this simply gives us permission to use and redistribute your |
11 |
| -contributions as part of the project. Head over to |
12 |
| -<https://cla.developers.google.com/> to see your current agreements on file or |
13 |
| -to sign a new one. |
| 10 | +### Sign our Contributor License Agreement |
14 | 11 |
|
15 |
| -You generally only need to submit a CLA once, so if you've already submitted one |
16 |
| -(even if it was for a different project), you probably don't need to do it |
17 |
| -again. |
| 12 | +Contributions to this project must be accompanied by a [Contributor License |
| 13 | +Agreement](https://cla.developers.google.com/about) (CLA). You (or your |
| 14 | +employer) retain the copyright to your contribution; the CLA simply gives us |
| 15 | +permission to use and redistribute your contributions as part of the project. |
| 16 | +Please visit https://cla.developers.google.com/ to see your current agreements |
| 17 | +on file or to sign a new one. You generally only need to submit a Google CLA |
| 18 | +once, so if you've already submitted one (even if it was for a different |
| 19 | +project), you probably don't need to do it again. |
18 | 20 |
|
19 |
| -## Code reviews |
| 21 | +> [!WARNING] |
| 22 | +> Please note carefully clauses [#5](https://cla.developers.google.com/about/google-corporate#:~:text=You%20represent%20that%20each%20of%20Your%20Contributions%20is%20Your%20original%20creation) |
| 23 | +> and [#7](https://cla.developers.google.com/about/google-corporate#:~:text=Should%20You%20wish%20to%20submit%20work%20that%20is%20not%20Your%20original%20creation%2C%20You%20may%20submit%20it%20to%20Google%20separately) |
| 24 | +> in the CLA. Any code that you contribute to this project must be **your** |
| 25 | +> original creation. Code generated by artificial intelligence tools **does |
| 26 | +> not** qualify as your original creation. |
| 27 | +
|
| 28 | +### Review our community guidelines |
| 29 | + |
| 30 | +We have a [code of conduct](CODE_OF_CONDUCT.md) to make the project an open and |
| 31 | +welcoming community environment. Please make sure to read and abide by the code |
| 32 | +of conduct. |
| 33 | + |
| 34 | +## Contribution process |
20 | 35 |
|
21 | 36 | All submissions, including submissions by project members, require review. We
|
22 |
| -use GitHub pull requests for this purpose. Consult |
23 |
| -[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more |
24 |
| -information on using pull requests. |
| 37 | +use the tools provided by GitHub for pull requests for this purpose. The |
| 38 | +preferred manner for submitting pull requests is to fork the, create a new |
| 39 | +branch in this fork to do your work, and when ready, create a pull request from |
| 40 | +this branch to the main project repository. The subsections below describe the |
| 41 | +process in more detail. |
| 42 | + |
| 43 | +Pleae make sure to follow the [Google Style |
| 44 | +Guides](https://google.github.io/styleguide/) in your code, particularly the |
| 45 | +[style guide for Python](https://google.github.io/styleguide/pyguide.html). |
| 46 | + |
| 47 | +### Repository forks |
| 48 | + |
| 49 | +1. Fork the OpenFermion-FQE repository (you can use the _Fork_ button in upper |
| 50 | + right corner of the [repository |
| 51 | + page](https://github.com/quantumlib/OpenFermion-FQE)). Forking creates a new |
| 52 | + GitHub repo at the location `https://github.com/USERNAME/OpenFermion-FQE`, |
| 53 | + where `USERNAME` is your GitHub user name. |
| 54 | + |
| 55 | +1. Clone (using `git clone`) or otherwise download your forked repository to |
| 56 | + your local computer, so that you have a local copy where you can do your |
| 57 | + development work using your preferred editor and development tools. |
| 58 | + |
| 59 | +1. Check out the `main` branch and create a new [git |
| 60 | + branch](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) |
| 61 | + from `main`: |
| 62 | + |
| 63 | + ```shell |
| 64 | + git checkout main -b YOUR_BRANCH_NAME |
| 65 | + ``` |
| 66 | + |
| 67 | + where `YOUR_BRANCH_NAME` is the name of your new branch. |
| 68 | + |
| 69 | +### Development environment installation |
| 70 | + |
| 71 | +Please refer to the section _Developer install_ of the [installation |
| 72 | +instructions](docs/install.md) for information about how to set up a local copy |
| 73 | +of the software for development. |
| 74 | + |
| 75 | +### Tests and test coverage |
| 76 | + |
| 77 | +Existing tests must continue to pass (or be updated) when changes are |
| 78 | +introduced, and code should be covered by tests. We use |
| 79 | +[pytest](https://docs.pytest.org) to run our tests and |
| 80 | +[pytest-cov](https://pytest-cov.readthedocs.io) to compute coverage. We use the |
| 81 | +scripts [`./check/pytest`](./check/pytest) and |
| 82 | +[`./check/pytest-and-incremental-coverage`](./check/pytest-and-incremental-coverage) |
| 83 | +to run these programs with custom configurations for this project. |
| 84 | + |
| 85 | +We don't require 100% coverage, but any uncovered code must be annotated with `# |
| 86 | +pragma: no cover`. To ignore coverage of a single line, place `# pragma: no |
| 87 | +cover` at the end of the line. To ignore coverage for an entire block, start the |
| 88 | +block with a `# pragma: no cover` comment on its own line. |
| 89 | +
|
| 90 | +### Lint |
| 91 | +
|
| 92 | +Code should meet common style standards for Python and be free of error-prone |
| 93 | +constructs. We use [Pylint](https://www.pylint.org/) to check for code lint, and |
| 94 | +the script [`./check/pylint`](./check/pylint) to run it. When Pylint produces a |
| 95 | +false positive, it can be silenced with annotations. For example, the annotation |
| 96 | +`# pylint: disable=unused-import` would silence a warning about an unused |
| 97 | +import. |
| 98 | +
|
| 99 | +### Type annotations |
| 100 | +
|
| 101 | +Code should have [type annotations](https://www.python.org/dev/peps/pep-0484/). |
| 102 | +We use [mypy](http://mypy-lang.org/) to check that type annotations are correct, |
| 103 | +and the script [`./check/mypy`](./check/mypy) to run it. When type checking |
| 104 | +produces a false positive, it can be silenced with annotations such as `# type: |
| 105 | +ignore`. |
| 106 | +
|
| 107 | +### Pull requests and code reviews |
| 108 | +
|
| 109 | +1. If your local copy has drifted out of sync with the `main` branch of the |
| 110 | + main OpenFermion-FQE repo, you may need to merge the latest changes into |
| 111 | + your branch. To do this, first update your local `main` and then merge your |
| 112 | + local `main` into your branch: |
| 113 | +
|
| 114 | + ```shell |
| 115 | + # Track the upstream repo (if your local repo hasn't): |
| 116 | + git remote add upstream https://github.com/quantumlib/OpenFermion-FQE.git |
| 117 | + |
| 118 | + # Update your local main. |
| 119 | + git fetch upstream |
| 120 | + git checkout main |
| 121 | + git merge upstream/main |
| 122 | + # Merge local main into your branch. |
| 123 | + git checkout YOUR_BRANCH_NAME |
| 124 | + git merge main |
| 125 | + ``` |
| 126 | + |
| 127 | + If git reports conflicts during one or both of these merge processes, you |
| 128 | + may need to [resolve the merge conflicts]( |
| 129 | + https://docs.github.com/articles/about-merge-conflicts) before continuing. |
| 130 | + |
| 131 | +1. Finally, push your changes to your fork of the OpenFermion-FQE repo on GitHub: |
| 132 | + |
| 133 | + ```shell |
| 134 | + git push origin YOUR_BRANCH_NAME |
| 135 | + ``` |
25 | 136 |
|
26 |
| -## Community Guidelines |
| 137 | +1. Now when you navigate to the OpenFermion-FQE repository on GitHub |
| 138 | + (https://github.com/quantumlib/OpenFermion-FQE), you should see the option |
| 139 | + to create a new [pull |
| 140 | + requests](https://help.github.com/articles/about-pull-requests/) from your |
| 141 | + forked repository. Alternatively, you can create the pull request by |
| 142 | + navigating to the "Pull requests" tab near the top of the page, and |
| 143 | + selecting the appropriate branches. |
27 | 144 |
|
28 |
| -This project follows |
29 |
| -[Google's Open Source Community Guidelines](https://opensource.google/conduct/). |
| 145 | +1. A reviewer from the OpenFermion-FQE team will comment on your code and may |
| 146 | + ask for changes. You can perform the necessary changes locally, commit them |
| 147 | + to your branch as usual, and then push changes to your fork on GitHub |
| 148 | + following the same process as above. When you do that, GitHub will update |
| 149 | + the code in the pull request automatically. |
0 commit comments