Open Community (TDC) Meeting, Thursday 13 February 2025

[github-actions]

Weekly meetings happen on Thursdays at 9am - 10am Pacific

This agenda gives visibility into discussion topics for the weekly Technical Developer Community (TDC) meetings. Sharing agenda items in advance allows people to plan to attend meetings where they have an interest in specific topics.

Whether attending or not, anyone can comment on this issue prior to the meeting to suggest topics or to add comments on planned topics or proposals.

Meetings take place over Zoom: https://zoom.us/j/975841675, dial-in passcode: 763054

Accessibility & Etiquette

• Participants must abide by our Code-of-Conduct.

• Meetings are recorded for future reference, and for those who are not able to attend in-person.

• We invite you to feel comfortable to challenge any language or behaviour that is harmful or not inclusive during this meeting.

• We look forward to your participation, but please consider these acts of etiquette:

  • Remain on mute when not speaking to prevent interruptions.
  • Blur your background to reduce visual distractions.
  • Use the Zoom meeting "Raise Hand" feature to notify the group when you wish to speak.

Blur My Background	Raise Hand

Agenda Structure

Topic	Owner	Decision/NextStep
Intros and governance meta-topics (5 mins)	TDC
Reports from Special Interest Groups (5 mins)	SIG members
Any other business (add comments below to suggest topics)	TDC
Approved spec PRs	@OAI/tsc
Active Projects	@OAI/openapi-maintainers
New issues needing attention	@OAI/triage

/cc @OAI/tsc please suggest items for inclusion.

[ralfhandl]

Housekeeping

• respec.yaml: use older Ubuntu #4337
• dev: update from main #4344

[duncanbeevers]

• dev: update from main #4344; process improvement suggestions
  • This catch-up PR includes changes to main from mid-December
  • Drift between main and dev branches makes contributing more difficult
  • Can these catch-ups be entirely automated?

Automation Suggestions

• Auto-PR targeting dev with any changes from main (example)
• Auto-PR targeting v3.1-dev with any changes from dev
• Fail CI on mixed-changes PRs

mixed-changes: A PR which satisfies ALL of these:

• targets a dev branch (dev, v3.1-dev, …)
• includes changes to files present in main (eg; scripts/md2html/build.sh)
• includes changes to files not present in main (eg; src/oas.md)

[whitlockjc]

I would like to discuss the potential use of an OpenAPI issue for an RFC as it relates to extension design. TL;DR, Google is looking at its OpenAPI extensions for API Management features (details do not matter at this time) and there are a couple different approach discussed internally about how best to defined these things. Before I (a TSC member) just created an issue and labeled it "RFC", I want to discuss this with the OpenAPI TSC in this meeting to get approval for such things, and to hopefully get some traction for a quicker turnaround.

I'll talk to y'all tomorrow!

[lornajane]

• Add tags fields to schema for 3.2 Add new tags fields to schema #4353
• Question about when we release schema changes Adjust uri to uri-reference for security schema fixed fields #4328 (comment)

[mikekistler]

• Allow discriminator to be optional #4339

[baywet]

to follow up on @duncanbeevers 's comment:

• general agreement that it'd be beneficial to automate replication of changes.
• it's the first time we merge back from main to dev, so we want to get a feeling for the process first.
• things to consider to guard against wrong type of change in wrong type of branch:
  • multiple version files being changed.
  • should be a comment on the PR beyond the check/CI to get people's attention.
  • provide more context to the author what would be the right branch for what they are trying to accomplish.
• let's start small with main to dev first, and demo it on one of the next calls. @duncanbeevers

[baywet]

Notes on @whitlockjc's point. Google uses a bunch of vendor extensions, that are not standardized. Ask can we have a discussion place to suggest/debate/iron out extensions, as well as gather guidance around extensions design? There are registries in place https://spec.openapis.org/registry/namespace/index.html https://github.com/microsoft/OpenAPI/blob/main/extensions/index.md. There are discussions of this type already happening today #4330
General advice from the TDC: start discussions for guidance, and for individual extensions.
Some interesting content https://packagemain.tech/p/practical-openapi-in-golang

[baywet]

And we were running out of time for the last point, please jump in this discussion #4339 (comment)
Otherwise @mikekistler please add it to the agenda next week.