@@ -5,14 +5,15 @@ We do have some guidelines to follow, covered in this document, but don't
5
5
worry about (or expect to) get everything right the first time!
6
6
Create a pull request and we'll nudge you in the right direction. Please also
7
7
note that we have a [ code of conduct] ( CODE_OF_CONDUCT.md ) to make Cirq an
8
- open and welcoming environment.
8
+ open and welcoming community environment.
9
9
10
10
## Contributor License Agreement
11
11
12
- Contributions to this project must be accompanied by a Contributor License
13
- Agreement. You (or your employer) retain the copyright to your contribution;
12
+ Contributions to this project must be accompanied by a [ Contributor License
13
+ Agreement] ( https://cla.developers.google.com/about ) (CLA). You
14
+ (or your employer) retain the copyright to your contribution;
14
15
this simply gives us permission to use and redistribute your contributions as
15
- part of the project. Head over to < https://cla.developers.google.com/ > to see
16
+ part of the project. Head over to https://cla.developers.google.com/ to see
16
17
your current agreements on file or to sign a new one.
17
18
18
19
You generally only need to submit a CLA once, so if you've already submitted one
@@ -26,27 +27,28 @@ use GitHub pull requests for this purpose.
26
27
[ GitHub Help] ( https://help.github.com/articles/about-pull-requests/ ) has
27
28
information on using pull requests.
28
29
29
- The preferred manner for submitting pull requests is for users to fork
30
- the Cirq [ repo] ( https://github.com/quantumlib/Cirq ) and then use a
31
- branch from this fork to create a pull request to the main Cirq repo.
32
-
33
- The basic process for setting up a fork is
34
- 1 . Fork the Cirq repo (Fork button in upper right corner of
35
- [ repo page] ( https://github.com/quantumlib/Cirq ) ).
36
- Forking creates a new github repo at the location
37
- ``` https://github.com/USERNAME/cirq ``` where ``` USERNAME ``` is
38
- your github id. Use the directions on the
30
+ The preferred manner for submitting pull requests is for developers to fork
31
+ the Cirq [ repository] ( https://github.com/quantumlib/Cirq ) and then use a [ git
32
+ branch] ( https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell )
33
+ from this fork to create a pull request to the main Cirq repo. The basic process for setting
34
+ up a fork is as follows:
35
+
36
+ 1 . Fork the Cirq repository (you can use the _ Fork_ button in upper right
37
+ corner of the [ repository page] ( https://github.com/quantumlib/Cirq ) ).
38
+ Forking creates a new GitHub repo at the location
39
+ ` https://github.com/USERNAME/Cirq ` , where ` USERNAME ` is
40
+ your GitHub user name. Use the instructions on the
39
41
[ development page] ( docs/dev/development.md ) to download a copy to
40
42
your local machine. You need only do this once.
41
- 1 . Checkout main and create a new branch from this main
43
+ 1 . Check out the ` main ` branch and create a new branch from ` main ` :
42
44
``` shell
43
45
git checkout main -b new_branch_name
44
46
```
45
- where ` ` ` new_branch_name` ` ` is the name of your new branch.
47
+ where ` new_branch_name` is the name of your new branch.
46
48
1. Do your work and commit your changes to this branch.
47
- 1. If you have drifted out of sync with the main from the
48
- main cirq repo you may need to merge in changes. To do this,
49
- first update your local main and then merge the local main
49
+ 1. If your local copy has drifted out of sync with the ` main` branch of the
50
+ main Cirq repo, you may need to merge in the latest changes. To do this,
51
+ first update your local ` main` and then merge your local ` main`
50
52
into your branch:
51
53
` ` ` shell
52
54
# Track the upstream repo (if your local repo hasn't):
@@ -60,70 +62,74 @@ into your branch:
60
62
git checkout new_branch_name
61
63
git merge main
62
64
` ` `
63
- You may need to fix merge conflicts for both of these merge
64
- commands.
65
- 1. Finally, push your change to your clone
65
+ You may need to fix [merge conflicts](
66
+ https://docs.github.com/articles/about-merge-conflicts)
67
+ during one or both of these merge processes.
68
+ 1. Finally, push your changes to your forked copy of the Cirq repo on GitHub:
66
69
` ` ` shell
67
70
git push origin new_branch_name
68
71
` ` `
69
- 1. Now when you navigate to the cirq page on github,
70
- [https://github.com/quantumlib/cirq] (https://github.com/quantumlib/cirq)
72
+ 1. Now when you navigate to the Cirq repository on GitHub
73
+ (https://github.com/quantumlib/Cirq),
71
74
you should see the option to create a new pull request from
72
- your clone repository. Alternatively you can create the pull request
75
+ your clone repository. Alternatively, you can create the pull request
73
76
by navigating to the " Pull requests" tab in the page, and selecting
74
77
the appropriate branches.
75
- 1. The reviewer will comment on your code and may ask for changes,
76
- you can perform these locally, and then push the new commit following
77
- the same process as above.
78
+ 1. A reviewer will comment on your code and may ask for changes.
79
+ You can perform the necessary changes locally, and then push the new commit
80
+ following the same process as above.
78
81
79
82
# # Development Environment Setup
80
83
81
- Please refer to our [development page](docs/dev/development.md) for instructions
82
- on setting up your local development environment.
84
+ Please refer to our [development page](docs/dev/development.md) for
85
+ instructions on setting up your local development environment.
83
86
84
87
# # Code Testing Standards
85
88
86
89
When a pull request is created or updated, various automatic checks will
87
- run to ensure that the change won' t break Cirq and meets our coding standards.
90
+ run on GitHub to ensure that the changes won' t break Cirq, as well as to make
91
+ sure they meet the Cirq project' s coding standards.
88
92
89
- Cirq contains a continuous integration tool to verify testing. See our
93
+ Cirq includes a continuous integration tool to perform testing. See our
90
94
[development page](docs/dev/development.md) on how to run the continuous
91
95
integration checks locally.
92
96
93
- Please be aware of the following code standards that will be applied to any
97
+ Please be aware of the following coding standards that will be applied to any
94
98
new changes.
95
99
96
100
- ** Tests** .
97
101
Existing tests must continue to pass (or be updated) when new changes are
98
- introduced. We use [pytest](https://docs.pytest.org/en/latest/ ) to run our
102
+ introduced. We use [pytest](https://docs.pytest.org) to run our
99
103
tests.
100
104
- ** Coverage** .
101
105
Code should be covered by tests.
102
- We use [pytest-cov](https://pytest-cov.readthedocs.io/en/latest/ ) to compute
106
+ We use [pytest-cov](https://pytest-cov.readthedocs.io) to compute
103
107
coverage, and custom tooling to filter down the output to only include new or
104
108
changed code. We don' t require 100% coverage, but any uncovered code must
105
109
be annotated with `# pragma: no cover`. To ignore coverage of a single line,
106
110
place `# pragma: no cover` at the end of the line. To ignore coverage for
107
111
an entire block, start the block with a `# pragma: no cover` comment on its
108
112
own line.
109
113
- **Lint**.
110
- Code should meet common style standards for python and be free of error-prone
111
- constructs. We use [pylint ](https://www.pylint.org/) to check for lint.
114
+ Code should meet common style standards for Python and be free of error-prone
115
+ constructs. We use [Pylint ](https://www.pylint.org/) to check for code lint.
112
116
To see which lint checks we enforce, see the
113
- [dev_tools/conf/.pylintrc](dev_tools/conf/.pylintrc) file. When pylint produces
114
- a false positive, it can be squashed with annotations like
115
- ` # pylint: disable=unused-import` .
117
+ [dev_tools/conf/.pylintrc](dev_tools/conf/.pylintrc) file. When Pylint produces
118
+ a false positive, it can be silenced with annotations. For example, the
119
+ annotation `# pylint: disable=unused-import` would silence a warning about
120
+ an unused import.
116
121
- **Types**.
117
122
Code should have [type annotations](https://www.python.org/dev/peps/pep-0484/).
118
123
We use [mypy](http://mypy-lang.org/) to check that type annotations are correct.
119
- When type checking produces a false positive, it can be ignored with
120
- annotations like ` # type: ignore` .
124
+ When type checking produces a false positive, it can be silenced with
125
+ annotations such as `# type: ignore`.
121
126
122
127
## Request For Comment Process for New Major Features
123
128
124
- For larger contributions that will benefit from design reviews, please use the
129
+ For larger contributions that will benefit from design reviews, please use the Cirq
125
130
[Request for Comment](docs/dev/rfc_process.md) process.
126
131
127
132
## Developing notebooks
128
133
129
- Please refer to our [notebooks guide](docs/dev/notebooks.md) on how to develop iPython notebooks for documentation.
134
+ Please refer to our [notebooks guide](docs/dev/notebooks.md) on how to develop
135
+ iPython notebooks for documentation.
0 commit comments