-
Notifications
You must be signed in to change notification settings - Fork 347
Pull request checklist
gracjan edited this page Apr 28, 2015
·
4 revisions
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.
- Code quality
- Indentation and style mimics surrounding code (does not stand out)
- Style and semantics follows Emacs Lisp practice
- New functionality is reflected in unit test cases (as separate commits)
- Pull request structure
- Commit messages roughly follow A Note About Git Commit Messages
- Commits are split in semantic parts, one commit per semantic change
- Fixup commits are squashed properly
- Documentation quality
- There is a sensible docstring for everything and reflects current semantics
-
defcustom
s docstring references functions where it is used -
defun
s docstring references related functions anddefcustom
s it depends on - Process quality
- TravisCI has run and is green
- Pull request is cleanly rebased over current master branch
- Project scope and focus
- Code will not be a maintenance burden on Haskell Mode community
- Code falls into project scope (decided on case by case basis by Core Team)