...
| Members | Attended |
|---|
| Khalilah Gambrell | X |
| Mike Gorrell | X |
| Harry Kaplanian | X |
| Holly Mistlebauer |
|
| Jakub Skoczen | X |
| Mark Veksler |
|
Guests: Ann-Marie Breaux (Deactivated), Oleksii Petrenko, Marc Johnson Anton Emelianov (Deactivated)
Discussion items
| Time | Item | Presenter(s) | Notes |
|---|
| 30 minutes maximum | Approvals for R1 2021 Hot Fixes Export Manager - health checks (Khalilah) |
issuesfolioorgandissuesfolioorgSRS Query API (MODSOURCE-265) (approved) Data Import (Ann-Marie) See Ready for CPT section of https://folio-org.atlassian.net/secure/Dashboard.jspa?selectPageId=11810 SRS. | Khalilah Gambrell | Questions to answer: - What is issue?
- How many people are impacted?
- What is effort to fix it?
- What will it take to test the fix?
|
| Addressing Quality Debt – URGENT!!! | | After the discussion at the Cap Planning meeting, I (MV) suggest for Anton to present at the key venues, such as Scrum of Scrums, PO meeting, Tech Council, Product Council. - Quality memo from Anton:
- Allocating % sprint capacity for technical debt didn't work because very little progress has been made. I have dashboards to prove it:
- https://
|
issuesfolioorgissuesfolioorg- net/secure/Dashboard.jspa?selectPageId=11818
- That being said, UXPROD testing features should be estimated and assigned to a release and they should be treated equally as functional features. If they are not included into release they'll never get done. If they are rolling from release to release they'll never get done either. For example, instead of having https://
|
issuesfolioorg- net/browse/UXPROD-2697: Karate it should be Karate R3 with concrete list of testing stories assigned to both R3 release and this feature. @kg did it right for https://
|
issuesfolioorgissuesfolioorg- net/browse/UXPROD-3094.
- Story points for UXPROD testing features should represent % of total capacity for a dev team. This % should be defined by Capacity Planning for each team individually. According to a number of defects the team generates historically from release to release.
- For R3 prioritization purposes, testing features should focus on modules that produce the highest number of defects. Here is the dashboard to illustrate the point.
- Testing work can take lower priority for modules that are stable and don't produce a high amount of bugs.
- UI modules should focus on RTL/Jest migration first and E-2-E Integration tests second.
- BE modules should focus on Karate tests.
- Regarding UI E-2-E testing - each team should complete a spike in R2 (see the top widget) to be able to estimate work to create E-2-E tests in R3
|
| Discuss what is going to happen next with optimistic locking | Jakub Skoczen | At the May 24 meeting we decided there would be an update on the progress of optimistic locking work. This "feature" is one of the highest pointed "features". Charlotte: Inventory work (started in R2 2021): |
Jira| JIRA | | serverId | 01505d01-b853-3c2e-90f1-ee9b165564fc |
|---|
| key | UXPROD-3089 |
|---|
|
|
| Holly's reduction to 50% on FOLIO effective August 1, 2021 | Holly Mistlebauer | Currently OLE pays for 50% of my time and Cornell donates 30%, for a total of 80% on FOLIO. My OLE contract is up on June 30, 2021, and it appears that it will not be renewed. Cornell has agreed to donate 50% of my time to continue on FOLIO, but aren't in a position to donate the full 80%. I will not be able to keep all of my current responsibilities at 50%, so I will need to give up some things. I want to determine what the project needs me for most, with help from this group. |
| R3 2021 Kiwi timeline | | Kiwi (R3 2021) |
| R2 2021 Juniper Feature freeze overdue | |  Image Added
|