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 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

Reply via email to