2021-07-12 Capacity Planning Meeting

Date

12-July-2021

Attendees

Khalilah Gambrell	X
Mike Gorrell	X
Hkaplanian	X
Holly Mistlebauer	X
Jakub Skoczen	X
Mark Veksler	X

Guests: Oleksii Petrenko , Charlotte Whitt , Ann-Marie Breaux (Deactivated)

Discussion items

30 minutes maximum	Approvals for R1 2021 Hot Fixes	Ann-Marie Breaux (Deactivated)	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? Approved two hotfixes from Ann-Marie.
10 minutes maximum	Status update	Oleksii Petrenko	Reviewed some hotfixes not labelled as approved.
	Prokopovych team back-end capacity	Holly Mistlebauer	Announcement: On paper the team has 2.5 FTE BE devs, but in actuality it's more like 1.0 FTE. This will really impact our ability to fix bugs and develop Karate tests during the Kiwi development cycle.
	Holly's reduction to 50% on FOLIO effective after Juniper released	Holly Mistlebauer	SHORT TERM: Currently OLE pays for 50% of my time and Cornell donates 30%, for a total of 80% on FOLIO. My OLE contract was up as of 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. LONG TERM: I am entering a phased-retirement on February 1, 2022, when I start working half-time. This half-time will be spent on FOLIO for one-year, until I retire on January 31, 2023. Holly will leave the Capacity Planning Team over the next month–Mike has indicated that the Community Council plans on making changes anyway. Harry will take over the agendas, meetings on Outlook, etc.
	Need BE developer to work on FOLIO-3215	Mark Veksler	Request from the Tech Council to find a team that can allocate a BE developer to work on FOLIO-3215 - SPIKE: Improved Reference data handling during upgrades PoC OPEN Formalized Recommendation: Improved Handling of Reference Data During Upgrades Prokopovych is the logical team, but doesn't have BE capacity (see agenda item above). What about Vega? Harry and Mark will discuss this outside of our meeting.
	Discuss use of JIRA Issue Type "Bug"	Holly Mistlebauer	Issues related to what we define as a "bug"... Historically, I have created bugs in situations where I (as PO) made a mistake in a user story by overlooking something or stating something incorrectly. I believe the the PO is part of the dev team, so POs are the cause of bugs too. The devs don't want PO bugs to count against them because they are "graded" based on the number of bugs they have. POs need these to be bugs because only a bug can be part of a bugfix/hotfix release. 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... No public statistics? We don't need to compare teams with stats that have no context. Comparing teams is anti-Agile. Find other ways of measuring team success in a non-public way. Share information about the "spirit" behind the statistics. No intention to shame specific teams. What are we actually doing with statistics? Who is doing something with this information?