json-schema-spec
json-schema-spec copied to clipboard
json-schema-org
Core: Add section to define expectations for proposals
We need a section in Core that defines what we expect from tooling around support for feature proposals.
Basically, proposals are OPTIONAL but RECOMMENDED.
Tooling must also specify in their docs which proposals they support and the latest date or some kind of proposal version that they support.
@abhayymishraa if you have ideas, simply state them. You don't need permission to participate in discussion. However, as you can see under the "Projects" header to the right, this is still in discussion; it's not ready to be worked on.
Secondly, spec changes require in-depth knowledge of JSON Schema and experience with specification authorship. That generally means TSC members and other experts who have been working with JSON Schema for a long time and have proven their understanding of the spec and knowledge of its uses. While anyone may contribute their ideas to discussions, contribution to the documents is not generally open.
@json-schema-org/spec-team I'm having a hard time deciding whether this should go into the spec. On one hand, it is defining expectations. On the other, an implementation isn't necessarily required to support proposals.
Maybe this should go in a supporting project document similar to PROCESS.md.
I could use some other opinions.
This doesn't sound like something that would go into the specification itself. I can't think of other specifications that talk much about implementations at all, let alone future-looking changes that aren't reflected in the spec yet.
A separate document sounds good -- it can talk about how new feature proposals progress through various statuses and eventually make it into the spec, and our expectations/desires for implementations with respect to specification compliance (including the formal test suite, bowtie, etc) as well as new proposed features. Thinking of recent discussions about "reference implementations", this might be a good place to mention what we expect from a fully-compliant implementation.
I agree with Karen. To me, this is belongs in documentation about our spec development process. However, we should provide a reference to the process in the spec, which I don't remember if we've done yet.
Okay. So the action here is to include a pointer to the spec process in Core.
I imagine at some point there will be a folder with the proposals in, and in that folder will be a README.md, which will include the requirements details.
