Skip to content

Latest commit

 

History

History
31 lines (28 loc) · 1.9 KB

mergers_guidelines.md

File metadata and controls

31 lines (28 loc) · 1.9 KB

Merger Guidelines

DO

  • Create a merge commit
  • Set the following
    • A purple component label (e.g. api, providers/vmware, etc).
    • A 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).
    • 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.

DON’T

  • 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.