KohaCon12: Making Koha Even Better

by Nicole C. on Jun 7, 2012

MJ Ray was up next at KohaCon and talked to us about making Koha even better. He started with how we tell people new things get in to Koha:

• Put a request for comment (RFC) on wiki
  • RFCs are rarely written and if they are they’re not commented on
    • MJ showed us a page on the wiki that I couldn’t find (until he told me where to go) … there is an RFC category but I think things are organized poorly because he’s looking at a different RFC category page than I have been
• File an enhancement bug report on bugzilla
  • Enhancement bug reports are submitted but the sponsored tag isn’t using right. Some of them have been there since 2009 and marked as sponsored.
• Send email to koha-devel list
• Start sending patches or branches or …

And now things actually get in to Koha:

• 1 library hires 1 developer for 1 task
  • Sometimes in this process they follow the above steps as well (particularly the bug reporting since the RM requires one of those for each patch)
• … or a group goes away with Koha makes big changes, then comes back and offers them to the community
  • meanwhile the community has moved on and the product has changed significantly
• … or people just flat out beg for features 🙂

Always remember that free and open source software has professors and “Professors can find a correct answer to any question … given sufficient time to find the answer” so what’s the answer to our disorganization problem?

Why doesn’t the above work? Why doesn’t asking developers for big features and having one library pay one developer for that feature work? Because that forgets the “open” and the “collaborative” nature of open source and Koha.

What we need is to get more developers collaborating. We want more libraries sharing in innovation (something that we have seen at ByWater in recent years – but could do it on a bigger scale). And we want that all to be done with the community’s feedback/help/etc.

What can we do with what we have to improve things? A while back, MJ would put in the RFC roundup in the newsletter – featuring rfcs on a specific module, but it didn’t really get things moving.

One site MJ showed us was Pledgebank, a crowdfunding-like site for getting people to collaborate on features/developments for Koha (and it’s open source so we can create our own for Koha). Other groups have a “bounty” type program where they put bounties on specific bugs to get them fixed. Basically a reward for fixing bugs. We, however, are a more friendly community than those that do this kind of thing.

So … what answers do we have? How can we make this work?

I asked about using a crowdfunding site because libraries often need a paper trail and/or an RFP in order to give money to a development. Lee brought up a good point – she (as a library director) can’t donate money to Koha or to a vendor, she needs to have an invoice that she can show the powers that be, she has to pay for something specific. Colin added a good point – we’re not traditional vendors – we’re not selling software it’s not the same as the traditional model. We are selling services, so having people give us money to update or clean up the software is part of our services (maybe that can be the line item). Irma brought up a point as well – libraries belong to associations and pay those dues each year, so maybe paying a Koha association of sorts could be the line item on the budget and we (the community) can use it to develop/clean up/add to Koha. MJ said that Pledgebank is actually not a site that collects money and as such might get us what we need – people promising money and then we can write the necessary documents for them to send the money.

Kyle asked if maybe we should move the RFCs to the bug tracker instead of the wiki since the wiki is so free form. MJ says that that makes it hard to edit the RFC and update it as comments are made, but Paul pointed out that most of the enhancements that he pushes are on bugzilla but not on the wiki. So maybe since this is the way we’re doing it now it should just be that way.

A discussion of patches and what gets signed off came up next. Sometimes patches can sit for months and months with no sign off because it’s not exciting enough for people to test. MJ says that he tries to sign off on other’s patches so that people will sign off on his – but how do we choose which ones to sign off on?

Chris said that one possibility is to open up a store online to sell Koha branded products so that we can raise money for projects that benefit us all – like a code clean up project.

The discussion continued, but no decisions were made yet, but hopefully some seeds have been planted and we’ll see something come up someday soon.

[tags]koha, kohacon12[/tags]