14:03:22 <kmlussier> #startmeeting 2014-12-11 - Evergreen for Academics meeting
14:03:22 <pinesol_green> Meeting started Thu Dec 11 14:03:22 2014 US/Eastern.  The chair is kmlussier. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:22 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:03:22 <pinesol_green> The meeting name has been set to '2014_12_11___evergreen_for_academics_meeting'
14:03:41 <kmlussier> #info The meeting agenda is available at http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:2014-12-11
14:03:52 <kmlussier> #topic Introductions
14:04:08 <kmlussier> Please feel free to introduce yourselves with the #info command.
14:04:20 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
14:04:26 <yboston> #info yboston is Yamil Suarez - Berklee College of Music
14:04:34 <mdriscoll> #info mdriscoll is Martha Driscoll, NOBLE
14:04:42 <phasefx> #info phasefx is Jason Etheridge - Equinox (and lurking)
14:04:47 <sandbergja> #info sandbergja is Jane Sandberg, Linn-Benton Community College
14:05:13 <D0nB> #info D0nB is Don Butterworth - Asbury Theological Seminary
14:06:10 <jihpringle> #info jihpringle is Jennifer Pringle, BC Libraries Cooperative
14:06:21 <kmlussier> Welcome everyone! :)
14:06:23 <Christineb> #info Christineb is Christine Burns, BC Libraries Cooperative
14:06:40 <kmlussier> People can continue introducing themselves as they come in.
14:07:16 <kmlussier> #topic Action Items fromthe  Last Meeting
14:08:06 <kmlussier> #info kmlussier sent an e-mail to the list to ask about academic PAC flavor ideas
14:08:24 <kmlussier> I offered to take over that action item from yboston since he volunteered to step up for authorities.
14:08:43 <kmlussier> #link http://markmail.org/message/ficcz33r4gb6ngwh
14:09:42 <kmlussier> We did get some ideas for the Academic PAC flavor, but I have yet to incorporate them on the wiki page.
14:10:15 <kmlussier> One concern I have is that the ideas are representative over the broader academic community using Evergreen.
14:10:46 <kmlussier> There were several libraries who indicated they wanted to see an Academic PAC flavor on the survey. However, we aren't hearing from many of those libraries.
14:11:15 <kmlussier> I'm just not sure how to reach out to those sites to get their feedback on the ideas.
14:11:53 <jck_> Do you know who the libraries are by name?
14:12:09 <kmlussier> jck_: The ones who filled out the survey?
14:12:15 <yboston> should we narrow are focus on one or two issues and send out another letter about it? just in case the narrower focus gets them interested
14:12:29 <yboston> alternatively, we can find volunteers to reach out to those libraries to get feedback
14:12:41 <jck_> Yes, the libraries that indicated interest on the survey.
14:12:58 <kmlussier> jck_: I can find that information. I can't remeber who they were off the top of my head.
14:13:30 <jck_> I can contact them if any were C/W MARS libraries.
14:13:38 <kmlussier> We did get good feedback from Asbury, which is nice. I just don't know if their ideas are things a lot of other academics would like to see or not.
14:13:46 <dbs> #info dbs is Dan Scott, Laurentian University
14:13:49 <kmlussier> jck_: I think there may have been a couple. :)
14:14:38 <D0nB> Everybody always like Asbury suggestions ;-)
14:14:49 <kmlussier> I would say there was a lot of interest in the "Read More" feature D0nB recommended. But I think there's interest in seeing it done in the main PAC, so maybe we can file a wishlist bug for that.
14:15:54 <kmlussier> So maybe jck_ and I can take an action item to follow up directly with some academics who showed interest in this work?
14:16:34 <yboston> I defiently expect that some of the changes that we identify in this group will end up just being default changes fro EG going forward; or just become features that just need to eb turned on
14:16:53 <kmlussier> #action jck_ and kmlussier to follow up directly with libraries that showed interest in an academic PAC flavor.
14:17:12 <kmlussier> yboston: Yes, and that might be a better approach than the academic flavor approach.
14:17:16 <jck_> kmlussier: Okay
14:18:24 <kmlussier> #mdriscoll sent a  message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets
14:18:37 <kmlussier> Bah! Let me try that again.
14:18:43 <kmlussier> #info mdriscoll sent a  message to Evergreen list to get feedback on requirements for batch patron load and for batch batch patron updates/deletes through patron buckets
14:18:58 <kmlussier> #link http://markmail.org/message/nfxovop3xxerxs33
14:19:05 <kmlussier> mdriscoll: Do you have anything you want to report on that?
14:19:11 <mdriscoll> I got a lot of feedback which I have incorporated into the wiki page
14:19:40 <yboston> Another approach is that we end up with "example" Academic TPAC templates, like there are currently "example" cron files or example OSRF config files in the intalation file for libraries to use as starter values as they customize their local system
14:20:24 <mdriscoll> One person said the functions would be of interest to a public library.  Certainly batch update and delete would be.
14:20:55 <kmlussier> yboston: Yes, that was my thought on the way to go with the academic flavor route. Files in a template directory.
14:21:00 <kmlussier> #link http://wiki.evergreen-ils.org/doku.php?id=evergreen_for_academics:batch_patron_functions
14:21:13 <phasefx> possibly related low-hanging fruit might be patron buckets.. the infrastructure exists, just no UI for it
14:21:19 <kmlussier> mdriscoll: I agree it could be useful for a lot of libraries.
14:21:42 <yboston> phasefx: +1
14:22:10 <kmlussier> phasefx: That's good to know.
14:22:14 <jck_> phasefx: +1
14:22:28 <mdriscoll> phasefx: +1
14:22:54 <kmlussier> mdriscoll: Do you feel like the requirements are in a semi-finished state or do you think they need more time for feedback?
14:22:54 <yboston> mdriscoll++ good job updating the wiki
14:23:09 <kmlussier> mdriscoll++ indeed
14:23:38 <mdriscoll> There are probably some more tweaks to do, but I think its a good start.
14:24:07 <kmlussier> It looks like there are a couple of outstanding questions in there too.
14:24:19 <mdriscoll> Galen mentioned patron addresses and its still an unanswered question of how many addresses to provide for.
14:24:23 * kmlussier will try to give some thought to those questions before the week ends.
14:25:14 <jck_> I think most of C/W MARS patron records have 1 or 2 addresses.
14:26:13 <mdriscoll> I vote for 2 addresses because that's what I do.  I don't know if anyone would need more, but it seems like providing for more than one is a good idea.
14:26:26 <kmlussier> Yeah, I was thinking that 2 was a good number.
14:26:42 <jck_> I agree on 2 addresses.
14:26:52 <jihpringle> two addresses sounds good to me
14:27:03 <yboston> I assume it would be OK to only have 1 address?
14:27:11 <kmlussier> yboston: yes
14:27:53 <kmlussier> It sounds like we have a consensus here.
14:28:10 <kmlussier> mdriscoll: Can you expand on your authorization question?
14:28:14 <mdriscoll> I'll update the wiki and say 2 addresses.  If anyone objects, they can speak up.
14:28:50 <mdriscoll> I mean permissions to update/delete the records.  Can you update records that don't "belong" to your library.
14:29:59 <kmlussier> mdriscoll: I'm thinking it should be done in a similar fashion as the patron update permissions.
14:30:36 <kmlussier> But my question is: do we want a separate permission to handle a batch of patron updates/deletes or should it just be tied to the current permissions for updating/deleting patron records?
14:31:46 <jck_> A separate permission for batch updates and actually a separate permission for batch deletes would be safest.
14:32:06 <jihpringle> agreed
14:32:09 <mdriscoll> I would have to think of some use cases.  In our situation, a public library patron can be edited by other public libraries.  That could be more permission than is safe in a batch function.
14:32:27 <mdriscoll> jck_: agreed
14:32:42 <kmlussier> Yes, of course. I was forgetting that. So more reasons for the separate permission.
14:33:34 <kmlussier> OK, I'm going to move on to other past action items now, but maybe later we can talk briefly about what we do with these requirements now that we have them. :)
14:33:40 <kmlussier> Overall, I think they look really good.
14:33:43 <kmlussier> mdriscoll++
14:34:18 <kmlussier> yboston: I have an action item that you would take charge of the authorities group. But I don't know if there were any real "actions" related to that item.
14:34:28 <kmlussier> Do you have anything to report or should I just move on to the next action item?
14:34:56 <yboston> I did write a tiny little bit of authorities code, but I have not shared the branch so I can get feedback yet
14:35:09 <yboston> I will do it by next week
14:35:17 <kmlussier> OK.
14:35:32 <kmlussier> #action yboston to share authorities code he has been working on.
14:36:08 <kmlussier> #info D0nB identified reaining LC Call Number issues and reported back to the group.
14:36:20 <kmlussier> #link http://markmail.org/message/ppf4dmovfjy2lw4j
14:36:31 <kmlussier> D0nB: Do you have anything to add on that front?
14:36:45 <D0nB> Not particularly
14:37:04 <D0nB> Response from the group at large was pretty small
14:37:22 <D0nB> Not sure if there is little interest
14:38:12 <D0nB> But there is a big list of tweaks that can be worked on by programmer types
14:38:29 <kmlussier> D0nB: It's hard to say. I don't think we've heard that call numbers have been a particularly thorny issue for our libraries. But there was some interest on that survey that went out.
14:38:41 <D0nB> Anybody have any questions?
14:39:34 <D0nB> What little feedback I have gotten I'll get on the wiki
14:40:06 <kmlussier> D0nB: Just a thought. One way to get those tweaks in the direct line of sigh for those proramer types is to file LP bugs on the problems.
14:40:19 <kmlussier> I know there are already some bugs reported, but I think some may be new too.
14:40:28 <D0nB> OK
14:40:36 * kmlussier will move on to the next action item.
14:40:38 <yboston> We have had plenty of small issues, though I have had hard a time explaining our issues since I am not a cataloger and we have a brand new cataloger
14:41:20 <D0nB> I am an experienced cataloger
14:41:33 <D0nB> Just let me know how/if I can help
14:41:49 <kmlussier> yboston: Maybe when the new cataloger is up to speed, they can help explain them.
14:42:01 <yboston> that is what I hope to do
14:42:18 <kmlussier> #info posted testing feedback for bug 1389403 and has signed off on it.
14:42:18 <pinesol_green> Launchpad bug 1389403 in Evergreen "OPAC numeric search's call number search bug with LC call numbers " (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1389403
14:42:27 <yboston> kmlussier++
14:43:07 <kmlussier> OK, moving on to new business, I think we covered most updates during the action item updates.
14:43:16 <yboston> quick question
14:43:23 <kmlussier> Sure, go ahead.
14:43:38 <yboston> can that patch be a candidate for being backposrted to older versions of EG?
14:43:51 <yboston> *backported
14:44:04 <kmlussier> yboston: I think it's up to the release maintainers, but I would think so. It's a bug fix, not a new feature.
14:44:25 <yboston> I plan to ask ESI to load it on our 2.6 server anyway, but I wanted to bring it up for the sake of others
14:44:28 <kmlussier> dbwells may be a better person to answer that question, though.
14:44:50 <yboston> is bshum the release manager of 2.6?
14:45:01 <kmlussier> Actually, the milestone on the bug is 2.7, which is a backport.
14:45:03 <yboston> no, he is 2,7 I beleive
14:45:18 <kmlussier> bshum is the 2.7 release maintainer. dbwells is 2.6
14:45:27 <yboston> thanks
14:46:04 <kmlussier> Although we've had updates for the sub-groups, I think it's worthwhile to discuss some next steps, especially for something like patron loading, which seems to be in very good shape.
14:46:24 <kmlussier> #topic Next steps for projects
14:47:00 <kmlussier> Now that we have some solid requirements for one of the projects, where do we go from here?
14:48:02 <kmlussier> Are there institutions interested in funding the projects? Or does somebody want to take the next step to see how much interst there is in the community to fund it?
14:48:58 <kmlussier> This question could also be directed towards any of the other projects we've been discussing.
14:49:49 <mdriscoll> It would be interesting to know what kind of cost something like this would be.  That may affect interest in funding it.
14:50:20 <kmlussier> Sure.
14:50:50 <mdriscoll> How does the web client development affect something new like this?
14:50:52 <kmlussier> Given what phasefx said about the patron bucket infrastructure being there, I also wonder if that's a good project to start with.
14:51:11 <kmlussier> Or maybe it's better to look at all of it at once.
14:51:31 <yboston> mdriscoll: that is an excellent question
14:51:35 <kmlussier> mdriscoll: Given that this is related to patrons, I think it would have to be developed for the web client since patron functionality has already been ported over.
14:51:58 <eeevil> (sorry to butt in, but...) regarding cost (and reducing it), ESI wrote a student/faculty info loader for UPEI long ago and then updated it to work with the core staging schema (when that happened)... you may want to reach out to them.  I think my copy of the code was lost with SVN :(
14:52:13 <jck_> Buckets can have limits to the number of updates that can be done efficiently so we should identify if that will be a limitation.
14:52:21 <jihpringle> I'd be interested in seeing mock-ups of what we want the user interfaces to look like (thinking of the patron batch loading)
14:52:23 <kmlussier> eeevil: But is it available in the client?
14:52:56 <eeevil> kmlussier: it was completely automated, no staff interface required. insert and update as needed
14:53:06 <kmlussier> eeevil: I think most of the academics here have some kind of script, but are looking at building it into the client to make it easier for libraries to handle their own updates.
14:53:22 <eeevil> ah, well, I'll step back then :)
14:53:35 <phasefx> jck_: buckets as exposed in the current xul client have limitations, but new code could be written server-side to bypass those
14:53:44 <kmlussier> eeevil: No, that's fine. It's always best to know that we aren't missing something that's already there.
14:54:22 <jeffdavis> It might be worth looking at some of the different custom patron batch load tools to see the range of desired features, but I thought mdriscoll did a great job of accounting for a lot of considerations.
14:54:25 <phasefx> jck_: in other words, do batch edits on the server rather than in the client, implementation-wise
14:54:58 <jck_> phasefx: Thanks.  I was thinking buckets on the client side.
14:55:09 <kmlussier> mdriscoll: I'm looking at the performance section for the patron loader. It might be nice to have a similar section for the buckets.
14:55:31 <mdriscoll> jeffdavis: that would be interesting!
14:55:42 <mdriscoll> kmlussier: I'll add that.
14:55:49 <yboston> BTW, I would be OK to continue to use a non-GUI batch import solution, if it has some/most of the features we have put up on the wiki list
14:56:25 <yboston> also, there is often some limitaton to using GUI tools, like a mximun number of students that can be batched at once
14:56:56 <eeevil> yboston: the reason I raised the UPEI code is that it covers things like statcats and addresses (including updates to both) ... fwiw. but, no user UI
14:57:03 <yboston> it would be great if there was a singular back end logic that could be tapped irregardless if one uses a GUi batch loader versus a GUI tool
14:57:04 <mdriscoll> I have had academic IT staff ask me if we had a web interface to send the records to.  A hands-off solution is not out of the question.
14:57:27 <mdriscoll> eeevil: statcats++
14:57:27 <yboston> mdriscoll: good to know
14:57:42 <kmlussier> Would somebody be interested in taking an action item to gather the scripts that are already being used?
14:57:58 <jeffdavis> kmlussier: I'll do that.
14:58:05 <kmlussier> jeffdavis++
14:58:17 <mdriscoll> jeffdavis++
14:58:20 <yboston> jeffdavis++
14:58:27 <kmlussier> #action jeffdavis to put out a call for current patron loading scripts that are already in use.
14:58:32 <jeff> jeffdavis++
14:58:50 <kmlussier> What about the mock-ups jihpringle mentioned? Do we want to work on those?
14:59:14 * kmlussier notes that we're quickly reaching the one-hour mark.
14:59:24 <mdriscoll> Maybe wait for the scripts to make sure we have the feature set complete?
14:59:29 <yboston> which mock-ups are those?
14:59:59 <kmlussier> yboston: jihpringle had said it might be good to see make some mock-ups of what we would like to see in the client for the patron loader.
15:00:08 <kmlussier> But waiting on the feature set works for me too.
15:00:24 <kmlussier> OK, it sounds like we have some next steps for these projects.
15:00:30 <jihpringle> we also may want to do a mockup of an academic flavoured pac
15:00:36 <kmlussier> Does anyone have any other topics they would like to bring up?
15:01:08 <kmlussier> jihpringle: D0nB has created a mock-up for the pac.
15:01:56 <kmlussier> It would be good, though, to make sure we have some consensus on what an academic pac means.
15:02:37 <D0nB> I think it would be great if others would try their hand at a mockup
15:03:09 <D0nB> Given the "read more" comments, I would want to revise my original try
15:03:22 <kmlussier> Does anybody want to work on that?
15:03:47 * kmlussier feels like she needs feedback from more libraries before trying to create anything.
15:04:58 <kmlussier> Well, let's leave it as a task that's available for anyone who has the tuits.
15:05:15 <kmlussier> Any other comments before I end the meeting?
15:05:27 <yboston> I would focus for a bit on the
15:05:34 <yboston> title versus copy holds
15:05:45 <yboston> issues of the PAC.
15:06:00 <yboston> That is what I think a good area that will need a toggle switch
15:06:12 <kmlussier> A toggle to do what?
15:06:18 <yboston> turn it on or off
15:06:36 <yboston> or is there such a thing already and we only need better documentation?
15:07:05 <kmlussier> I could be wrong, but I think you just need to give the right permission to patron to surface the volume/copy holds in the pac.
15:07:13 * kmlussier hasn't tested it, though.
15:07:48 <dbs> it's hard-coded right now as staff-only
15:08:04 <kmlussier> dbs: OK, thanks for correcting me then.
15:08:13 <yboston> dbs: thanks
15:08:15 <kmlussier> Maybe I'm thinking of jspac
15:08:44 <dbs> around line 160 of Open-ILS/src/templates/opac/parts/record/copy_table.tt2 "IF ctx.is_staff"
15:08:48 <kmlussier> I'm going to wrap up the meeting now, but we can continue discussions if we want to.
15:08:54 <kmlussier> #endmeeting