[Koha] Community Feedback

[BWS Johnson]

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 impatient.


>
>>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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20081217/c6bd558c/attachment.htm