2022-07-06 Meeting notes

Zak Burke will take notes today. Ingolf Kuss is next, followed by Maccabee Levine 

All

None; subgroup is forming related to TCR-9

All

• Tech evaluation: Tod Olson anticipates having more time to dedicate to this in the near future; will check in 7/20, and anticipate discussion on it at WOLFCon. 
• Need help from devops in order to figure out permissions and resolve some comments in the repo. Radhakrishnan Gopalakrishnan anticipates resolving comments on RFC PR #3 (localizing API backend messages). 
• i18n: Tod Olson suggests active recruitment but we don't know who to request. Radhakrishnan Gopalakrishnan may be able to assist. Zak Burke will repost recruitment request to Slack#general

• Nothing new open; RFC #3 discussed above. Radhakrishnan Gopalakrishnan will begin work with Olamide Kolawole on Kafka soon. 

• CC did not meet this week due to US's July 4th holiday; no relevant updates from PC.

Revisit the various roles and responsibilities within the Technical Council: help set expectations for new members. 

• Chair, co-chair: Craig McNally is Chair and Jeremy Huff is co-chair; both happy to continue. 
• Scribe: responsibility rotates by last name; meeting chair is exempt. This is akin to "secretary" and as an office is responsible for recording decisions. PLEASE NOTE: Recording decisions is very important, so call out "who is doing what" for action items and consider being more formal with technical decisions, capturing them into ADRs. 
• Liaisons to PC & CC: Tod Olson and Marc Johnson , both happy to continue unless others want it. 
• Participation and Attendance expectations: attend or send a proxy. There is not a rule about participation in subgroups (whether from the TC or off-council folks) but more is better! Subgroups page tries to estimate the anticipated level of effort so folks can ascertain expected commitment. 

• Sobha Duvvuri , guest from FSE, will present some examples encountered by hosting providers. Impt for hosting provider to read release notes for a flower-release. Breaking changes in any FOLIO module could break non-FOLIO integrations, e.g. in edge-modules that are not part of FOLIO. Pretty hard to find breaking changes notes in the GitHub repo of each individual module; would be really helpful to have that in the flower-release wiki page.
  • major changes made in requests broke VuFind, which is directly integrated, not via an edge-module. Could break FSE's integration, or self-hosted libraries' integrations. So need to widely publicize "this breaking change might impact..." This will allow clients to start thinking about this earlier, before deployment, rather than when an upgrade happens and then things are broken.
  • erm introduced new, optional, storage mechanism. But the previous default stopped working, IOW needed to make a change in order. Documentation discussed new permissions but did not discuss the feature in detail. 
  • Summary: really hard for a non-FOLIO development team to keep abreast of breaking changes when there is so much going on (so many modules, so many breaking changes, so many teams, ...)
• Tod Olson : have heard the same from sysops folks, i.e. breaking changes that are not well-documented is a pain-point felt by many.
• Craig McNally : less important than any specific example is the need to set expectations about how breaking changes are communicated. 
• Marc Johnson : if we are going to discuss specific examples, should invite those teams to be present. 
• Radhakrishnan Gopalakrishnan : WRT release notes: we could require release notes to have a very specific format, e.g. with breaking changes, config changes, perms changes, ...
• Marc Johnson : there is a misalignment between wiki's flower-release notes and modules' own notes. Recently polled some folks who all said they really only read the wiki notes because reading the module release notes is too cumbersome.
• Zak Burke : getting devs to handle commits in specific ways has met with a lot of friction in the past
• Radhakrishnan Gopalakrishnan : figure out how to consolidate this stuff so it's only maintained in one place, "conventional commits" is an established protocol that could be leveraged both for automation of per-module and cross-module (flower) release notes.
• Tod Olson : is there an additional problem with how changes are rolled out? What if instead of breaking changes, we added new endpoints with the new behavior, aka the DirectX module. Craig McNally : have done some of this with some edge APIs. 
• Marc Johnson : there isn't even agreement among devs about what breaking changes are and when semver bumps should happen, so there's even friction here too. Adding new APIs is possible but it comes with a lot of carrying costs that may not be obvious at first glance. Commit message quality, at present, is low, but changing it is hard. 
  • Sobha's major point: we found about this stuff late. We need to figure out how to publicize changes earlier!
• Craig McNally disagreement over breaking change vocab is interesting, problematic. 
• Jakub Skoczen 's note from chat: devs should be responsible for module release notes; release coordinator should be responsible for flower release notes. (Craig McNally : unfortunately RC is not here today to accept/refute/respond). 
• Mark Veksler : lots of interest here:
  • testing
  • TC's stance on API development, definition of breaking changes, catching changes early across different teams
  • what constitutes a "good" release that goes into GA
  • bugfest typically focuses on "functional" testing that results in a list of blockers, but not much testing WRT upgrading over version to another. i.e. not everything is integration related, but upgrade related and therefore only caught during dry-run upgrades of live clients. 
  • IOW, should we revisit current dev cycle, figure out what specific actions TC can take/recommend in order to make fewer mistakes as we inch toward Morning Glory?
• Craig McNally : Action Items: define "breaking change" in a subgroup? adjust definition of done? adjust release cycle to accommodate upgrade testing? Try to get Oleksii Petrenko 's input on this in the near future?
• Zak Burke will post to Slack#tc WRT semver to get the discussion started
• Mark Veksler how do we enforce stuff once we decide on it? Craig McNally lets us focus on defining things first. Veksler: Just note that both creating and enforcing policy are important. 

Craig McNally 

• Will be away next week; Jeremy Huff will chair. 

Craig McNally 

Radhakrishnan Gopalakrishnan 

*** out of time***

Radhakrishnan Gopalakrishnan : So Craig McNally please add this to next week's agenda

Craig McNally will add this to next week's agenda, 2022-07-13. 

Notes from previous meetings:

• The question was raised in slack by Marc Johnson 

How do we make tool version decisions? I’m asking because FOLIO is currently on Java 11. I imagine it could be prudent to move to 17 (the next LTS) at some point, and it seems that the #stripes-architecture group made the decision to move the project from Node 14 to 16 recently.I don’t think there is an equivalent group for the back end. How do we envisage the project making these kinds of decisions?

• Some feedback was given, but it's probably worth discussing as a group.
• Should we form a sub-group to define policies/processes?
• there was some discussion and some comments; in general, the problem is relevant for the backend, frontend, and infrastructure. Agreed to make a placeholder for next week, and once again contact in search of volunteers
• Make a page with the tools and versions for Morning Glory as a starting point.
• tools-and-versions page created by Radhakrishnan Gopalakrishnan