Adds process for changing the Ion Schema language #133
Conversation
|
|
||
| *This section is addressed to the Ion Schema ** **maintainers**.* *It is included here in order to be transparent about the approval process.* | ||
|
|
||
| ## Requesting an RFC |
There was a problem hiding this comment.
Should we consider a Service Level Objective (SLO), e.g. The "2 and 5 Promise" for interviewing?
There was a problem hiding this comment.
We could, but I don't think that it belongs here. To use a governmental analogy—this document is intended to be a bit of a "constitution" for the Ion Schema specification. Something like a SLO for response time seems more like a "department policy".
|
|
||
| The outcome of this process will be shared on the `ion-schema` GitHub issue, resulting in the PR being merged or closed as appropriate. | ||
|
|
||
| ## Creating an RFC for a new Ion Schema version |
There was a problem hiding this comment.
This section has a lot of good details on when to create a new schema version. I had a suggestion to add a consideration in this section, feel free to skip it if it doesn't make sense to add here. Should this also add a consideration of when to have major vs minor version based on current requests? For example, if the current feature request includes a breaking change then we might want to wait for a couple of more features to be added for a new major version release.
There was a problem hiding this comment.
No, I don't think we should delay a breaking change in order to batch them up (unless there is another breaking change that is currently in flight). We've demonstrated that it is possible to have ISL 1.0 and ISL 2.0 import types from each other and mostly share an internal model in the implementations. The different ISL versions are really just feature gates for different syntax.
|
|
||
| * Are we still in the midst of implementing the last Ion Schema version? | ||
| * How many accepted features are waiting to be released in a new version of the ISL spec? | ||
| * Has anyone specifically asked for a new version to be released? |
There was a problem hiding this comment.
Maybe there should also be some attempt to quantify the impact of the new change.
There was a problem hiding this comment.
While I think impact is a good idea, I think that "bandwidth to work on it" is probably the closest proxy we should use for an open source project. The people/corporations who are funding the project (with their time or money) have different opinions about what is impactful—or more precisely, what is impactful enough to take priority over other projects (internal or external) that also need funding.
I think "bandwidth to work on it" implies "impactful enough that someone is willing to invest time/effort into changing it" and is a reasonable enough proxy for subjective, relative impact. What do you think?
Co-authored-by: Tyler Gregg <[email protected]>
Issue #, if available:
Description of changes:
Adds a document describing the process for adding new features to the Ion Schema Language.
See the rendered version at https://popematt.github.io/ion-schema/docs/process-for-changing-ion-schema.html
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.