Pull request checklist

Pull request checklist

It is a responsibility of Core Team to go through this checklist before merging a pull request. Especially it is NOT expected that people creating pull request should know of its existence all by themselves. We are grateful for their pull requests and we are resolved to help them improving until the pull request can be merged.

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 require some 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)