Re: [OPEN-ILS-GENERAL] Patrons cannot change their user name
Ben, Thanks for sharing this information - this question was brought up to me this week and now I can cross something else off my to-do list! Cheers, Chris - Original Message - From: Ben Shum b...@evergreener.net To: Evergreen Discussion Group open-ils-general@list.georgialibraries.org Sent: Tuesday, July 30, 2013 8:52:49 PM Subject: Re: [OPEN-ILS-GENERAL] Patrons cannot change their user name 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 wag...@lincoln.library.on.ca 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 -- Chris Sharp PINES System Administrator Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csh...@georgialibraries.org http://pines.georgialibraries.org/
Re: [OPEN-ILS-GENERAL] Bug bounties
Thinking out of the box for a moment. What about having documentation bounties? I am sure there are can be Dilbertesque issues to those too, but I had floated around the idea of group sponsoring a retired librarian, consultant, or part time librarian to devote serious amounts of hours to work on documentation projects. I have had success with using an intern, but they still needed me to proofread everything and be trained and supervised. Just a thought. Thanks, Yamil On Thu, Jul 18, 2013 at 6:58 PM, Rogan Hamby rogan.ha...@yclibrary.net 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.
Re: [OPEN-ILS-GENERAL] Bug bounties
Doing some basic Googling for bug bounties I found mention of Koha discussing it at KohaCon 12. I didn't find mention past that but wether they did or didn't implement one their experience may be educational to us. On Tue, Jul 30, 2013 at 5:48 PM, Dan Scott d...@coffeecode.net 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 http://www.goodreads.com/author/show/1069006.C_S_Lewis
Re: [OPEN-ILS-GENERAL] Patrons cannot change their user name
Thanks Ben: The settings as you described them were easy to find and change, and the results were perfect. Our patrons will now be able to change their usernames themselves. Also, thank you for the scenario where this setting might be used differently. James Wagner Technical Services Co-ordinator Lincoln Public Library Vineland, Ontario, Canada 905-563-2799 ext 216 wag...@lincoln.library.on.camailto:wag...@lincoln.library.on.ca www.lincoln.library.on.ca From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum Sent: July-30-13 8:57 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Patrons cannot change their user name 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 wag...@lincoln.library.on.camailto:wag...@lincoln.library.on.ca 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 216tel:905-563-2799%20ext%20216 wag...@lincoln.library.on.camailto:wag...@lincoln.library.on.ca www.lincoln.library.on.cahttp://www.lincoln.library.on.ca
Re: [OPEN-ILS-GENERAL] Bug bounties
I think we should high light that Dan Wells has helped push cleaning up a lot of bugs with 2.5 including wishlist ones which as he pointed out is characteristic of a maturing software project. I like the idea of the bug squashing being something symbolic but meaningful. I don't mind giving out money but nor do I want it to be about money. I like the bug squashing idea too. A big part of all this though is what do the developers think would be a fun thing that they would rally behind. A bug squashing day? Should we devote some time at the hack-a-way to reviewing long standing bugs and seeing what can be done about them? What do you think? On Wed, Jul 31, 2013 at 3:46 PM, Kathy Lussier kluss...@masslnc.org wrote: Hi Rogan, Dan, et al., 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. Hmmm...I think what I said was I would be willing to *help* work out the details, but I guess I could poke around to see what other projects do and start with something bare bones for the community to react to. One of the reasons I was so quick to volunteer to help on this is because I do submit a lot of bugs and don't really have the ability to fix them, with the exception of some really, easy tpac bugs. In some cases, the bugs are resolved fairly quickly; others are collecting dust, not because the community doesn't care about fixing them, but because everyone has limited time and usually must address the needs important to their own organizations before working on other bugs. I just did a search of Launchpad and saw that I have 48 outstanding bugs that have not been committed or released, though a few do have code that needs to be tested. Since I'm limited in the amount of fixing I can do, I see this as another way I can contribute to help get Evergreen bugs resolved. I also understand some of Dan's concerns and was thinking it might be good to reframe this discussion. Maybe we should look at the underlying problem, which is the issue of valid bugs that languish in Launchpad, and then consider ways that the community can support getting those bugs fixed. One idea is to go with the bug bounty system, providing some type of incentive (monetary or otherwise) to developers who fix bugs of a certain age. In thinking about the monetary incentive, I couldn't help but think about all the money and staff time that many Evergreen sites (including MassLNC) put into new enhancements without giving the same attention to long-standing bugs that need to be fixed. Even when the new enhancement has gone through thorough testing, it isn't unusual for it to introduce even more bugs that then get added to the list of bugs that need to be fixed. When Rogan first raised the ideas of bug bounties, I was seeing it as a way to provide a little more balance between all of the funding that supports new enhancements and funding that supports fixing bugs. Swag could be another incentive, but, since I anticipate one developer may be submitting fixes for several bugs, we might need to do a scale where fixing 1-5 bugs gets you a sticker, 10 gets you a t-shirt, and 20 gets you a bike. Or maybe we could do something where the person who has submitted the most bug fixes during a certain month gets a spotlight on the community web site. Incentives can take many forms. Another idea is one I raised at the June developers meeting regarding an Evergreen bug squashing day. I was left with an action item to e-mail the list about this idea, but I never followed up on it, partially because of other time commitments, but also because Dan Wells has been so effective in encouraging developers to review active pullrequests that I wasn't sure it was still needed. However, it might be a good way to encourage contributors to spend one day where they can focus on fixing bugs. The idea came from a Koha global bug squashing day that was held last May - http://wiki.koha-community.org/wiki/2013-05-10_Global_bug_squashing_day. The Koha community even had a scorecard of number of kittens saved to highlight the contributors who had the most bug fixes, patches reviewed, etc. I can't remember all of the categories, and the scorecard doesn't appear to be available online anymore. We could designate one day where contributors are committed to submitting code to fix bugs, reviewing bugs, signing off on the fixes, etc. Koha even provided sandboxes for people who do not have access to a testing server, but are interested in testing fixes. I think this would be a great way to encourage more people to get involved in the process. I don't think these ideas need to be mutually exclusive of each other. Maybe we could organize a bug squashing day sometime after the 2.5 release to see how many old bugs can be knocked off before running a test of a bug bounty system. Maybe there are other ideas out there for addressing the issue of
