Hey Brooke, My perception is that you're coming at this from the perspective of a library who's downloaded Koha on your own, and who's been active in the community with respect to documentation and help on the various mailing lists, right? ie, you haven't signed up for support with a Koha company, and you haven't contributed or sponsored any code, right? BTW: I think that's just great, hats off to you for your continued involvement and community support, it's much appreciated and the community wouldn't be the same without you and others like you. However, things get tricky because as valuable as all those activities you do are, they don't do help motivate Koha developers to change add or improve code. This isn't the kind of open source community where we've got a bunch of volunteers contributing code out of the goodness of their hearts ... over 90% of Koha is done by programmers who work on Koha as a full time job (or two) to put meals on the table. Currently, the margins on Koha development are so low, many of us have to supplement our Koha development work with other services just to make ends meet. So from that perspective, the perspective of a starving developer, what are your thoughts on how we developers can both keep our stomachs full (not to mention mortgages, etc.), and fulfill the needs of users like yourself? Some kind of voting mechanism that gives a weight of voting based on dollars, and a commitment from the development community to tap that resource for sponsoring voted-upon features? It's a very interesting problem, and I'd love to hear your thoughts on how we might solve it. Cheers, Josh On Wed, Dec 17, 2008 at 11:00 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
Finally, I'd again like to point out that out and out removal of functionality is not a bug solution.
It may not be a solution for the feature, but it is a bug solution *for that release version*.
If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was fixed before something new was added to the core programme.
Easily said, but practically impossible to accomplish. And surely other users would prefer to have their favorite feature integrated into a release without waiting for every outstanding bug in unrelated, orphaned features to be addressed, especially if they are paying developers to accomplish just that.
If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely discussing things on the developer's list.
A poll doesn't matter much when there isn't code to back it up. I think it would be counterproductive to conduct a poll that suggests itself as a mechanism to accomplish something when in fact it is unrelated to accomplishing it. If the group being polled had a developer they could dedicate to the task(s), or even a set number of developer hours, then it would be a totally different situation.
Librarians other than me are very patient. One of my favourite things to relate in terms of new features is the 27 year bookmobile feature implementation. Yes, we're waiting for it. Yes, we've not forgot this year. Do you have it yet? No? When will you have it done? It's been a while...
I have no idea what a 27-year bookmobile feature is, but we have sizable libraries using the existing offline circulation code for their bookmobile transactions. I suspect this would work in your case as well. I hope you don't mean that you've been waiting 27 years for an implementation! (Koha of course hasn't been around half that long.)
The pickle is in telling us something will be done by a certain date and then not meeting that, OR in promising a feature that you never deliver upon, in which case we use our Awesome Powers of Nagging.
Heh. As fearsome as those powers surely are, in my experiments, they are not impressive to the perl compiler running our Kohas. Unfortunately.
I'm not sure what features/dates you are referring to, or who you think promised them. But in general, for a codebase that is moving rather quickly, I think the developer community has been reasonably pragmatic in its decisions.
--Joe
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS