Skip to content

docs: add maintainer guidelines for landing PRs #177

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 26, 2020
Merged

docs: add maintainer guidelines for landing PRs #177

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 15 additions & 5 deletions maintainer_guidelines.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,23 @@ Here are a few tips for repository maintainers.

* Stay on top of your pull requests. PRs that languish for too long can become difficult to merge.
* Work from your own fork. As you are making contributions to the project, you should be working from your own fork just as outside contributors do. This keeps the branches in github to a minimum and reduces unnecessary CI runs.
* Try to proactively label issues with backport labels if it's obvious that a change should be backported to previous releases.
* When landing pull requests, if there is more than one commit, try to squash into a single commit. Usually this can just be done with the GitHub UI when merging the PR. Use "Squash and merge".
* Triage issues once in a while in order to keep the repository alive. During the triage:
* Try to proactively label issues and pull requests with labels
* Actively review pull requests as the are submitted
* Triage issues once in a while in order to keep the repository alive.
* If some issues are stale for too long because they are no longer valid/relevant or because the discussion reached no significant action items to perform, close them and invite the users to reopen if they need it.
* If some PRs are no longer valid but still needed, ask the user to rebase them
* If some PRs are no longer valid due to conflicts, but the PR is still needed, ask the contributor to rebase their PR
* If some issues and PRs are still relevant, use labels to help organize tasks
* If you find an issue that you want to create a fix for and submit a pull request, be sure to assign it to yourself so that others maintainers don't start working on it at the same time.
* If you find an issue that you want to create a pull request for, be sure to assign it to yourself so that other maintainers don't start working on it at the same time.

## Landing Pull Requests

When landing pull requests, be sure to check the first line uses an appropriate commit message prefix (e.g. docs, feat, lib, etc). If there is more than one commit, try to squash into a single commit. Usually this can just be done with the GitHub UI when merging the PR. Use "Squash and merge". To help ensure that everyone in the community has an opportunity to review and comment on pull requests, it's often good to have some time after a pull request has been submitted, and before it has landed. Some guidelines here about approvals and timing.

* No pull request may land without passing all automated checks
* All pull requests require at least one approval from a maintainer before landing
* A pull request author may approve their own PR, but will need an additional approval to land it
* If a maintainer has submitted a pull request and it has not received approval from at least one other maintainer, it can be landed after 72 hours
* If a pull request has both approvals and requested changes, it can't be landed until those requested changes are resolved

## Branch Management

Expand Down