Skip to content

Add PROCESS.md documenting the new SDLC #1348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

Add PROCESS.md documenting the new SDLC #1348

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
12a8a9a
Add PROCESS.md documenting the new SDLC
jdesrosiers Nov 14, 2022
5501224
PROCESS: Clarifications and fixes based on feedback
jdesrosiers Nov 17, 2022
313b12b
PROCESS: Updates addressing Ben's review comments
jdesrosiers Nov 28, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
PROCESS: Updates addressing Ben's review comments
  • Loading branch information
@jdesrosiers
jdesrosiers committed Nov 28, 2022
commit 313b12b13f532cfcaf24a6aeb5f9a05c3e114ce8
27 changes: 17 additions & 10 deletions PROCESS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,10 @@ This process doesn't apply to third-party dialects, vocabularies, or other
extensions. However, third-parties are welcome to use this as a basis for the
process they use for their specifications.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119.

## Canonical URLs
There MUST be a stable canonical URL for referencing any specification that
follows this process. If the spec is made available from any other URLs, they
Expand All @@ -32,17 +36,17 @@ deprecated. Flags are used to show the status a feature is in. If it has a year
flag (such as `2024`) that's the year the feature reached stability. The other
flags indicate a feature that is not yet stable or is deprecated.

If a feature doesn't have a flag, it's considered stable. A feature can only be
unflagged if it was stable in the initial stable release in 2023. Any functional
change to the spec after the initial stable release MUST have a flag indicating
it's status.
If a feature doesn't have a flag, that means it was part of the original stable
release and MUST be considered stable. Any functional change to the spec after
the initial stable release MUST have a flag indicating it's status.

### Champions
Any feature that is evolving SHOULD have a champion. The champion is responsible
for shepherding the feature through the process to into stable status. The
champion doesn't need to do all the work, they're just responsible for making
sure the work gets done. The champion role MAY be shared by more than one
person. An evolving feature without a champion SHOULD be removed from the spec.
person or transferred to someone else if necessary. An evolving feature without
a champion SHOULD be removed from the spec.

### Proposals
New features start out as proposals. Proposals are informal GitHub Issues or
Expand Down Expand Up @@ -100,10 +104,12 @@ feature should stay in `STAGE-1` for about one year, but may stay longer if we
don't see it used enough in the wild.

**Promotion to STAGE-2 Checklist:**
[] There is general consensus that the feature has been proven to be a good
addition to JSON Schema and is unlikely to change.
[] We see the feature being used successfully in the wild and not generating a
lot of community support issues that could indicate a problem.
[] There is general consensus among the active specification contributors that
the feature has been proven to be a good addition to JSON Schema and is
unlikely to change.
[] The active specification contributors see the feature being used successfully
in the wild and not generating a lot of community support issues that could
indicate a problem.

### STAGE-2
`STAGE-2` features are in the last stages of becoming stable. Changes are
Expand All @@ -126,7 +132,8 @@ year to allow implementations to catch up.
`STAGE-2` features can only be promoted to stable as part of a release.

**Promotion to Stable Checklist:**
[] The vast majority of actively maintained implementations support the feature
[] The active specification contributors determined that the vast majority of
actively maintained implementations support the feature.

### Stable
Any part of the specification that doesn't have stability flag or has a year
Expand Down