You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
More information about configuring a remote for a fork can be found [here](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork).
46
-
47
46
1. Sync your fork:
47
+
48
48
```shell
49
49
git fetch upstream
50
50
```
@@ -135,17 +135,17 @@ depending on how and where git is installed on your system, for example:
135
135
1. Add type hints to all new classes and functions added. Including type hinting
136
136
on unit tests.
137
137
138
-
2. Add a sample to show users how to use the new feature. Try to keep the command
138
+
1. Add a sample to show users how to use the new feature. Try to keep the command
139
139
line arguments of your sample consistent with the [Samples documentation page](samples)
140
140
and with other samples.
141
141
142
-
3. Add documentation (most likely in api-ref.md) in a separate pull request
142
+
1. Add documentation (most likely in api-ref.md) in a separate pull request
143
143
(see more below).
144
144
145
145
### Add tests
146
146
147
147
All of our tests live under the `test/` folder in the repository. We use
148
-
`pytest`and the built-in test runner `python setup.py test`.
148
+
`pytest`which is run with `pytest test`.
149
149
150
150
Follow the structure of existing tests, especially if new server responses
151
151
are going to be mocked.
@@ -225,7 +225,7 @@ follow these steps:
225
225
1. (Optional) Do a test publish to PyPI without creating the next version tag.
226
226
This will create a pre-release package with a version like `0.30.post0.dev`.
227
227
228
-
1. On a local clone of the repo, create and push the tag for the *next* version
228
+
1. On a local clone of the repo, create and push the tag for the _next_ version
0 commit comments