From Koha Wiki

Bug-enhancement-patch Workflow describes the different steps required to fix and enhance Koha code.

Different people are involved in the process.

Contents 1 Steps 2 Failure cases 3 Roles 4 Rules

Steps

1. A bug/enhancement is submitted by the 'bug reporter'.
   
2. A patch is submitted by the 'patch writer'.
3. (optional) RM pushed it as a QA branch.
4. The patch is tested and signed off by the 'patch signer'.
5. The patch is checked by the QA team member, and bug status is set to Passed QA
6. The patch is tested and signed off by RM
7. If the patch passes, it is pushed into master by the RM, status is set to Pushed to master.
8. If the RMaint has consider the patch must be pushed to stable version too, he does it and set the status to Pushed to stable
9. The bug is marked resolved/fixed by the 'bug closer'.
10. The bug is closed when a release is made containing that patch.

Failure cases

1. if the 'patch signer' can't test the patch because it does not apply anymore, the status is set to does not apply
2. if the 'patch signer' can apply the patch but after some tests see that there is a functionnal problem with the patch, the status is set to In discussion, does not apply or Failed QA, depending on the kind of the problem the tester has detected. The description from the tester must be as detailled as possible to be able to reproduce the failure.
3. if the 'QA manager' has some objections during the QA process, the status is set to Failed QA
4. if a patch has been applied into Koha and a problem is detected after that, there are two options :
   1. the bug is reopened, the patch status is set back to "Assigned/Reopened" and the reopened explain why he has reopened the bug.
   2. a new bug is filed, linked to the original one, explaining that the fix is not complete, or has a side-effect.

In this case, the Release Manager can revert the patch or not, depending on the explanation/criticity on the reopening. Usually, if you open a new bug, it means it's not worth reverting the patch.

Roles

• Bug reporter: the person who reported the bug. Can also be the patch writer
• Patch writer: the developer who proposed a patch. Can also be the bug reporter
• RM: the Release Manager (elected position)
• QA Manager: the developer (elected member of the QA team) who says the patch is QA compliant
  
• Patch signer: the user who tested the patch and saw it works
  
• Bug closer: the person who checked that the bug is now fixed. Can be the reporter, it's preferred that the patch writer is not the closer.
  

Rules

• A bug report must contain information allowing other people to reproduce the bug and test the patch. Usually, there is a section "steps to reproduce: do this, do that, you'll see this buggy behaviour)
  
• Patch signer should not be patch writer. Preferably, patch writer and patch signer should not be from the same company or institution.
• Bug closer should not be patch writer. Preferably, bug closer should not be patch signer too.
• if your patch is an ENHancement, please add [ENH] just after the patch number in your patch comment 1st line (example: "Bug 6543 [ENH] I add a very nice feature")