2024-05-22 - Communicating Breaking Changes

Ankita Sen is next, followed by Jakub Skoczen 

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. 

Recent discussion:

• 2024-02-21 - Communicating Breaking Changes
• 2024-04-01 Meeting notes (POC demo)

Today's discussion (22.05.2024):

Maccabee Levine - Brief recap of Breaking Changes and Communicating breaking changes points that have been discussed in the TC before. POC demo.

Zak Burke - finding out about a breaking change when it's merged is too late. From the ui point there is a hierarchy of dependencies and by the time it is merged the platform-complete build breaks and beats the purpose of communication of the said breaking changes. Automation might be too late to make a difference, at least in the daily builds. There also a signal to noise ratio issue with regards to the slack channel.

Craig McNally - might be devs/folks get burned the first time then subscribe to the channel.

Maccabee Levine - Agree with Zak's feedback

Zak Burke - Would not want to wait till the change is merged, would want to know as soon as the change is identified. That is useful in saving the nightly builds from failing

Marc Johnson - The devs making the change if they proactively identify the breaking change and the interdependencies and collaborate is what is needed. The automation or automated communication can be used as a back up

Craig McNally - 

Taras Spashchenko - Ticket is created for breaking change and ticket is created for every dependent module. Once the Ticket is merged the interdependent tickets are notified and the Devs responsible for them do the necessary changes.

Marc Johnson - Lables are already present in JIRA, not well adopted but are present. Agree with Taras about developers being active.

• compatibility-breaking and implementation-compatibility-breaking are the two Jira labels referred to here.

Zak Burke - How can we make the process Taras described the default rule, not the exception? What are the technical things we can do like tooling to communicate but also how to educate developers to notify about the changes through tickets(Taras' process) ?

Craig McNally - We cannot enforce it all that well, but we can put the process out there may be in a Wiki Page? Some teams have been proactive since a long time. Being proactive cannot cover all the bases. It will help the developer community. For the external users of folio - a mechanism which Maccabee defined could be useful.

Maccabee Levine - The emphasis should be to communicate the change as soon as possible and a Wiki page would also be useful for the external-users of folio APIS and also for the sys-ops.

Marc Johnson - A multi layer approach is a good idea.