>> Back in the Template Toolkit days, there was a tag we used in
Launchpad that identified bugs we thought should be fixed before
removing the old catalog from Evergreen. Maybe we could consider doing
something similar for the web client. <<
I like that idea. Although our circulation staff have moved over to
the web client for the most part, there are still some major
roadblocks that need to be overcome in cataloging before we are able
to move everyone over completely.
I like the idea too, but, along with it, there also needs to be a
commitment to make sure bugs with those tags get fixed before the old
client is removed. IIRC, the old javascript catalog was removed before
many of those bugs were fixed because nobody directed their developers,
funded development, etc. to get those bugs addressed. I think the tag is
a good way to organize the bugs and highlight the important ones, but it
doesn't offer a guarantee that they will be fixed without that commitment.
Kathy
On 03/16/2018 04:20 PM, Terran McCanna wrote:
>> Back in the Template Toolkit days, there was a tag we used in
Launchpad that identified bugs we thought should be fixed before
removing the old catalog from Evergreen. Maybe we could consider doing
something similar for the web client. <<
I like that idea. Although our circulation staff have moved over to
the web client for the most part, there are still some major
roadblocks that need to be overcome in cataloging before we are able
to move everyone over completely.
Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org>
On Fri, Mar 16, 2018 at 4:08 PM, Kathy Lussier <kluss...@masslnc.org
<mailto:kluss...@masslnc.org>> wrote:
Hi Diane,
I'm sorry to hear your frustration, but I can also empathize.
While working on a recent project to sponsor more bug fixes for
the web client, I also got discouraged as new bugs were reported,
particularly when they were ones that would have made our priority
list if we had known about them at the time we were selecting bugs
to fix. To keep myself from getting discouraged, I found it helped
to keep some things in mind.
- Despite the current open bugs, the web client has come a long
way just in the past year. Setting aside the addition of serials
and offline, there has been a lot of bug fixing over the last
months. In many cases, the fixes have been for what I consider to
be showstopper bugs. I continued to see this work even today as I
was going through my bug mail. It might be useful for the
community to track statistics of how many web client bugs are
getting fixed on a monthly basis to help us see the progress
that's been done. Looking at the 3.0 point release notes is also a
good way to see how much work has been done.
- There were many people, including myself, who spent a lot of
time testing the web client when the code was initially written,
but, no matter how much testing was done, we knew that there are
just some bugs that just won't be found until people start using
it in production. This isn't unique to Evergreen or open-source
software, but is something I've seen when using proprietary
software as well. We tried to catch some of these bugs by having
2.12 available for trial use in production, but I don't think most
sites really started using the web client heavily until 3.0,
which was just released in October. I would say the flurry of bug
reporting since that time is an expected part of the process of
eventually getting to a more stable web client. This is also why
we are keeping the xul client around through the 3.1 release,
because we knew it would take time to get the web client to where
it needs to be for all Evergreen users to move to it.
I still remember the early days of the Template Toolkit catalog. I
was equally discouraged about bugs and missing features, but as
more sites started using it, they made sure features important to
them were fixed or added, and we now have a stable and feature
rich public catalog.
- I'm worried about stating this the wrong way, but we also have
to remember the number of bugs we've learned to live with under
the xul client. I'm not saying we should just learn to live with
the web client bugs, but they certainly are more noticeable now
because they are new. There are also several xul client bugs we
were able to close out because they were fixed in the web client.
The important thing is that the bugs are open and known. Evergreen
sites can see where the problems are and ultimately choose to
focus on addressing the ones most important to them.
Having said all of this, I do think it's important that if there
are showstopper bugs in the web client (not annoyances, but things
that really prevent you from using the web client), we need to
identify those to increase the likelihood that they will be fixed
ahead of other bugs. For example, one of the groups I work with
recently set the bug priority to High for a handful of bugs they
considered to be showstoppers. Back in the Template Toolkit days,
there was a tag we used in Launchpad that identified bugs we
thought should be fixed before removing the old catalog from
Evergreen. Maybe we could consider doing something similar for the
web client.
Kathy
On 03/16/2018 03:27 PM, Diane Disbro wrote:
Good afternoon -
I volunteered to keep track of Webby problems for the Missouri
Evergreen circulation committee. I am pretty discouraged. My
library began using Webby in December but there were so many
frustrations that we stopped after about a month. My spreadsheet
of problems now has thirty-five issue on it. Every time a new bug
report is sent out my heart sinks.
Diane Disbro
Branch Manager/Circulation Coordinator
Union Branch
Scenic Regional Library
308 Hawthorne Drive
<https://maps.google.com/?q=308+Hawthorne+Drive+%0D%0A+++++++++++++++++++++++++Union,+MO+%C2%A0+%C2%A0+63084&entry=gmail&source=g>
Union, MO 63084
<https://maps.google.com/?q=308+Hawthorne+Drive+%0D%0A+++++++++++++++++++++++++Union,+MO+%C2%A0+%C2%A0+63084&entry=gmail&source=g>
(636) 583-3224 <tel:%28636%29%20583-3224>
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128 <tel:%28508%29%20343-0128>
kluss...@masslnc.org <mailto:kluss...@masslnc.org>
Twitter:http://www.twitter.com/kmlussier <http://www.twitter.com/kmlussier>
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier