- Set the following
- A purple component label (e.g. api, providers/vmware, etc).
- A colored scope label (bug, enhancement, refactoring, test, tools, developer, cleanup, performance, technical debt).
- A backport label for the next release (e.g. jansa/yes or jansa/no).
- The milestone.
- If there is no assignee, set yourself as the assignee.
- Proactively look at new PRs and Issues on some interval.
- If you know the SME (subject matter expert) for a particular PR or Issue, assign it to them.
- If you are the SME, assign to yourself, and do the review.
- Feel free to review PRs in which you are not the SME. The more help, the better.
- Ask for help from others, with @mentions, if you are unsure, or just want a second set of eyes.
- Do not be afraid to merge. ;)
- If you are hesitant to merge, re-assign to someone who will.
- Do not push to master or other release branches.
- Do not merge your own PRs.
- Do not merge a PR expecting the author to merge your PR (quid pro quo).
- Do not merge WIP PRs - A helpful Chrome extension to prevent it is here .
- Do not push branches to the main repo. Use a fork for your own work like other developers.
- By extension, do not use the revert or edit buttons in the GitHub UI as they create direct branches on the main repo.
- Instead, for reverts, you can create a local branch, run
git revert SHA, then push to your fork and make a PR.
- It may be preferable to revert the merge commit, particularly if there are multiple commits in the PR and you want to revert the entire PR.
- Do not let PRs sit unreviewed.
- Make a comment that you’ll get to it soon (if you don’t have time yet).
- If you’re not the authority, assign to someone else; or at least @mention them.