[Koha] Users and developers (was KUDOS - ALA Proposed Agenda)

vtl at scls.lib.wi.us vtl at scls.lib.wi.us
Sun Jan 24 01:28:45 NZDT 2010


I would like to say that I am in favor of pursuing this in one way or
another.  I do feel that bugzilla is more of a developer's tool.  Yes, I do
agree that we should check there to see if an enhancement has been suggested
before we do anything else.

But, for the purposes of pursuing shared development I think another type of
tool may be needed.  One that is intended for that purpose.

If bugzilla could become that tool, then someone should reply to the RFP as
Lori suggests.

But I think we would be foolish to completely ignore the opportunity we are
being offered to participate in this grant along with the Evergreen users.
What could be more open source than that?

2010/1/21 Lori Ayre <loriayre at gmail.com>

> Could be it isn't a good fit for the Koha community.  As I said, it is
> designed to fill a need for Evergreen which isn't currently using anything
> like this.  But even if no one here thinks it makes sense for Koha, perhaps
> someone could respond to the RFP with a Bugzilla-based solution!  That would
> be welcome.
>
> Lori
>
>
> On Thu, Jan 21, 2010 at 3:03 PM, Joann Ransom <jransom at library.org.nz>wrote:
>
>> Hi Lori,
>>
>> My understanding is that is what Bugzilla is designed to manage. Are you
>> suggesting this replaces bugzilla as the official Koha enhancement and bug
>> database?  As a user I really don't want to have to go to 2 different
>> places, and I am sure we are all aware of the strong feelings around forking
>> Koha, not juist the code here but the community tools which support the
>> code.
>>
>> Cheers Jo.
>>
>>
>> Lori Ayre wrote:
>>
>>> Hi All,
>>>
>>> As some of you know I'm involved as a consultant with both Koha and
>>> Evergreen projects.  One of the things that is being pursued by King County
>>> Library System as part of the IMLS grant they received is the development of
>>> an Enhancement Database.  The RFP is going to be "on the street" soon.  The
>>> concept is to create an online venue and set of tools to help people find
>>> out what others are doing with development and to find out what they WANT to
>>> do so they can chime in or join up in some way.
>>> Whatever is created could certainly be used by either project as it will
>>> not be Evergreen centric in any way (except possibly in the way that it
>>> relates to the Equinox team's development environment - since we're
>>> specifying that the product should be able to export specs to the
>>> development team once they've been accepted and funded ...or something).
>>> Anyway, just wanted to alert you to that.  I'll post it to this list (if
>>> you like) as soon as it is released (the RFP that is).
>>>
>>> Lori
>>>
>>> On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <skushner at mtpl.org<mailto:
>>> skushner at mtpl.org>> wrote:
>>>
>>>    Owen, MJ. Et. Al.
>>>
>>>    Didn't mean to start a minor controversy amongst the list. Let me
>>>    clarify what I meant.
>>>
>>>    Where I see developers and users at odds (or, a "disconnect, if you
>>>    will), is in the Request for Code Development process.
>>>    Right now, we are all operating like little "islands" where each
>>>    library
>>>    goes through a long "planning process" in which each library decides
>>>    what features that they absolutely need to see in Koha to operate
>>>    daily
>>>    and meet their patron's needs. Now, much development currently needed,
>>>    which is not yet committed, is very redundant, and what I'm trying to
>>>    suggest is that we all don't spend (and waste) time trying to
>>>    re-invent
>>>    the same wheel. Also, we can't really know what others are planning
>>>    right now for KOHA without communicating to them, before the RFC
>>>    process.
>>>
>>>    I see KUDOS as a place where libraries can meet and discuss the code
>>>    that they are "planning" to sponsor, before submitting to Bugzilla
>>>    (brrr..) ,or the Koha Wiki, so code development can be leveraged
>>>    before
>>>    being submitted, thereby making the process more stream-lined and
>>>    efficient.
>>>
>>>    Am I saying that developer's should be excluded from this process?
>>>    Absolutely not.
>>>
>>>    Am I saying that a KOHA USERS group is an excellent vehicle for the
>>>    USERS to communicate and further leverage the planning process and
>>>    development thereby making KOHA better. Absolutely.
>>>
>>>    That is my take on the value of a "USERS" group in KOHA.
>>>
>>>    If I am wrong, then, have at me....
>>>
>>>
>>>    Scott Kushner
>>>    Information Technologies
>>>    Middletown Public Library
>>>    -----Original Message-----
>>>    From: koha-bounces at lists.katipo.co.nz
>>>    <mailto:koha-bounces at lists.katipo.co.nz>
>>>    [mailto:koha-bounces at lists.katipo.co.nz
>>>    <mailto:koha-bounces at lists.katipo.co.nz>] On Behalf Of Owen Leonard
>>>    Sent: Tuesday, January 19, 2010 7:59 PM
>>>    To: koha at lists.katipo.co.nz <mailto:koha at lists.katipo.co.nz>
>>>    Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed
>>>    Agenda)
>>>
>>>    Okay, get ready for a rant...
>>>
>>>    > Sometimes "users" and "developers" are at opposite poles...
>>>
>>>    When? I'm a Koha user. And in using Koha I saw that I could make Koha
>>>    better, and in time became a Koha developer. There is no Koha
>>>    developer out there who is developing Koha features just because they
>>>    think it would be cool to do. Koha developers are doing their work
>>>    because they *see* a need, in an actual user or an actual library. Or
>>>    developers are getting paid by libraries to develop the features the
>>>    libraries need.
>>>
>>>    Here's when users and developers are at opposite poles:
>>>
>>>    - When a company decides to develop a feature that they think will
>>>    help sell a product, even though the feature doesn't meet any actual
>>>    need
>>>    - When a company throttles or cripples a feature in a product because
>>>    they want to charge extra for a particular feature
>>>
>>>    No self-respecting Koha developer or Koha support company is doing
>>>    that kind of stuff. That's why we're here.
>>>
>>>    > I think this is more about giving the "users" more of a voice than
>>>    they've traditionally had in
>>>    > the past, no?
>>>
>>>    I honestly don't know where this comes from. The Koha project is just
>>>    about as open and accessible as any software project can be. You can
>>>    participate on the mailing list, you can submit bug reports yourself,
>>>    you can submit your own patches or hire your own programmers to write
>>>    code for you. You can talk to Koha developers on IRC almost 24 hours a
>>>    day!
>>>
>>>    The only way in which one might consider that users need "more of a
>>>    voice" is if you think of it in terms of working collectively to
>>>    achieve a goal that Koha libraries individually could not. If that's
>>>    the intention of that statement then, rant over. I agree 100% that
>>>    libraries should be seeking ways to pool their resources ($$) to get
>>>    done the things they want done, i.e. hire developers or commission
>>>    existing companies to do work for them.
>>>
>>>    However, if by "more of a voice" you mean, "If we all get together an
>>>    ask for a feature the Koha developers should implement it," then no.
>>>    This is open source, but time is money. You can donate your time (as I
>>>    do, every day, in code, markup, email, and IRC) or you can donate your
>>>    money--in the form of paid development work.
>>>
>>>    This doesn't shut anyone out. But yes, there is a bar that you have to
>>>    clear. I don't know how else it can work.
>>>
>>>    So: Let's get together as users and/or developers and figure out how
>>>    we can get some stuff done. Let's put together a structure by which
>>>    Koha users can spec out new features and get them funded,
>>>    collectively. Let's put together a structure by which Koha users can
>>>    communicate with their vendors without fear of exclusion or reprisal.
>>>    Let's not talk about a users group breaking down some barrier that
>>>    isn't really there--let's talk about strengthening and leveraging the
>>>    connection that we *already have!*
>>>
>>>     -- Owen
>>>
>>>    --
>>>    Web Developer
>>>    Athens County Public Libraries
>>>    http://www.myacpl.org
>>>    _______________________________________________
>>>    Koha mailing list
>>>    Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>>>
>>>    http://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>>>    _______________________________________________
>>>    Koha mailing list
>>>    Koha at lists.katipo.co.nz <mailto:Koha at lists.katipo.co.nz>
>>>
>>>    http://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Koha mailing list
>>> Koha at lists.katipo.co.nz
>>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>>
>>>
>>
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>


-- 
Vicki Teal Lovely

Helping our 52 member libraries provide the best possible service to the
public.

Software Applications Supervisor
South Central Library System
vtl at scls.lib.wi.us
(608)242-4713
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20100123/56bfecd2/attachment.htm 


More information about the Koha mailing list