Re: [OPEN-ILS-GENERAL] Patrons cannot change their user name

[Ben Shum]

Hi James,

I believe that is controlled via library settings.  Look in the editor for
"Allow multiple username changes" to be true so that patrons can change it
more often than just the first time.  And "Lock Usernames" to be false or
not set to allow patrons to change their username at all.

One use case I immediately thought of for disallowing change of username
would be in a school setting where usernames follow consistent practices:
first name initial, last name, etc.  In that environment, the username may
have more implications in interactions with other systems that depend on
consistent and unchanging username fields.

Hope this helps.

Regards,

Ben Shum


On Tue, Jul 30, 2013 at 6:37 PM, James Wagner
wrote:

>  We are on Evergreen 2.4 and TPAC. One of our patrons was wondering why
> they couldn’t change their user name within their Account Preferences in
> the TPAC. We’re pretty sure that in the former OPAC that was possible. But,
> before I take this any further, I’d like to know if maybe there is a
> specific reason/rationale for setting up the TPAC this way. (In the
> meantime, we have no difficulty changing usernames for patrons in the staff
> client.)
>
> ** **
>
> James Wagner
>
> Technical Services Co-ordinator
>
> Lincoln Public Library
>
> Vineland, Ontario, Canada
>
> 905-563-2799 ext 216
>
> wag...@lincoln.library.on.ca
>
> www.lincoln.library.on.ca
>
> ** **
>

Re: [OPEN-ILS-GENERAL] Bug bounties

[Tim Spindler]

I generally like the idea and support but would have the same concerns as
Dan Scott.  I don't have a solution either.

Tim Spindler
C/W MARS

On Tuesday, July 30, 2013, Rogan Hamby wrote:

> I think I know the Dilbert cartoons you speak of and none of us want those
> scenarios!  Wally made a fortune
>
> Anyway, I think those are valid concerns and concerns I have as well but
> I'd like to see what Kathy comes up with for a proposal.  I don't think we
> have the resources to offer more than a minimal award so I would hope that
> potential financial gain would be a big factor.  And unlike Wally hopefully
> no one would create bugs just to fix them later.  :)
>
> Also, in the spirit of it being largely symbolic, as Ruth points out, in a
> discussion off list about swag the idea has been thrown out to use some
> kind of swag.  I'm personally amused at the idea of a t-shirt that says
> "Bug Killer"
>
>
>
> On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott 
> 
> > wrote:
>
>> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
>> > I haven't heard any dissents and at least two in favors of (you and I)
>> so
>> > in the spirit of a meritocracy I would say Kathy that at the least if
>> you
>> > want to come up with a model of how to handle it, go ahead and let's
>> start
>> > poking at the details.
>> >
>> > I won't derail things with my wishlist for accessibility.  :)
>> >
>> > I agree that wishlist bugs shouldn't be on the list.
>>
>> Okay, I'll offer a conditional dissent then. I worry that the
>> introduction of financial incentives will disrupt the contributor
>> ecology. As soon as money is in the picture, all sorts of interesting
>> side effects can occur.
>>
>> For example, will this act as a disincentive for open communication
>> and collaboration about potential alternatives for fixing a bug (because
>> potential fixers jealously guard their approaches from one another)?
>> Will it reduce the interest of current developers in providing
>> assistance to new contributors? Will it introduce difficulties in trying
>> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
>> share of the cash? Do reporters of bugs who provide reproducible test
>> cases get any share of the cash? Is there any requirement to providing
>> regression tests (to prevent the bug from ever rearing its head again)
>> as part of the bug fix? Will contributors of new functionality bury bugs
>> they know about in the interest of getting paid twice, once for the new
>> functionality, and then later for the bug fixes?
>>
>> My conditional dissent would like some examples of projects where bug
>> bounties have actually worked. The examples that I've seen have focused
>> on reporting security vulnerabilities. If there are a few solid cases
>> out there that can serve as a model for us, then I would turn my dissent
>> into cautious assent.
>>
>> It could be that I've just read one too many Dilbert cartoons...
>>
>
>
>
> --
>
> Rogan Hamby, MLS, CCNP, MIA
> Managers Headquarters Library and Reference Services,
> York County Library System
>
> "You can never get a cup of tea large enough or a book long enough to suit
> me."
> -- C.S. Lewis 
>


-- 
Tim Spindler
tjspind...@gmail.com

*P**   Go Green - **Save a tree! Please don't print this e-mail unless it's
really necessary.*

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I think I know the Dilbert cartoons you speak of and none of us want those
scenarios!  Wally made a fortune

Anyway, I think those are valid concerns and concerns I have as well but
I'd like to see what Kathy comes up with for a proposal.  I don't think we
have the resources to offer more than a minimal award so I would hope that
potential financial gain would be a big factor.  And unlike Wally hopefully
no one would create bugs just to fix them later.  :)

Also, in the spirit of it being largely symbolic, as Ruth points out, in a
discussion off list about swag the idea has been thrown out to use some
kind of swag.  I'm personally amused at the idea of a t-shirt that says
"Bug Killer"



On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott  wrote:

> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> > I haven't heard any dissents and at least two in favors of (you and I) so
> > in the spirit of a meritocracy I would say Kathy that at the least if you
> > want to come up with a model of how to handle it, go ahead and let's
> start
> > poking at the details.
> >
> > I won't derail things with my wishlist for accessibility.  :)
> >
> > I agree that wishlist bugs shouldn't be on the list.
>
> Okay, I'll offer a conditional dissent then. I worry that the
> introduction of financial incentives will disrupt the contributor
> ecology. As soon as money is in the picture, all sorts of interesting
> side effects can occur.
>
> For example, will this act as a disincentive for open communication
> and collaboration about potential alternatives for fixing a bug (because
> potential fixers jealously guard their approaches from one another)?
> Will it reduce the interest of current developers in providing
> assistance to new contributors? Will it introduce difficulties in trying
> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
> share of the cash? Do reporters of bugs who provide reproducible test
> cases get any share of the cash? Is there any requirement to providing
> regression tests (to prevent the bug from ever rearing its head again)
> as part of the bug fix? Will contributors of new functionality bury bugs
> they know about in the interest of getting paid twice, once for the new
> functionality, and then later for the bug fixes?
>
> My conditional dissent would like some examples of projects where bug
> bounties have actually worked. The examples that I've seen have focused
> on reporting security vulnerabilities. If there are a few solid cases
> out there that can serve as a model for us, then I would turn my dissent
> into cautious assent.
>
> It could be that I've just read one too many Dilbert cartoons...
>



-- 

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long enough to suit
me."
-- C.S. Lewis 

[OPEN-ILS-GENERAL] Patrons cannot change their user name

[James Wagner]

We are on Evergreen 2.4 and TPAC. One of our patrons was wondering why they 
couldn't change their user name within their Account Preferences in the TPAC. 
We're pretty sure that in the former OPAC that was possible. But, before I take 
this any further, I'd like to know if maybe there is a specific 
reason/rationale for setting up the TPAC this way. (In the meantime, we have no 
difficulty changing usernames for patrons in the staff client.)

James Wagner
Technical Services Co-ordinator
Lincoln Public Library
Vineland, Ontario, Canada
905-563-2799 ext 216
wag...@lincoln.library.on.ca
www.lincoln.library.on.ca

Re: [OPEN-ILS-GENERAL] Bug bounties

[Ruth Frasur]

It's been mentioned elsewhere that maybe the bounties be something other
than money.  I think it was in the swag conversation.
On Jul 30, 2013 5:49 PM, "Dan Scott"  wrote:

> On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> > I haven't heard any dissents and at least two in favors of (you and I) so
> > in the spirit of a meritocracy I would say Kathy that at the least if you
> > want to come up with a model of how to handle it, go ahead and let's
> start
> > poking at the details.
> >
> > I won't derail things with my wishlist for accessibility.  :)
> >
> > I agree that wishlist bugs shouldn't be on the list.
>
> Okay, I'll offer a conditional dissent then. I worry that the
> introduction of financial incentives will disrupt the contributor
> ecology. As soon as money is in the picture, all sorts of interesting
> side effects can occur.
>
> For example, will this act as a disincentive for open communication
> and collaboration about potential alternatives for fixing a bug (because
> potential fixers jealously guard their approaches from one another)?
> Will it reduce the interest of current developers in providing
> assistance to new contributors? Will it introduce difficulties in trying
> to divvy up credit for bug fixes? Do reviewers of bug fixes get any
> share of the cash? Do reporters of bugs who provide reproducible test
> cases get any share of the cash? Is there any requirement to providing
> regression tests (to prevent the bug from ever rearing its head again)
> as part of the bug fix? Will contributors of new functionality bury bugs
> they know about in the interest of getting paid twice, once for the new
> functionality, and then later for the bug fixes?
>
> My conditional dissent would like some examples of projects where bug
> bounties have actually worked. The examples that I've seen have focused
> on reporting security vulnerabilities. If there are a few solid cases
> out there that can serve as a model for us, then I would turn my dissent
> into cautious assent.
>
> It could be that I've just read one too many Dilbert cartoons...
>

Re: [OPEN-ILS-GENERAL] Bug bounties

[Dan Scott]

On Tue, Jul 30, 2013 at 05:35:04PM -0400, Rogan Hamby wrote:
> I haven't heard any dissents and at least two in favors of (you and I) so
> in the spirit of a meritocracy I would say Kathy that at the least if you
> want to come up with a model of how to handle it, go ahead and let's start
> poking at the details.
> 
> I won't derail things with my wishlist for accessibility.  :)
> 
> I agree that wishlist bugs shouldn't be on the list.

Okay, I'll offer a conditional dissent then. I worry that the
introduction of financial incentives will disrupt the contributor
ecology. As soon as money is in the picture, all sorts of interesting
side effects can occur.

For example, will this act as a disincentive for open communication
and collaboration about potential alternatives for fixing a bug (because
potential fixers jealously guard their approaches from one another)?
Will it reduce the interest of current developers in providing
assistance to new contributors? Will it introduce difficulties in trying
to divvy up credit for bug fixes? Do reviewers of bug fixes get any
share of the cash? Do reporters of bugs who provide reproducible test
cases get any share of the cash? Is there any requirement to providing
regression tests (to prevent the bug from ever rearing its head again)
as part of the bug fix? Will contributors of new functionality bury bugs
they know about in the interest of getting paid twice, once for the new
functionality, and then later for the bug fixes?

My conditional dissent would like some examples of projects where bug
bounties have actually worked. The examples that I've seen have focused
on reporting security vulnerabilities. If there are a few solid cases
out there that can serve as a model for us, then I would turn my dissent
into cautious assent.

It could be that I've just read one too many Dilbert cartoons...

Re: [OPEN-ILS-GENERAL] Bug bounties

[Rogan Hamby]

I haven't heard any dissents and at least two in favors of (you and I) so
in the spirit of a meritocracy I would say Kathy that at the least if you
want to come up with a model of how to handle it, go ahead and let's start
poking at the details.

I won't derail things with my wishlist for accessibility.  :)

I agree that wishlist bugs shouldn't be on the list.


On Tue, Jul 30, 2013 at 4:53 PM, Kathy Lussier  wrote:

>  Hi Rogan,
>
> Sorry to be late in getting you feedback on this, but I just wanted to
> send along a vote of support for the idea of offering bug bounties. I think
> it's a great idea!
>
> I think it should be limited to true bugs and not be used for wishlist
> bugs. I know there are plenty of bugs to tackle that are more than a year
> old, but, when working in two-releases per year cycle, I'm thinking bugs
> become old much sooner than that. Maybe six month or even less? I generally
> have found that if a bug doesn't receive some kind of attention in the
> first three months (attention being questions, confirmation, lots of "me
> too"s etc.), it is likely to be one of those bugs that ends up gathering
> dust. I think it's important that we give bugs a chance to get community
> attention before offering a bounty. Six months seems like it would be more
> than sufficient.
>
>
> some would say it doesn't weigh importance of more recent bugs (and that's
> true).
>
>
> I think it was me who said that. :) Overall, I would say targeting the
> older bugs is important. However, as with anything, I think there are
> exceptions. The specific bug I had in mind was
> https://bugs.launchpad.net/evergreen/+bug/1187993 which is related to an
> accessibility issue in the catalog when autosuggest is enabled. I see this
> bug as an exception because I believe accessibility is something the
> community should be supporting/striving for in any way we can. Perhaps
> there are/will be other unique cases out there where priority will take
> precedence.
>
> In any case, if the community decides to move forward with this, I would
> be willing to volunteer to help work out the details. We might not come up
> with the perfect system, but, whatever happens, it should lead to some
> fixes for issues that have been frustrating people.
>
> Kathy
>
> Kathy Lussier
> Project Coordinator
> Massachusetts Library Network Cooperative(508) 343-0128kluss...@masslnc.org
> Twitter: http://www.twitter.com/kmlussier
>
> On 7/18/2013 6:58 PM, Rogan Hamby wrote:
>
> I'll be honest it's partially unclear because this is bouncing it off
> people thing at this point in time.  This probably frustrates some people
> but I think these are things that as a community we should have dialogues
> about.
>
>  If I were asked to put forth my personal vision it would be something
> like this:
>
>  The community votes on bugs over X age (a year old?) using some kind of
> mechanism and presumably ranks based on priority.  We then offer bug
> bounties on a set rate to Y number of bugs based on how much we have in
> that fund.  Let's say we have $1,000 and pay $100 per bug, then we can
> offer it to the top ten bugs ranked by people's votes.
>
>  There are flaws with that approach.  Some may say it does't give weight
> to payments based on complexity of bug (and that's true) and some would say
> it doesn't weigh importance of more recent bugs (and that's true).  Fixing
> those things add issues of their own and  maybe we want to take those
> issues on.  That's part of why I'm throwing it out.
>
>
>
>
> On Thu, Jul 18, 2013 at 6:51 PM, Tim Spindler wrote:
>
>>  Rogan,
>>
>>  It is a little unclear what you are proposing.  Are you proposing that
>> bounties are given for fixing bugs?  Finding bugs? or Both?
>>
>>  Don't get me wrong, I think it has some real potential.  If we are to
>> put resources to it, I would advocate for rewarding those who fix bugs
>> because I'm sure many are pressured to add features but not rewarded to fix
>> bugs.
>>
>>  Tim
>>
>>
>> On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby 
>> wrote:
>>
>>>  I wanted to bring up an idea that has been kicked around by several
>>> folks (including myself).  At this point I don't have a fleshed out
>>> implementation proposal in mind but wanted to throw it out for
>>> consideration.  The context of conversation so far had been targeting older
>>> bugs though perhaps we should weight them by priority as well.  What, how
>>> much and where are big questions attached to funds.  But, I don't want to
>>> put the cart before the horse.  This is a practice used successfully by
>>> some other open source projects and I think there's merit in considering it.
>>>
>>> Excuse my brevity, sent from my iPhone
>>>
>>>  --
>>>
>>>  Rogan Hamby, MLS, CCNP, MIA
>>> Managers Headquarters Library and Reference Services,
>>> York County Library System
>>>
>>>  "You can never get a cup of tea large enough or a book long enough to
>>> suit me."
>>> -- C.S. Lewis 

Re: [OPEN-ILS-GENERAL] Bug bounties

[Kathy Lussier]

Hi Rogan,

Sorry to be late in getting you feedback on this, but I just wanted to 
send along a vote of support for the idea of offering bug bounties. I 
think it's a great idea!


I think it should be limited to true bugs and not be used for wishlist 
bugs. I know there are plenty of bugs to tackle that are more than a 
year old, but, when working in two-releases per year cycle, I'm thinking 
bugs become old much sooner than that. Maybe six month or even less? I 
generally have found that if a bug doesn't receive some kind of 
attention in the first three months (attention being questions, 
confirmation, lots of "me too"s etc.), it is likely to be one of those 
bugs that ends up gathering dust. I think it's important that we give 
bugs a chance to get community attention before offering a bounty. Six 
months seems like it would be more than sufficient.


some would say it doesn't weigh importance of more recent bugs (and 
that's true). 


I think it was me who said that. :) Overall, I would say targeting the 
older bugs is important. However, as with anything, I think there are 
exceptions. The specific bug I had in mind was 
https://bugs.launchpad.net/evergreen/+bug/1187993 which is related to an 
accessibility issue in the catalog when autosuggest is enabled. I see 
this bug as an exception because I believe accessibility is something 
the community should be supporting/striving for in any way we can. 
Perhaps there are/will be other unique cases out there where priority 
will take precedence.


In any case, if the community decides to move forward with this, I would 
be willing to volunteer to help work out the details. We might not come 
up with the perfect system, but, whatever happens, it should lead to 
some fixes for issues that have been frustrating people.


Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 7/18/2013 6:58 PM, Rogan Hamby wrote:
I'll be honest it's partially unclear because this is bouncing it off 
people thing at this point in time.  This probably frustrates some 
people but I think these are things that as a community we should have 
dialogues about.


If I were asked to put forth my personal vision it would be something 
like this:


The community votes on bugs over X age (a year old?) using some kind 
of mechanism and presumably ranks based on priority.  We then offer 
bug bounties on a set rate to Y number of bugs based on how much we 
have in that fund.  Let's say we have $1,000 and pay $100 per bug, 
then we can offer it to the top ten bugs ranked by people's votes.


There are flaws with that approach.  Some may say it does't give 
weight to payments based on complexity of bug (and that's true) and 
some would say it doesn't weigh importance of more recent bugs (and 
that's true).  Fixing those things add issues of their own and  maybe 
we want to take those issues on.  That's part of why I'm throwing it out.





On Thu, Jul 18, 2013 at 6:51 PM, Tim Spindler > wrote:


Rogan,

It is a little unclear what you are proposing.  Are you proposing
that bounties are given for fixing bugs?  Finding bugs? or Both?

Don't get me wrong, I think it has some real potential.  If we are
to put resources to it, I would advocate for rewarding those who
fix bugs because I'm sure many are pressured to add features but
not rewarded to fix bugs.

Tim


On Thu, Jul 18, 2013 at 5:58 PM, Rogan Hamby
mailto:rogan.ha...@yclibrary.net>> wrote:

I wanted to bring up an idea that has been kicked around by
several folks (including myself).  At this point I don't have
a fleshed out implementation proposal in mind but wanted to
throw it out for consideration.  The context of conversation
so far had been targeting older bugs though perhaps we should
weight them by priority as well.  What, how much and where are
big questions attached to funds.  But, I don't want to put the
cart before the horse.  This is a practice used successfully
by some other open source projects and I think there's merit
in considering it.

Excuse my brevity, sent from my iPhone

-- 


Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long
enough to suit me."
-- C.S. Lewis





-- 
Tim Spindler

tjspind...@gmail.com 

*P**   Go Green - **Save a tree! Please don't print this e-mail
unless it's really necessary.*




--

Rogan Hamby, MLS, CCNP, MIA
Managers Headquarters Library and Reference Services,
York County Library System

"You can never get a cup of tea large enough or a book long

[OPEN-ILS-GENERAL] REMINDER: Evergreen Reports Interest Group Meeting TODAY in IRC!

[Jessica Venturo - Bibliomation]

RIG will be meeting TODAY in #evergreen from 3 - 4 PM Eastern.  See you soon!

Jessica Venturo
Applications Support Specialist
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708 
203-577-4070 ext. 105

- Original Message -
From: "Jessica Venturo - Bibliomation" 
To: "Evergreen Discussion Group" , 
"Evergreen Community Reports Email List" 

Sent: Tuesday, July 23, 2013 3:32:39 PM
Subject: [Evergreen-reports] Agenda for Next Evergreen Reports Interest Group 
Meeting

The agenda for the next RIG meeting has been posted: 
http://open-ils.org/dokuwiki/doku.php?id=evergreen-reports:meetings:2013-07-30

Feel free to email any additional agenda items to jvent...@biblio.org.

The meeting will take place next Tuesday, July 30th, from 3-4 PM Eastern in IRC 
(http://evergreen-ils.org/irc.php).  Anyone interested in reports is welcome to 
attend.  Hope to see you there!

Jessica Venturo
Applications Support Specialist
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708 
203-577-4070 ext. 105

___
Evergreen-reports mailing list
evergreen-repo...@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-reports