Open Community (TDC) Meeting, Thursday 29 August 2024

[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]

3.1.1

• 3.1.1: tables cleanup #4056
• 3.1.1: example for "raw JSON" as message body #4055
• Clarify security; state what [] means #4007

3.0.4

• gh-pages: view link and download link for latest JSON schemas #4034
• 3.0.4: tables cleanup & markdownlint #4040 - to be ported to 3.1.1

Roadmap

• What absolutely MUST go into the patch versions?
• When do we publish the patch versions?
• What is the publishing ceremony for patch versions?
  • Release candidates with public review period?
  • Or just approval by the TSC and out they go?
  • Who announces this how and where?
• What should go into 3.2.0?
  • @handrews has a plan

[LasneF]

in the context of #2996

i wonder if we should have a Schema version not only per major version only but as well for minor version ie 3.0 / 3.1 , the question can be raised as the introduction to 3.2

[lornajane]

Here is the plan for the 3.0.4 and 3.1.1 patch releases, we're going to need more input on some of these things, probably from @darrelmiller, @earth2marsh and @webron who have done this before and whom we might embarrass in public if we get this wrong in some way.

What else to include: Only the clarification on the security wording SHOULD be included (not MUST, we won't wait).

Release process: (we're winging this, more additions or corrections would help us a lot)

• No RC or review period is needed for patch releases, we just release.
• Do we need a formal signoff from all @OAI/tsc people, or something else?
• Draft the release in GitHub, and then make it a release when we are ready.
• Do we even have a changelog?
• How do the files get from the dev branches into the main branch? Do I merge them?
  - DO NOT SQUASH branches, we need to preserve the history. Also lock branches, don't delete them.

Announcing:

• @handrews and @lornajane will collaborate on a blog post to announce the patch releases, we'll talk to @hellobudha about how the dates line up with the upcoming hangouts and use that channel too.
• We'll also produce some shorter content to use with newsletters, social posts, LF slides, whatever else we need - @swaldron58 is our outreach contact and co-conspirator for getting published.

Post release:

• we're refactoring our GitHub setup to try to make things less strange. Helpfully, I don't think this is documented anywhere yet but TL;DR:
  - we have a specification.md file in the repo and this is the latest version and in-progress version on every branch so that commits can be cherry-picked from one branch to another where we're applying the same changes to the same file. We still rename it to its new version (maybe before naming branches?)
  - github pages becomes a directory or a separate project (there's an issue for that somewhere) instead of a branch
  - we make it easier to build the HTML version locally and on each PR
  - the build scripts for formatting need to update with these changes
  - we think we only need to do these tasks for 3.1 and 3.2 - we don't expect any further patch releases for 3.0 (but nothing prevents us from doing that if something comes up)

[mikekistler]

Regarding the mechanics of merging the branches to main, I took a look at the v3.0.4-dev branch to see what files are actually changed there:

base=$(git merge-base main v3.0.4-dev)
>git diff --name-only $base..v3.0.4-dev
.github/workflows/validate-markdown.yaml
.gitignore
.markdownlint.yaml
package.json
scripts/format-markdown.sh
versions/3.0.4.md

The versions/3.0.4.md is obviously the file we want. I think the rest are all "behind" the version in main, so I think we need to fix those if we want to make a PR from the v3.0.4-dev branch to main (which will preserve all the history, as we've said we want). There are a few ways to do this but I think the easiest way is to just bring the branch up to date with main. I'll open a PR for this.

Update: Simply pulling over the latest files from main will not fix the merge conflicts, so we'll need something more advanced here. Not sure what.

[ralfhandl]

I've created a draft PR that will merge main into v3.0.4-dev and resolve the two merge conflicts, see PR description

• 3.0.4: update from main #4065

After that we should be able to merge v3.0.4-dev into main without difficulties.

[earth2marsh]

For guidance on the release process, see: https://github.com/OAI/OpenAPI-Specification/blob/main/DEVELOPMENT.md#release-process

That describes what approvals are required for patch/minor/major releases.