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

1. The patch must do what it claims to do, in all commonly-supported Koha environments.
   • Include Unit Tests if at all possible.
2. The patch must not break existing functionality.
3. The patch must apply to the current HEAD of the master 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.
4. The patch must follow the Coding Style Guidelines.
   • This includes the copyright statement.
5. The patch must be MARC-flavour agnostic.
6. If a database update is require, the patch must handle the update both for new installs and upgrades.
7. If a new feature is added, the patch must include appropriate Help documentation.
8. 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
9. 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

1. The patch covers a single topic
2. The patch is easy to read
3. The patch does not contain the detritus of your coding process