Description
Agenda
| Topic | Owner | Decison/NextSteps |
|---|---|---|
| Discuss WoT case study1 | @jviotti | Review the PR and set the right publication date for the article |
| Last call for comments on license | @Julian | Read it at PR #1255 |
| Unresolved SDLC discussions - Should we add a STAGE-0? How would it be defined? - Should unstable features be included directly in the spec or someplace else? |
@jdesrosiers | Read the latest at discussion #234 |
No agenda items were set and members were asked to bring one or two of their own to discuss.
Highlights
-
Some of the unresolved thoughts on SDLC like stable and unstable features, stages of including features etc.
-
A discussion on compatibility and behaviour of features
Actions
- Set right publication date for WoT Case Study Blog Post1
- @Relequestual to review contents of the WoT case study article
- Ideas from stakeholders and a log of them to reduce duplication
- @handrews to share case studies on features and keywords
- Use cases of snapshots
- A
keyworddependency tree for analysis - Merge PR #1255
Attendees
| Account |
|---|
| @Relequestual |
| @jdesrosiers |
| @handrews |
| @jviotti |
| @Julian |
Details
SDLC
Discussion on following unresolved thoughts regarding SDLC
Unstable Features
Should unstable features be included directly into the spec or someplace else was the topic raised. The working group agrees that it is appropriate to include features that are encouraged for implementation and in addition to stage-1 having a stage-0 for sorting out the encouraged features for stage-1. The thinking being, stage-1 requires implementation, testing, a written specification etc. so it has to be more concrete and "stabler".
The point of unstable features is to not having to put maintainenance work for every version as features evolve. At the same time being able to go back into past to see how a feature was defined in its unstable state is not thought to be useful.
Moreover, progressive transition in development of specification is considered a better way than a giant leap. The timespan in the process above will also allow for stakeholders to get involved and share their visions in the meantime. Therefore a process to be made for seeking ideas from stakeholders and keeping a log to reduce duplication.
The discussion also mentioned the ECMAScript TC39 specification process and their use of highlighting their stage three in sdlc on their homepage.
Snapshots are still under consideration along with living specification document. Filters were touched upon, like 2023 features, unstable and stable together with living specification will most likely make it easier to peruse through the docs and the same filters can be used to create the snapshot of specification.
Also, it was recongnized that it is better for everyone if unstable features do not make into the snapshots.
Regarding stage-2 Features
Discussion on how broadly deployed the working group wants stage-2 feature to be. The working group would like stage-2 features
to be implemented by implementers who are keeping their implementation up-to-date.
Does stage-2 fall into category of unstable features that is not in the snapshots ?
Technically stage-2 is unstable but it is part of the process of specification development lifecycle but stage-2 is to be considered having features most unlikely to change. The thought behind the stage is to slow down and consider all things possible before stable releases.
Compatibility
Compatibility is behavior based rather than feature based. If the underlying mechanism of generating certain behaviour changes while the final behaviour i.e the output remaining the same that would mean compatibility. It was acknowledged that in this case it is possible to break a feature already implementated which is considered to be fair as the working group's aims lean more towards schema authors and library users as opposed to implementors. As such an approach will allow authors to make more deterministic decisions.