Open Community Working Meeting 2022-09-06

[Relequestual]

📺 See Recording

⏪ Go To Previous Meeting

Agenda

Topic	Owner	Decision/NextSteps
ADR for decoupling from IETF1	@Relequestual	Read the updates at Spec PR #1277
Proposal for post-IETF SDLC	@jdesrosiers	Follow the discussion #234
New Website Work	@jdesrosiers	Deferred to next meeting

Highlights

• Other than the website update, all items on agenda were brought up and discussed.

• Update on website work was deferred for later.

• How do we decide the reviewers as an organizational practice ?

• @handrews and @jdesrosiers shared their views on topics ranging from keyword behavior, feature stabiliy, vocabulary systems and releases.

Actions

• Article distinguishing and clarifying vocabulary, features and keywords

• Progress report on website work

• @Requestual to add W3C perspective to the discussion #234

• Add @handrews to reviewers

• @jdesrosiers to add comments made by @handrews ¹

Attendees

Account
@Relequestual
@jdesrosiers
@jviotti
@handrews
@devinbost

Details

ADR decoupling with IETF process

Members shared their thoughts on how the IETF process does not work for JSON Schema as an organization. Decoupling ADR then requires documenting the process of trying something different¹. Although it is widely agreed upon that the IETF process for the media-type registration and JSON Schema's association with Linux Foundation is legitimacy confirming.

A struggle community faces is getting vendors involved in discussions which is not particular to JSON Schema. As it was pointed out that even with membership in OpenAPI, they too struggle to get stakeholders to become part of the discussions. Therefore, how to ensure due dilligence with other working groups and participation of stakeholders was touched upon.

For more read spec pr #1277

---

Post IETF SDLC

@jdesrosiers presented a brief overview of the situation. Briefly put, the aim is a stable specification whose parts can be evolved. Leading from that thought, the next spec would be stable i.e no backward and forward incompatible changes from then on. Along with an ability to flag features like certain features can be flagged unstable and be evolved from there.

A three stage process to add new features to spec is suggested -

Stages

• Proposal Stage
• Discussion, review and decision regarding whether to add feature in the specification
• If added, feature stays for year while it is made sure it is not going to change before reaching a stable status

Regarding Releases

• Once a year, say on January 1st, promote features from stage-2 to stable.
• Change the flag in the spec eg. stage-2 to stable 2023 release feature.
• Evolving spec. eg. bug fixes, non-functional clarification can be updated anytime without waiting for release cycles.

A few concerns were raised regarding the above process and its impact on implementers along with keywords, vocabulary and validation behaviour. The answer provided was, as most of what is being discussed and written is for the process of how the JSON Schema Org. updates its specification rather than how others implement or use it. Hence, most users won't be affected as none is bound to provide support for unstable features and implementation docs alongside specification doc will have to be referred to at time of working with it. It is hoped the process described will give both implementors and schema authors the surety of no surprises in their schema processing.

The above can be thought of as analogous with feature supports in browsers.

---

Further Readings

• https://www.youtube.com/watch?v=GjJpRsVffg0?utm_source=awesome-jsonschema
• https://www.youtube.com/watch?v=ZrVTZwmTR3k
• In OpenTelemetry, specification is split:
  https://opentelemetry.io/docs/reference/specification/status/
• https://opentelemetry.io/docs/reference/specification/versioning-and-stability/
• https://json-schema.org/blog

---

Footnotes

1. https://github.com/json-schema-org/json-schema-spec/pull/1277 ↩ ↩² ↩³

[jdesrosiers]

I don't know if this meeting is actually going to happen because it's a holiday, but here's a couple of things that I'd like to discuss.

• ADR for decoupling from IETF - Add ADR for decoupling from IETF json-schema-spec#1277
• Proposal for post-IETF SDLC - https://github.com/orgs/json-schema-org/discussions/234

[github-actions]

Hello! 👋

This issue has been automatically marked as stale due to inactivity 😴

It will be closed in 180 days if no further activity occurs. To keep it active, please add a comment with more details.

There can be many reasons why a specific issue has no activity. The most probable cause is a lack of time, not a lack of interest.

Let us figure out together how to push this issue forward. Connect with us through our slack channel : https://json-schema.org/slack

Thank you for your patience ❤️