Open Community (TDC) Meeting, Thursday 16 May 2024

[github-actions[bot]]

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.

[handrews]

• If anyone is on the call who knows the 2.0 / 3.0 referencing intent, let's talk about OAI/OpenAPI-Specification#3772 (but if not, I'll update it based on feedback so far and take it out of draft as it has enough approvals, so no need to spend time on that in the call)
• Competing alternative solutions for OAI/OpenAPI-Specification#3792 (seriously, what is going on here- apparently the default value prevents poorly-defined "empty" values, but we've deprecated the non-default value? Do we just not support empty parameters? What is the justification for that?)
  • OAI/OpenAPI-Specification#3798
  • OAI/OpenAPI-Specification#3803
• We should look at these schema-related PRs from new contributor @TakahikoKawasaki
  • OAI/OpenAPI-Specification#3790
  • OAI/OpenAPI-Specification#3791
• OAI/OpenAPI-Specification#3808 (Can anyone confirm the timeline of Jason Harmon's TSC tenure?)
• OAI/OpenAPI-Specification#3740 (our allegedly normative Markdown doesn't include the references list (can we just deem the rendered HTML authoritative now since it is literally the only complete presentation of the spec?) and splitting normative and informative references turns out to be more complex than first seems, as @Bellangelo discovered by trying to submit a PR)
• More issues for review – How many TSC opinions are necessary to take an issue out of review and work on a PR and not risk the PR being shot down by other TSCers? (of course, sometimes PRs get shot down anyway, but in general...?)
  • https://github.com/OAI/OpenAPI-Specification/issues/1551#issuecomment-2110600330 (more obscure form serialization problems)
  • https://github.com/OAI/OpenAPI-Specification/issues/3800#issuecomment-2110592705 (should we update RFC numbers in patch releases or only in minor releases? ignore my ranting about whatwg, that was a tangent)
  • https://github.com/OAI/sig-moonwalk/issues/112 (@ralfhandl has suggested lumping this in with the Moonwalk reconsideration of the whole area, does that work for everyone? If so I'll label it Moved to Moonwalk and close)
  • https://github.com/OAI/OpenAPI-Specification/issues/1806#issuecomment-2081015562 (is there anything here we're going to do, or should we just close this?)
  • https://github.com/OAI/OpenAPI-Specification/issues/1435#issuecomment-2081606362 (is anyone willing to look at XML bug reports? If not, should we delcare that we're not supporting XML anymore and close them all? This is one of the most obvious problems so I figured it was a decent starting point)

[lornajane]

We did not cover a lot of ground this week, but we had some really good discussions on deeply technical topics.

• OAI/OpenAPI-Specification#3772 hinges on the intention (which isn't clearly written) of whether references are supposed to be context-dependent or not. In 2.0, references inlined the target content. In 3.1, the reference behaviour is clearer - but in 3.0, it's not clear. This matters because while we don't want to spend a lot of time on small (but impactful!) details of 3.0, a compliance tool is being created for 3.0 and these details are important.
• OAI/OpenAPI-Specification#3798 discussion concluded with the idea that if the field was called disregardEmptyValues, it would make more sense. The idea is that while in its default state (allowEmptyValues is false) an empty value is an empty value and should be handled as empty, when allowEmptyValues is true then the empty value should be ignored by the server. The use case is browsers sending all fields where some of them are empty.
• OAI/OpenAPI-Specification#3790 is a contribution aimed at helping us move forward with the schemas. However it's written in Ruby which isn't currently a tech stack used in the project. We've asked if it can be changed since adding more and more technical dependencies and requirements to the project doesn't help people to get started or participate.
• We did merge OAI/OpenAPI-Specification#3808 after checking the details of past maintainers
• We discussed the merits of adding defaults to parameters (currently this is only on schemas) OAI/sig-moonwalk#112 . It's not clear how this should look and since we don't have support in 3.x yet, this issue has been moved to Moonwalk to consider. When that spec takes shape, we'll be evaluating which of those solutions can be adopted by minor or patch updates in the 3.x branch.