Skip to content

Latest commit

 

History

History
95 lines (51 loc) · 5.72 KB

stages.md

File metadata and controls

95 lines (51 loc) · 5.72 KB
Raw

Maintenance and Incubation

Status

This is a proposal intended to facilitate maintenance of W3C Recommendations at W3C.

Problem Statement

The W3C Technical Reports page contain a long list of W3C Recommendations that are not maintained properly, due to lack of editors, participants, or Working Groups.

Classes of Changes

W3C Process contains the following classes of changes:

  1. No changes to text content
  2. Corrections that do not affect conformance
  3. Corrections that do not add new features
  4. New features

We will refer to these classes in the different types of modifications below.

7 Types of modifications

We identify here 7 different types of modifications applicable to a W3C specification and the existing and recommended path to address them.

All types of modifications, except for in-place modifications, will result in a new dated version of the W3C Recommendation.

0. In-place modification of W3C Technical Reports

There is a policy regarding the in-place modification of W3C Recommendations. It allows the following types of modifications:

  1. Fixes to broken markup (e.g., invalid markup) (category 1)
  2. Fixed to broken links (i.e., URIs)
  3. Fixes to broken style sheets
  4. Some visible status updates, such as indicating newer versions
  5. An individual's name upon request to a W3C Ombudsperson

Except for those changes required by this policy in section four, no in-place changes to the text of a document, besides some visible status updates, are permitted, however minor.

All those types of modifications are classified under the Class of Change 1 and 2, per W3C Process.

Since the modifications are in-place, this will not result in a new dated version of a W3C Recommendation.

1. Editorial modifications

Those modifications are classified under the Class of Change 1 and 2, per W3C Process and cannot be done as an in-place modification.

Editorial changes to a Recommendation require no technical review of the proposed changes and do not need to be part of an errata page initially. This will result in an Edited Recommendation, at the request of a W3C Working Group or done directly by W3C.

2. Maintenance of an errata page for the W3C Recommendation

Each W3C Recommendation contains a link to an errata page. This page is best maintained by the corresponding Working Group. If no such Working Group exists, the W3C is responsible for maintaining the errata page and may need assistance in doing so, such as requesting the help of a Community Group.

All those types of errata are classified under the Class of Change 1, 2, and 3, per W3C Process.

This will not result in an Edited Recommendation.

Note: this diverges from W3C Process, where only Working Groups are allowed to decide how to document errata.

3. Revising a Recommendation using an errata list

A list of errata becomes part of a W3C Recommendation by the process for revising a Recommendation. To make corrections to a W3C Recommendation, a Working Group may request publication of a Candidate Recommendation. If no such Working Group exists, the W3C is responsible for requesting the publication of a Candidate Recommendation. If this is done at the request of W3C instead of a Working Group, the status should indicate that the substantive changes are NOT covered by the W3C Patent Policy. This is an acceptable trade-off between having a broken Recommendation with full patent policy coverage and a well-maintained Recommendation without RF commitments. However, the disclosure requirement still applies.

All those types of errata are classified under the Class of Change 1, 2, and 3, per W3C Process.

This will result in an Edited Recommendation, at the request of a W3C Working Group or done directly by W3C.

Note: this diverges from W3C Process, where only Working Groups are allowed to request substantive corrections to a W3C Recommendation.

4. New features that were previously classified "at risk"

Working Groups may identify features in a document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation, per W3C Process.

Such feature should stay within the scope of the Working Group and may be reincorporated in a future version of the W3C Recommendation.

These features are classified under the Class of Change 4, per W3C Process.

This will result in a new Recommendation, at the request of a W3C Working Group.

5. New features under discussion but not included

Working Groups may identify new features while working on a document but not have enough time to include them as part of the specification.

Such discussion/feature should stay within the scope of the Working Group and may be incorporated in a future version of the W3C Recommendation.

These features are classified under the Class of Change 4, per W3C Process.

This will result in a new Recommendation, at the request of a W3C Working Group.

@@need example

  1. Brand new feature

Those features were not listed or discussed sufficiently while working on the specification. As such, those should be incubated in a Community Group first.