Mypy pull requests are reviewed by one of the core developers. All pull requests arenot created equal, however. By following a few guidelines youcan make it more likely that your PR will be merged quickly. Many of uswork on mypy full-time, so you should expect an initial response to your pull request within a few days.Easy-to-merge pull requests will generally be reviewed sooner.If your pull request involves a major change, please post an issue for discussion first to avoid wasted work.

Properties of an easy-to-merge pull request:

1. PR contains a single logical change. Grouping multiple not directlyrelated changes into a single PR makes them slower to review.

2. PR has tests (if relevant). If there are no tests, we'll probably ask you to write them. In some cases (most notably platform compatibility), we may do manual testing instead.

3. PR has clean CI builds and merges cleanly.

4. PR has a message or comments that explain what the PR does in somedetail, and why this is useful. For small changes this is lessimportant, but the more complex the change, the moreimportant this is.

5. There is a github issue related to your PR that has been discussed,and there are no unresolved objections or open questions. This is important ifyour PR makes big changes or adds new dependencies. If there is anexisting issue (that is not tagged as a proposal) then this is notas important, but it may still be worth it to get feedback onnon-trivial design decisions. Please mentionin an issue when you start work on it.

6. PRs that address github issues in more imminent milestones get priority when reviewing.

Things that may make a PR difficult or slow to review (these may evenget a PR rejected, and we want to avoid wasted work):

1. The PR doesn't merge cleanly to master. Usually the creator of thePR has the most context to deal with merge conflicts. We don't geta GitHub Actions CI test build if there are merge errors.

2. There are failing tests. If you think that the failures are unrelatedto your change, create a separate issue for the failure with steps toreproduce it, so that there is more visibility for others to work on a fix,and mention that this issue is blocking your PR.

3. Multiple, unrelated changes in a single PR.

4. Very large PRs (several hundred lines or more of new code). Theseoften require manual testing and deep analysis of tradeoffs, andmay also involve profiling and writing new tests. Even just readingthrough the code can take much time. Splitting a large PR into multiplePRs (if feasible while making each PR self-sufficient alone) canspeed up code review significantly.

5. A big refactoring, rewrite or a newfeature that hasn't been discussedbefore. This is especially true if mypy users or developers willhave to change their code or workflows.

6. PR partially implements a feature or has bugs or limitations. Thesemay or may not get merged.