[Koha] Community Feedback

[Marijana Glavica]

Brooke, 

I take Koha as a gift. I test it and use the features that work. 
I don't expect it to work perfectly, Koha or any other free software.
If Koha loose some important feature in the future, I will not 
upgrade until I find someone who will fix it - that could be some 
payed programmer, or someone who is doing it from hart.

It would never come to my mind to complain on the community list.
I feel welcomed here to ask for help. Being impatient doesn't help you, 
and annoyance can seriously damage developer's motivation.

And about planing... I consider planning in free software more as
goals setting. Also it never came to my mind to complain about not 
being on time. I can not make plans in my library depending on planed
feature of Koha. Again, if I need the feature and can not wait, I will 
pay someone to do that.

For now we didn't have some extra development for Koha (just some minor, 
very specific changes in templates), but we are implementing functions 
step by step, so probably, I hope, in the future there could be some 
code contribution.



Marijana


On Wed, Dec 17, 2008 at 09:23:58AM -0800, BWS Johnson 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.
> 
>    >>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.
>    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 im patient.
> 
>    >
>    >>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.
> 
>    So you'd prefer to develop in a vacuum?
> 
>    > 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.
>    >
> 
>    There are developers on this list as well. Why would anyone want to pay
>    for something they've no say in?
> 
>    >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.)
>    >
> 
>    Nope, but I knew people that did on a different ILS. Koha develops much
>    more rapidly than other ILSs, which is nice. But I'm now worried about
>    losing quality. We've a nearly mature product now. I think some real time
>    in thinking over what we do in Release 4 or later is warranted. I truly
>    believe that that has to happen _here_ and not solely on the developer's
>    list. I'd like to see things work out of the box for different Library
>    sizes and types.
> 
>    >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.
>    >
> 
>    There were numerous release dates slated for 3 that I feel should have
>    been scheduled for further in the future. As a result, numerous dates that
>    were slated on the roadmap were not met. It would have been better to just
>    set the date for release further in the future than to have to scrap the
>    date time and again. I know I was getting antsy for release after 2 or 3
>    of them were missed. I realise that the codebase is moving rather quickly,
>    but if that's disorientating to users and developers alike, then perhaps
>    it's time to put on the brakes a bit.
> 
>    Cheers,
>    Brooke

> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha