@@ -13,12 +13,9 @@ are important to the project's success.
13
13
3 . [ Prepare your changes] ( #preparing-changes ) :
14
14
* Small fixes and additions can be submitted directly as pull requests,
15
15
but [ contact us] ( #discussion ) before starting significant work.
16
- * IMPORTANT: For new libraries, [ get permission from the library owner first] ( #adding-a-new-library ) .
17
16
* Create your stubs [ conforming to the coding style] ( #stub-file-coding-style ) .
18
17
* Make sure your tests pass cleanly on ` mypy ` , ` pytype ` , and ` flake8 ` .
19
- 4 . [ Submit your changes] ( #submitting-changes ) :
20
- * Open a pull request
21
- * For new libraries, [ include a reference to where you got permission] ( #adding-a-new-library )
18
+ 4 . [ Submit your changes] ( #submitting-changes ) by opening a pull request.
22
19
5 . You can expect a reply within a few days:
23
20
* Diffs are merged when considered ready by the core team.
24
21
* Feel free to ping the core team if your pull request goes without
@@ -104,21 +101,6 @@ recommend starting by opening an issue laying out what you want to do.
104
101
That lets a conversation happen early in case other contributors disagree
105
102
with what you'd like to do or have ideas that will help you do it.
106
103
107
- ### Adding a new library
108
-
109
- If you want to submit type stubs for a new library, you need to
110
- ** contact the maintainers of the original library** first to let them
111
- know and ** get their permission** . Do it by opening an issue on their
112
- project's bug tracker. This gives them the opportunity to
113
- consider adopting type hints directly in their codebase (which you
114
- should prefer to external type stubs). When the project owners agree
115
- for you to submit stubs here or you do not receive a reply within
116
- one month, open a pull request ** referencing the
117
- issue where you asked for permission** .
118
-
119
- Make sure your changes pass the tests (the [ README] ( README.md#running-the-tests )
120
- has more information).
121
-
122
104
### What to include
123
105
124
106
Stubs should include the complete interface (classes, functions,
@@ -390,3 +372,4 @@ Core developers should follow these rules when processing pull requests:
390
372
* Delete branches for merged PRs (by core devs pushing to the main repo).
391
373
* Make sure commit messages to master are meaningful. For example, remove irrelevant
392
374
intermediate commit messages.
375
+ * If stubs for a new library are submitted, notify the library's maintainers.
0 commit comments