2023-09-18 Meeting notes

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

 Maccabee Levine is next, followed by Tod Olson 

5 minTCR Board Review

All


  • PC approval?  Seems like yes. → list app has been approved by the PC (tick)
5 minLiaison Updates
  • CC: Maccabee Levine no CC meeting this week
  • PC: Tod Olson 
    • Presentation on Application Formalization by VBar and Craig McNally 
    • See 2023-09-14 Product Council Agenda and Meeting Notes for details.
    • Discussion about what gets included in what platforms.  And can we not do some of the flexibility in composing platforms with the current module framework.
    • PC experimenting with shorter (60m) meeting and more subgroups, like TC.
    • A small group is looking at the implications of the proposal and preparing a document for the PC which is expected to cover some problem statements, implications of the ideas presented, and questions arising for the PC/product.
  • RMS Group: Jakub Skoczen 
    • Jakub Skoczen not present.  Mark Veksler : Group reviewed draft timeline for Q release, currently targeted 4/29.  Additional work needed for scope, development capacity, and Easter holiday.
  • Security Team: Craig McNally 
    • Logging vulnerability found last week, some sensitive info logged.  Patched and releases made, announced in #sysops channel.
5 min

Technical Council Sub Groups Updates

All

Quick updates... 1 minute each

Distributed / Centralized PR

Breaking Changes

Translation

  • Zak Burke no organizer yet.
  • Craig McNally Look for CC or PC to drive.
  • Zak Burke People actively involved in the project happy where it is.  KnowledgeWare would like FOLIO to function in a multi-lingual manner, not just "not English".  I.e. translations of lookup-table in UI and via API requests.  Is there an architecture that doesn't require major backend work.  Figure out the real-world requirements.
  • Maccabee Levine I brought this up, needs CC involvement if we are getting KW engaged, and PC to define functionality first.  No point in technical solution without those.
  • Jeremy Huff Need requirements gathering, but we know some of the technical boundaries that we want any solution to live with.  Could put together a problem statement, i.e. we know this is something people desire, any solutions would have to fit within these boundaries, maybe RFC for possible solutions that fit.
  • Marc Johnson Given "problem statement" discussion, TC is the wrong part of the community to be driving this.  Product needs should drive it.  Could express boundaries/constraints but whether those are a good idea or not depends on what people want to achieve.
  • Owen Stephens Feel opposite.  From PC, the need was expressed.  Single tenant should be able to provide different languages at different times.  Requirement came from KWare to PC, PC accepted and supported need.  Solution was rejected as not technically appropriate by TC.  Can't loop again.
  • Craig McNally Need a volunteer to help wrangle this.  Engage with PC on list of requirements?  Having something in writing would be better.  Then driving effort to look at options, maybe for RFC.  Put something in PC and CC channels as well.  I will post.
  • Marc Johnson If call for participation, ensure PC and CC folks represent what people want on a multi-lingual perspective.  Not what happened last time.
1 minDecision LogAll
  • Nothing new
1 minRFCs

All

  • Nothing new
5 min

Officially Supported Technologies

All

Standing agenda item to review/discuss any requested or required changes to officially supported technology lists

  • Postgres 12 EOL Fall 2024...  
  • Handle in Quesnelia page Quesnelia - Technical Council - FOLIO Wiki
  • Typescript needs to be addressed
  • Open question: Timelines
  • Want to give people more lead time before the Poppy release

Today:

  • Marc Johnson We don't have a process for driving these decisions, we've been reactive after dev teams.  Led to discussion about actively delegating to interested parties.  Does TC own or is there a group to delegate to?
    • Craig McNally Was looking more specifically at Postgres, give dev team time to plan for it.
  • Craig McNally For typescript, teams already using it, should probably add to the list?
  • Jeremy Huff What about edge modules?
    • Craig McNally We do tend to forget about edge modules on this list. edge-common, edge-common-spring.
  • Tod Olson Re: Postgres, recommend 15?  Would be a while before we need another bump.
    • Craig McNally Balance how much time to upgrade, three major revs may be tricky.  But if we do now, not again for some time.  See how much effort is required.  Does Postgres have LTS versions?
    • Tod Olson Just a fixed window for each release.
    • Marc Johnson Implicit in Craig McNally 's comment that TC will drive this.  So who figures that out?  What person or group?
    • Jeremy Huff Find out if anyone out there is currently using a newer version of Postgres
    • Mark Veksler EBSCO experimented with Aurora serverless which required v13 of postgres.  Was smooth upgrade.  Someone from EBSCO can talk to TC about what that process was like.  But upgrade to v15 would be different.
    • Florian Gleixner Used Postgres 13 for a long time now, didn't see requirement.  Not a problem.
    • Craig McNally Maybe v13 is easiest path, look to 15 later.  Volunteer to look at this, make a recommendation?  Florian Gleixner volunteered.
  • Craig McNally typescript experience?  Do we need that?
    • Zak Burke TC never had an official stance, but could help to explicitly include that.  Also fine just saying v4.
    • Jeremy Huff Typescript not the path of least resistance in react.  Willing to explore with Zak Burke .
    • Zak Burke Probably other stripes folks better suited.  John Coburn Noah Overcash 
    • Maccabee Levine Agree with deleting these decisions to groups like the one just defined rather than making ourselves.
    • Marc Johnson Already using typescript for ages, so this is really a documentation thing.
    • Craig McNally Yes, but what version for Quesnelia.  Agree this is more reactive than others.
    • Mark Veksler Even for Quesnelia, scope freeze planned by early October.
    • Marc Johnson In release status meetings, not how FOLIO works right now.  I.e. from last week's meeting, we added RMB and Spring, those tend to change at last minute.  Things change right up to deadline of current release.
    • Craig McNally Don't want to get into process right now.
1 minConflict of Interest Avoidance

A PR has been created, and some discussion has been happening.  Please chime in if you have an opinion.

1 minThings Folio can do betterAll

See slack post from Tom Cramer:

At the August 25, 2023 meeting of the Tri-Council at University of Chicago, it was agreed that we would repeat the “List of Things that Could Be Better About FOLIO” survey that was conducted after WOLFcon at Hamburg (Sept ’22).

We ask all Council members to each survey three community members for a list of three things that could be better about FOLIO. Please enter the results into this document by September 29, 2023.

In October, we will report back both on this year’s responses as well as an analysis on progress made against the 2022 goals.

Thank you.
-Tom Cramer (CC), Jesse Koennecke (PC) and Maccabee Levine (TC)


Questions/Notes:

  • "Things that could be better about FOLIO" presentation slide deck:
5 minPlatform and Application Formalization Questions

https://docs.google.com/document/d/1OLae-eGN3_dEOXbAr7Tr1cvudBzqNA7TttzH9QmvuR8/edit?usp=sharing

Any objections to sharing this with the PC?

  • Jeremy Huff The subgroup is happy with the list.  Some items productive for TC to talk about at future meetings.  But wanted TC agreement before we sent to CC and PC.
  • Maccabee Levine Reminded context that tri-council asked for this, and other councils are working through these issues now.
  • There was no objection.  Jeremy Huff will announce.
5-10 minRefresh Tokens

Tod Olson / All

See slack post from Tod Olson:

Looking ahead to the late fall, I see that Refresh Token Rotation is coming in Poppy, that's a big change and the new API token management API is still in progress. In any case, it appears this will require changes to any scripts or integrations that hit the (non-edge) APIs. Does TC have a role in publicizing and making recommendations for how to prepare for this change? Or am I misunderstanding the impact? 


Notes:

  • Does the TC has a role in this ?
  • @Steve Ellis seems to be the contact person
  • Tod Olson : Steve Ellis is writing recommendations based on testing.  Does the TC need to help get the word out?  If not, then who?
  • Craig McNally External scripts by hosting providers & libraries may not be updated yet.  Avoid situation where all those integrations break on upgrade.
  • Tod Olson At least to the implementers list.
  • Marc Johnson Given the work that was done didn't involve the TC, the onus to communicate should be on those who did the work, planning and deciding it should be in a single release.  TC can "signal boost" what they put together.
    • Craig McNally Core platform team make announcement then?
    • Marc Johnson Start with Steve Ellis and Alexi, with delivery plan.  TC could announce whatever they want us to announce, but they could do it just as well, have access to all the same places.
    • Tod Olson Either way, TC should push for message getting out, regardless who it comes from.
    • Jenn Colt Holiday season release is hard, and some other code controlled by outside vendors.
    • Maccabee Levine Involve those people so they can respond to questions.
1 minUpcoming MeetingsAll
  • - Dedicated Discussion - Topic?
  • Marc Johnson Discuss outstanding TCRs?
  • Maccabee Levine Officially Supported Technologies scheduling consensus?  Marc Johnson and Mark Veksler disagreed above.
  • Marc Johnson But if we don't discuss TCRs on Wednesday, and no time scheduled Friday, then effectively saying they will not get in for Poppy.
    • Craig McNally Could try to find time on Friday.  Or just accept they will not be in Poppy.
    • Marc Johnson The four downstream modules of mod-fqm-manager can't pass until it does, since they are dependent.  So effectively all lists modules are blocked until Friday.  So the only one would could talk about is edge-courses which won't be ready by Wednesday either.
    • Jeremy Huff Opposed to voting on modules pre-eval.  Not opposed to any discussion.  Voting before eval would subvert our process.  
    • Marc Johnson Threads from slack implies there's nothing productive we can do until eval, i.e. Friday.
    • Jeremy Huff Probably true.  Could call it failed as soon as any criteria fails.
    • Marc Johnson No time for that either; if we discuss each failure (multiple things), even if we gave one a bye, we still have to finish the evaluation.
    • Craig McNally Plan on continuing this conversation in Slack.
NAZoom Chat

Placeholder.  Scribe should copy/paste the zoom chat here.

Topic Backlog

Discuss during a Monday sessionOfficially Supported Technologies - UpkeepAll

Previous Notes:

  • A workflow for these pages. When do they transition from one state to another. Do we even need statuses at all ?
  • Stripes architecture group has some questions about the Poppy release.
  • Zak: A handshake between developers, dev ops and the TC. Who makes that decision and how do we pass along that knowledge ? E.g. changes in Nodes and in the UI boxes. How to communicate this ? We have a large number of teams, all have to be aware of it.  TC should be alerted that changes are happening. We have a couple of dedicated channels for that. Most dev ops have subscribed to these channels. How can dev ops folk raise issues to the next level of community awareness ? There hasn't been a specific piece of TC to move that along.
  • Craig: There is a fourth group, "Capacity Planning" or "Release Planning". Slack is the de facto communication channel.  There are no objections to using Slack. An example is the Java 17 RFC. 
  • Craig: The TC gets it on the agenda and we will discuss it. The TC gets the final say.
  • Marc Johnson: We shouldn’t use the DevOps Channel. The dev ops folks have made it clear that it should only be used for support requests made to them.
  • Jakub: Our responsibility is to avoid piling up technical debt.
  • Marc: Some set of people have to actually make the call. Who lowers the chequered flag ?
  • Craig: It needs to ultimately come to the TC at least for awareness. There is a missing piece. Capacity Planning needs to provide input here. 
  • Marc: Stakeholders / Capacity Planning could make that decision. Who makes the decision ? Is it the government or is it some parts of the body ?
  • Marc: the developers community, the dev ops community and sys ops are involved. For example the Spring Framework discussion or the Java 17 discussion. But it was completely separate to the TC decision. It is a coordination and communication effort.
  • Marc: Maybe the TC needs to let go that they are the decision makers so that they be a moderating group.
  • Jakub: I agree with Marc. But we are not a system operating group. Dependency management should be in the responsibility of Release management. There are structures in the project for that.
  • Jason Root: I agree with Jakub and with Marc also. Policies should drive operational/release/support aspects of Folio.
  • Jason Root: If the idea of “support” is that frameworks are supported, then of course the project should meet that.
  • Marc Johnson
    Some group needs to inform OleksAii when a relevant policy event occurs.
    These documents effectively ARE the manifestation of the policy.
  • Craig: This is a topic for the next Monday session.
  • Craig to see if Oleksii Petrenko could join us to discuss the process for updating the officially supported technologies lists.

Today Notes:


Action Items