Lorna Jane Mitchell

I'd suggest that we say that features are to be added on 3.1 branches only, but let's keep adding resources, clarifications and upgrade-easing changes to both 3.0 and 3.1. We...

@baywet This is the full [project release history](https://en.wikipedia.org/wiki/OpenAPI_Specification#Release_dates) - Your ideas are good but they are entirely the wrong "size" for a project like this which took ten years to...

My comments from today's meeting, copied here as it's probably a better place for them: Released spec versions are immutable. Even for broken links. Let's get better at releasing patches...

Yes, we had a discussion about being cautious in patch releases and putting everything new into minor (or major!) releases so that users and toolmakers alike know exactly what's expected...

Possibly useful reading: the equivalent documentation from the Kubernetes project, which has a recognised role between contributor and maintainer called "reviewer" which I thought was cool https://github.com/kubernetes/community/blob/master/community-membership.md The submitter can...

Good summary! For the question on we want to categorising old issues, I'd say that we don't - or at least let's start with the ones that are open so...

I'm +1 on all these suggestions - and we can always re-create and/or re-label as we go along if we want to evolve the strategy.

I think @karenetheridge 's list was `review`, `triage`, and `discussion-needed`. If we can nail down when to apply each of those, we can put something in the contributing guide and...

Yes, let's open an issue for it. I have this on a bunch of other repos and can add it here too

I opened #3596 to make this repeatable