Answers of the poll “Ready to help the Koha community?”

Here are the results of the poll «Ready to help the Koha community?» launched at the beginning of the 17.11 release to estimate the task force we could expect and to delimit the tasks we can focus on, depending on the wishes and needs of everybody. If you did not answer the poll yet, you can still do it, I will update the results.

Raw results

We got 54 answers so far, 38 from support companies, 8 from libraries and 7 volunteers.

50 out of these 54 announced they will have time to help during the 17.11 development cycle.

Who are you?

Support company 38
Library 9
Volunteer 7

Will you have time to help during the 17.11 development cycle?

Yes 50
No 4

How would they like to help?

Most of them are willing to help on testing bugs or write patches.

Test bugs (signoff) 36
Write patches – bug fixes 23
Write patches – enhancement 18
Write documentation 15
Translation 15
Help new contributors 11
Improve the wiki 10
Code review (QA) 8

Tasks they are willing to help on

Further improve our already great documentation 19
Elastic search 18
Make our tests suite even more robust 11
Refactoring 10
Cache more things to improve performance 9
FRBR, BibFrame 9
Remove all the SQL queries to become DBMS agnosticism 8
Finish what has been deprecated earlier (non-XSLT view, GRS-1) 6
Get rid of CGI emulation and move to a Plack app 6

Tasks they would like to see moving forward but they cannot provide help

Cache more things to improve performance 15
Get rid of CGI emulation and move to a Plack app 14
Elastic search 13
FRBR, BibFrame 12
Make our tests suite even more robust 8
Further improve our already great documentation 7
Remove all the SQL queries to become DBMS agnosticism 6
Finish what has been deprecated earlier (non-XSLT view, GRS-1) 6
Refactoring 5

How many people will be ready to help?

They reported 83 people to dedicate 1003 hours per month to the Koha project.

How many people will really help?

I have no idea.

Other requests/notes ?!

«Make Koha WCAG 2.0 AA compliant ( – See European Commission Study on Assessing and Promoting E-Accessibility ( We believe that this is somewhat standard legislation in every EU country. We would like to contribute to the main source-code by fixing all the issues necessary to make Koha WCAG 2.0 AA compliant (starting with the OPAC). However, we would like to have strong a commitment from the steering committee and from the release team that these contributions will not be forgotten on a subsequent release. This means adding to the release checklist a verification step that makes sure that all modified and newly included pages are checked for conformity.»

I have created a new entry on the kanban. If you are interested by contributing, let us know. If you have a plan for this task you can propose you as leader to let us know what is it and to coordinate the different tasks.

«Bug 12599 – IndependentBranches Holes»

As there is already an entry in our bug tracker you should tell us by letting a comment. However it seems that the lack of founding is blocking this enhancement request.

«Bug 7317 – Add an Interlibrary Loan Module to Circulation and OPAC»

Several people have show interest in this feature. There is a card on the kanban already. I have CCed everybody that is willing to help. Do your best to make it into 17.11!

«Auth Rewrite to use Plack Session»

This is a big task and it sounds like we will need a plan and volunteers to work on this one.

«Better support for environments with more than one language (multilingual authorised values)»

Yes that would be great. The ground is ready to welcome new feature, now we need funding I guess to continue.

«Write documentation in my language»

There is some work done to make the new Sphinx based manual translatable, please keep your eye on Editing the Koha Manual, Koha Manual and the mailing lists. We also need help in updating the manuals with the latest features, so that they are ready for translating!

«I would be happy to start updating the manual»

Same as previously, see Editing the Koha Manual and I guess you may want to follow the relevant epic to know what you can help with. We will add new entries to this epic to ask volunteer to write the missing documentation.

«Test the Beta system before release»

Even more useful would be to test it all over the release, but yes we absolutely need people to test the Release Candidate when it is out. The release will be frozen few weeks before the release and we will need you to test it deeply to make sure it will be released as stable as possible.

«Please make the Advance Catalog module RDA compliant!!!!!!»

The catalog is already RDA compliant.

«The Acquisitions seems to need some bolstering in order to properly handle medium to larger size library systems»

Yes indeed, the acquisition module is messy and would need to be rebuilt. Funding will certainly be needed here…

«I’m not sure to be able to provide help for Elastic search. I will need special environment to test (not sure it would be possible on sandbox?)»

You can test it easily if you install KohaDevBox. But yes we will ask for a support company to provide a test server.

«Suggest new features»

Yes please! You can suggest new features and enhancement on our bug tracker. Search a bit before to make sure the request has not been done yet.

«Would love to see performance without Plack improved (SQL queries, caching etc. The scripts are by far the biggest culprit when I look at performance and timeline)»

Plack is required since few versions. You should not use recent versions of Koha without Plack and Memcached enabled. Given the answers from the poll it seems that we still need to focus on performances (even if it has been a main goal since 3.18).

«I’ve come to notice that waiting times for signoffs and QA together with 6month release cycle makes it harder to convince people to always post upstream. Also sometimes patches that are critical for a library can get stuck in discussions. I’m interested in ways of resolving these issues in the future.»

You have several ways to alert the whole community on a specific problem. The first one is to answer by commenting the bug report, then to send an email to the ML to get other people’s opinions. If you do not get answers or the discussion is stuck you should bring the problem to the next general or dev meetings.

«My experience with Koha is based on the training topics in the use of its modules and tools, I do not know programming skills, but I would like to collaborate in some way in its development, I was attentive to any concerns” “We have been using Koha for a year and would like to start contributing to the community. We are ready to code but can help in any other way.” “Unfortunately I am not a coder but happy to help documentation though.»

Welcome! We have reviewed and updated our wiki pages to let you know how to get involved, depending on your skills and wishes.

«Provide feedback from library point of view, new requirement for libraries those are not yet included in Koha»

It is a big lack in a development process, we do not get enough feedback from library point of view. You are more than welcome to do it. You can also see the different bug reports we have in the “In discussion” status, most of them are stuck because of the need of other opinions

«In the past I tried to setup a kohadevbox to possibly signoff bugs. But I was a total failure and in the end I was totally frustrated about the signoff process. I would be willing to try once more since I see you still need people who signoff patches – but I’d need some assistance when trying to tame and understand the kohadevbox. There are many more things to say but I’m afraid noone wants to hear them ;-)»

You should try again from scratch following the documentation of KohaDevBox. Tomas is going to write a wiki page about it to explain how it works. If you have any questions or issues about how to install or use it, you should join us on IRC and ask.

«We have observed that technical issues have given so much importance rather than library related issues. Does Koha for technologists? Does Koha for IT developers? Both the cases, the answer is ‘No’. Koha is for library users for better access of library materials. Those issues come into surface are most of the cases nothing to have any importance in libraries of Indian Subcontinent. The users here want the document in AACR2 format which is very much ignored in Koha. There are several items in catalogue code, but only one place of ISBD in Global Systems Preference. Users requirements are to print catalogue card, transliterate of title and other field for having better search options, AACR2R format for different items, preparation of reference entries very easily, generation of library clearance certificate from Koha, using SMS service with ease. Much emphasis has been given to release newer and newer version but ignoring different issues arise in the earlier version. Do you think every 3-6 months release of new version of Koha is helpful for libraries already using Koha? We don’t think so. We think, more important is to stabilize a particular version as early as possible and for a library already using Koha, running behind and upgrading to different new version is not desirable all time at all. Again, our observation is that new release or bug fixing may be based on sample testing not profound testing of at 20000-30000 database, e.g. when we upgrade 3.18 to 3.20 version a lot of bugs came into surface. Why this would be so? So you may think of the issues. These are the opinions that may not have any ‘technological’ value to you, but these are totally based on librarians’ opinion from libraries of Indian Subcontinent. If you need our help, inspite of all our limitations, we are willing to help.»

There is too many points to answer all of them one by one completely here. I would suggest you to start to discuss about your needs on the ML to see if others have the same as yours. As I already said earlier we are lacking librarians point of view. A major version of Koha is released every 6 months, but you do not have to upgrade every 6 months, we use to support the last 3 versions, so you could upgrade to the next major release every 18 months if you like. We are doing our best to make the releases as stable as possible, but unfortunately we are lacking testers during the development process and sometimes the issues are raised by users, in production (like any softwares). The issues you occur during the upgrade are not expected and should be reported on our bug tracker. Yes we need you to help!
First you need to report the blocking issues you occur, then you can initiate the discussions with other librarians on the mailing list. On my side I will do my best to make the next release error-proof and consolidate our testing suite.

«We also have a number of paid developments that we will be working on. Our path is to write code, submit it to community and assist with sign-off. And then once it’s pushed and released, it makes its way back to our customers.»

Awesome, you understood how a free software community works!

«We love Koha!»

We love you too ❤

What’s next?

If you want to be involved in the Koha community you should subscribe to the Mailing list if it is not done yet, then read the “What’s on in koha-devel” emails.

Attending to both general and dev meetings is a good way to discuss subjects. Then I invite you to join us on the kanban board I have created for this development cycle release. If it is not done yet you should contact me and I will send you an invitation. Once you are on it, feel free to add yourself as “watcher” of the “Epics” you want to follow.

To know how you can help, take a look at the Getting involved page.

Everything related to FRBR, BibFrame, etc. will be managed from thefrom the kanban kanban. I would like to see a working group around these important topics to tell the developers what need to be done to get an overview of the situation. With 80 people ready to dedicate 1000h per months to the project, we could make great things.