Meeting Minutes for 11/05/2019

Discovery Committee Meeting
November 05, 2019
Minutes

Demo of new features, bug fixes, and documentation for the upcoming release

Discussion of development priorities for the next release 

Current Release

  • Montrose - New Marmot Member Implementation
    • Completed
  • Virtualize Flatirons Pika server
    • Will be completed in November
    • They are virtualizing their ILS at the same time
  • Sierra API Patron Integration
    • The whole team will need to focus on replicating existing functionality and test it out to make sure it is stable and reliable
    • The plan is to have this finished by the December release

Next Release

  • Record Grouping Adjustments
    • Rescheduled to begin in December
  • PHP Language Update and PHP 3rd Party Library
  • Stability Version - Will be worked on for most of 2020
    • Stability Version - Record Grouping: New grouping categories
    • Stability Version - Record Grouping: Language

Next Quarter

  • Stability Version - Record Grouping: Improved handling for grouping Category: Movie
  • Memcache vs Memcached
  • Control of Econtent Manifestation Display in Search Results and Grouped Work Views

 

Other Discussion Topics

  • MUG 2019 Pika prioritization summary (Minute 15:13;07)
    • This is the final report of the second prioritization activity leading up to the MUG conference that Marmot hosts
    • Marmot did the large grooming of the backlog from February - April 2019.
    • Marmot provided this backlog to members for feedback on selecting the priorities that will go into a Pika stable build.
    • Also to identify items that were put into a potential bucket and are features that are not oxygen but are really expensive chocolate that would appeal to a lot of people.
    • As the Pika team is working on the stable build priorities, they would like to be able to sprinkle in some of these chocolate features into the development sprints so they are making progress on those as well.
    • Marmot wanted to do a similar process and make sure that out of the entity of the items in the potential bucket that they were looking and prioritizing ones that relevant to members.
    • The original review of the backlog left the team with slightly over 60 tickets that were sent to the members of the Discovery Committee by survey in mid-September
    • Functional Area priorities from the survey were reviewed first looking at the results from voting members and associate members. There was a high degree of overlap between the two groups.
    • The team identified the items that had a very high level of priority assigned to them by ranking.
    • The team identified three functional areas that had the highest level of support from everyone and automatically included them in the stable build.
    • Anything that received a priority rating of 2 or higher by either voting members or discovery partners and put those into an activity at MUG
    • Ashley found the activity that prioritized collaboration with a forced ranking activity 
    • The team estimated the amount of time it would take to complete the priorities with a ranking of 2 or higher, and priced the ticket at a rate of 7 Pika pounds per day.  
    • The participants for this activity were given a set number of Pika pounds per library, and no one library had enough Pika pounds to buy some of the larger items on their own.  It forced the group to collaborate with each other to cooperate.
    • Out of this activity at MUG, the team was able to identify tickets that rose to the top and narrow it down by the investment that was made (the ratio) to the amount of Pika pounds or time that was required.
    • Items that had a ratio of 1 or higher were narrowed down into the priority list.
    • The report includes the full list of tickets that were sent out in the survey.
    • Appendix B shows all the items that had an average of 2 or higher what the minimum investment required.
    • This was a very data-informed, member-driven, and transparent process for identifying sone of the next steps.
    • Marmot intends to continue doing these types of activities at least yearly, so they can be looking to the future and planning the sprints farther ahead while making sure they are being responsive to what the Pika community identifies as being most important.
    • Adam suggested people look over the documentation and bring up any questions, thoughts, or suggestions on how to continue to improve this process and making sure that it reaches the goals of being iterative, member-driven, and transparent at the next meeting.
  • Macmillan boycotts: options for Pika display (Minute 25:08;04)

  • A few libraries are taking it upon themselves to create ILS eContent records that will display in search results depending on the cataloging of those records will group properly on the group works.
  • Pika team played a bit with the idea of maybe having some kind record available, but it might be more work for some libraries because they would have to create ILS records.
  • Another option is to use the Pika banner at the top of your Pika sites that has an Html editor, so you can link to pages with information. Contact pika@marmot.org, if you want help with creating a Pika banner.
    • Sarah from Sacramento shared her catalog to show how he manually ungrouped records, so her descriptions to their patrons would not be overwritten by the Syndetics description.
  • Sarah set up her access online button to direct their patrons to a page to explain more about what is happening with Macmillan titles.
  • Alysa commented that it looks like Sarah created a dummy bib and a dummy item record, and it looks like you can access it online.  If the item record was not included would that work a little better?  
    • Pascal commented that ILL URLs are particular to Marmot as ILS eContent.  If Marmot did something comparable it would still have the “access online” button and have the status of available online. He would have to look to see if they can modify the status. They could look into creating a new status for “not available online”.
    • Ashley commented that the tricky thing with Marmot would be having to have item records scoped to people’s holdings.
  • Cari asked there will be no message in OverDrive, correct?
    • Tammy mentioned there is a banner for the Marmot OverDrive site where a message could be displayed.
    • Alysa noticed that when a Macmillan title is purchased and a patron places a hold,  that OverDrive created an automatic message that has information about the restriction.
    • OverDrive created a banner for Maryland’s Digital eLibrary Consortium which includes the Anne Arundel County Public Library. 
  • Pascal mentioned it might be easy for the Marmot libraries to have a sideloaded collection, but someone would still need to generate these records from some source. For Marmot, the sideload would avoid having to recreate items records. The recordset could be shared among Marmot libraries who want to participate.  Even if you had a custom URL that you wanted direct your library patrons that can easily be done in Pika by replacing the existing URL with the one that you want. Finally, the record sets should not group with the regular titles to be effective. 
    • Ashley warned that as libraries start purchasing titles that libraries would have these arrant records in the ether that you would have to delete at some point from the ILS or sideload. 
  • Progress on Sierra patron APIs (Minute 38:11;07)

    • This information is specific to libraries who have the Sierra ILS.
    • The Pika team is working through the patron API for Sierra
    • They are down to the very fine details
    • This is a segway into the PHP 7 project and creating some standards to use with the API that will go into the PHP 7 project as well.
    • Marmot wanted input from Sierra libraries on self-registration, iii SMS, and My Account.
    • Self-registration
      • Self-registration minimum requirements that would not apply to your library’s special needs.
      • The team came up with: name, address, phone, and email.
      • Email would need to be required for libraries who have pins, so patrons can reset their pins via email.
      • Chris wanted to know if anyone would ever include the alternative phone, or telephone 2 in self-registration?
      • When Pika was screen-scraping the classic catalog the rules were already enforced. Now that they are not going to be screen-scraping anymore, they have to recreate some of the settings in Pika. Some will be admin settings.  Some might be configuration settings. Through the API, you can create an empty patron record, so that means they have to set everything for the self-registration.
      • The team will need from each library the default patron type for self-registration, the days before expiration (the team thinks 90 days is safe to use), and the patron agency code (if used).
      • According to Chris, no information has to be sent to the API to return a valid Sierra ID that will exist in Sierra.  However, no barcode is automatically generated, so the Sierra API has to generate a barcode. If anyone has any special requirements with temporary barcodes, they would like to hear about your requirements. 
      • They were thinking this defaults to a random six-digit number with something like the patron’s name to get good random numbers.
      • Pika will supply the branch code for the home library, and the MBlock. 
      • They cannot get the agency code from the API.
      • If you have any special needs, please email pika@marmot.org with those needs. Also, they would like to hear from any libraries that have a barcode range for these limited accounts 
    • iii SMS
      • What the team knows from digging through a ton of documents is that opting into SMS is as simple as providing a mobile phone. 
      • Jo asked will III SMS replace the use of ShoutBomb?
        • Marmot is using a third-party SMS service outside of iii SMS, so they do not need to worry about this part of the Sierra API integration.
      • The patron can have the same phone number in different fields, but removing the mobile phone number does not opt the patron out of SMS.
      • Basically, there is no way to opt a patron out of SMS through the API.
      • According to the documentation, patrons need to text the STOP, STOP ALL, END, QUIT, CANCEL, or UNSUBSCRIBE to 82453 or 35143 from the mobile phone number specified during the opt-in process.
    • My Account Settings
      • There are some things the API cannot do, so they will still need to be connected to the classic OPAC. This includes reading history opt-in and out, bookings, and the check-in grids (for now).  The team hopes to work through the check-in grids using Sierra DNA.
      •  As far as the notification settings go there is not a notification setting in Pika for none.  They will add that notification setting. If a patron only wants to know if their hold is ready by looking at their account in Pika, they can do that. 
      • Sierra has a booking module that allows people to reserve materials for a designated time. Currently, only Fort Lewis uses this module. Bookings in Pika will still need to go through screen-scraping. 

 

Next Meeting is Tuesday, December 3rd

 
Meeting Date: 
Tuesday, 2019, November 5
Documentation Type: 
Meeting Minutes
Committees: 
Discovery Committee