Guidelines for Patch Acceptance/Rejection

The following guidlines for getting your patch accepted in Koha were compiled from a thread on the koha-devel mailing list

The patch must do what it claims to do, in all commonly-supported Koha environments.
- Include Unit Tests if at all possible.
The patch must not break existing functionality.
The patch must apply to the current HEAD of the main branch of the code.
- All patches which will not apply cleanly to maintenance versions should be ported and submitted as separate patches marked as such.
The patch must follow the Coding Style Guidelines.
- This includes the copyright statement.
The patch must be MARC-flavour agnostic.
If a database update is require, the patch must handle the update both for new installs and upgrades.
If a new feature is added, the patch must include appropriate Help documentation.
The patch must have at least 1 signoff from another party who is outside the organization responsible for the patch. The patch must then be signed off by a memer of the QA team. Exceptions may be made by the QA team or release manager for trivial patches
The patch must refer to a bug number
- To avoid cases where the bug number could be stripped from the patch during the Git workflow, please don't enclose the bug number in square brackets. In other words, don't do "[Bug 1234]", do "Bug 1234:"

Additional characteristics of a good patch