1 |
Proposed change to DocStd: Add a section 1.6, "Errata and Evolution", with |
2 |
the content: |
3 |
|
4 |
As a recommendation is published in the IVOA document repository, a |
5 |
globally editable page[1] titled <standardname>-<currentversion>-Next is |
6 |
created. This page will have four sections: |
7 |
|
8 |
* Accepted Errata |
9 |
* Rejected Errata |
10 |
* Proposed Errata |
11 |
* Proposed Features |
12 |
|
13 |
All the Errata sections will consist of listings whose items are |
14 |
pointers to globally editable pages titled |
15 |
<standardname>-<currentversion>-Erratum-<runningnumber> |
16 |
where the text for the erratum will physically reside. |
17 |
|
18 |
The Proposed Features section may have a similar structure or just |
19 |
consist of actual description of the features depending on the content |
20 |
length and complexity. |
21 |
|
22 |
The Accepted Errata elements (i.e. the errata reviewed by TCG and Exec as |
23 |
described later in this section) must be linked from the standard's |
24 |
landing page as well as from the document text. |
25 |
|
26 |
The standard preamble on the "Status of this |
27 |
Document" for a REC must now contain text to the effect that "Discussion |
28 |
on the evolution of this standard, as well as accepted errata, can be |
29 |
found at <links to the Accepted-Errata-page(s)>." |
30 |
|
31 |
Rejected and Proposed Errata not yet reviewed, as well as Proposed |
32 |
Features, will continue living in the -Next page as recollection of |
33 |
present and past activity on the specification. |
34 |
|
35 |
One such Next-page is maintained per recommendation (i.e., standards |
36 |
version); as a new REC is passed, a new, empty -Next page is created. |
37 |
|
38 |
Both Accepted and Rejected Errata may only be edited by the responsible |
39 |
working group chairs on behalf of the TCG as discussed below, who also |
40 |
MUST remove edits by other parties. |
41 |
|
42 |
The other two sections are open for editing to anyone. |
43 |
|
44 |
On revision of standards, material and discussions from Proposed |
45 |
Features should be taken into account. No further constraints are put |
46 |
on usage of the Proposed Features section here. |
47 |
|
48 |
Errata, on the other hand, have a formal process. To start it, any |
49 |
interested party can create a proposal for an erratum which SHOULD |
50 |
contain text on each of |
51 |
|
52 |
* Proposed change of standards text |
53 |
* Rationale |
54 |
* Impact Assessment |
55 |
|
56 |
As already said, physically, the text resides on a globally editable |
57 |
page linked from the Proposed Errata section of the -Next page. The |
58 |
proposed erratum is then announced on the Working Group's mailing |
59 |
list, which should also be the main medium of discussing the erratum. |
60 |
Errata likely to affect other working groups should also be announced |
61 |
on the full VO community. |
62 |
|
63 |
Before each meeting of the TCG, the TCG chair collects a list of |
64 |
proposed errata for the WG chairs. It must be circulated to all TCG |
65 |
members at least two weeks before the meeting. The texts of the |
66 |
errata under consideration are, at that point, frozen until the TCG |
67 |
descision. |
68 |
|
69 |
At each TCG meeting, a vote is taken on each erratum circulated in |
70 |
this way. All WGs (represented by a consensus of chair and vice-chair |
71 |
if both are present) must vote one of accept, defer, or reject. An |
72 |
erratum is accepted if all WGs vote accept, it is rejected if an |
73 |
absolute majority rejects; in all other cases it remains a proposed |
74 |
erratum. The TCG may, unanimously, amend an Erratum an with |
75 |
redactional changes proposed in-session. |
76 |
|
77 |
Both accepted and rejected errata are frozen at that point, i.e., no |
78 |
further edits are allowed on their pages. Their links on the -Next |
79 |
pages are moved by the WG chair to the Accepted Erratum section. A |
80 |
rejected erratum is moved by the WG chair to the Rejected Errata |
81 |
section of the -Next page. Errata deferred are unfrozen and open to |
82 |
further discussion and/or refinement. |
83 |
|
84 |
A list of all errata accepted for a document together with links to |
85 |
them is also maintained on the document's landing page in the IVOA |
86 |
document repository while the version in question is the most recent |
87 |
one, as well as on the cover page of the actual standard text in the |
88 |
version the erratum is written for. |
89 |
|
90 |
For each meeting of the Executive Committee, the TCG chair prepares a |
91 |
list of the errata passed since the last meeting of the Executive |
92 |
Committee. The Executive Committee can withdraw an erratum with single |
93 |
majority. Such errata will be marked as rejected in the document |
94 |
repository, possibly with a reference to a superseding erratum. |
95 |
|
96 |
[1] As of this writing, the page will reside in IVOA's wiki, but the |
97 |
technical details are not subject of this norm. |
98 |
|
99 |
|
100 |
|
101 |
The rationale for requiring consensus is that if it's contentious, it's |
102 |
probably not an erratum. Keeping rejected errata will help clarify |
103 |
subtle points of standards. |