Koha Test Wiki MW Canasta on Koha Portainer

Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.

For the current Koha Wiki, visit https://wiki.koha-community.org .

Kohacon13/Hackfest

From Koha Test Wiki MW Canasta on Koha Portainer
Jump to navigation Jump to search

Just a place to gather some ideas for the Hackfest

Ideas for tutorials

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