Meeting Minutes 12/06/2022

Discussion Topics

• OverDrive Lucky Day (Minute 00:28)
  • If you are considering using Lucky Day, essentially these titles are not discoverable from library catalogs or available in API integration.  
  • They are meant to be like the Lucky Day items patrons physically see in the library when walking into the building. When someone is browsing in the Libby app, a Lucky Day item is available, then they get to checkout the item. 
  • Designating copies as Lucky Day will decrease the number of copies displayed in the catalog. This means that any Lucky Day items will not display in your catalog at all.
  • Lisa mentioned that their library was the one that brought up Lucky Day. She mentioned that there are a few issues with Lucky Day. First, you have to have more than one copy of a title in order to use Lucky Day. Second, if your library is using Advantage Share, those titles will be available to all member libraries so your library will no longer have preference.

• Marmot indexing review (Minute 07:37)
  • With the last couple of releases, one issue with the Marmot Pika site is that the index is very large. The main trouble is to do a full reindex that takes the majority of the night to process.  On some days when the performance of the server is slow, it will cut into the morning when people are using the service. 
  • The full index has been disrupting search results in a number of ways. The Pika team has been trying to investigate ways to alleviate this problem. The main way that Pascal has been investigating it is by trying to see if they could reduce the size of the index mainly by reducing the use of the location scopes. It looks pretty clear that a lot of the location search scope fields are often redundant to the library-level search scope. If they could correctly remove those location search scopes this would be saving a lot of data from being indexed, as well as time from being indexed. Unfortunately, Pascal has not been able to make a breakthrough on that concept, so it is still a work in progress.        
  • The other idea the Pika team is exploring is instead of doing a nightly full index, do the index once a week. The preference would be to do the index on the weekend. The team has been exploring that option on their test server to see what things they would need to adjust to be able to put that into production. That option is still in the exploratory phase. Pascal wanted to call out these options because a lot of his focus has been on resolving this issue.
  • A question was asked about having to delete location codes a library is not currently using. 
    • Pascal responded that this is not about shelf location codes. These are the Pika locations.  A library has a search scope for each specific branch. Each specific branch will have a search scope of its own as well to enable the OPAC mode search so your in-building catalog terminal. Searching on that machine has additional features of that scope that can be localized to that building or specific branch.  There is a lot of data that is created duplicating all the search field values that exist at the library level. With some smarter handling, they could just use the library search scope when it is known that it is redundant.
    • A single branch library would have the shelf location code that would have the words, “It’s Here”. While the library system scope would have the words, “On shelf”. 
  • What changes with the once-a-week indexing is Pika settings that get changed that do affect indexing and would not take complete effect until the full index takes place.  Search results will not be incorrect because the continuous indexing process keeps things updated. They would build a process that does not wait for the nightly full update when you upload new updates for sideloading. This would be a smaller nightly process that handles sideload updates so they will show up in search results the next day.  

• Ubuntu server build and migration project (Minute 12:03)
  • Chris is working on a new server to replace CentOS 7 machines that are starting to age. 
  • Flatirons will be the first libraries to go onto the new server in the next week.
  • Marmot intends to move all the libraries to these new Ubuntu servers.
  • The support for CentOS is going away or becoming costly, so they have to migrate to a new Linux operating system.
  • There has been a problem with the Flatirons production servers since the Apache security update that they had at the beginning of the year that has been causing web server problems that are unique for their site. The only solution Marmot came up with was to migrate them to a new server on a new OS. It does appear that migration will solve the problems they have been having with the Flatirons production server this year.  

• Progress on the MLN2 migration project (Minute 13:40)
  • The Flatirons consortium is dissolving and all six libraries are joining Marmot as full members.
  • In regards to Pika, Ashley has been getting them up to speed on what they will need to handle as individual admins at their respective libraries. 
  • Those libraries are going to stay on the same Sierra server. Those libraries will also maintain a separate Pika server. Resource sharing with all six libraries will be done through Prospector.
  • MLN1 libraries will not see the MLN2 library physical items in Marmot’s existing MLN1 Pika interface. The now-dissolving Flatiron group will still maintain the Front Range Downloadable Library OverDrive consortium. They will not be contributing to the Marmot OverDrive consortium. 
  • Adam mentioned that the migration project is not about how to keep the Flatirons libraries separate from the Marmot libraries. All libraries will be Marmot members. This is really about how Marmot can start to incorporate a different approach to the server provision for Sierra compared to the past. Ultimately, in terms of the shared index, Marmot is hoping over time particularly as they look into Resharet that the two indexes will be blended into one at some point.       

Demo of new features, bug fixes, and documentation for the upcoming release (Minute 24:30)

• Release Notes

Other discussion topics 

• Discussion of development priorities for the next release (Minute 40:21)
  • Tech debt focus for 2023
  • Projects include:
    • Islandora upgrade and associated Pika updates
    • Pika accessibility development
    • Supporting software upgrades
    • Migration of all Pika boxes to Ubuntu OS
    • Pika reindexing optimization
    • The team will pick back up on the prioritization process for new feature ideas in Q4 2023

The next meeting is Tuesday, March 7, 2023