Sponsorship Discussion

Unrecorded sponsorship discussion

  • Wiki and Koha Users list
  • Even the small projects should be posted somewhere so we can see all the projects – share among ourselves before we tell the vendor.
  • Use IRC to get status reports on where a development is in the process
  • Libraries, as sponsors, should add their sponsorships to a joint list, along with wishes and dreams and hopes – independent of vendors and developers (one line descriptions – RFC? wiki? koha.org?)
  • Ability to contact, collaborate – just need more communication and openness (different need)
  • From librarians for librarians (then link to the the developers wiki for the programmers)
  • Prior to sponsorship, get a more robust and thought-out feature and gauge need/demand (ranking feature) –
    • bugzilla enhancements (bugs.koha.org)
    • Encourage use of bugzilla
    • 234 enhancements in bugzilla at this time (clean them out and add new)
    • French ticket system – some copy/paste between the 2
    • Existing tool, allows CC, searchable > Give sample instructions ‘best practices’
  • Users group participation, be careful of not recreating the traditional ILS voting mechanism/model
  • How do we handle a situation where a library wants to get an enhancement from one vendor when they already have a contract with a 2nd vendor due to time constraints?  Galen’s not sure how it would be handled and would have to be looked at ‘case by case’ and eventually vendors may have unique areas of expertise.

KohaCon09 and Koha 3.2 and Beyond

Koha 3.2 – What’s in it? – Galen and Paul

  • New acquisitions module
  • Holdings support
  • Circ improvements – configure policy to nth degree!  Woo hoo.
  • Improve stability
  • RFCs – Request for Comments – proposals, ideas, statement saying what we want in terms of functionality
    • programmers, libraries, groups, etc.
    • “Wouldn’t it be nice if Koha had a module to dispatch the library policy to get rid of really obnoxious patrons”
    • Grand cattle call – Interested parties submit proposals, posted to wiki, evaluated and discussed, from chaos comes a list of goals for next release of Koha
    • Need to communicate what you are planning to do and then Do It.
      • We need to share our own list of RFCs on bugzilla or IRC or KUDOS or just on our site!
    • Not all RFCs are implemented – just proposals, not sponsored, tempis fugit
  • New Acquisitions module
    • developed by BibLibre for a customer, working to submit patches, review and testing prior to live
  • Holdings structure – WALDO/LibLime
    • Introduces ‘summary’ records to Koha – bib records and item records (OK for monographs, but bad for serials not so good) – bound volumes – add a layer in between bib and item
    • Support MARC format for holdings display – MFHD – from “holding” to “summary” > not MARC format not necessary, can pretend 842 doesn’t exist.  Optional.
    • How will koha serials subsystem work with auto checkin? Links to update summary statements – doesn’t tie into serials – have a summary record separate from the serial check in/prediction pattern
  • Proxy patrons, fines thresholds, callslips, recalls, hourly loans, email checkout slips – more WALDO circ enhancements
  • Circulate fines in days debarred, Alloy computing (www.alloycomputing.com – Stephen Edwards committer), place hold on multiple items (already up and running!)
  • No Fines – you are debarred a certain number of days, instead! (FRENCH IDEA WE SHOULD STEAL)
  • Hold policy and request improvements (NEKLS)
    • Architectural changes – less complex than imagined – biblio table and items table, adding summaries table that will be weakly linked to bib and items.  Indexing will be extended to include item and holds for zebra to index.
  • ReservsDirect integration with Koha (course reserves for academics)
  • OPAC Enhancements – the ‘pretty stuff’
    • Support enhanced content providers :: Syndetics, LibraryThing, Babeltheque and Tag multiple items
  • Cataloging
    • biblios.net integration – service and embed biblios editor into Koha
    • improve browse indexes – browsing name, title and subject headings.  Current not a ‘complete headings’ browse
    • ISBN 13 normalization – for searching, indexing and matching – index 10 and 13 digit numbers
    • Item bulk status change (GOOD!!!) – BibLibre and LibLime both working on this
    • Brief records, record maintenance and deleted records – WALDO :: attach workflow statuses to bib records (ILL and on the fly cataloging)
  • Serials
    • improved display and prediction pattern management
    • more control over display of recently checked in issues – WALDO
  • Administration
    • Jesse rocks – he fixed the sys pref editor (he’s young and brilliant and in a few years when he can drink, I’ll buy him one)
  • Reporting – improvements to guided reports – add placeholders and template variables (edit statements???)
    • Integer parameter – specify how many days you want to run
    • Save time of library staff, too.  “Makes for happier librarians”
    • We need to get the CKLS report specs in the works! (hope, pray, push at KEGGER)
  • Misc
    • Granular permissions (more) – ex. Tools
    • IE compatibility (WALDO)
    • Overdue report improvement (PISD)
    • OAI-PMH server improvement (Tamil) – metadata farming improvements, protocols, etc.
    • URL checker cron job (Tamil – France)
  • Time Line – not finalized – 3.1 release for testing in early summer :: 3.2 most likely to be late summer or early autumn (future rolls, not freezes > ?)
  • Version numbering system – odd numbers = bleeding edge (3.1), more complete = even (3.2)

Koha Unconference for the Developers – Holiday Inn Board Room this weekend at 8 am

Where are Sys Groups? – Proposed as mechanism to cleanly seperate branches, working with a customer to implement more functionality, but doing more.  Part of it will be in 3.2, some will be available by late summer per commitment to that customer – will it go to 3.3?  Governed by the calendar.

Beyond 3.2

See twitter Search for Kohacon09

People –

  • RM, QA, Docs – ability to take on the task, endorsement, IRC election – “Usually only one person is crazy enough to volunteer” – Chris
  • Being a Manager, requires neutrality – reject patches, etc. if they break things – observe neutrality in respects to the source (commercial v. independent)
  • Koha developed by its users from the creation in NZ in 1999!  Exploded in India, China, North America, Europe and South America – will this lead to more formalized management??  Users Groups (France & US) – lots of interests to balance.

Specs and RFCs –

  • What bugs squashed? What enhancements made? OUR QUESTION – If we’ve contracted with LibLime to write code and there is independent development happening at the same time, do we pay for that or get a refund??
  • In-between projects
  • Galen recommends that KUDOS NOT work on the proprietary vendor model of user groups.  I would say, know that with Koha we can get an independent contractor/programmer to give us what we want!  Whoever contributes the code, has the most say!  Ask for something or find someone to Do it!  Band together to sponsor.
  • Avoid a split between the developers and the users/librarians.  Nag with money…and impress with contributions (and American Peanut butter not found in New Zealand grocery stores.)

Koha Project Time Line

  • RFCs – schedule developed by RM
  • Wheeling/dealing – input of users groups, vendor clients, developers, funding arrangements
  • RM elected – roles filled
  • Other roles
  • Proposed timeline: interim :: alpha :; beta :: translations :: production :: still more translations
  • Story of a new Feature: Specifications/requirements :: testing :: Contributed to project :: warm fuzzies
  • Head v. Maintenance version – 3.0 will be maintained for about a year after 3.2 is released and many libraries will continue to use ‘old’ versions.  Then a ‘tapering down’ process.

What’s next? 3.4 / 4.0?

  • More features? New architectural revisions? major new features? Still up in the air and debated during developers session over the weekend
  • Users are always dissatisfied (as are good programmers).  New workflows, new features, new interfaces…
  • fashion and impetus
  • RDA (maybe yes, maybe no) (RDA is?? Please fill in for me) ::Linked data :: dismodulation :: OLE :: Web Services
  • Swiss army chain saw (aka PERL) – aquabrowser, viewfind > have libraries put together systems that talk amongst self.
  • Needs:
    • Electronic Resource Management (for academics)
    • Consortia – Koha supports, but many models to accommodate – databases talking together and single database with various types of libraries
    • Resource sharing – trend and economic reality
    • 4.0 – architeture :; mod_perl :: memcached :: moose (up and coming PERL thing)
    • Interfaces:  SIP2, RFID, EDI for Acquisitions, Jangle project interaction (glue together different ILS for resource sharing – ILS talks to Jangle, Jangle translates and talks back to different ILS – research project at this time)

KohaCon09 Day 2

Poor Chris is voice-less.  Be kind to him and use sign language.

Under the Hood with MySQL with Joe Atzberger

  • Keeping kohasructure.sql in synch with mysql/updatedatabase.pl defines your Koha version (version number)
  • We need read only access (command line) to our database – so we can see ALL 125 tables and how they relate!
  • Tools – phpMyAdmin, MySQL Admin or Query Browser (free), or OSS
  • Design principles: limit dup values, put related data together, proper data typing, keys and indexes
  • Bib Data Problems – MARC not a relational design, has limits on record dimensions and performance implications
      • Legacy code and data – UNIMARC v. MARC21 issues
      • FRBR, holdings, bindings, serials (bound periodicals) – when / where will FRBR be implemented?
  • Core Tables: SysPref (key) :: Branches (most referenced by other tables & hard to delete) :: Borrowers (staff & patrons) :: Biblio (title level) > Biblioitems (marc & marcxml going away soon / historical & query speed – in future avoid “*” queries) :: Items (barcodes)
  • Parallel tables: deletedxxx or old_xxx: old_issues, old_reservese etc.  Inactive transactions are copied off to the old_issues table (b/c high volume)  Joe says we need more for high volumne transactions – same structure, but different constraints.  Need an “old_fines” – Ryan working on the fines issue – pending as active, historical as “old” –
    • Look at deleted borrowers table for ‘missing’ patrons
  • Black Magicks – marc_subfield_structure and marc_tag_structure – allows for MARC21 & UNIMARC (on the fly)
  • Paul covered Structure, Nicole handled queries – what’s left?  Pretty DB Scheme Picture

Looking at the Circ Wizard generated SQL statements and there are multiple!  I have no idea if this can be transferred to the SQL report builder.