Pull request checklist

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)