2023-10-23 Meeting notes

 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.

All

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:

    Current text:
        The council will have 15 members but can operate with a minimum of 9. The council will seek to have a diverse membership.
    Proposed replacement:
        The community council will have 13 members but can operate with a minimum of 7. The council will seek to have a diverse membership.

    
    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. 

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.

• 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

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:

• https://github.com/folio-org/rfcs/pull/11 (Updates to the RFC Template) has been merged.
• https://github.com/folio-org/rfcs/pull/15 (Retroactively applying metadata changes to RFCs) has been created, please review.
• Made good progress on this document, Can likely wrap this effort up with one last session.

• 25 Oct 2023 - RFC process improvements part III
• 01 Nov 2023 - See topic backlog below

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.

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.

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.