On Wed, Dec 17, 2008 at 12:23 PM, BWS Johnson <mhelman@illinoisalumni.org> wrote:
Salve!
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*.
I respectfully disagree. It's like a doctor saying that you'll need your leg amputated before trying physical therapy. Sigh ... I can't even count how many ways it's NOT like that.
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.
The prevailing attitude in this community prior to arrival of LibLime was that features and Libraries would not be orphaned and left high and dry. I used to be very proud to go out and speak to others about the quality of the programme and the compassion of the community. The more I see the attitude that if you're not a developer, we don't care what your opinion is, the less likely I am to recommend it to a friend. The Koha release date has nothing to do with a custom contract that LibLime promises to a paying customer. A solution is easily bundled and shipped out to that client. LibLime's lack of planning is not my emergency, nor are their vendor promises. You seem to be aiming a lot of your frustration at LibLime. I'd argue that we've done a very good job promoting just the spirit you're saying the community is known for. I think we've specifically planned for that, and have aired topics for discussion to plan for just that type of project. I wonder why you think we have a lack of planning, from my POV, it's quite the opposite.
It isn't practically impossible to fix what's broken, it'll just take time. It's better to wait longer, schedule things out with a longer lead time, and have a better product at the end of the day then to have a Frankenstein's monster of features since there's this silly notion that stuff has to be done quickly. I fail to see why nagging problems, like acquisitions, cataloguing, the installer and spine labels aren't being given a better once over between releases to get them user friendly and nearly bug free. There's been progress, but there's a lot of traffic on the list for the same errors year in and year out. How is this beneficial to anyone? I'm aware that folks like MJ are all over QA, and I very much appreciate that. When the roadmap is set, just factor more time in. I've seen some of this stuff slated for next week or next month with an initial feeling that it would take much longer. Why put yourself through that? Better planning will avoid folks getting impatient. This is over on the other thread, where this started, before you changed threads on me, so I'll paste it in again:
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 -- 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