[OPEN-ILS-GENERAL] Problem reporting and tracking process (was: Books only coming up by TCN)

[Dan Scott]

2009/7/9 Hardy, Elaine <ehardy at georgialibraries.org>:
> We noticed a huge increase in the number of these problem records since the
> upgrade to 1.4 and have a helpdesk ticket with Equinox. ESI developed the
> script to correct the records themselves while they investigate the
> underlying issue that causes it. We have had success with the script.
> Otherwise, the solution was to overlay each record fixing the
> metabib.keyword_field_entry entries. Overlaying was not a viable option
> considering the number of records affected in PINES.

Very interesting, Elaine. I appreciate you speaking up. When I first
ran across this problem in our system, I thought that there was
something wrong with our particular configuration (being all
bleeding-edge) and with some of the other systems that had similarly
installed and configured their own Evergreen system. It's really nice
to know that we're not alone.

One of the things we discussed at the start of the Evergreen
Conference "hackfest" was a need for a better coordination of feature
enhancements as the community grows. We (core developers) were open to
the idea of making better use of the community ticket system
(http://svn.evergreen-ils.org/trac/ILS/report/1), but we need to
figure out how to manage it (sanely, without spending all of our time
munging ticket metadata and managing ticket system user accounts) as
well as how to use it consistently. Right now the open tickets don't
necessarily reflect what any of us are working on or towards in the
community.

If we do figure out that process (and it's possible, there are
thousands of projects that do this successfully), I think we could use
the same sort of central, open coordination for defects. It doesn't
make sense for me to spend time developing a script over in
ILS-Contrib,, when a variation on that same script may have already
been written and deployed for another Evergreen institution. If that
other version of the script isn't publicly available, then I guess it
does make sense for me to spend time developing a script that everyone
can make use of - whether they're self-hosted or commercially
supported.

In my ideal world, the only tickets that would live solely in a
private ticket system (such as Conifer's, or Equinox's, or others) are
those that are not generally applicable to Evergreen (such as local
customizations of skins or permissions or whatnot), or those that
contain sensitive information. I've tried to open tickets in the
public Evergreen ticket system when there are basic enhancements
required, and pointed to that from a corresponding ticket in our our
system, but haven't been as diligent about creating corresponding
defect tickets in the public Evergreen system. I'll try to do a better
job of that going forward. If you're a customer of a support vendor,
you should be able to ask or insist that your support vendor tracks
generally applicable tickets in the public system. There's arguably a
benefit to the support vendor, too, in that it gives another site a
chance to tackle or collaborate on a solution for that problem (free
labour!).

Maybe I'm over-thinking all of this, though. The simplest and most
important step is just to bring our problems to the broad community
via the mailing list, like Adam did. The problem reporter just needs
to signed up for the mailing list, and the resolution (or lack
thereof) is available thereafter in the list archives - which have
hopefully been searched by the problem reporter for previous solutions
before reporting the problem :)

Defects in software aren't something to be embarrassed about; they
happen in all software, and they need to be confirmed, tracked, and
eliminated (workarounds like the reingest script can be used as a
stopgap measure). Preferably with tests in place to ensure that the
same defect doesn't creep back in a release or two later.

-- 
Dan Scott
Laurentian University