Date
20-September-2021
Attendees
Guests: Oleksii Petrenko, Marc Johnson
Discussion items
| Time reserved | Description | Presenter | Details/Comments |
| 10 minutes | Status update | | Juniper Hot Fixes - Need a decision re: HF2 release:
Prior to upgrading HF2, institutions will have to clean up existing duplicate barcodes - the deployment will fail otherwise. It was discovered that some institutions can have many duplicates, 100K, so time is needed to 'clean' the data. - Back out unique barcode changes (and dropping of other indexes) from HF2. Instead, roll them into the Kiwi release
- Release notes for Kiwi will have to be updated to notify libraries of this change
- ICs will work with EBSCO-hosted libraries to address the duplicates issue
- Others in the community will need to work on addressing the duplicate issue for their respective institutions prior to upgrading to Kiwi
- Release HF2 without those changes
- After it become available, it will be applied to EBSCO hosted sites.
- In Cornell’s case, as part of their Juniper HF2 upgrade, we WILL apply the unique barcode changes (since it works fine for them)
Recommendation for HF2 is to:
Kiwi release preparation
Lotus timeline approval 
|
20 minutes Ran out of time, so will discuss this at special September 21 meeting | Identify next steps for circulation performance improvements | | Draft proposal discussed at the last Capacity Planning meeting–now we need to determine the next steps. - Address the 4 requests with highest response time
- Fetch automated blocks (546 ms response) – Vega has made a change in Kiwi that should reduce this.
- Fetch item by barcode (163 ms response) – Core Platform has made a change in Kiwi that should reduce this.
- Update item status (194 ms response) – Julian has proposed a change per MODINVSTOR-776, which is under discussion
- Fetch manual blocks (133 ms response) – Holly created ticket UICHKOUT-745 for Vega on Friday.
- Further technical discussion about options, in particular derived data option (using caching approach).
- Proceed with caching approach
- Discuss impact of caching with Resource Access SIG to identify what they will tolerate (i.e. if cached record is more than X minutes old, refresh it).
- Work on a spike to try out the caching option on one record type.
- After we are satisfied with the results of #3 b., implement caching for the other record types.
- Have the PTF team analyze the results as we implement them (e.g. after #1 a & b implemented, after #1 c & d implemented, after #3 b implemented, after #3 c implemented).
- Determine next steps based on PTF team analysis.
|
15 minutes Ran out of time, so will discuss this at special September 21 meeting | Elimination of institution ranking | | At the last Capacity Planning meeting we decided that we have outgrown the ranking process. Our plan for identifying work is to... - Use the pointing exercise results to prioritize.
- If a PO doesn't have highly pointed features, that PO should go to the PO group to see if they can take on a highly pointed feature for another PO.
- If #2 above doesn't resolve the issue, the PO should talk to the Capacity Planning Team.
Issues to address: - How does a site make it clear that a feature is a "showstopper" for them. We could continue applying a Label of "Cornell-showstopper", "TAMU-showstopper", etc. or we could create a multi-select field called "Showstopper for". (The drop-down for "Showstopper for" will include all sites. The only issue I have with this is this approach is that an editor would need to make sure the other institutions aren't de-selected when they select their institution.)
- Should we allow sites that have already ranked features to keep their ranks in JIRA? (We would remove the rank fields for sites that never actually ranked features.)
|
15 minutes Ran out of time, so will discuss this at special September 21 meeting | Redo pointing exercise? | | Should we redo the pointing exercise? Options - 1) We haven't actually used the results of the Kiwi pointing exercise, so we should continue on with them. 2) We could re-open the Kiwi pointing exercise spreadsheet for new institutions to participate and old institutions to make changes if needed. 3) Re-do the whole exercise for everyone. Background: Originally we called this the "Kiwi pointing exercise" because we thought we would be doing pointing for every release. When we saw the results of the "Kiwi pointing exercise" it became clear that we will not be able to implement all of the highest pointed features within one release, so it isn't appropriate to do pointing for every release. Instead, it makes more sense to do pointing after we have completed some of the existing highly pointed features. We have not done that. |