[OPEN-ILS-GENERAL] Holdings View in Web Client

Fri Mar 30 11:40:49 EDT 2018

Very nicely said, Kathy.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmccanna at georgialibraries.org

On Fri, Mar 30, 2018 at 10:45 AM, Kathy Lussier <klussier at masslnc.org>
wrote:

> 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.thomas at 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-bounces at list.georgialibraries.org <open-ils-general-bounces at list.georgialibraries.org>] On Behalf Of Jason Stephenson
> Sent: Thursday, March 29, 2018 1:44 PM
> To: open-ils-general at list.georgialibraries.org
> Subject: Re: [OPEN-ILS-GENERAL] Holdings View in Web Client
>
> On 03/29/2018 11:27 AM, scott.thomas at 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-0128klussier at masslnc.org
> Twitter: http://www.twitter.com/kmlussier
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20180330/f574a04f/attachment.html>