[Koha-devel] Re: MyLib Next Steps (fwd)

[Pat Eyler]

I'm forwarding this off of the MyLib list because I think the conversation
is worth holding on our end too.  I'll forward another email shortly.

-pate

---------- Forwarded message ----------
Date: Thu, 15 Aug 2002 15:44:44 -0400 (EDT)
From: Pat Eyler <address@hidden>
To: MyLibrary portal development <address@hidden>
Subject: Re: MyLib Next Steps



On Thu, 15 Aug 2002, Eric Lease Morgan wrote:

>

I cut out a lot of stuff to get to what I consider the real meat of the
message (from my perspective at least).  I'm also adding the koha-devel
list into the fray because the same issues apply in our camp.  Thanks for
putting together such a thoughtful overview Eric.

>
> To make the job of deciding what to do easier, we might compare and contrast
> the next steps by cost (time and money) as well as impact/usefulness.
> Consequently, we could create a matrix like this:
>
>              High impact Low impact
>             +-----------+-----------+
>    Low cost |  Do now   |   ???     |
>             +-----------+-----------+
>   High cost |   ???     | Don't do  |
>             +-----------+-----------+
>
> Things classified as being very useful (high impact) and implementable with
> relatively low cost should be done as soon as possible. Things that cost
> buckets of time and money and have little impact should be put lowest in the
> priority. The problems really come when we talk about the thing that have
> low cost and low impact as well as high costs and high impacts.
>
> Other next steps do not necessarily relate to the software but the issues
> surrounding the application itself. A couple of the more interesting issues
> are privacy and the relationship of a portal like MyLibrary to the balance
> of a library's website offerings. "How is a library's website similar and
> different from a library's catalog? What type of content should be listed on
> a website versus the type of content recorded in an integrated library
> system?"
>
> In short, to create a "next steps" document I suggest we:
>
>   1) articulate a list of enhancements, features, and/or issues
>      to be addressed
>   2) prioritize each item in the list
>   3) get people address each item
>
> What do y'all think? Can you suggest an enhancement, feature, or issue?
>

[As I've mentioned, I'm very firmly in the XP camp -- this may explain a
fair amount about where I'm coming from with the below.]

One of the most important things here is to get the input of our customers
(librarians, systems administrators, consultants, and patrons).  We as
developers have an (often) limited or incorrect view of what is important
and why.  By drawing the users of our software into the discussion about
what features are the most important, we can deliver better value, faster.

One approach would be to develop a board (or similar group) of librarians
to review lists of possible enhancements and have them place them in a
matrix like that above (good for OSS).  Another method would be to give
them a pool of 'developer units' and allow them to spend that pool on
building a release (good for commercial style development).  (Note, there
is no reason that commercial style development can not produce free
software.)

A final note to consider is that all of our planning and information
gathering can be obviated by some organization deciding that it is worth
funding the development of some module or function.  We need to be
flexible enough to handle this (and to integrate it into our source tree).
Ideally, we should have published inforamtion on coding standards and
other requirements for inclusion e.g., 'Any new code most have unit
tests, and must not break the existing unit test suite.'


hopefully, the above is useful ...

happy hacking,
-pate



> --
> Eric Lease Morgan
> (574) 631-8604
>
> For information about this mailing list, such as the location of its
> archive and instructions for managing your subscription, see:
> http://dewey.library.nd.edu/mylibrary/mailing-list.shtml. --ELM
>