Open Community Working Meeting 2022-10-17 - 14:00 PT

[Relequestual]

Open Community Working Meeting 2022-10-17 - 14:00 PT

📺 Watch Recording

⏮Go To Previous Meeting

Agenda

Topic	Owner	Decision/NextSteps
SDLC update? - What's left on the table to discuss?	@jdesrosiers	For updated text and discussion read discussion #234.
Current work file and explanation of it PR #250	@Relequestual	Current Work File to be added and another explaining the purpose of the current work file.
Article on stable JSON Schema / IETF - Anything to mention?	@jdesrosiers	The relevant updates can be read and followed at PR #23.
Referencing and identification of issues that have come up in the context of AsyncAPI's $ref tooling requirements discussion. Read	@handrews	A public proposal requesting for comments is to be shared with the community.
Next steps of the SDLC process ?	@jdesrosiers	Assigning a Champion for stage-0.
Forward and backward compatibility scheme.	@awwright	The draft document is to be shared for further discussion, clarification of scope and intent.

Highlights

• All the items on the agenda were brought up and discussed.
• Consensus on stage names of SDLC and a brief discussion on deprecated features.
• Discussion on assigning a champion for features at stage-0 who will be responsible of making sure all steps are followed before transition to stage-1.
• Unambiguity using BCP14¹ and decision to be made on a state machine to further make specification unambiguous.
• Where will process documentation live ? A website or as repository README.
• Updates to ADR template and articles aimed at public which provide context, and reasoning for the ADRs.
• Referencing and identification of issues were discussed as brought up by discussion at AsyncAPI.².
• Discussion on backward and forward compatibility was introduced.

Actions

• Adding two files, one current work file with automated notifications of updates and one explaining the use of it.³⁴⁵⁶
• Public facing articles regarding architectural decision records
• A location for process documentation to be decided
• @jdesrosiers and @handrews to talk about external / new reference standard proposals
• Sharing and review of compatibility document

Attendees

Accounts
@jdesrosiers
@Relequestual
@gregsdennis
@handrews
@awwright

Details

Specification Development Lifecycle

SDLC and IETF

Regarding SDLC decoupling from IETF, an explanation as to why the working group is taking a different paradigm for specification development
as opposed to the past published. This exercise will bring issues and visions to surface, which can be followed by discussion in detail about further aspects to be considered. Community participation is welcomed.

Publication of above will be followed by publishing of a formally written process.

Stages and Champion

Regarding semantic naming or numbered naming of stages of specification development a consensus is reached. Read discussion #234

With regards to features, it was decided that at stage-0 a champion (anyone other than the core contributing members) will be assigned by the core contributing members.
The Champion will be responsible for making sure all the steps are followed before transitioning to stage-1. The reasoning for the decision being; further stages would require more involved attention from working group as compared to stage-0.

---

Current Work File to highlight focus of working group

Following the discussion from previous meeting⁶ with respect to prioritization of concerns. Two new files, current work file³⁴
where current focus and interests of working group will live and an explainer's location is to be decided.
An automated process is to be created so that the community members can be made aware of updates to it on a regular basis.

At present a minimal working model of these automated updates is sought.

---

Reasoning for ADR decisions

Modifications to ADR template along with discussion on having something similar to SDLC/IETF discussion but for ADR.
So that when an architecture decision record is discussed the reasoning for the same can be communicated by the working group to the community at large.

---

JSON Schema referencing and tooling

With respect to discussion at AsyncAPI ² a public proposal was discussed to be published (with disclaimers, as there are other proposal out there as well) and working group will be requesting for comments on the same. It is thought, this will help in keeping the discussion moving forward along with increased participation of stakeholders.

This proposal will be concerned with identification of issues raised by stakeholders with referencing, reference tooling, bundling etc with feedback from them.^{2 7}.

Moreover, from the discussion at AsyncAPI² it was felt that the intent of their scope was vast and rather a common base set out of those and from further public discussions should be derived i.e rather than doing all things,
things that allow for building all things being the approach.

---

Updates on compatibility

Document and thought relevant to backward and forward compatibility was introduced and a brief overview was shared in the meeting.
The same will be shared with the members of the working group for further discussion as it is in a tentative stage.

Footnotes

1. https://www.rfc-editor.org/info/bcp14 ↩

2. https://github.com/orgs/asyncapi/discussions/485 ↩ ↩² ↩³ ↩⁴

3. https://github.com/json-schema-org/community/pull/250 ↩ ↩²

4. https://github.com/json-schema-org/community/pull/249 ↩ ↩²

5. https://github.com/json-schema-org/community/issues/248 ↩

6. https://github.com/json-schema-org/community/issues/244 ↩ ↩²

7. https://json-schema.org/blog/posts/bundling-json-schema-compound-documents ↩

[handrews]

I'd like to discuss referencing and identification issues that have come up in the context of AsyncAPI's $ref tooling requirements discussion.

[jdesrosiers]

Let's talk about next steps for the SDLC process.

[awwright]

I've been hard at work detailing a forward compatibility scheme, I'd like to share what this looks like, starting with motivations—the problems that schema authors, implementers, and spec editors each encounter when interoperability requirements are incomplete. For example, the question "which meta-schemas can we stop supporting" becomes a major consideration, and the difficulty of writing "multi-consumer schemas."

[benjagm]

Closing this issue as all tasks are completed. Thanks for your contributions!