/
2023-10-23 Meeting notes

2023-10-23 Meeting notes

Oct 30, 2023

Date

Oct 23, 2023

Attendees 

  • @Craig McNally 

  • @Anuar Nurmakanov (Proxy for @Taras Spashchenko)

  • @Maccabee Levine 

  • @Tod Olson 

  • @Jenn Colt 

  • @Florian Gleixner 

  • @Raman Auramau 

  • @Jeremy Huff 

  • @Marc Johnson 

  • @Ingolf Kuss 

  • @Matt Weaver 

  • @Owen Stephens 

  • @VBar 

  • @Julian Ladisch 

Discussion items

Time

Item

Who

Notes

Time

Item

Who

Notes

1 min

Scribe

All

 @Jeremy Huff is next, followed by @Marc Johnson 

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

1 min

TCR Board Review

All

Nothing New

5-10 min

Liaison Updates

@Maccabee Levine @Tod Olson  @Jakub Skoczen  @Craig McNally 

  • CC: @Maccabee Levine - 

    • From Simeon: 

      Please will you ask your councils to ratify the following change to our governance model concerning the CC size and quorum:


      This was approved by CC as noted in https://folio-org.atlassian.net/wiki/display/CC/2023-09-25+Meeting+notes
      Rationale is that initially a large CC was usefully representative but with 43 members that is no longer possible, it is better to have a smaller/tighter/more-engaged CC that handles necessary business effectively, works with PC and TC, and  works to support engagement from all members

    • @Craig McNally asks the TC if anyone had any concerns, and this was ratified via lazy consensus 

    • Discussed the Application Formalization cross-council subgroup.  Got another member or two from CC.  Leadership / schedule still not clear

  • PC: @Tod Olson - SIG reports, current stats of FOLIO QA testing. There was discussion of the application architecture changes, and the PC is endorsing the basic approach of moving toward applications, noting that there are many stakeholders, and asking for clarification on terminology. 

    • @Jenn Colt points out that the PC had not endorsed the approach but postponed endorsing it

    • @Tod Olson concurred, stating that the subgroup endorsed it, but the PC postponed 

  • RMS Group: @Jakub Skoczen - Not present

  • Security Team: @Craig McNally -  Came up with rough guidance on clarification for the relative sensitivity of information. There are complications surrounding the encryption of sensitive data in the database. 

 

 

5 min

Technical Council Sub Groups Updates

All

Quick updates only.  If we can't find volunteers for groups, we'll need to add the topic to our backlog and address it during dedicated discussion sessions.

 

AWS Hosting: @Maccabee Levine  will "present" this to TC after to the PO leads and devs, but it's just a reminder of the new AWS Costs Review Group process that TC approved a few months back

Distributed VS Centralized Configuration: There was no meeting, @Florian Gleixner  refined the RFC. He will touch base with @Julian Ladisch who may be on vacation.

Architectural Review Subgroup: @Craig McNally do we need to shut this group down until later? @Jenn Colt  feels we should keep it, to allow the TC to provide leadership for the TRI Council sub group on application formalization. @Marc Johnson likes this idea but notes that this was not the original purpose of this group. He wants us to make sure we are clear about the purpose of this group. @Craig McNally we will revisit next week

Communicating breaking changes: No updates

Translation Subgroup: No updates

TCR Process Improvements: @Maccabee Levine the first meeting is scheduled for a week from today.

10 min

Decision Log

All

  • DR-000037 - TESTCONTAINERS_POSTGRES_IMAGE @Florian Gleixner

    • Discuss, make a decision?

      • @Marc Johnson raises the question if this is applicable to the DRs. @Craig McNally notes that it was decided that it is.

      • @Craig McNally asks Marc if it isn't a decision record then how should we document this? @Marc Johnson thinks that this the TC should operate at a more strategic level, and should not document changes of this scope at all. He feels that this is more of an implementation detail and not at the strategic level. He notes that the TC is already overwhelmed by the volume of decisions, and this will not helped.

      • @Florian Gleixner maybe this should be discussed with the other development groups. It effects a lot of groups and we should not decide on this without getting feedback from them

      • @Craig McNally points out that there is not a lot of communication between development groups which makes this challenging. We could post this to the development slack

      • @Marc Johnson We need to decide if the TC is endorsing these decisions or just recording them

      • @Jeremy Huff notes that it might be useful for the TC to crowdsource or delegate decisions, and reserve the right to discuss any thing that the TC finds rises to the level of strategic significance 

      • @Tod Olson Agreed, and notes that since tech leads no longer exists, someone needs to lead in these things. Maybe, when lower level decisions need to be made, maybe the TC needs to appoint someone

      • @Maccabee Levine also agrees, and references governance models

      • @Marc Johnson Thinks that it would be inconsistent  , since we did not get dev feedback on deciding to upgrade postgres

      • @Craig McNally disagreed, stating that the decision of upgrading was unavoidable, but this is a question of implementation

      • It was decided to seek input from the developers

10-20 min

RFCs

All

  • 0004 Date-time values must comply with IETF RFC-3339

    • @Tod Olson this is not ready to move forward, because of some of the breaking API issues raised by @Julian Ladisch . We will need to make a decision, but maybe not today

    • @Marc Johnson he raised a decent on this based on a scope issue. This RFC is at a very small scope, when compared to the application formalization RFC. He wants consistency with scope consistency with RFCs

    • @Maccabee Levine Feels that scope analysis should be part of the preliminary review stage

    • @Owen Stephens the requirement to approach storage in the way the RFC recommends will create more work for development. He is not clear on the benefit gained from this storage component of the RFC

  • 0005 Application Formalization

    • @Craig McNally notes that there has been some feedback, and he is not sure if the feedback is appropriate for the preliminary review phase. He asks if 

    • @Jenn Colt She does not like being limited in expression based of the phase of the processes. There are more RFCs coming and the discussion about what should be in this RFC is not complete

    • @Marc Johnson this is a particularly challenging RFC. He does not understand the scope of this RFC, since it is a subsection of a larger set of RFCs. He wants to wait until the proper review stage to provide input. His instinct is to progress these as quickly as possible.

    • @Maccabee Levine agreed with a comment Craig made that scope questions will be sorted out in iterating on the RFC

    • @Craig McNally He wants to get the processes right, and to understand what sort of comments and questions need to be addressed in the RFC. He is trying to be flexible and open minded in bringing this RFC forward, but wants clarity on how to proceed

    • @Jenn Colt points out that the contention here was about listing the bounded scope as a benefit expanded the scope to include the bounded scope

    • @Craig McNally points out there were other threads and discussion beyond the bounded context question

    • @Marc Johnson was concerned by modules sharing database access being listed as a benefit. Because this RFC is a building block for other RFCs he finds it difficult to determine scope. If we are always going to pass an RFC through the preliminary review, then why don't we get rid of it

    • @Craig McNally Feels that if he had done a high level RFC this would have been told that there were not enough details

    • @Jenn Colt She is thinking about the subgroup on architecture might provide a more collaborative environment to discuss this

    • @Craig McNally Feels that the conversation we are having is healthy. He has broken up the application formalization into what might amount to 4 RFCs, and thinks that he may have scoped these too narrowly

    • @Tod Olson He does not think the scope is wrong but does see how it is difficult to keep context. This is about the formal definition of an application, and not what is done after you have the formal definition. Would like to see more development on the motivation content in the RFS

    • @Craig McNally says the comment concerning rationale is fair

RFC Process Improvements:

1 min

Upcoming Meetings

All

  • Oct 25, 2023 - RFC process improvements part III

  • Nov 1, 2023 - See topic backlog below

5-10 min

Officially Supported Technologies

All

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

  • Check in on progress

  • Handle in Quesnelia page Quesnelia - Technical Council - FOLIO Wiki
    @Taras Spashchenko together with the Kitfox team arrange testing FOLIO on PostgreSQL 13

  • Bring Quesnelia page up to date

    • @Craig McNally originally volunteered for this but is asking if anyone else can take this on.

Time Permitting

Dev Documentation Visibility

All

Previous Notes:

@Marc Johnson raised a point regarding the maintenance of the dev.folio.org website. He mentioned that in the early days of Folio, this website was managed by a small group of individuals who were working on the project. However, with the project's growth, keeping the site up to date has become a challenge. Marc suggested that the community should collectively decide whether to continue maintaining the website or explore alternative platforms for sharing development information, as there are differing preferences regarding resources such as the wiki. He also observed that the dev.folio.org site is not updated frequently due to the effort involved.

  • RFCs are not searchable from the wiki or dev site.  

  • DRs help, but may not be applicable or enough in some cases.
    @Craig McNally proposed the use of Decision Records in the RFC process, emphasizing their role in formalizing decisions and creating a wiki presence, especially for handling breaking changes. @Maccabee Levine  supported this.

  • ...

@Craig McNally and @Marc Johnson  discussed the need for a central reference and documentation hub for Folio developers. Marc raised this topic, which had also been mentioned in the "Things Folio Can Do Better" discussion. He proposed creating a developer index on the wiki to guide developers, despite the potential complexity of the task. Craig supported the idea, highlighting the challenges of finding information and improvements in GitHub search. Concluded with plans to revisit the topic in future discussions.

Today:

  • ...

NA

Zoom Chat

 

10:05:16 From Tod Olson To Everyone:
    @Huff, Jeremy T , could you set the main table to "responsive"? Even if it's already selected, sometimes you have to set it again.
10:10:05 From Jenn Colt To Everyone:
    Just want to point out PC actually postponed “endorsing” https://folio-org.atlassian.net/wiki/display/PC/2023-10-19+Product+Council+Agenda+and+Meeting+Notes
10:13:24 From Marc Johnson To Everyone:
    If there is a presentation happening to EBSCO dev teams about AWS costs, how will none EBSCO teams get the same information?
10:20:22 From Maccabee Levine To Everyone:
    Replying to "If there is a presen..."
    
    So, there are presentations planned to the three councils (which have already happened, since TC and CC already *approved* this, but I'll do a recap), and PO leads...
10:20:23 From Maccabee Levine To Everyone:
    Replying to "If there is a presen..."
    
    And one final group, which TC members have referred to as EBSCO dev leads, and someone from EBSCO referred to (loosely paraphrasing) as "dev leads but non-EBSCO folks stopped attending".  I don't have any context of that meeting.
10:23:49 From Marc Johnson To Everyone:
    We didn’t even get the development groups to agree to the PostgreSQL upgrade
10:24:00 From Jenn Colt To Everyone:
    Replying to "If there is a presen..."
    
    I was thinking about FOLIO governance ‘constituents’ this morning. EBSCO devs seem like well-represented constituents. Are other devs?
10:26:03 From Maccabee Levine To Everyone:
    Replying to "If there is a presen..."
    
    I wonder about that as well.  Would be interested to hear from other vendor's teams as well as independent devs
10:27:18 From Marc Johnson To Everyone:
    If we are going to ask for input into the test containers decision, we should do the same for the overall PostgreSQL one
10:27:46 From Marc Johnson To Everyone:
    I don’t understand how this fits with folks concerns that the TCs processes don’t scale 😕
10:29:49 From Jenn Colt To Everyone:
    https://www.onboardmeetings.com/board-portal-glossary/meeting-consent-agenda/
10:31:12 From Owen Stephens To Everyone:
    Point of order - has this got allocated the same number as an existing Decision Record?
10:31:32 From Owen Stephens To Everyone:
    Replying to "Point of order - has..."
    
    Isn’t Breaking Changes already DR36
10:32:48 From Owen Stephens To Everyone:
    Replying to "Point of order - has..."
    
    This has been updated to DR-37 now (thank you whoever did that) https://folio-org.atlassian.net/wiki/display/TC/DR-000037+-+TESTCONTAINERS_POSTGRES
10:35:11 From Tod Olson To Everyone:
    @Marc Johnson , good point on scope, I'm treating this as being further along than the prelimin
10:35:33 From Tod Olson To Everyone:
    Replying to "@Marc Johnson , good..."
    
    ...preliminary review.
10:43:02 From Maccabee Levine To Everyone:
    In my mind, a comment or question is raised in the PR, there will likely be some back and forth, either in PR comment thread, out of band, in a meeting, etc. Then the submitter makes some adjustment to the RFC accounting for the comment/question.  Maybe this is adding something to the "risks/implications" section, maybe it's adding or adjusting an example, etc.  The comment thread can then be resolved as the concern has either been addressed or incorporated into the RFC for later stages.
10:44:01 From Maccabee Levine To Everyone:
    last comment was copied from Craig in a slack thread
10:44:16 From Marc Johnson To Everyone:
    Replying to "In my mind, a commen…"
    That’s not how those conversations have gone for me, personally
10:55:35 From Marc Johnson To Everyone:
    The breaking changes RFC was given feedback in a meeting rather than text
10:56:51 From Jenn Colt To Everyone:
    Maybe right sizing is just always a tension
10:57:34 From Marc Johnson To Everyone:
    It’s me that isn’t understanding the grouping
    
    I do seem to be the contentious element to this 😞
10:57:43 From Marc Johnson To Everyone:
    Reacted to "Maybe right sizing i…" with 💯
10:59:02 From Jenn Colt To Everyone:
    I don’t think it’s just you!
10:59:29 From Marc Johnson To Everyone:
    Replying to "I don’t think it’s j…"
    It feels like it at the moment, but my brain is known to default to that 😃

Topic Backlog

Decision Log Review

All

Review decisions which are in progress.  Can any of them be accepted?  rejected?

Translation Subgroup

All

Since we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?

Communicating Breaking Changes

All

Since we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?

Officially Supported Technologies - Upkeep

All

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.

 

Action Items