Skip to content

Pull request checklist

gracjan edited this page Apr 28, 2015 · 4 revisions

Pull request checklist

Related page How to merge.

Core Team is responsible to go through this checklist before merging a pull request.

Note that we especially do NOT expected first time contributors to know about this checklist upfront. We are grateful for their pull requests and we are resolved to help them with their pull request by politely pointing out specific items to fix.

Important: It is a discretion of Core Team to forgo some of items on this list provided it better serves current Project focus. Symmetrically it might be beneficial to impose additional requirements on case by case basis.

  1. Code quality
  2. Indentation and style mimics surrounding code (does not stand out)
  3. Style and semantics follows Emacs Lisp practice
  4. New functionality is reflected in unit test cases (as separate commits)
  5. Pull request structure
  6. Commit messages roughly follow A Note About Git Commit Messages
  7. Commits are split in semantic parts, one commit per semantic change
  8. Fixup commits are squashed properly
  9. Documentation quality
  10. There is a sensible docstring for everything and reflects current semantics
  11. defcustoms docstring references functions where it is used
  12. defuns docstring references related functions and defcustoms it depends on
  13. Process quality
  14. TravisCI has run and is green
  15. Pull request is cleanly rebased over current master branch
  16. Project scope and focus
  17. Code will not be a maintenance burden on Haskell Mode community
  18. Code falls into project scope (decided on case by case basis by Core Team)
Clone this wiki locally