Owen Leonard provided a succinct and useful description of how new developments make their way into a final release. Here's my rendition of the process....

He began the story with "a patch is submitted" which means that your or your developer has figured out how to add the enhancement or fix the bug and the code has been made available to other developers to take a look at.  That code is "a patch."

Once the patch is available to others, it can be pulled into a live or (more likely) a test system so someone can test it.  Once someone tests it and verifies that that is indeed a useful and functional patch, they can "sign off" on that patch.  It is great to have more than one person "sign off" on a patch.  The patch cannot move to the next step until at least one person has signed off and changed the status of the patch to (predictably) "Signed Off."

After that, it is really up to the core development team to take the necessary steps to get that patch into the next release.

The QA manager (currently that person is Ian Walls, congratulations, Ian!) tests the "signed off" patch again and confirms that it works AND that the code meets project standards.  Only the QA Manager can get it past this step.  Once it is approved, its status become "Passed QA." 

Next, the Release Manager examines the patches that have "Passed QA" and assuming the RM also agrees that the patch is good, that patch is "pushed" which means it becomes part of the next release!

The Open Source - Open Libraries Consortium will be sponsoring the development of Fee Payment Support (E-Commerce) for SIP2 connected devices such as self-check machines.  Many libraries in the Consortium were using their self-checks for fines and fees payment before migrating to Koha and know how important this functionality is.  Libraries that haven't had self-check and E-commerce before will benefit from this enhancement as well.

Per Ian Walls of ByWater, the coding should be complete by the end of April 2011 at which point testing will begin.  Because SIP2 is implemented so differently from vendor to vendor, testing may take some time.  Once adequate testing has been done, the enhancement will be bundled for release into Koha.  Members of the Consortium will be able to take advantage of the development as soon as the code has been vetted by Koha's core developers.

If your library would like to assist with testing the code, please contact ByWater and let them know!  The more testers we have, the better the final product will be and the sooner we'll have code that is ready to be committed to Koha.

Development Details:

Koha SIP2 Enhancement: Fee Payment Support

This development shall enable Koha to accept, process and respond to SIP2 'Fee Paid' messages, as per the SIP2 protocol specification defined by 3M.

Accepting 'Fee Paid' messages

Koha shall accept SIP2 messages following the 'Fee Paid' message standard outlined by 3M. 

Processing 'Fee Paid' messages

Koha shall parse the 'Fee Paid' message to extract the following mandatory information:

• Transaction date
• Fee type
• Payment type
• Currency
• Amount
• Institution ID
• Patron identifier (barcode)

Koha shall also be able to parse the following optional information:

• terminal password
• patron password
• fee identifier (the ID of the fine to which the payment is applied)
• Transaction ID (as assigned by the SIP client)

Once the message is parsed, a payment line shall be added to Koha's accountlines table.  This line shall include the borrowernumber, amount (as a negative), the transaction date, the payment type, and the account against which the payment is made.  A note shall also be made to indicate that the payment was made from SIP client, rather than through the Koha staff client.

Payments shall be accepted if the borrowernumber and account against which the payment is made are both valid.  Otherwise, the payment shall not be accepted, and return an error message. 

Responding to 'Fee Paid' messages

Koha shall respond to 'Fee Paid' messages using the 'Fee Paid Response' message type as laid out by 3M in the SIP specification.  

The Screen Message attribute of the 'Fee Paid Response' Message shall be used to display the details of any error that prevented the payment from being accepted.  If the payment is accepted, this attribute shall contain a friendly “thank you for your payment” message.

Check out this communication between a Koha end user and Ian Walls, one of the Koha developers and a ByWater Solutions employee. This exchange occurred via ByWater's support ticketing system. I think it shows what is so incredible about working in an open source environment. I can't imagine this exchange happening with a proprietary system!

Dan Scott, an Evergreen developer Systems Librarian at Laurentian University recently blogged about using code  developed in Koha for a routine he developed in Evergreen which will enable LC call numbers to sort correctly (Dewey works okay today but LC numbers don't).