Kohacon13/Hackfest

Just a place to gather some ideas for the Hackfest

Ideas for tutorials

• General overview of Koha code merely introducing more specialised topics which people have listed below (seeking volunteer) (Paul Poulain has led such brief tutorials at KohaCon hackfests in the past.)
  • Thomas Dukleth
• Git use with special attention to recovering from various git error states (interest was expressed in such a tutorial at a gathering late Tuesday 14 Oct.)
  • Thomas Dukleth
• dbix::class (Galen Charlton)
  • Katrin (interested in participating, being around on all days)
  • Tomas
  • Thomas Dukleth
• class::accessor (Chris)
  • Katrin (interested in participating, being around on all days)
  • Tomas
  • Thomas Dukleth
• Coding for Plack (seeking volunteer)
  • ...
  • Thomas Dukleth
• Zebra Basic Configuration (seeking volunteer)
  • Bob.birchall 20:16, 7 October 2013 (EDT) (attending all days)
  • Thomas Dukleth may be able to give some hints about following the Index Data Zebra documentaion for how to edit etc/zebradb/marc_defs/marc21/biblios/record.abs configuration for MARC based Zebra indexes or etc/zebradb/marc_defs/marc21/biblios/biblio-zebra-indexdefs.xsl configuration for XPath (DOM) based Zebra indexes but is not prepared to lead a proper tutorial.
• The Mechanics of Bug Squashing for Beginners
  • ...JD (interested in learning, I'm attending all days)
  • Petter Interested in learning; I'm new to Koha & Perl
  • Peggy Experience fixing bugs, but new to Koha

Ideas for presentations

• Koha and the semantic web
  • We (Petter + Robert) come from Oslo Public Library (www.deichman.no). At the moment we are evaluating Koha, and we will most likely recommend it and start the migration early next year. In our vision for a future-proof IT-architecture, all our metadata should ideally be in a semanticallly coherent and extendable format. This means that we want our catalouging to be done in RDF. If this sounds dramatic, I'll stress that we don't want to break any current MARC-related functionality of the systemm, but only extending the APIs of Koha so that we have good programmable interfaces into the system.
  • We hope this might be intersting for other members of the Koha community! (there is already a module to convert save biblio data as rdf, ready to go, I will show you this at Kohacon --Chris 03:21, 30 September 2013 (EDT))

Thats great Chris! We also need a way to do it the other way around; Converting the RDF into MARC and pushing back into the catalogue, I think maybe the Koha /svc/ HTTP API can be used for that. I've just started to explore the possibilities in Koha, and I'm eager to learn more:) --Petter

Ideas for discussions

• Where do we go from here?
  • I can't speak for anyone else, but the majority of my time is spent on a combination of bug fixes and enhancements. While some of these find their way back into the community, they are primarily based on the feedback and interests of individual client libraries (or our clients as a collective). However, it might be useful if we discuss ideas for how we want to move Koha forward as a community, and maybe talk about how we could spread the work around. I imagine that we all have plans about how to improve Koha but big improvements (like improving search or even doing code cleanup) aren't likely going to happen piecemeal. Perhaps instead of just working in our offices then submitting to Bugzilla and discussing there, it might be an idea to have strategic discussions as a group of developers. Perhaps this already happens with the higher ups or maybe the idea of a central strategic vision doesn't make sense for a decentralized community like ours. However, it might be a conversation that's worth having (David Cook).

• Going the packages way: should we change the 'standard' install? (Tomas)
  • The convenient way packages handle Koha instances and the handy set of tools provided raise this question: shouldn't we make the (most common) install methods converge into 'the packages way'? Maintaining only one codebase (maintenance scripts) and workflow might save us (lots of valuable) time and might let us focus on other stuff. Default configs and such differ too much from one isntall method and the other. Required QA tasks should get narrowed a bit with this move too. I'm not sure we could reach an agreement on this, but the discussion itself migt raise interesting POV on maintainability of the project.

Ideas for group work

• Get f*ng UTF-8 encoding/decoding problems solved at its source.
• Make columns.def translatable.

Feedback from Conference participants

We asked attendees to give us written feedback about what problems they run into, what bugs need to be fixed etc. Wishlist

Fix all the bugs!

... and save kittens doing so! Scoreboard