diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4cf190229..5ebfae6b4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -462,33 +462,6 @@ steps: If feeling kindly, please update [mypy](https://github.com/python/mypy/blob/master/mypy/stubinfo.py) for any stub obsoletions or removals. -## Maintainer guidelines - -The process for preparing and submitting changes also applies to -maintainers. This ensures high quality contributions and keeps -everybody on the same page. Avoid direct pushes to the repository. - -When reviewing pull requests, follow these guidelines: - -* Typing is hard. Try to be helpful and explain issues with the PR, - especially to new contributors. -* When reviewing auto-generated stubs, just scan for red flags and obvious - errors. Leave possible manual improvements for separate PRs. -* When reviewing large, hand-crafted PRs, you only need to look for red flags - and general issues, and do a few spot checks. -* Review smaller, hand-crafted PRs thoroughly. - -When merging pull requests, follow these guidelines: - -* Always wait for tests to pass before merging PRs. -* Use "[Squash and merge](https://github.com/blog/2141-squash-your-commits)" to merge PRs. -* Make sure the commit message is meaningful. For example, remove irrelevant - intermediate commit messages. -* The commit message for third-party stubs is used to generate the changelog. - It should be valid Markdown, be comprehensive, read like a changelog entry, - and assume that the reader has no access to the diff. -* Delete branches for merged PRs (by maintainers pushing to the main repo). - ### Marking PRs as "deferred" We sometimes use the ["status: deferred" label](https://github.com/python/typeshed/labels/status%3A%20deferred) @@ -500,25 +473,9 @@ external factor. Blockers can include: - A dependency on a typing PEP that is still under consideration. - A pending change in a related project, such as stub-uploader. -PRs should only be marked as "deferred" if there is a clear path towards getting -the blocking issue resolved within a reasonable time frame. If a PR depends on -a more amorphous change, such as a type system change that has not yet reached -the PEP stage, it should instead be closed. - -Maintainers who add the "deferred" label should state clearly what exactly the -blocker is, usually with a link to an open issue in another project. - ### Closing stale PRs To keep the number of open PRs manageable, we may close PRs when they have been open for too long. Specifically, we close open PRs that either have failures in CI, serious merge conflicts or unaddressed feedback, and that have not seen any activity in three months. - -We want to maintain a welcoming atmosphere for contributors, so use a friendly -message when closing the PR. Example message: - - Thanks for contributing! I'm closing this PR for now, because it still - - after three months of inactivity. If you are still interested, please feel free to open - a new PR (or ping us to reopen this one). diff --git a/MAINTAINERS.md b/MAINTAINERS.md index 9a30d7952..c2323cece 100644 --- a/MAINTAINERS.md +++ b/MAINTAINERS.md @@ -27,3 +27,57 @@ They will also be moved to the "former maintainers" section here. Former maintainers who want their access rights restored should open an issue or mail one of the active maintainers. + +## Maintainer guidelines + +The process for preparing and submitting changes as outlined +in the [CONTRIBUTING document](./CONTRIBUTING.md) also applies to +maintainers. This ensures high quality contributions and keeps +everybody on the same page. Avoid direct pushes to the repository. + +### Reviewing and merging pull requests + +When reviewing pull requests, follow these guidelines: + +* Typing is hard. Try to be helpful and explain issues with the PR, + especially to new contributors. +* When reviewing auto-generated stubs, just scan for red flags and obvious + errors. Leave possible manual improvements for separate PRs. +* When reviewing large, hand-crafted PRs, you only need to look for red flags + and general issues, and do a few spot checks. +* Review smaller, hand-crafted PRs thoroughly. + +When merging pull requests, follow these guidelines: + +* Always wait for tests to pass before merging PRs. +* Use "[Squash and merge](https://github.com/blog/2141-squash-your-commits)" to merge PRs. +* Make sure the commit message is meaningful. For example, remove irrelevant + intermediate commit messages. +* The commit message for third-party stubs is used to generate the changelog. + It should be valid Markdown, be comprehensive, read like a changelog entry, + and assume that the reader has no access to the diff. +* Delete branches for merged PRs (by maintainers pushing to the main repo). + +### Marking PRs as "deferred" + +*See also the [guidelines in the CONTRIBUTING file](./CONTRIBUTING.md#marking-prs-as-deferred).* + +PRs should only be marked as "deferred" if there is a clear path towards getting +the blocking issue resolved within a reasonable time frame. If a PR depends on +a more amorphous change, such as a type system change that has not yet reached +the PEP stage, it should instead be closed. + +Maintainers who add the "deferred" label should state clearly what exactly the +blocker is, usually with a link to an open issue in another project. + +### Closing stale PRs + +*See also the [guidelines in the CONTRIBUTING file](./CONTRIBUTING.md#closing-stale-prs).* + +We want to maintain a welcoming atmosphere for contributors, so use a friendly +message when closing the PR. Example message: + + Thanks for contributing! I'm closing this PR for now, because it still + + after three months of inactivity. If you are still interested, please feel free to open + a new PR (or ping us to reopen this one).