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
Salve! that release version*.
If it were bugged, then I as a user would like whatever bug (or more
I respectfully disagree. It's like a doctor saying that you'll need your leg amputated before trying physical therapy. 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.)
I'm not sure what features/dates you are referring to, or who you think
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. 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
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
OK, and reading this a bit more carefully, here are some specific responses to your commentary: On Wed, Dec 17, 2008 at 12:23 PM, BWS Johnson <mhelman@illinoisalumni.org> wrote:
It isn't practically impossible to fix what's broken, it'll just take time. It takes more than time, it takes people. Specifically, developers. And developers need to eat.
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. The reason is that none of the developers in this community get paid a salary to work on it. That's the bottom line. The librarians get paid a salary to use the system, and presumably that gives people like you some time to spend doing great stuff like documentation, etc. But us developers don't have salaries outside of our Koha work, so we only have time to work on stuff we're paid for, it's as simple as that.
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. I agree it's about planning, but there have to be resources in place to plan with. You can't build Rome in a day, I agree, but you certainly can't build Rome at all if you have no skilled workers.
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? Not at all, and that's not what's going on. Developers aren't just
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? The point Joe's making is that it wouldn't be fair to give people a
Now what do you mean MJ is all over QA. Can you point to some specific patches or emails, I just don't know what you mean. My perception is that most (all?) of the QA work has been done by Andy and Galen. paid to do whatever they want, we're handed specifications from users such as yourself who are sponsoring specific enhancements or functions. These specs are typically shared with the community using the RFC process, which I'm sure you've seen happen time and time again on the koha-devel list if you're on that list. poll which is essentially a 'voting mechanism' for what they want to be done, if we don't have the resources (people) to do it.
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. As would I, and I do think the user community should definitely be more actively involved in development, so we agree here.
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. Again, as the RM, I can speak to this specifically. I was dealing with a very limited number of resources for 3.0. What I mean by that, is that I didn't have much to work with w/respect to number and time on the part of developers except for developers that worked at LibLime. We invested a ton of our own resources into 3.0 features that our customers don't directly benefit from, but that we felt were important to the health of the community. The Translation Framework is just one example, there are dozens.
3.0 quite literally nearly bankrupted LibLime, I kid you not, and it was precisely because we spent so much energy making sure that 3.0 was truly stable, and accommodated as much as could be preserved from past versions. It's shocking to me that you're accusing us of the thing we worked so hard to prevent. 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
3.0 quite literally nearly bankrupted LibLime, I kid you not, and it was precisely because we spent so much energy making sure that 3.0 was truly stable, and accommodated as much as could be preserved from past versions. It's shocking to me that you're accusing us of the thing we worked so hard to prevent.
I'll add I can well believe this - being RM costs a lot for the organisation doing it. The comments about things not being committed back - from my POV anything not done by us would have been because we ran out of resources to do it rather than any desire to hold some code as "private". How to maintain major bits of functionality that only a few orgs use is a dilema - we ran out $$ to do it for both versions of acquisitions, although now there may be more who want it, and some of the core stuff has stabilised, so it is less of a moving target. Cheers Rachel
"Joshua Ferraro" <jmf@liblime.com> wrote: [...]
Now what do you mean MJ is all over QA. Can you point to some specific patches or emails, I just don't know what you mean. My perception is that most (all?) of the QA work has been done by Andy and Galen.
Maybe in the main repository but that's mainly because we have no access. I'm doing a hell of a lot of QA for customers and friends (probably 90% QA and 10% development which is not how I want to be working) so we've a very stable local koha branch but the changes have not been getting pushed upstream quickly because we felt our funders' priorities (usually stability) and the koha.org release managers' priorities (usually new features) seem different enough to make that difficult and I hate trying to negotiate with LibLime developers when I don't have enough resources to do it well and now apparently I've broken TTLLP's public repository so people can't even pull from there (not that any release managers have ever seemed interested in that) and there just aren't enough hours in the day because...
3.0 quite literally nearly bankrupted LibLime, [...]
while the same isn't true for TTLLP (as I understand it, it's very very difficult to bankrupt a cooperative), 3.0 has put us in a Very Bad Place that we're only just fully recovering from. I haven't even had time to read koha list mail more than once a week lately. Oops - the above sentence was too long but hopefully you get my drift. As for user-led (rather than customer-led) development, I'd like to see users gather themselves into a user cooperative and give money to it and then vote on what tasks to buy with that money. If any users are interested and need help finding their local equivalent of Somerset Cooperative Services, CDA Anywhere, NCBA or such, email me, IM/jabber me, or so on. Hope that explains, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
"Joshua Ferraro" <jmf@liblime.com> wrote: [...]
Now what do you mean MJ is all over QA. Can you point to some specific patches or emails, I just don't know what you mean. My perception is that most (all?) of the QA work has been done by Andy and Galen.
so we've a very stable local koha branch but the changes have not been getting pushed upstream quickly because we felt our funders' priorities (usually stability) and the koha.org release managers' priorities (usually new features) seem different enough to make that difficult mmm... 1- our funders never request more stability, they request new feature. 2- The branch 3.0.x is the stable one. No new feature is added. where's
MJ Ray a écrit : the problem with this one to send patches ? Henri-Damien, as RMaint, take care of all the patches that are submitted for 3.0.x -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
paul POULAIN <paul.poulain@biblibre.com> wrote:
so we've a very stable local koha branch but the changes have not been getting pushed upstream quickly because we felt our funders' priorities (usually stability) and the koha.org release managers' priorities (usually new features) seem different enough to make that difficult mmm... 1- our funders never request more stability, they request new feature. 2- The branch 3.0.x is the stable one. No new feature is added. where's
MJ Ray a écrit : the problem with this one to send patches ? Henri-Damien, as RMaint, take care of all the patches that are submitted for 3.0.x
The problems are that we forked somewhere during the 3.0rc series and are only now converging again; and that I broke our public-facing repository somehow. We will converge and will repair and will start sending patches again, but as noted in 1 above, our priorities differ. Regards, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Brooke -- I don't even think we're talking about the same thing anymore. Versions will differ, and if you prefer an old version for its featureset or the specific implementation of a given feature, then stick with that version or please work to port the code over. No substantive feature has been deprecated capriciously. Indeed, bugs are sometimes introduced with new architectures and compromises between competing designs can alter requirements, interfaces or functionality. But this is normal to any developing project. The point was already settled in the other thread that aspects of the HLT acquisitions implementation in question never made it to mainline Koha. As far as that goes, it was not "broken" or taken out: it was never there. So we're not talking about the same thing. I don't blame Katipo or Chris or HLT or anybody else, because managing customizations vs. mainline code can get complicated, especially using the version control systems of that time, with limited professional and community resources, etc, etc. Similarly, I'm not going to argue LibLime's business practices to you in this or any other thread. In the end, for the Koha project, the best code coming in wins. I have yet to see a situation where code that was better for *all* Koha users was rejected in favor of inferior code. It doesn't matter who wrote it, or whether they were paid, by whom, or how much. This includes situations where my own code was rejected as inferior! --Joe Atzberger
On Thu, Dec 18, 2008 at 8:06 AM, Joe Atzberger <ohiocore@gmail.com> wrote:
Brooke --
I don't even think we're talking about the same thing anymore. Versions will differ, and if you prefer an old version for its featureset or the specific implementation of a given feature, then stick with that version or please work to port the code over. No substantive feature has been deprecated capriciously. Indeed, bugs are sometimes introduced with new architectures and compromises between competing designs can alter requirements, interfaces or functionality. But this is normal to any developing project.
The point was already settled in the other thread that aspects of the HLT acquisitions implementation in question never made it to mainline Koha. As far as that goes, it was not "broken" or taken out: it was never there. So we're not talking about the same thing. I don't blame Katipo or Chris or HLT or anybody else, because managing customizations vs. mainline code can get complicated, especially using the version control systems of that time, with limited professional and community resources, etc, etc.
Just to clarify this bit. There was a version HLT were satisfied, it was in 1.0 ... it remained in a version they were satisfied up through and including 1.2.4. Then it got broken, I think around the time MARC storage in the db was added (lots of things got broken). HLT didnt upgrade to 2.0.0, but waited for 2.2.x Where acquisitions was fixed for them, but parts of that fix must not have made it into the code repository. This was before Liblime existed. So it's fair of them to say they never saw a working version. So 2 problems, 1 a feature got broken (it happens), and 2 the fixes didn't survive/make it into the 3.0.0 code base. Chris
BWS Johnson <mhelman@...> writes:
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.
I have not found this to be true. The quality and stability have been good. The support has been good, and Koha has been cost-saving for us. In some respects, Koha 3 has shaped up to be *too* good! About any decent techie can download it and follow simple instructions to install it, and then you have a full-featured ILS. Our library saving many thousands of dollars by using Koha is also a good thing, and it has run very stable for us. All Koha users owe something to the project, be it time, support, funding, or just thanks to the people doing the hard work (yes, even if paid, it is still hard work).
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. The quality has certainly improved from release to release. As the software grows more complex, this is more difficult. Koha 3 is a quality release.
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. Sure, but at some point someone needs to say: "OK, it's a wrap" and then you have the latest version. One cannot proceed forever. A release number is just a number. Sure I would have liked to see some of the features of Ubuntu 8 in Ubuntu 7, but at some point they had to say "It is done, it is officially Ubuntu 7, now on to 8!" Koha is perhaps one of the biggest innovations ever for the library world. We could all do more to support it. And one important way is "support!" Even if funding is low, and time is minimal, one can just say that this is software with merits and it should be seriously considered, not rubber stamped, just considered. That is all. If you are looking for perfect you will find none if you deal with *any* software. Koha is good and has helped many libraries. The programmers work very hard and should be supported. I officially thank the people who work every day on Koha, all over the world. Keep up the great work! -Darrell Ulm
participants (9)
-
BWS Johnson -
Chris Cormack -
Darrell Ulm -
Joe Atzberger -
Joshua Ferraro -
Marijana Glavica -
MJ Ray -
paul POULAIN -
Rachel Hamilton-Williams