Date

12 Aug 2020

Attendees

Discussion items

Time	Item	Who	Notes
5 Min	Quick update on Reference data/environments	spampell and/or Marko Knepper	From 7/29 - spampell and Marko Knepper have volunteered to assume the "Product Owner" role; clarify the problem and to break down the needs and potential approaches - goal is to deliver something of use for Q4.... Still a "To Do" - will follow up September 2nd.
25 min	Technical Debt Discussion	TC	We have the DEBT project and we also have a new IssueType of "TechDebt" that people have started to use in JIRA. What would we like to establish for a review process? Discussion: DEBT Project is more strategic... the IssueType are more tactical. The DEBT work has influenced work and moved things forward - so there has been progress, even if not specifically linked up. Nearly half of the list has had significant progress. Still, it would be nice to have those activities linked to the DEBT so that we can measure the progress or more easily get visibility into the project's effort towards addressing Tech Debt. Questions: How do we define "Done"... as in we've done enough for now? When is it no longer "debt"? E.g: Is a missing architectural feature now present? E.g.: Is there now an ongoing process that addresses the strategic issue? Does each ticket need to define when it is done? If we are to discuss/plan/review, at what Frequency - Every 6 months, lighter review, annually a deeper review Note more discussion and "grooming" might end up reducing the size of the list. What does the review process look like? Quick/Cursory review of the list - make adjustments as needed/warranted (i.e. close or ramp up activity) Assign TC member to go deeper on a topic if needed Annually a more thorough analysis to potentially add to the list and/or review current landscape Resolve to check DEBT project with every TC item discussed each week Identify places where we need to change priority or resource allocation Who should be part of the discussion (subset of TC, Tech Leads, Cap Planning, other)? Tech Leads will definitely have input and likely opinions on Tech Debt items. Also focused on a narrower portion of FOLIO and so might not have the perspective to comment on all items. General feeling is that ad-hoc inquiry makes the most sense, as requested by TC, and the goal is to make sure that TC is confident that plans and actions are appropriate.
25 min	Horizontal Scaling and other requirements	TC	From Marc Johnson on the TC channel: It came up during the Scrum of Scrums meeting that teams are going to be expected to conduct a review of the horizontal scalability of back end modules that they are responsible for. That suggests to me that horizontal scalability is intended to be a cross functional requirement for all back end modules. Is that the case? Is that something that the Technical Council might be interested in discussing? Discussion at TC: Discussed the origin of the message Marc posted. Some issues related to OAI-PMH in Goldenrod release triggered developments that brought this implied 'requirement' into question. Other cases of limitations in the ability to horizontally scale modules have also surface, usually in performance related work. On possible cause is failure to adhere to microservice principles and introducing statefulness, and thus stickiness, at the module level. Another cause is sometimes bottlenecks that exist, for example RMB, which render horizontal scaling ineffective. One outcome of this discussion is that perhaps horizontal scalability is an issue that TC should take a stand on. Definition of "horizontal scaling" Guidelines for implementing and confirming horizontal scalability Message was delivered by a Scrum Master - which is how a "Project Decision on a new requirement" would be delivered to teams - which hasn't happened. There is an opportunity for the various teams to establish if horizontal scaling is a widespread issue or merely the situation for a few modules. In the former case it would need to be elevated to the TC. We agree that this type of potential 'mandate' (ie. *that horizontal scalability is a cross functional requirement for all teams*) would need to be approved by TC before being carried to teams. Question - is there a set of principles that we ask developers to operate by in building FOLIO code? If not, we should have this. ACTION: Mike Gorrellto research whether this already exists somewhere. There is potential overlap with the previous discussion involving the definition of done. Some baseline definitions could be established by the TC and "included" in the individual team DoD definitions. To provide proactive guidance, some developer guides could also be created and made available through the developer website.

Time

Item

Who

Notes

5 Min

Quick update on Reference data/environments

spampell and/or Marko Knepper

From 7/29 - spampell and Marko Knepper have volunteered to assume the "Product Owner" role; clarify the problem and to break down the needs and potential approaches - goal is to deliver something of use for Q4.... Still a "To Do" - will follow up September 2nd.

25 min

Technical Debt Discussion

We have the DEBT project and we also have a new IssueType of "TechDebt" that people have started to use in JIRA. What would we like to establish for a review process?

Discussion: DEBT Project is more strategic... the IssueType are more tactical. The DEBT work has influenced work and moved things forward - so there has been progress, even if not specifically linked up. Nearly half of the list has had significant progress. Still, it would be nice to have those activities linked to the DEBT so that we can measure the progress or more easily get visibility into the project's effort towards addressing Tech Debt.

Questions:

How do we define "Done"... as in we've done enough for now? When is it no longer "debt"?
- E.g: Is a missing architectural feature now present?
- E.g.: Is there now an ongoing process that addresses the strategic issue?
- Does each ticket need to define when it is done?
If we are to discuss/plan/review, at what Frequency - Every 6 months, lighter review, annually a deeper review
- Note more discussion and "grooming" might end up reducing the size of the list.
What does the review process look like?
- Quick/Cursory review of the list - make adjustments as needed/warranted (i.e. close or ramp up activity)
- Assign TC member to go deeper on a topic if needed
- Annually a more thorough analysis to potentially add to the list and/or review current landscape
- Resolve to check DEBT project with every TC item discussed each week
- Identify places where we need to change priority or resource allocation
Who should be part of the discussion (subset of TC, Tech Leads, Cap Planning, other)?
- Tech Leads will definitely have input and likely opinions on Tech Debt items. Also focused on a narrower portion of FOLIO and so might not have the perspective to comment on all items. General feeling is that ad-hoc inquiry makes the most sense, as requested by TC, and the goal is to make sure that TC is confident that plans and actions are appropriate.

25 min

Horizontal Scaling and other requirements

From Marc Johnson on the TC channel:

It came up during the Scrum of Scrums meeting that teams are going to be expected to conduct a review of the horizontal scalability of back end modules that they are responsible for.

That suggests to me that horizontal scalability is intended to be a cross functional requirement for all back end modules.

Is that the case? Is that something that the Technical Council might be interested in discussing?

Discussion at TC:

Discussed the origin of the message Marc posted. Some issues related to OAI-PMH in Goldenrod release triggered developments that brought this implied 'requirement' into question.
- Other cases of limitations in the ability to horizontally scale modules have also surface, usually in performance related work.
- On possible cause is failure to adhere to microservice principles and introducing statefulness, and thus stickiness, at the module level.
- Another cause is sometimes bottlenecks that exist, for example RMB, which render horizontal scaling ineffective.
One outcome of this discussion is that perhaps horizontal scalability is an issue that TC should take a stand on.
- Definition of "horizontal scaling"
- Guidelines for implementing and confirming horizontal scalability
Message was delivered by a Scrum Master - which is how a "Project Decision on a new requirement" would be delivered to teams - which hasn't happened.
There is an opportunity for the various teams to establish if horizontal scaling is a widespread issue or merely the situation for a few modules. In the former case it would need to be elevated to the TC.
We agree that this type of potential 'mandate' (ie. that horizontal scalability is a cross functional requirement for all teams) would need to be approved by TC before being carried to teams.
Question - is there a set of principles that we ask developers to operate by in building FOLIO code? If not, we should have this. ACTION: Mike Gorrellto research whether this already exists somewhere.
- There is potential overlap with the previous discussion involving the definition of done. Some baseline definitions could be established by the TC and "included" in the individual team DoD definitions.
- To provide proactive guidance, some developer guides could also be created and made available through the developer website.

Browser not supported