2021-08-30 Capacity Planning Meeting




Guests: Oleksii Petrenko

Discussion items

Time reservedDescriptionPresenterDetails/Comments
10 minutesStatus update

Issue - Mod-source record storage.  Needs a hotfix for Iris.  A data consistency problem when importing data using external tools creates a bad record ID (duplicate record id's).  A script is ready.  A SQL script should run prior to Juniper upgrade to check for duplicates.

Solution, Apply this fix to Juniper.  What are the next needed steps?

They will upgrade to hotfix for Juniper 1.  Should include the the circ block/barcode fix.

Need to discuss with spitfire team 1st.  Script should identify the data for libraries that they can be fixed by the customer at the database level.

ModInvstor - 523 should be included.

Script needs to identify the records.  Discuss with Ann-Marie if import could be used to fix these.

Do we need protection from loading data directly to the database?  

Teams will meet to discuss solution.

Timing for hotfix 1 for Juniper?  Will check if it can be released this week.  September 10th.

5 minutesNext Monday is a US HolidayHolly Mistlebauer

Should we skip our meeting or reschedule it?  (BTW, I will be OOO September 1-8.) 

Will skip meeting on September 6.

FYI (no discussion needed)Circulation Performance Proposal

Marc Johnson was planning to present a proposal about the check out performance challenges at today's meeting, but was pulled in on other issues and will not be ready until next week.  Hkaplanian :  Please add Marc to next week's meeting.  I will be out, but we should proceed anyway.  Thanks.

15 minutesCirculation HotfixOleksii Petrenko

Is it needed?  If so, which release and when?  (For what?–Holly)

If you are talking about https://issues.folio.org/browse/MODPATBLK-91 and https://issues.folio.org/browse/MODPATBLK-94, Cornell needs these fixes ASAP.  We can't really wait for a planned hotfix.  Cornell is experiencing 10-12 second checkouts that these tickets should fix. I am happy to do testing on BugFest so that we make sure these tickets don’t break anything else--Holly

5 minutesPlans for ZakHolly MistlebauerZak's last day as a community developer is September 24.  Zak mentioned that he will spend part of his time doing community work.  What will this entail?   
10 minutesProkopovych Team Capacity

As of September 27, when Zak is no longer on the Prokopovych team, we will have the following capacity:

  • 1.0 FTE backend devs (at any given time)
  • 1.5 FTE frontend devs (firm, given Michal and Matt consistently give their planned time)

Given the volume of issues assigned to the team, and expectations by the project, we need more devs.

In order to manage expectations, please note that...

  • We are merging the ElasticSearch FE changes (UXPROD-3046) with only 20% test coverage (Falcon didn't write any tests and we don't have time to write all of the tests before Kiwi is released).  Zak will create JIRA tickets for the test coverage and Michal will finish as many of these test tickets as he is able before the September 17 code freeze.  (Michal is out this week, so he will only have two weeks of work before the freeze.)
  • We will not finish all of the RTL/Jest tests by the end of September, as required.  We are starting on them in Sprint 122 (which started today) and will continue working on them as part of Lotus.
  • We will not likely generate any Karate tests before the September 17 code freeze.  Our BE devs have been asked to work on other tech debt.  Holly is working with the POs to define what tests are needed.  We will plan to generate tests as part of Lotus.

Prokopovych priorities between now and September 17 code freeze (see our Scrum Board)...

  • CIRC-1181: Performance of checkout process.
  • UXPROD-3046:  Implementing ElasticSearch FE changes and completing as many test as possible.
  • Other tech debt, such as inventory performance and permissions fixes.
  • CIRC-1182: Performance of check-in process.  (Will be worked on by Marc after CIRC-1181 is further along.)

15 minutesInstitution RankingHolly MistlebauerWe currently have 29 institutions with a Rank field in JIRA.  Anya has requested that we add 33 more.  The process we are using has become unwieldy.  Our plan was to use the "points" to plan most work, but then use the "rankings" to determine what to do next when nothing is highly ranked for the team/epic.  Perhaps the POs should work with the appropriate SIG to determine what to work on when nothing is highly pointed?  Then we can eliminate the ranking process.  Thoughts?