2024-04-01 Meeting notes

Date

Attendees 


Discussion items

TimeItemWhoNotes
1 minScribeAll

 Jakub Skoczen is next, followed by Taras Spashchenko

Jenn Colt acted as scribe

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.

5-10 minLiaison Updates
5 minUpcoming MeetingsAll
4 minTCR Board ReviewAll
5-10 min

Technical Council Sub Groups Updates

All

  • TCR process:  still working with RMS, then some communication that may or may not wait for RMS
    • Existing modules: some criteria should apply, but current review process doesn't
    • Return to process after formalization
  • Working on static code review subgroup, need to reach out to devs
5 minRFCs

All

  • Public review update
    • Application Formalization RFC - some comments, need to dig in
      • Not a ton of feedback, need to incorporate changes and then move along
    • Go Programming Language for Backend Development RFC - active comments
    • Distributed vs Centralized Configuration RFC - is in public Review
1 minDecision LogAll

Standing agenda item... is there anything in the decision log requiring attention? 

5-10 minOpen Call to Devs for TC Backlog TopicsJeremy Huff

Review the following language:

Hello FOLIO Developers!

The FOLIO Technical Council wants to ensure that we are engaging with topics that are relevant to the development efforts of our community. We feel that no group is more aware of what these topics are then the developers themselves. We would like to encourage you to share with us  suggestions for topics that that are impactful to the FOLIO development experience.

Please share any such topic suggestion with us in the #tech-council slack channel, and thank you for all the hard work!

___

  • Jeremy will post for developers + slack channels
10-15 minFOLIO Breaking Changes Utility PoCMaccabee Levine
  • Mine GH for evidence of breaking changes, ask teams to add labels to PRs
  • see 2024-02-21 - Communicating Breaking Changes
  • https://docs.google.com/spreadsheets/d/1jHfxvNQRnQuHeCcv0NlSc6eti0IHEyVTe4eO1q419gk/edit#gid=0
  • https://github.com/folio-org/breaking-changes-notification-poc
  • Once things are gathered what happens? Posts to slack channel where interested parties can watch for changes and see if they are affected.  Hoping summary in PR will let people know if they need to investigate further.
  • Have release notes with breaking changes but those are too late.
  • Try running the POC for a while and see how it goes. Need to make sure development community understands how to do the labels. Description is optional but useful. See if some set of teams thinks it is worthwhile and willing to try.
  • Olamide: Things could get missed in the slack channel, knowing before the change is merged is most helpful.
  • Any major version change should be accompanied with the label. A way to force agreement? Would we want to?
  • How do teams currently signal?  Nothing formal. This is an attempt to provide the mechanism. Tech leads could be an option but that group didn't work so well. Is there a better way than slack to make people aware of breaking changes.
  • Hard for TC to facilitate announcement before it is evidenced in code.  PR is the earliest can automatically scan for, anything else would require active participation from the dev teams to make announcements.
  • Some kind of notification when the PR is created, if PR has the label, could make it happen earlier.
  • Targeted to teams working on specific modules?
  • Slack notifications can be used to let people to opt into their own announcements. Individuals can set up their own notifications
  • People not attending them to later in the process, or not realizing they were breaking changes, leading to some scrambling
  • Try with limited scope experience
  • Use a Wednesday topic discussion and try to get folks already using the breaking change label to try this
  • Can also give refresher link on definition of breaking changes
  • At one point teams were responsible for creating PRs when they made breaking changes that affected other modules
  • Make sure useful for development teams and sysops as well
  • Jeremy will publicize upcoming discussion
5 min WOLFCon Presentation UpdatesJeremy Huff

Proposal: 

  •  give feedback, have until end of the month
Time Permitting

Officially Supported Technologies (OST)

All

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


Time Permitting

Topic Backlog Grooming

All

Review the topics on our Topic Backlog to remove those that are no longer relevant, modify those that require change, and add topics that might be missing.


NAZoom Chat

11:02:09 From Jenn Colt to Everyone:

Same here

11:06:35 From Jenn Colt to Everyone:

Overly proactive

11:12:05 From Tod Olson to Everyone:

I need to step away for a couple minutes...

11:18:52 From Tod Olson to Everyone:

...back

11:23:48 From Jenn Colt to Everyone:

I’m also nodding with my camera off which definitely helps

11:23:58 From Tod Olson to Everyone:

Reacted to "I’m also nodding wit..." with 😆

11:24:15 From Maccabee Levine to Everyone:

Reacted to "I’m also nodding wit..." with 😆

11:40:53 From Maccabee Levine to Everyone:

And even if the dev teams signaled each other about breaking changes, it would not help signal external apps that use the APIs

11:58:23 From Jenn Colt to Everyone:

Implementers might just give async feedback


Topic Backlog

Decision Log ReviewAll

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

Translation SubgroupAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Communicating Breaking ChangesAllSince we're having trouble finding volunteers for a subgroup, maybe we can make progress during a dedicated discussion session?
Officially 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.


Dev Documentation VisibilityAll

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.

Action Items

TC members to review policy guidance in Ramsons OST page and provide feedback