VimPlug/typeshed
1
0
Fork 0
mirror of https://github.com/davidhalter/typeshed.git synced 2026-05-06 13:33:59 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

Move maintainer guidelines to MAINTAINERS document

Browse Source 
The guidelines are unchanged, apart from linking back to the
CONTRIBUTING document and introducting section headers.

This serves multiple purposes:

* The maintainer guidelines are easier to find for maintainers.
* The CONTRIBUTING document needs fewer changes, meaning fewer
  "guideline changed" warnings for contributors.
* The – already very long – CONTRIBUTING document is shorter,
  and doesn't contain information irrelevant for regular contributors.
This commit is contained in:
Sebastian Rittau
2025-03-21 16:01:35 +01:00
parent 67923168ef
commit 10913cff2c
2 changed files with 54 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CONTRIBUTING.md
-43
View File
@@ -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
<fails some tests OR has unresolved review feedback OR has a merge conflict>
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).
MAINTAINERS.md
+54
View File
@@ -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
<fails some tests OR has unresolved review feedback OR has a merge conflict>
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).