2021-09-21 Capacity Planning Meeting

Owned by Holly Mistlebauer
Last updated: Sep 21, 2021
3 min read

Date

21-September-2021

Attendees

Khalilah Gambrell
X
Mike Gorrell

Hkaplanian

X
Holly Mistlebauer
X
Jakub Skoczen
X
Mark Veksler

X

Anton Emelianov (Deactivated)

Aleksey Poflankov


Guests: Marc Johnson

Discussion items

Time reservedDescriptionPresenterDetails/Comments
20 minutesIdentify next steps for circulation performance improvements

Holly Mistlebauer and Marc Johnson

Draft proposal discussed at the last Capacity Planning meeting–now we need to determine the next steps.

  1. Further technical discussion about options, in particular derived data option (using caching approach).
  2. Proceed with caching approach (devs are familiar with this approach, as are users)
    1. Ask assigned team to come up with approach within 2 weeks.
    2. Try out the caching option on one record type (choosing the one with the biggest impact). 
    3. After we are satisfied with the process, implement caching for as many other record types as we are able during the release.  Note: Need to prioritize the rest of the record types so that we get the heavy hitters first.
    4. Have the PTF team analyze the results of caching work completed.
    5. Discuss impact of caching with Resource Access SIG (i.e. if cached record is more than X minutes old, refresh it).  Note:  We are waiting until we know the impact of caching on one record.
  3. Also address the 4 requests with highest response time
    1. Fetch automated blocks (546 ms response) –  Vega has made a change in Kiwi that should reduce this.
    2. Fetch item by barcode (163 ms response) – Core Platform has made a change in Kiwi that should reduce this. 
    3. Update item status (194 ms response) – Julian has proposed a change per MODINVSTOR-776, which is under discussion.
    4. Fetch manual blocks (133 ms response) – Holly created ticket UICHKOUT-745 for Vega on Friday.
  4. Determine next steps based on PTF team analysis.

Discussed briefly at the last TC meeting–will discuss more at this week's meeting (tomorrow).

If Circ Rules are updated, give person who changes them the right to refresh cache?  How would we know about all instances that need to be refreshed?  Do Circ Rules get updated that often?

Individual users will not be able to refresh, but we could add something to force a reload when a person logs in.

Holly will create a feature for caching, and link it to a spike to try the first record type.

20 minutes

(ran out of time–will discuss at next meeting)

Elimination of institution ranking
Holly Mistlebauer

At the last Capacity Planning meeting we decided that we have outgrown the ranking process.  Our plan for identifying work is to...

  1. Use the pointing exercise results to prioritize.
  2. 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. 
  3. If #2 above doesn't resolve the issue, the PO should talk to the Capacity Planning Team. 

Issues to address:  

  1. 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.)
  2. 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.)

20 minutes

(ran out of time–will discuss at next meeting)

Redo pointing exercise?

Khalilah Gambrell and Holly Mistlebauer

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.