Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/haskell/haskell-mode/wiki/Pull-request-checklist below:

Pull request checklist · haskell/haskell-mode Wiki · GitHub

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4