Merger Guidlines

DO

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.