Open Community (TDC) Meeting, Thursday 29 February 2024

[github-actions]

NOTE: 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.

Zoom: https://zoom.us/j/975841675, dial-in passcode: 763054

Participants must abide by our Code-of-Conduct.

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	TDC
New issues needing attention	@OAI/triage

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

[AxelNennker]

Could we talk about #3595 in this meeting?

oauth2 metadata

[handrews]

Process Stuff:

• Define deployment process for link fixes to published specifications #3515 (comment) (@baywet asks about using GitHub branches in a normal way now that we are sustaining multiple release lines for the first time, so that we don't have to do complex git-fu to port PRs from one line to the next.)
  • I've been looking at synchronizing v3.0.4-dev, v3.1.1-dev, and v3.2.0-dev
  • While there is a fwdport script, using it is complex, error-prone, and it's not meant to be used regularly (but putting off synchronization also makes everything more fragile and error-prone)
  • I tried to modify the script and make it easier to use, but then ended up accidentally deleting stuff and have felt too demoralized to try again because it's so annoying to do this sort of things the way we have it set up - it's currently the most frustrating task on my OpenAPI TODO list.
  • Continuing to do this will mean a constant stream of forward-port PRs to merge instead of more git-typical branch updates or rebases
  • It would be a little complicated to restructure onto a normal single-file, multiple-branches approach, but probably less than synchronizing what we have manually
• Add essential policies to DEVELOPMENT.md #3599

PRs that could be merged async:

• Fix incorrect OpenIDConnect discovery url #3607
• Add structured fields primitive types to format registry #3390 (@mkistler has addressed all feedback, just needs one more approval to merge)

PRs/Issues requiring discussion:

• Draft proposal for experimental field #2386 (this field is actually in use as an x- field, does that mean we should go ahead and merge the draft proposal?)
• 3.1.1 discriminator improvements #2618
• Discriminator updates for v3.2 #2621
• No possibility currently to specify grant-type ciba in OAS  #3587
  • Extends security scheme with ciba flow #3609

[lornajane]

Quick summary from my meeting notes, with thanks to @miqui for hosting this week!

SIG updates: Workflows group is meeting weekly and pushing for their first 1.0 release in March. Moonwalk has been active and is considering the differences between tools for validation and those for data modelling.

We talked about the difficulties in making new releases of each of our various branches, tagging old releases with updated links, and maintaining three version branches simultaneously. I (@lornajane ) made a proposal that we never update tags, and that with the 3.2.0 release we announce a probably-final release of the 3.0 branch (likely 3.0.4). I'll add a longer version of this point as a separate comment.

We discussed whether we needed a formal lifecycle document, but since we haven't released anything in some years, we agreed that we probably weren't ready to commit to something like that. Thanks @baywet for the suggestion.

There's a proposal to add an experimental tag to OpenAPI specification (#2386). This tag is in use in the wild as an extension. While we had some concerns about how appropriate it would be to implement this in OpenAPI, it's a good proposal so we'll review the pull request with a view to accepting the proposal pull request and taking the idea to further consideration and iterations.

We've got a couple of Discriminator-related issues open at the moment, but both of them would involve some amount too much change. #2618 has some excellent content and clarication and we'd like to partially accept some of those changes. However there are changes proposed for 3.2 (#2621 ) that are probably too much and we don't plan to proceed with those.

#3587 was discussed for adding a grant type for Ciba. We agreed that we'd review a pull request adding this for 3.2.

In #3152 we had a link fix for the OIDC connector discovery which was linking to something else, oops! After discussion in the meeting today, @shilpa-padgaonkar will follow up with a new pull request which links somewhere better.

[lornajane]

A recap of my in-meeting proposal for our branch/tag/release strategy:

• Released spec versions are immutable. Even for broken links. Let's get better at releasing patches as needed. This approach also stops all the discussion about editing tags. Technically possible or not, it's probably a bad idea. New versions are always safe and we should do that.
• We currently maintain 3.0 and 3.1 branches. Our next set of releases will include a 3.2.0, and I propose that we therefore declare 3.0.4 as the final 3.0.x release and move to maintaining 3.1 and 3.2 instead. This is in line with the direction of travel of the project and will reduce the workload/complexity of what goes on which branch. There's nothing stopping us from doing a quick 3.0.5 if something compelling came up in the future.

Many OpenAPI users are on 3.0.x, but neither their API descriptions nor their tooling tracks new OpenAPI 3.0.x releases, so there's limited benefit to this work (I mostly see 3.0.1 versions, not sure why). We want to be moving forward and offering reasons to upgrade, so people can keep using what they know, and the 3.1 ecosystem is mature enough for people to upgrade without feeling like they're at the bleeding edge.

@OAI/tsc I don't know how we formalise this as a decision (if you even agree) but your feedback would be valuable here. You as well, @handrews.