Skip to content

Pull request checklist

Gracjan Polak edited this page Sep 13, 2015 · 4 revisions

Pull request checklist

Related page How to merge.

Haskell Mode is a mature project that requires high quality engineering and adherence to project process. We strive to deliver working solution, well written documentation while keeping maintenance cost feasible for an all-volunteer effort project.

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.

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

  1. Project scope and focus
  2. Code will not be a maintenance burden on the Haskell Mode community
  3. Code falls into project scope
  4. Functionality is sufficiently general to serve many users
  5. Engineering quality
  6. New functionality is reflected in unit test cases (as separate commits)
  7. There is an ERT test case for every modified function
  8. TravisCI has run and is green
  9. Indentation and style mimics surrounding code (does not stand out) and follows Emacs Lisp practice
  10. User guidelines, manual and documentation quality
  11. Functionality is properly described in haskell-mode.texi
  12. There is a sensible docstring for everything and reflects current semantics
  13. defcustoms docstring references functions where it is used
  14. defuns docstring references related functions, modes and defcustoms it depends on
  15. Pull request structure
  16. Commit messages roughly follow A Note About Git Commit Messages
  17. Commits are split in semantic parts, one commit per semantic change
  18. Tests are in a separate commit
  19. Documentation changes are in a separate commit
  20. Pull request is cleanly rebased over current master branch and does not have fixup commits

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.