CDM Steering Working Group - February 13th, 2024

[eteridvalishvili]

CDM Steering Working Group Minutes

Meeting Host: David Shone, ISDA

Date

February 13th, 2024 - 11am ET / 4pm BST

Untracked attendees

• Fullname, Affiliation, (optional) GitHub username

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

• [x] Convene & Roll Call reminder- @eteridvalishvili
• [x] Display FINOS Antitrust Policy summary slide @eteridvalishvili
• [x] Approve past meeting minutes
  • [x] https://github.com/finos/common-domain-model/issues/2566
• [x] Ratification of Lyteck Lynhiavu as maintainer on behalf of ISDA
• [x] Updates:
  • [x] Release governance and scheduling- @tomhealey-icma
  • [x] Reference Data Lists- @dshoneisda
  • [x] Serialisation- @dshoneisda and @chrisisla
• [x] Github roles, labelling, triage and Editors- @chrisisla and @eteridvalishvili
• [x] Open invite for updates from other WGs
• [x] 5. AOB

Minutes

Minutes & Actions

Admin

• ED ran through anti-trust statement and meeting notices
• Past meeting minutes approved
• DS notified attendees that next session would 12th March

Ratification of Lyteck Lynhiavu as maintainer on behalf of ISDA

• There were no objections to this, thus LL will now be a maintainer
• ED to add LL to relevant CDM maintainers github team and published list on readme/website

Updates: Release Governance and Scheduling- TH

• Still many issues and discussion points to work through including ownership and PR automation PoC- further meetings to occur and another update required at next session of SWG- TH to action
• It was noted that a proposal had been made by DS at the CRWG earlier in January to ensure that candidates for minor release are notified to the CRWG on fortnightly cycles- see also minutes of the CRWG; this is to be added to final governance proposals for formal ratification
• Question on whether the build process meetings in flight would also tackle governance- TH responded in the positive

Updates: Ref Data Lists & Serialisation

• Ref data list issue was created as per last SWG; there are yet to be any submissions to carry out the work though deadline is 29th Feb
• Serialisation- funding has not yet been agreed, but ISLA and ISDA are closer to agreeing a possible way forward

Github roles, labelling, triage and Editors

• CR confirmed that the triage github role supplied by ED gave exactly the permissions required which are namely to allow regular contributors to edit PRs and issues with labels and assignment. ED to ensure/confirm the Editor role follows that triage permission list
• Questioned on process to appoint Editors, it was agreed that maintainers can propose editors by email to cdm maintainer list, and if no objection then those persons can be given the Editor role; this group will then be in a list

AOB

• Versioning was brought up by Fragmos as something that should urgently be looked at and specifically a mechanism to translate between versions
• CR pointed towards discussion 2180 as per comments on this meeting issue below.
• During serialisation scoping it was agreed by that sub-group that transforming between versions would be in a later phase of development
• Fragmos suggested there are lighter ways to approach the problem- interoperability between versions is not a yes/no binary answer- those suggestions are to be brought to the TAWG- DI took an action
• Brian Lynn will also present thoughts on change control at the next SWG when release conversations should be further progressed

Decisions Made

Action Items

Zoom info

Join Zoom Meeting https://zoom.us/j/93756205037?pwd=NFd1SUh1ZXdOdVNjQXdLVzZBbnpudz09

Meeting ID: 937 5620 5037 Passcode: 911071 Find your local number: https://zoom.us/u/axu5kFLKy

[DIVA291265]

I'd like 2 topics to be addressed:

1. Management of versions: this is an important topic so that CDM can be used in production, whether for DRR or post-trade. But it seems that it's not considered as a priority topic in the Technology WG.
2. Various CDM "types": there are several types - Opensource, ISDA extension, same with ICMA & ISLA. Whether we should use one or the other is not clear. And importantly, they are not consistent, for instance CDM in ISDA foundation contains an old version of CDM Opensource.

Thanks, Daniel

[chrisisla]

Hi @DIVA291265,

Thanks for your comments.

For point 1, the TAWG is a technology working group and has no say on the content, governance or management of releases. This is all under the guidance of the Steering WG, so this is the correct place to raise this as a topic for discussion 👍 (As a side point, the priority of what the TAWG works on is set by the participants of that group - if you would like to have more say over what gets worked on by the TAWG then please join that WG and help set the priority)

For point 2, after the migration of the CDM to FINOS there is only one CDM model, being the version housed in this repository. The old ICMA and ISLA models, that were used as pilots/proof of concepts, where deprecated quite some time ago and are no longer available.

DRR and ISDA Foundations are separate extensions to the CDM. If either of these models are not using the correct versions of the CDM then please contact ISDA, as this is not controlled by the WGs here at FINOS.

Thanks!

[DIVA291265]

Hi @chrisisla ,

Thanks for your answer.

Regarding point 1: I'm not referring to release schedules and content, but to versioning method. I mean the ability to support upgrading existing objects from old versions to new versions (the concept of migrations in typical software products) and/or the ability for newer versions of the CDM to support handling objects created with older versions of the CDM. Current upgrades to upper versions of CDM leaves all persistent objects to become un-usable and migrating them from old version to new version is a manual and error prone process involving a lot of assumptions of what goes where and how.

[chrisisla]

Thanks for the clarification @DIVA291265 , that makes more sense now and yes, interoperability between versions of the CDM is a subject that has been considered by the TAWG at some length during the recent discussions on serialisation. At the time we felt versioning was big enough to be a topic in its own right and so had to remove it from the serialisation scope.

The discussion on serialisation can be found here: 2180

At one of the first meetings we decided to remove versioning from these conversations, the minutes can be found here: minutes

There are also some supplementary questions about versioning which are being discussed here: 2305

Adrian was involved in the serialisation discussions and it would be great for him to be involved with ongoing discussions on versioning too. As I mention above, the priority of topics undertaken by the TAWG are constantly under review, so please join the WG meetings if you want to raise the priority of something.

Thanks!

[brianlynn2]

Brian Lynn / ISDA & GEM

[dshoneisda]

David Shone/ISDA

[dschwartznyc]

Daniel Schwartz/FT Advisory

[DIVA291265]

Daniel Ivanier, Fragmos Chain

[jgavronsky]

Jane / FINOS

[tomhealey-icma]

Tom Healey/ICMA

[deyan-paroushev]

Deyan Paroushev / Sofia University St Kliment Ohridski

[mgratacos]

Marc Gratacos / TradeHeader

[chrisisla]

Chris Rayner / ISLA

[dschwartznyc]

@tomhealey-icma - following up on whether there is a process in place to clarify, resolve, and get community agreement on open concerns regarding Release Governance including the Build Process. cc: @dshoneisda @chrisisla

[tomhealey-icma]

Yes - I published a summary of the governance issues and current proposals on Monday, and requested comments and any other proposals due back by EOD March 11th.

[dschwartznyc]

Yes - I published a summary of the governance issues and current proposals on Monday, and requested comments and any other proposals due back by EOD March 11th.

@tomhealey-icma - where were the issues and proposals published?

[tomhealey-icma]

Following up on the discussions on release governance I’ve described below the open items to be resolved. As we’ve heard differing views on these topics and in order to move forward, I propose that anyone with a different view on any of the governance topics, should circulate a clear proposal. If you are in favor of the proposal your comments are welcomed but a non-comment will be considered approval as well.

Proposal 1: Draft PRs and Ready for Review

Current: Most PRs are submitted as “review ready” even if they are not labeled.

Proposal: All PRs will be submitted as Draft. A contributor/editor can move from Draft after all labels are properly set. This process will be implemented using Github actions.

Proposal 2: PR Approvals

Current: PRs only need one approval from a maintainer and the approving maintainer can be from the same organization.

Proposal: Any PR with a model change or DSL change will require approval by at least one maintainer from each of the three TAs. This process will be implemented using Github actions.

Proposal 3: Dev Release Cycle

Current: Dev minor and patch release are ad-hoc.

Proposal: Dev minor releases and unreleased patches will be automatically released weekly unless there are no approved PRs. Patches can be released as needed. Minor and patch releases must be backward compatible.

Proposal 4: Dev to Prod Release Cycle

Current: Prod releases occur approximately once per year but date is not fixed

Proposal: Prod minor releases will be based on contributor request and approval by CRWG. Prod major releases will occur once per year on a fixed date set by the Steering Committee. Where a non-backward compatible change is approved, an ad-hoc prod release can be requested.

Proposal 5: Definition of Backward Compatibility

Current: Like other types of software, backward compatibility in the context of a domain model means that an implementor of that model would not have to make any change to update to such version.

Prohibited changes: Change to the structure (e.g. the attributes of a data type or the inputs of a function) or removal of any model element Change to the name of any model element (e.g. types, attributes, enums, functions or reporting rules) Change to any condition or cardinality constraint that makes validation more restrictive Change to the DSL that results in any existing expression becoming invalid Change to the DSL that results in change to any of the generated code's public interfaces Allowed changes: Change that relaxes any condition or cardinality constraint Change to any synonym that improves, or at least does not degrade, the mapping coverage Addition of new examples or test packs Change to the user documentation or model descriptions Addition of new data types, optional attributes, enumerations, rules or functions that do not impact current functionality Proposed:

Prohibited changes:

All the above plus:

Any DSL change that results in any prohibited change or change in a test case input or output file. A public interface shall be defined as any generated API or function that can be called from software or service outside the CDM.

Responses are due by EOD ET Monday, March 11.

[dschwartznyc]

Following up on the discussions on release governance I’ve described below the open items to be resolved. As we’ve heard differing views on these topics and in order to move forward, I propose that anyone with a different view on any of the governance topics, should circulate a clear proposal. If you are in favor of the proposal your comments are welcomed but a non-comment will be considered approval as well.

Proposal 1: Draft PRs and Ready for Review

Current: Most PRs are submitted as “review ready” even if they are not labeled.

Proposal: All PRs will be submitted as Draft. A contributor/editor can move from Draft after all labels are properly set. This process will be implemented using Github actions.

Proposal 2: PR Approvals

Current: PRs only need one approval from a maintainer and the approving maintainer can be from the same organization.

Proposal: Any PR with a model change or DSL change will require approval by at least one maintainer from each of the three TAs. This process will be implemented using Github actions.

Proposal 3: Dev Release Cycle

Current: Dev minor and patch release are ad-hoc.

Proposal: Dev minor releases and unreleased patches will be automatically released weekly unless there are no approved PRs. Patches can be released as needed. Minor and patch releases must be backward compatible.

Proposal 4: Dev to Prod Release Cycle

Current: Prod releases occur approximately once per year but date is not fixed

Proposal: Prod minor releases will be based on contributor request and approval by CRWG. Prod major releases will occur once per year on a fixed date set by the Steering Committee. Where a non-backward compatible change is approved, an ad-hoc prod release can be requested.

Proposal 5: Definition of Backward Compatibility

Current: Like other types of software, backward compatibility in the context of a domain model means that an implementor of that model would not have to make any change to update to such version.

Prohibited changes: Change to the structure (e.g. the attributes of a data type or the inputs of a function) or removal of any model element Change to the name of any model element (e.g. types, attributes, enums, functions or reporting rules) Change to any condition or cardinality constraint that makes validation more restrictive Change to the DSL that results in any existing expression becoming invalid Change to the DSL that results in change to any of the generated code's public interfaces Allowed changes: Change that relaxes any condition or cardinality constraint Change to any synonym that improves, or at least does not degrade, the mapping coverage Addition of new examples or test packs Change to the user documentation or model descriptions Addition of new data types, optional attributes, enumerations, rules or functions that do not impact current functionality Proposed:

Prohibited changes:

All the above plus:

Any DSL change that results in any prohibited change or change in a test case input or output file. A public interface shall be defined as any generated API or function that can be called from software or service outside the CDM.

Responses are due by EOD ET Monday, March 11.

Comments/questions:

Proposal 2 - PR Approvals Requiring all three TAs to approve every model or DSL change seems restrictive both in terms of requiring extensive oversight regardless of the impact of the change and in that it removes the opportunity for maintainers who are outside of the TAs to guide CDM's direction.

What about releasing the constraints based on the extent of the change? IE, something like:

• Minor changes: two maintainers at least one of which comes from a different organization than the one proposing the change. This would also apply to a patch release when bundled into the scheduled Minor change
• Urgent defect resolution: this may require additional scrutiny since this type of release might have immediate timing with limited testing. Rollback of a change might be approved with less oversight than forward fixes.
• Major changes: approval of the SWG

Proposal 3: Dev Release Cycle Proposal 4: Dev to Prod Release Cycle

• Please clarify what is meant by "Dev minor releases" as it seems to imply constraints on releases of code in development and one would think that these should take place with no constraint to facilitate collaboration and testing.

WRT changes to production code:

• Patches and Minor changes: please confirm that patches and minor releases will be released to Production on at least a weekly basis with the potential that patches can be released immediately to production depending on the severity of the defect to be resolved.
• Major changes: is the proposal to restrict major releases to once annually? If so, it would seem to limit CDM's adoption and development. Instead, perhaps it would make sense to have at least one annual release with more at the discretion of the SWG.

Proposal 5: Definition of Backward Compatibility

• The terminology of this proposal is also confusing. For example, is the intent for using the term "prohibited change" to describe those that must be migrated to the next Major release and cannot be included in a Minor or Patch release? If so, there is an urgent need for definitions that are very clear since "prohibited changes" must fall under the proposed annual schedule for Major releases.
• What is the categorization for the migration of data from one field to another? Is it "prohibited" for releases labeled "Minor" / "Bug-fix"?
• Are we confident that any addition of a test case should be a breaking change? What if the addition increases the test coverage of the existing model and the test passes?
• How do we classify changes to the machinery associated with the DSL such as the code-generators?
• How do we classify changes to the build process for CDM and who is responsible for its maintenance?

Overall there seem to be several significant open issues. Perhaps a community discussion is warranted?

[ahutusoru123]

Following up on the discussions on release governance I’ve described below the open items to be resolved. As we’ve heard differing views on these topics and in order to move forward, I propose that anyone with a different view on any of the governance topics, should circulate a clear proposal. If you are in favor of the proposal your comments are welcomed but a non-comment will be considered approval as well.

Proposal 1: Draft PRs and Ready for Review

Current: Most PRs are submitted as “review ready” even if they are not labeled.

Proposal: All PRs will be submitted as Draft. A contributor/editor can move from Draft after all labels are properly set. This process will be implemented using Github actions.

Proposal 2: PR Approvals

Current: PRs only need one approval from a maintainer and the approving maintainer can be from the same organization.

Proposal: Any PR with a model change or DSL change will require approval by at least one maintainer from each of the three TAs. This process will be implemented using Github actions.

Proposal 3: Dev Release Cycle

Current: Dev minor and patch release are ad-hoc.

Proposal: Dev minor releases and unreleased patches will be automatically released weekly unless there are no approved PRs. Patches can be released as needed. Minor and patch releases must be backward compatible.

Proposal 4: Dev to Prod Release Cycle

Current: Prod releases occur approximately once per year but date is not fixed

Proposal: Prod minor releases will be based on contributor request and approval by CRWG. Prod major releases will occur once per year on a fixed date set by the Steering Committee. Where a non-backward compatible change is approved, an ad-hoc prod release can be requested.

Proposal 5: Definition of Backward Compatibility

Current: Like other types of software, backward compatibility in the context of a domain model means that an implementor of that model would not have to make any change to update to such version.

Prohibited changes: Change to the structure (e.g. the attributes of a data type or the inputs of a function) or removal of any model element Change to the name of any model element (e.g. types, attributes, enums, functions or reporting rules) Change to any condition or cardinality constraint that makes validation more restrictive Change to the DSL that results in any existing expression becoming invalid Change to the DSL that results in change to any of the generated code's public interfaces Allowed changes: Change that relaxes any condition or cardinality constraint Change to any synonym that improves, or at least does not degrade, the mapping coverage Addition of new examples or test packs Change to the user documentation or model descriptions Addition of new data types, optional attributes, enumerations, rules or functions that do not impact current functionality Proposed:

Prohibited changes:

All the above plus:

Any DSL change that results in any prohibited change or change in a test case input or output file. A public interface shall be defined as any generated API or function that can be called from software or service outside the CDM.

Responses are due by EOD ET Monday, March 11.

Comments/suggestions

Proposal 2: I think Dan's input here is quite on point, but it will require a clear, objective definition of a Minor and major Change (which can be quite subjective to decide between) and what constitutes an Urgent defect (the only variant here that comes to mind would be if there is a party that is being directly affected by a defect in a severe way and reports it as such). The discussion around these definitions can be quite difficult and lengthy to conclude.

I propose starting with a simple approach that fixes the current issue but is not too restrictive: require at least two maintainers to approve and at least one from a different organization.

Proposal 3: I do not understand what we want to achieve by having a weekly cycle instead of the current way. We would have fewer dev releases, and multiple changes would be bundled together in a release. This comes with the downside that @Dan mentioned above, but I don't see the upsides.

Proposal 4: Having a yearly schedule for PROD releases can have a negative impact on adoption, on development contributions (the community that contributes to the CDM surely desires to use their contributions, and waiting for up to 1 year to use the contribution can be demotivating), and issue identification+resolution (finding an issue months or even 1 year later than it was created initially can bring a lot of complexity: the original creator of the change might not be around, there might be other parts built on top of the original change with the issue that also need to be changed, the information is not “fresh” anymore). An immediate side-effect will be using DEV versions in PROD systems as a workaround.

I suggest a monthly or quarterly release cycle at least or ideally moving gradually towards CI/CD.

---

I also believe a meeting dedicated to the topic would be ideal to iron out all the details.

[mgratacos]

Proposal 2: PR Approvals This seems more restrictive that what we currently have. I think it's already difficult to get the approvals from two TAS. I agree with @dschwartznyc 's suggestion to have a layered approach and have:

1. Patches, bug fixes, one maintainer is enough
2. Minor changes: two maintainers at least one of which comes from a different firm than the one proposing the change.
3. Major changes, including DSL changes: SWG

Maintainers should review that the labelling of the PRs regarding the type of change is accurate.

Proposal 3: I agree with @ahutusoru123. Not sure why we need to establish a weekly cycle. Is this a cost issue?

Proposal 4: If we want to expand the adoption, we cannot have only one Production version per year. Since we are generating new content rapidly, production versions will need to be generated more frequently than when the standard is more mature. We've seen this in other financial standards such as FpML and FIX. The CDM Roadmap based on content should define the timeline for Prod releases based on the timeline for adding new content that is needed to implementers. For example, the Collateral WG may want to have a Prod release in the summer and the Products and Events sooner than that. The CDM Roadmap should include an attempt to schedule the expected Prod releases for the year based on the book of work of each working group.

Proposal 5: It should include changes to functions. CDM is a functional language. We cannot think only in terms of data model changes. If someone changes the content of a function breaking the implementation of that function, it should be marked as a backward incompatible change.

[eteridvalishvili]

Eteri / FINOS

[llynhiavu]

Lyteck Lynhiavu / ISDA

[DIVA291265]

Daniel Ivanier, Fragmos Chain

[mikealambert]

Mike Lambert / Broadridge

[tomhealey-icma]

The CDM PR and Release Governance issue has been converted to a GitHub Discussion, Discussion 2774