# Maintainer Guidelines

These are guidelines for maintainers of this repository as (mostly) [gifted to us by](https://github.com/ReactiveX/RxJS/issues/121#issue-97747542)
His Beardliness, @jeffbcross. They are words to live by for those that are tasked with reviewing and merging pull requests and otherwise
shepherding the community. As the roster of trusted maintainers grows, we'll expect these guidelines to stay pretty
much the same (but suggestions are always welcome).

### The ~~10~~ 6 Commandments

- **[Code of Conduct](../../../CODE_OF_CONDUCT.md)**. We should be setting a good example and be welcoming to all. We should be listening
  to all feedback from everyone in our community and respect their viewpoints and opinions.
- **Be sure PRs meet [Contribution Guidelines](../../../CONTRIBUTING.md)**. It's important we keep our code base
  and repository consistent. The best way to do this is to know and enforce the contribution guidelines.
- **Clean, flat commit history**. We never click the green merge button on PRs, but instead we pull down
  the PR branch and rebase it against master then replace master with the PR branch. See
  [example gist](https://gist.github.com/jeffbcross/307c6da45d26e29030ef). This reduces noise in the commit
  history, removing all of the merge commits, and keeps history flat. The flat history is beneficial
  to tools/scripts that analyze commit ancestry.
- **Always green master**. Failing master builds tend to cascade into other broken builds, and
  frustration among other contributors who have rebased against a broken master. Much of our deployment
  and other infrastructure is based on the assumption that master is always green, nothing should be
  merged before Travis has confirmed that a PR is green, even for seemingly insignificant changes.
  Nothing should be merged into a red master, and whomever broke it should drop everything and fix it
  right away. Fixes should be submitted as a PR and verified as green instead of immediately merging
  to master.
- **No force pushes to master**. Only in rare circumstances should a force push to master be made,
  and other maintainers should be notified beforehand. The most common situation for a justified force
  push is when a commit has been pushed with an invalid message. The force push should be made as soon
  as possible to reduce side effects.
- **Small, logical commits**. A PR should be focused on a single problem, though that problem may be
  reasonable to be broken into a few logical commits. For example, a global renaming may be best to be
  broken into a single commit that renames all files, and then a commit that renames symbols within files.
  This makes the review process simpler easier, so the diff of the meaty commit (where symbols are
  renamed) can be easily understood than if both were done in the same commit, in which case github would
  just show a deleted file and an added file.
