<HTML>
<BODY>
Salve!<br>
<br>
>>Finally, I'd again like to point out that out and out removal of functionality is not a bug solution. <br>
><br>
>It may not be a solution for the feature, but it is a bug solution *for that release version*. <br>
><br>
<br>
<br>
I respectfully disagree. It's like a doctor saying that you'll need your leg amputated before trying physical therapy.<br>
<br>
<br>
<br>
>>If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was <br>
>fixed before something new was added to the core programme. <br>
><br>
>Easily said, but practically impossible to accomplish. And surely other users would prefer to have their <br>
>favorite feature integrated into a release without waiting for every outstanding bug in unrelated, orphaned <br>
>features to be addressed, especially if they are paying developers to accomplish just that. <br>
> <br>
<br>
<br>
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. <br>
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.<br>
<br>
<br>
><br>
>>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 <br>
>>discussing things on the developer's list. <br>
><br>
>A poll doesn't matter much when there isn't code to back it up.<br>
<br>
<br>
<br>
So you'd prefer to develop in a vacuum?<br>
<br>
<br>
<br>
> I think it would be counterproductive to <br>
>conduct a poll that suggests itself as a mechanism to accomplish something when in fact it is unrelated to <br>
>accomplishing it. If the group being polled had a developer they could dedicate to the task(s), or even a <br>
>set number of developer hours, then it would be a totally different situation. <br>
> <br>
<br>
<br>
There are developers on this list as well. Why would anyone want to pay for something they've no say in?<br>
<br>
<br>
<br>
>I hope you don't mean that you've been waiting 27 years for an implementation! (Koha of course hasn't <br>
>been around half that long.)<br>
> <br>
<br>
<br>
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.<br>
<br>
<br>
<br>
>I'm not sure what features/dates you are referring to, or who you think promised them. But in general, <br>
>for a codebase that is moving rather quickly, I think the developer community has been reasonably <br>
>pragmatic in its decisions. <br>
><br>
<br>
<br>
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.<br>
<br>
Cheers,<br>
Brooke
</BODY></HTML>