[Koha] Community Feedback

[Joshua Ferraro]

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

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.

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


>> 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
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 at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS