Regarding Holdings View, we can describe how we want it to work. (One
of our libraries provided excellent screen shots.) Do I share that
here or LP both?
I would put it on the Launchpad bug. However, whenever I add something
to LP that I believe needs broader end-user feedback, I usually post a
message to a list to let people know since they may not be following
that particular LP bug.
Regarding IRC, I am not shy about my opinions on that. I have to use
it for EOB meetings, but find it to be arcane to the uninitiated.
Also, it is simply not the way people in libraries communicate.
Please note that the one tiny reference to IRC in an email was not a way
to push people to IRC who don't want to go there. It was just one of
many options I cited for discussing problematic bugs. People should use
the communication venue that works best for them. For many in the
community, librarian and developer alike (FWIW, I am a librarian),
that's IRC, but we're all on the list too and are listening to the
concerns and ideas raised here. My main concern, for tracking purposes,
is that any discussions happening here or in IRC about a particular bug
eventually get linked from the bug in the question. Otherwise, it's too
easy to lose the different threads of that discussion.
Kathy
On 03/30/2018 11:26 AM, scott.tho...@sparkpa.org wrote:
Hi Kathy,
Your points about “positive advocacy” are well-stated and well-taken,
but advocacy is what we are doing with Congress as we try to get IMLS
money restored for FY2019. We who live in the non-developer
neighborhood of the Evergreen community have more power than that,
and, yes, it does involve sponsoring development or bug-fixing projects.
I also agree on the need for very good communication between those of
us who want a feature, but are not developers, and those who have the
skills to do the work. It is almost like I’m the patron and the
developer is the reference librarian, and I am probably in need of a
good reference interview. Regarding Holdings View, we can describe how
we want it to work. (One of our libraries provided excellent screen
shots.) Do I share that here or LP both? Regarding IRC, I am not shy
about my opinions on that. I have to use it for EOB meetings, but find
it to be arcane to the uninitiated. Also, it is simply not the way
people in libraries communicate.
I’ve been involved with Evergreen, us a user and then as a
consortium leader, since 2015, and these recent discussion have been
incredibly illuminating. I feel privileged to be a part of this community.
Scott
*From:*Open-ils-general
[mailto:open-ils-general-boun...@list.georgialibraries.org] *On Behalf
Of *Kathy Lussier
*Sent:* Friday, March 30, 2018 10:46 AM
*To:* open-ils-general@list.georgialibraries.org
*Subject:* Re: [OPEN-ILS-GENERAL] Holdings View in Web Client
Hi,
In regards to this question:
What can we do to get this fixed in 3.2 if not sooner?
And the responses thus far:
1. Fix it yourself.
2. Hire someone else to fix it.
3. Wait for someone else to do 1 or 2.
#4: work together to get it fixed (i.e. funding through development
partnerships)
I also would like to talk about the role of positive advocacy in
getting attention on particular bugs, which may not guarantee that
they get fixed, but certainly could draw enough developer attention
towards the bug to result in it getting fixed. I guess this is really
another spin on Jason's solution #3 - wait for someone else to do 1 or 2.
What exactly is positive advocacy? It's raising discussion on the
lists, just as we did here, to ask about a bug and to see if it also
has an impact on other Evergreen sites. It involves participating in
LP discussions or raising questions in IRC. It not only involves
discussing why the bug is important, but contributing to discussions
on the best approach to fix it. In the case of this particular bug,
for example, there was discussion of adding a "show empty libraries"
option and a question of whether it should replace the "show empty
volumes" option or not. Getting feedback on questions like this is
very helpful. If a developer decides to take on the bug, it will give
them a clear direction for moving forward. Positive advocacy also
includes committing to test a fix when it is available.
On a related side note, that Sandbox request form we use for Bug
Squashing Day is never turned off. If you ever want to test a bug fix
when it's not Bug Squashing Day, feel free to submit it or contact me
directly. If I have the a server and the time, I'm happy to load fixes
so that people can help with getting that bug fix merged to Evergreen.
It's available at https://goo.gl/forms/PE4fYfWDh5AixYpy2
I use the word 'positive' because I do think there is a thin line
between advocating that *we* as a community work together to fix a bug
and treating the community as a *they *that should be fixing a given
bug or introducing a new feature. FWIW, I am not saying that Scott was
doing this when he raised his question. Given the amount of sponsored
development that has come for both enhancements and bug fixes from
PaILS, it's clear that he already recognizes his organization's role
in contributing to the improvement of Evergreen. In general, though, I
have seen this sentiment in other discussions, and, as frustrating as
it can be when you're dealing with a problematic bug, we have to keep
in mind that we're all on this together. The more people who take on
the responsibility of helping improve Evergreen in some small or even
large way, the better the software will be for all of our users.
I'm guessing that part of the original question really related to how
positive advocacy turns into an actual bug fix. With the release of
3.1, I think we're all seeing that 3.2, when the xul client will no
longer be available for our users, is just around the corner. Although
the web client has come a long way, I think it's natural that there is
some anxiety over remaining bugs that are preventing staff from using
the new client or making it difficult for them to use it.
Based on my observations over the past eight years, I would say all of
the following are factors in whether a bug gets fixed through these
community channels.
Does the bug break critical functionality? For example, you can't
build the software, bib records can no longer be saved, you can no
longer perform checkouts. Generally, these are the types of bugs that
get High priority in Launchpad and are fixed very quickly.
Is there a developer capable of fixing a bug who has the time to work
on it or are they in the middle of some other large project, like a
migration?
How long will it take to fix the bug? Is it a complex or easy fix?
https://bugs.launchpad.net/evergreen/+bug/1187993
<https://bugs.launchpad.net/evergreen/+bug/1187993> has been a
high-priority bug for five years now, but it's complex and will take
many developer hours to fix. It's more difficult to get large fixes
done without asking a developer in your own organization to fix it or
funding the fix. Sometimes, low priority bugs get fixed simply
because they're quick and easy and more people may be capable of
fixing it.
Does the developer believe it will also affect the people in their own
organization? In organizations that have a developer, the positive
advocacy may be the thing that brings it to the attention of some
cataloger or circ person who then communicates to their developer that
it is indeed a critical issue. If the problem is related to serials
and the developer works at a library that doesn't use serials, they
are less likely to work on it.
Think of it in terms of volunteering that you may do in your own home
communities. If somebody asks you to bake something for a bake sale to
raise funds for a cause you believe in, you may quickly say yes
without a thought. If they ask you to organize the bake sale, the
answer may depend on whether you have time or on how strongly you feel
about the cause. If you don't care about the cause at all (i.e. you
can't understand why anyone would ever want Evergreen to work that
way), you may never say yes no matter how much time you have. If the
fundraiser is actually a capital campaign project for a new library,
it doesn't matter how many people feel strongly about the issue, you
may still need to hire a professional fundraiser to organize the
campaign for you.
No matter how much positive advocacy I personally do for specific
bugs, in the end, I know if the MassLNC organizations feel strongly
about a bug fix or feature, we need to be prepared to fund it or have
one of our internal developers work on it. There are times when I've
gritted my teeth while funding a project, either because I think the
software should just work that way or because I feel like we've
already invested enough into the feature. However, I also know we are
also indebted to many developers in this community who have quickly
fixed issues, both large and small, as a result of our positive
advocacy. In the end, it all balances out.
Kathy
On 03/29/2018 02:02 PM, scott.tho...@sparkpa.org
<mailto:scott.tho...@sparkpa.org> wrote:
Jason,
Thank you for this information. Regarding this particular bug, it is
too serious to leave to #3, and we don't have the wherewithal to do #1 so we
may try to do #2...but will likely need funding partners...which brings us to
#4: work together to get it fixed.
Scott
-----Original Message-----
From: Open-ils-general
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Jason
Stephenson
Sent: Thursday, March 29, 2018 1:44 PM
To:open-ils-general@list.georgialibraries.org
<mailto:open-ils-general@list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] Holdings View in Web Client
On 03/29/2018 11:27 AM,scott.tho...@sparkpa.org
<mailto:scott.tho...@sparkpa.org> wrote:
I agree this is an impediment to implementing the Web Client in
centralized or semi-centralized cataloging departments (of which we
have many). I am just not conversant on the ins & outs of how to get
fixes into a release versus a maintenance release versus a patch
Bug targeting is done by one of the members of the drivers group. It is
usually done only for bugs that have patches or where someone is working on it
and is likely to have a patch ready in time for the release. We (mostly I)
sometimes break the unwritten rules and target bugs prematurely.
As for how to get specific bugs fixed, you basically have 3 options:
1. Fix it yourself.
2. Hire someone else to fix it.
3. Wait for someone else to do 1 or 2.
HtH,
Jason
--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org <mailto:kluss...@masslnc.org>
Twitter: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