Preparing for Koha 3.2
In the cycle of Koha development there are slow times and there are busy times. Right now is a busy time. We’re in the run-up to a big release, Koha 3.2. It has been sixteen months since the release of Koha 3.0. Since that time developers have been working on two tracks: The first track is one devoted to bug-fixes and minor enhancements to 3.0.x. The fruits of those labors can be found in the releases of Koha 3.0.1, 3.0.2, 3.0.3, 3.0.4, and most recently 3.0.5. Each of these releases reflects incremental improvements.
At the same time work on major new features has taken place along the other track, the track leading to Koha 3.2. Major new features will often include structural changes like new software dependencies or database structure changes. For an interface designer like me this track is always the most interesting, because new features means new interfaces to help refine.
This is an exciting time because the Koha project has recently gotten a large contribution of code from BibLibre, a French Koha development and support company. BibLibre has a long history with Koha and a long history with the Athens County Public Libraries: When we were preparing to switch to Koha in 2002 BibLibre answered our RFP to add MARC support to Koha. Eight years later BibLibre is still a major contributor to Koha. Included in their recent submission is the new acquisitions functionality which Paul Poulain discussed at KohaCon 2009.
Much of what I do when I work on Koha is to look at existing or new interfaces and try to do what I can to make them cleaner, improve their structure, and help the design however I can. Some of these changes are guided by standards, whether they be web standards or simply conventions we’ve adopted for markup and interaction design. When a big contribution like BibLibre’s comes along, I start the process of reviewing every template and every new interface to see if everything works well and looks good. This isn’t just a process about making things look pretty, it’s a perfect opportunity to do some informal usability testing, some bug-hunting, and some bug-fixing.
This is what working on an open-source project is all about: contributing our work to the project to make the best software we can. And the best thing about it is it’s a lot of fun.