JSR358-96: Create errata process, separate from the MR process

[apastsya]

Jira issue originally created by user shannon:

As I describe here, there are two JCP processes (JSR, MR) that we use for two different kinds of changes (new spec version, errata). Unfortunately, the processes don't match the kinds of changes we make, which leads to confusion.

Having a lightweight process for creating a new version of a spec (the MR process) is important, but it would reduce confusion if there were a separate process for correcting errors in existing specifications (errata).

In the simplest case, errata might fix typographical and formatting errors in a specification document. They are also use to fix inconsistencies in a specification, improve the description of requirements, etc. There are some key differences between an errata and an MR or JSR:

** Errata do not* create a new version of a spec. If the spec was version "Wombat 1.1" before the errata, the spec is still version "Wombat 1.1" after the errata.

• Errata update a spec by introducing a new "rev level" of the specification document, e.g., updating "Wombat 1.1" to "Wombat 1.1 rev A". Both documents are specifications for the "Wombat 1.1" API.
• Errata apply to existing licensees of a spec, they do not create a new spec that can be licensed, or that existing licensees can choose to upgrade to. Thus, errata can not change the licensing terms for a spec.
• Errata do not introduce new requirements, although they may clarify existing requirements.
• Errata do not change API signatures except to correct inconsistencies between the specification and the reference implementation, or to correct incompatibilities with previous versions of the specification.
• Errata do not change functional requirements except to correct inconsistencies between the specification and the reference implementation, or to correct incompatibilities with previous versions of the specification.
• In general, errata will not require changes to the reference implementation or the TCK, except to correct inconsistencies or incompatibilities as described above.

A separate errata process with limitations of this sort will make it clear what sort of change is being proposed, and will distinguish these changes from the MR process, which becomes only a lightweight form of the JSR process used to introduce new versions of a spec.

[apastsya]

Comment created by ldemichiel:

Having myself (as a speclead) seen a fair amount of confusion on this issue, I would like to echo what Bill has stated. I think it would be very helpful for the JCP Process document to clearly distinguish between maintenance reviews that entail API changes and maintenance reviews that are strictly errata (i.e., not functional changes, but just clarifications or corrections to minor issues, such as typos.).

Distinguishing a separate "Errata Process" would facilitate this. It should also be considered whether this process should be more lightweight (e.g., just an exception process, rather than the current voting process).

[apastsya]

Comment created by heathervc:

Anish shared the errata process for OASIS and W3C.

https://www.oasis-open.org/policies-guidelines/tc-process#erratafrom
https://www.w3.org/2015/Process-20150901/#rec-modify

[heathervc]

Propose to add in section 3.6.1 - instead of 'free to consult', 'should consult with...if possible'
Propose to section 3.6.2 - errata review of 14 days with an EC item exception that could call for a 2 week ballot at the close of the errata review

[heathervc]

Propose to add in section 3.6.3 - At the close of the Maintenance Review the PMO shall initiate a Maintenance Review Ballot. An MR Ballot can also be called from an Item Exception raised by an EC Member during an Errata Review.

Perhaps see as reference, JCP 2.7 and prior: https://jcp.org/en/procedures/jcp2_7#4

Clarify that there is not an Expert Group in Maintenance - disbands at Final Release, so Spec Lead determines content of a Maintenance Review and Release. At the same time making it clear that the Spec Lead should consult with the members of the EG from the JSR.