@@ -483,15 +483,6 @@ The process for preparing and submitting changes also applies to
483
483
maintainers. This ensures high quality contributions and keeps
484
484
everybody on the same page. Avoid direct pushes to the repository.
485
485
486
- Maintainers should follow these rules when processing pull requests:
487
-
488
- * Always wait for tests to pass before merging PRs.
489
- * Use "[ Squash and merge] ( https://github.com/blog/2141-squash-your-commits ) " to merge PRs.
490
- * Delete branches for merged PRs (by maintainers pushing to the main repo).
491
- * Make sure commit messages to master are meaningful. For example, remove irrelevant
492
- intermediate commit messages.
493
- * If stubs for a new library are submitted, notify the library's maintainers.
494
-
495
486
When reviewing pull requests, follow these guidelines:
496
487
497
488
* Typing is hard. Try to be helpful and explain issues with the PR,
@@ -501,3 +492,14 @@ When reviewing pull requests, follow these guidelines:
501
492
* When reviewing large, hand-crafted PRs, you only need to look for red flags
502
493
and general issues, and do a few spot checks.
503
494
* Review smaller, hand-crafted PRs thoroughly.
495
+
496
+ When merging pull requests, follow these guidelines:
497
+
498
+ * Always wait for tests to pass before merging PRs.
499
+ * Use "[ Squash and merge] ( https://github.com/blog/2141-squash-your-commits ) " to merge PRs.
500
+ * Make sure the commit message is meaningful. For example, remove irrelevant
501
+ intermediate commit messages.
502
+ * The commit message for third-party stubs is used to generate the changelog.
503
+ It should be valid Markdown, be comprehensive, read like a changelog entry,
504
+ and assume that the reader has no access to the diff.
505
+ * Delete branches for merged PRs (by maintainers pushing to the main repo).
0 commit comments