Hi everyone, Well, hope you're all enjoying our new home at Savannah: http://savannah.nongnu.org/projects/koha. I trust the transition was fairly transparent to most of you. If you haven't done so already, please sign up at savannah and send me, paul or chris your username and we'll hook you up. Now, on to some business. As many of you know, we're in the process of planning version 3.0 of Koha. The biggest component of the 3.0 release is replacing the 2.x series MARC-in-SQL style database with the Zebra indexing engine (http://indexdata.dk/zebra). Paul's already done quite a bit of work in HEAD, preparing things by getting rid of the marc-* tables, writing some configuration files for Zebra, and some wrappers for searching using Net::Z3950, and documentation on how to get Zebra running with Koha. In the past few months, we haven't seen much activity in HEAD, largely because we've been waiting for the new Perl-ZOOM API. Perl-ZOOM will replace the current Net::Z3950 module and will add a number of new features. The most important being the Database Management functions (add, delete, edit data in a Zebra database), which will give us a single API for searching, retrieving, adding, deleting and editing bibliographic data in Koha. So ... the good news is that Perl-ZOOM is nearly completed. We're expecting a public release by the end the second full week in December (Friday, December 16 at the latest). In the meantime, while we wait for Perl-ZOOM to be completed, we need to discuss what our final list of features will be for 3.0. I've compiled a list of features that we've discussed on the Koha 3.0 Roadmap: http://www.saas.nsw.edu.au/koha_wiki/index.php?page=KohaRoadmap3.0 At the bottom, there is also a tentitive schedule in place. So, now, I need solid commitments and timelines for the various projects you're working on. I'd like to compile the final list and declare a feature freeze by the last week in December so we can begin to stabilize the 3.0 branch. It's going to be a busy first quarter of 2006 :-). Please send me (on or off-list) the list of things you're working on, and when you expect to have completed them, and I'll be sure they are added to the final Roadmap. As always, if you have any questions, let me know. Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro a écrit :
I've compiled a list of features that we've discussed on the Koha 3.0 Roadmap: http://www.saas.nsw.edu.au/koha_wiki/index.php?page=KohaRoadmap3.0
OK, read & some lines added I've some question/comments about serials management (http://wiki.liblime.com/doku.php?id=kohaserialsspec. I havent' read carefully the complete document, that is fairly long & in english ;-) ) But reading the doc quickly, it appears to me that most of requested features are already here (although not fully mature for some of them, I agree) 1. Check In: registering status of issues (received, missing, late etc) => it already exists in Koha 2.2. Since 2.2.4, it also manages the unpublished & delete statuses. 2. Predicting “Publication Patterns”: system will know when an issue is expected => it already exists in Koha 2.2, with 10 frequencies available. Numbers can only be calculated on a numeric basis, but i already know how to add non numeric sequences ;-) (added to 3.0 RoadMap) 3. Monitoring subscriptions: Tracking of orders and financial management of all acquisitions, budgetary information, vendor information (Fund Management) => already possible, although some sentences are not clear to me (& not everything possible. I agree some features have to be improved) 4. Routing lists - circulating journals to staff => already in CVS head, but in a simple way (search borrowers in borrowers list, or add manually entries. The routing list containing whatever the library wants, as it is manual !) a little bit basic I agree. 5. Claims facility - when an issue is late or missing this should set up an alert and set in motion a claim for the missing item => in Koha 2.2, the library can see late issues from a given bookseller, print the list, that's something not too far from what is described. => In Koha 3.0, with the Letters system, we could easily imagine sending mails to whoever/when we want ! SO, MY QUESTION : ================= Has kohaserialsspec been written without searching what already exists in Koha ? I think the stuff needed to reach what is described in this wiki doc is not so much. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
Paul POULAIN wrote:
Joshua Ferraro a écrit :
I've compiled a list of features that we've discussed on the Koha 3.0 Roadmap: http://www.saas.nsw.edu.au/koha_wiki/index.php?page=KohaRoadmap3.0
OK, read & some lines added
I've some question/comments about serials management (http://wiki.liblime.com/doku.php?id=kohaserialsspec. I havent' read carefully the complete document, that is fairly long & in english ;-) ) But reading the doc quickly, it appears to me that most of requested features are already here (although not fully mature for some of them, I agree)
[SNIP]
SO, MY QUESTION : ================= Has kohaserialsspec been written without searching what already exists in Koha ? I think the stuff needed to reach what is described in this wiki doc is not so much.
No it was written knowing what was there. Its a specification of what is needed to make serials useful to a corporate library. When you write a spec you should write down all the features you need. Its not a list of what current koha serials doesnt do. Its a list of what it should do. Chris -- Chris Cormack Katipo Communications Programmer www.katipo.co.nz 027 4500 789
participants (3)
-
Chris Cormack -
Joshua Ferraro -
Paul POULAIN