|
| 1 | +# How to contribute |
| 2 | + |
| 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. |
| 7 | + |
| 8 | +## Before you begin |
| 9 | + |
| 10 | +### Sign our Contributor License Agreement |
| 11 | + |
| 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. |
| 20 | + |
| 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 |
| 35 | + |
| 36 | +All submissions, including submissions by project members, require review. We |
| 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-PySCF repository (you can use the _Fork_ button in |
| 50 | + upper right corner of the [repository |
| 51 | + page](https://github.com/quantumlib/OpenFermion-PySCF)). Forking creates a |
| 52 | + new GitHub repo at the location |
| 53 | + `https://github.com/USERNAME/OpenFermion-PySCF`, where `USERNAME` is your |
| 54 | + GitHub user name. |
| 55 | + |
| 56 | +1. Clone (using `git clone`) or otherwise download your forked repository to |
| 57 | + your local computer, so that you have a local copy where you can do your |
| 58 | + development work using your preferred editor and development tools. |
| 59 | + |
| 60 | +1. Check out the `main` branch and create a new [git |
| 61 | + branch](https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell) |
| 62 | + from `main`: |
| 63 | + |
| 64 | + ```shell |
| 65 | + git checkout main -b YOUR_BRANCH_NAME |
| 66 | + ``` |
| 67 | + |
| 68 | + where `YOUR_BRANCH_NAME` is the name of your new branch. |
| 69 | + |
| 70 | +### Development environment installation |
| 71 | + |
| 72 | +Please refer to the section _Developer install_ of the [installation |
| 73 | +instructions](docs/install.md) for information about how to set up a local copy |
| 74 | +of the software for development. |
| 75 | + |
| 76 | +### Tests and test coverage |
| 77 | + |
| 78 | +Existing tests must continue to pass (or be updated) when changes are |
| 79 | +introduced, and code should be covered by tests. We use |
| 80 | +[pytest](https://docs.pytest.org) to run our tests and |
| 81 | +[pytest-cov](https://pytest-cov.readthedocs.io) to compute coverage. We use the |
| 82 | +scripts [`./check/pytest`](./check/pytest) and |
| 83 | +[`./check/pytest-and-incremental-coverage`](./check/pytest-and-incremental-coverage) |
| 84 | +to run these programs with custom configurations for this project. |
| 85 | + |
| 86 | +We don't require 100% coverage, but any uncovered code must be annotated with `# |
| 87 | +pragma: no cover`. To ignore coverage of a single line, place `# pragma: no |
| 88 | +cover` at the end of the line. To ignore coverage for an entire block, start the |
| 89 | +block with a `# pragma: no cover` comment on its own line. |
| 90 | +
|
| 91 | +### Lint |
| 92 | +
|
| 93 | +Code should meet common style standards for Python and be free of error-prone |
| 94 | +constructs. We use [Pylint](https://www.pylint.org/) to check for code lint, and |
| 95 | +the script [`./check/pylint`](./check/pylint) to run it. When Pylint produces a |
| 96 | +false positive, it can be silenced with annotations. For example, the annotation |
| 97 | +`# pylint: disable=unused-import` would silence a warning about an unused |
| 98 | +import. |
| 99 | +
|
| 100 | +### Type annotations |
| 101 | +
|
| 102 | +Code should have [type annotations](https://www.python.org/dev/peps/pep-0484/). |
| 103 | +We use [mypy](http://mypy-lang.org/) to check that type annotations are correct, |
| 104 | +and the script [`./check/mypy`](./check/mypy) to run it. When type checking |
| 105 | +produces a false positive, it can be silenced with annotations such as `# type: |
| 106 | +ignore`. |
| 107 | +
|
| 108 | +### Pull requests and code reviews |
| 109 | +
|
| 110 | +1. If your local copy has drifted out of sync with the `main` branch of the |
| 111 | + main OpenFermion-PySCF repo, you may need to merge the latest changes into |
| 112 | + your branch. To do this, first update your local `main` and then merge your |
| 113 | + local `main` into your branch: |
| 114 | +
|
| 115 | + ```shell |
| 116 | + # Track the upstream repo (if your local repo hasn't): |
| 117 | + git remote add upstream https://github.com/quantumlib/OpenFermion-PySCF.git |
| 118 | + |
| 119 | + # Update your local main. |
| 120 | + git fetch upstream |
| 121 | + git checkout main |
| 122 | + git merge upstream/main |
| 123 | + # Merge local main into your branch. |
| 124 | + git checkout YOUR_BRANCH_NAME |
| 125 | + git merge main |
| 126 | + ``` |
| 127 | + |
| 128 | + If git reports conflicts during one or both of these merge processes, you |
| 129 | + may need to [resolve the merge conflicts]( |
| 130 | + https://docs.github.com/articles/about-merge-conflicts) before continuing. |
| 131 | + |
| 132 | +1. Finally, push your changes to your fork of the OpenFermion-PySCF repo on |
| 133 | + GitHub: |
| 134 | + |
| 135 | + ```shell |
| 136 | + git push origin YOUR_BRANCH_NAME |
| 137 | + ``` |
| 138 | + |
| 139 | +1. Now when you navigate to the OpenFermion-PySCF repository on GitHub |
| 140 | + (https://github.com/quantumlib/OpenFermion-PySCF), you should see the option |
| 141 | + to create a new [pull |
| 142 | + requests](https://help.github.com/articles/about-pull-requests/) from your |
| 143 | + forked repository. Alternatively, you can create the pull request by |
| 144 | + navigating to the "Pull requests" tab near the top of the page, and |
| 145 | + selecting the appropriate branches. |
| 146 | + |
| 147 | +1. A reviewer from the OpenFermion-PySCF team will comment on your code and may |
| 148 | + ask for changes. You can perform the necessary changes locally, commit them |
| 149 | + to your branch as usual, and then push changes to your fork on GitHub |
| 150 | + following the same process as above. When you do that, GitHub will update |
| 151 | + the code in the pull request automatically. |
0 commit comments