Guests: Oleksii Petrenko
|30 minutes maximum||Approvals for R1 2021 Hot Fixes|
Questions to answer:
Approved MODORDERS-542 and MODINVSTOR-744 as a last minute addition to the R1 2021 Hot Fix #3 release.
|10 minutes maximum||Status update||57% of test cases have been passed.|
|What should BE devs on Prokopovych focus on for Kiwi?||Holly Mistlebauer|
As mentioned at last week's meeting, the Prokopovych team has 2.5 FTE BE devs on paper, but only about 1.0 FTE in actuality. We need to focus our limited BE capacity on what is most important. Aside from critical bugs that pop up with Juniper, what should we focus on first?
(Note: Code freeze for Kiwi is in less than two months, on September 17th.)
Creating Karate tests is important, but we really need to figure out how to improve performance with checkouts and check-ins. It is summer now, so performance will get worse when the fall semester starts. The likelihood that we will have a long-term fix in place by then is slim, but we need to start on this ASAP.
The team is focused on fixing P1 and P2 BE bugs right now. We will see if another team can donate a BE dev with circ experience to work on bugs while our BE dev focuses on this research.
We will start with checkout given patron is standing at the circ desk waiting (while check-in is usually completed without the patron standing there). Our person should work with Martin. We should define both short-term and long-term solutions.
Need to include test where data import is occurring while doing checkouts and check-ins.
Planning roll out of implementation of Elasticsearch in Inventory - timeline: Lotus?
The current technical approach for search in Inventory is using PostgreSQL, JSONB columns, CQL and RAML Module Builder. Using Elastic Search as a long term solution has been explored Autumn 2020 - Spring 2021 (POC). We should now plan for when to swap the current solution and use Elasticsearch in production.
Harry will talk to Magda and Khalilah about the long-term plan and how to research it.
|Hold for next week–ran out of time||Continue discussion of JIRA Issue Type "Bug"|
Issues related to what we define as a "bug"...
This issue was discussed ages ago, along with the possibility of making a new JIRA Issue Type for PO bugs. I'm not sure that is the answer. Perhaps we need to stop "grading" the teams on bugs? We have situations where the dev team that caused the bug is not the dev team that fixes the problem. This also counts "against" the dev team that fixes the bug.
(See Cate's document)
Need to discuss further. Some ideas/questions from last meeting...