- Koha-devel - lists.koha-community.org

[Bug 83] selectbranchprinter.pl doesn't show any branches
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=83 tonnesen(a)cmsd.bc.ca changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2002-08-17 08:25 ------- Found the problem: (next) unless ($branches->{$_}->{'IS'}) I didn't the issuing flag set for my second two branches. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 83] New: selectbranchprinter.pl doesn't show any branches
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=83 Summary: selectbranchprinter.pl doesn't show any branches Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net Has something to do with getbranches using the branchrelations table. What is this table? I'm not using it with the sample data. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 82] New: selectbranchprinter.pl is not executable
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=82 Summary: selectbranchprinter.pl is not executable Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 81] New: Getting an underscore character between Issues/Returns/Transfers buttons
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=81 Summary: Getting an underscore character between Issues/Returns/Transfers buttons Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net Just need to remove the space from the <a></a> elements. How's that for a nitpicky bug? :) Just submitting bugs as I test 1.2.3RC9 ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 80] New: printslip() subroutine is missing
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=80 Summary: printslip() subroutine is missing Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 79] New: Can't search by Item Number from main catalogue page
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=79 Summary: Can't search by Item Number from main catalogue page Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalogue AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 78] bug in getpatroninformation - fatal error
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=78 ------- Additional Comments From tonnesen(a)cmsd.bc.ca 2002-08-17 07:53 ------- Some code got removed that set up the $accessflagshash variable. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 78] New: bug in getpatroninformation - fatal error
by bugzilla-daemon＠wilbur.katipo.co.nz 16 Aug '02

16 Aug '02

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=78 Summary: bug in getpatroninformation - fatal error Product: Koha Version: 1.2.3 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: tonnesen(a)cmsd.bc.ca QAContact: koha-devel(a)lists.sourceforge.net ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Re: MyLib Next Steps
by Pat Eyler 16 Aug '02

16 Aug '02

On Fri, 16 Aug 2002, Chris Gray wrote: > > 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.) > > I have some reservations about this kind of approach. As Jakob Nielsen > puts it "don't listen to users" > <http://www.useit.com/alertbox/20010805.html>. The point is simply that > there is often a large gap between what people say they need and what > would actually help them. This may be true of end users (Though I take some of Jakob's words with a grain of salt ... he is a bit dogmatic for my tastes), but I'm talking about the professional users of the software, who use it to provide services to the end user. Ignoring their input is a dangerous game. Finding out how to get that input is an interesting challenge though. > > XP is good because the customer is an active participant in all phases of > the development so you get the benefit of their feedback all the way along > not just at the beginning and at the end. XP recognizes that there is a > lot that you don't know about something until you actually try to build > it. > > Here's one area where XP is more difficult in a "dispersed" environment. > You need on-line tools to help replace face-to-face feedback from users. There are certainly other approaches here. With Koha, we can rely on 'face-to-face' feedback between libraries and consultants/developers like Katipo, Steve, and Paul (among others) - this feedback occurs naturally as part of the client interaction, and drives the consultants development priorities. Koha and other projects can certainly make use of email, irc, wikis, and web based surveys to gather feedback from our users. Where we have created installation or upgrading scripts, we can certainly include an optional feedback form which could be emailed to a project address (given permission, and probably an option to edit the email). > Does this perhaps lead to a top priority of MyLibrary development? Maybe > we need to begin by tracking and analyzing how people actually do use > MyLibrary. I've got in mind something like the following story from > Philip Greenspun <http://philip.greenspun.com/panda/user-tracking>: > > "You can also use the logs to refine content. My very first log summary > revealed that half of my visitors were just looking at the slide show for > Travels with Samantha. Did that mean they thought my writing sucked? Well, > maybe, but it actually looked like my talents as a hypertext designer were > lame. The slide show was the very first link on the page. Users had to > scroll way down past a bunch of photos to get to the Chapter 1 link. I > reshuffled the links and traffic on the slide show fell to 10 percent." > This is a very good idea, and a nice illustration of how to make use of it. Beyond application logging, it may be fruitful to look into the logs of a projects website (particularily in on-line help and documentation) to see where people are going most often. -pate > Chris > > 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 >

1 0

Re: MyLib Next Steps (fwd)
by Pat Eyler 16 Aug '02

16 Aug '02

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(a)eylerfamily.org> To: MyLibrary portal development <MYLIB-DEV(a)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 >

1 0