2024-05-29 Meeting notes

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.

Maccabee Levine

Tod Olson

Jakub Skoczen

Craig McNally

Jenn Colt 

• CC: Maccabee Levine 
  • No CC meeting this week.
• PC: Tod Olson
  • Discussion of State of FOLIO doc with Mike Gorrell
  • PC action items from Things that could be better about FOLIO survey
    • Finding PC members to take point on specific areas where PC leadership makes sense.
    • Also suggesting which council is best to take lead on each issue and encourage councils to take them up.
• RMS Group: Jakub Skoczen
  • in a previous meeting, their request was approved but no action had been taken yet. Jakub Skoczen will follow up with Oleksii Petrenko and update the meeting notes accordingly
• Security Team: Craig McNally
  • No updates
• Tri-council Application Formalization: Jenn Colt
  • Jenn Colt mentioned the group feels at a crossroads, being at the turn of the quarter and approaching a Tri Council meeting. The group has been meeting for six months and is deciding on next steps, particularly regarding the movement towards Eureka.
  • Ingolf Kuss clarified that there are no current license questions, referencing a previous statement from EBSCO that if there were license issues, they wouldn’t have used the con. 
  • Discussion points:
    • Whether to endorse movement towards Eureka at the next Tri Council meeting.
    • The readiness of hosting providers to cope with and enact Eureka.
    • The potential transition period between classic folio and Eureka and how to manage it without leaving anyone behind.
    • The need to balance different tracks: governance impacts and readiness of hosting providers.

  • Action Items:

    • Ingolf Kuss has been asked to bring the topic of Eureka's introduction to the Sysops for their opinion on concerns, overlap periods, licenses, and complexity. He will ensure the overview document from EBSCO is copied into the Sysops channel for reference.
    • A Sysops meeting will be convened on Friday to gather opinions, which will be brought to the formalization subgroup.

• 29 May 2024 - Use as regular meeting for this week, due to Monday holiday
• 03 Jun 2024  - Regular TC Meeting
• 05 Jun 2024 - Alternate time meeting for China and Australia topics?
• 10 Jun 2024  - Regular TC Meeting
• 12 Jun 2024  - Dedicated Discussion - ???
• 17 Jun 2024  - Regular TC Meeting

All

All

• Go Language:
  • Ready for FINAL review by TC: https://github.com/folio-org/rfcs/pull/33
    The team discussed the review process for the Go language. There was a clarification about the readiness for the final review, with confirmation that the Go language had been in public review for months and all feedback had been addressed. The final review and vote were scheduled for next Monday 06/03/2024 The timeline was confirmed, and everyone agreed to proceed with the plan.
• Application Formalization: When will we do the final review?
  • The following Monday 

Jeremy Huff

• Jeremy Huff:
  
  • Reach out to Australia and China for topics
    • This is done, and we are waiting for feedback
• Maccabee Levine 
  • Create a calendar page for TC recurring events
    • Created
• Craig McNally
  • Investigate which version modules are actually using.
    • in progress

Review the summary of ideas discussed during the dedicated discussion on breaking changes

Google doc created with all the ideas discussed during last weeks dedicated discussion meeting : 

The discussion focused on improving the process for communicating breaking changes in the codebase based on a proof of concept (POC) utility designed by Maccabee Levine, aiming to facilitate the notification of breaking changes. Despite the progress, further improvements were suggested.
Key points:

1. Current POC and Feedback:

   • The POC utility's primary function is to communicate breaking changes as they occur.
   • Ankita Sen consolidated feedback and suggestions from previous meetings into a document for review.
   • There was a consensus that early notification of breaking changes is crucial, and current methods may be inadequate.

2. Challenges and Solutions:

   • One major challenge identified was the timing of notifications. Developers need to know about breaking changes as soon as possible.
   • There was discussion about whether JIRA could be used to flag potential breaking changes early in the development process.
   • It was suggested that developers might not always realize a change is breaking until later stages, making early notification difficult.

3. Role of Developers and Product Owners:

   • The responsibility of communicating breaking changes often falls on developers. However, there's a recognition that this might not always be effectively managed.
   • There was a suggestion to involve product owners and Scrum Masters more actively in this process, potentially during the planning stages of development.
   • This could include prompting developers to identify potential breaking changes early and ensuring these are flagged in JIRA or other tracking tools.

4. Communication Strategies:

   • The effectiveness of using videos for communication was discussed, with a preference for having clear, written documentation as a primary source of information.
   • A hybrid approach using videos to highlight key points in documentation was considered beneficial but not a replacement for written records.

5. Practical Examples and Best Practices:

   • Examples were shared where communication about breaking changes was handled well, such as posting notifications in Slack and creating JIRA tickets for all affected modules before merging changes.
   • The need for a culture of proactive communication and responsibility among developers was emphasized. Encouraging developers to subscribe to channels where breaking changes are discussed was seen as vital.

6. Future Steps:

   • The discussion concluded with an acknowledgment that more work is needed to define actionable steps for improving the communication process.
   • Suggestions included potentially automating some aspects of identifying and notifying about breaking changes, though manual effort and responsibility would still be crucial.

Overall, while the discussion advanced understanding and clarified the issues, the need for continued dialogue and development of concrete solutions was recognized.

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

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.

Possible topic/activity for a Wednesday session:

Discuss/brainstorm:

• Ideas for the type of developer-facing documentation we think would be most helpful for new developers
• How we might bring existing documentation up to date and ensure it's consistent 
• etc.