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 <pate@eylerfamily.org> To: MyLibrary portal development <MYLIB-DEV@listserv.nd.edu> 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