Permalink
Browse files

Policy: allow PRs to be merged more easily

  • Loading branch information...
Kodiologist committed Feb 24, 2018
1 parent 10cd36d commit 6994be6cfda8405e624b4f7657b89e8dd2b3106f
Showing with 14 additions and 9 deletions.
  1. +14 −9 CONTRIBUTING.rst
@@ -120,15 +120,20 @@ handy. Conversely, avoid this exact language if you want to mention
an issue without closing it (because e.g. you've partly but not
entirely fixed a bug).
Before any PR is merged, it must be approved by members of Hy's core team
other than the PR's author. Changes to the documentation, or trivial changes
to code, need to be approved by **one** member; all other PRs need to be
approved by **two** members.
Anybody on the team may perform the merge. Merging should create a merge commit
(don't squash unnecessarily, because that would remove separation between
logically separate commits, and don't fast-forward, because that would throw
away the history of the commits as a separate branch), which should
There are two situations in which a PR is allowed to be merged:
1. When it is approved by **two** members of Hy's core team other than the PR's
author. Changes to the documentation, or trivial changes to code, need only
**one** approving member.
2. When the PR is at least **two weeks** old and **no** member of the Hy core
team has expressed disapproval of the PR in its current state. (Exception: a
PR to create a new release is not eligible to be merged under this criterion,
only the first one.)
Anybody on the Hy core team may perform the merge. Merging should create a
merge commit (don't squash unnecessarily, because that would remove separation
between logically separate commits, and don't fast-forward, because that would
throw away the history of the commits as a separate branch), which should
include the PR number in the commit message.
Contributor Code of Conduct

0 comments on commit 6994be6

Please sign in to comment.