projects/docstd/errata-proposal.txt

Proposed change to DocStd: Add a section 1.6, "Errata and Evolution", with
the content:

  As a recommendation is published in the IVOA document repository, a
  globally editable page[1] titled <standardname>-<currentversion>-Next is
  created. This page will have four sections:

  * Accepted Errata
  * Rejected Errata
  * Proposed Errata
  * Proposed Features

        All the Errata sections will consist of listings whose items are
        pointers to globally editable pages titled
        <standardname>-<currentversion>-Erratum-<runningnumber>
        where the text for the erratum will physically reside.

        The Proposed Features section may have a similar structure or just
        consist of actual description of the features depending on the content
        length and complexity.

        The Accepted Errata elements (i.e. the errata reviewed by TCG and Exec as
        described later in this section) must be linked from the standard's
        landing page as well as from the document text.

        The standard preamble on the "Status of this
  Document" for a REC must now contain text to the effect that "Discussion
  on the evolution of this standard, as well as accepted errata, can be 
        found at <links to the Accepted-Errata-page(s)>."
  
        Rejected and Proposed Errata not yet reviewed, as well as Proposed
        Features, will continue living in the -Next page as recollection of
        present and past activity on the specification.

  One such Next-page is maintained per recommendation (i.e., standards
  version); as a new REC is passed, a new, empty -Next page is created.

  Both Accepted and Rejected Errata may only be edited by the responsible
  working group chairs on behalf of the TCG as discussed below, who also
  MUST remove edits by other parties.  

  The other two sections are open for editing to anyone.

  On revision of standards, material and discussions from Proposed
  Features should be taken into account.  No further constraints are put
  on usage of the Proposed Features section here.

  Errata, on the other hand, have a formal process.  To start it, any
  interested party can create a proposal for an erratum which SHOULD
  contain text on each of

  * Proposed change of standards text
  * Rationale
  * Impact Assessment

  As already said, physically, the text resides on a globally editable 
        page linked from the Proposed Errata section of the -Next page. The  
  proposed erratum is then  announced on the Working Group's mailing
        list, which should also be the main medium of discussing the erratum. 
        Errata likely to affect other working groups should also be announced 
        on the full VO community.

  Before each meeting of the TCG, the TCG chair collects a list of
  proposed errata for the WG chairs.  It must be circulated to all TCG
  members at least two weeks before the meeting.  The texts of the
  errata under consideration are, at that point, frozen until the TCG
  descision.

  At each TCG meeting, a vote is taken on each erratum circulated in
  this way.  All WGs (represented by a consensus of chair and vice-chair
  if both are present) must vote one of accept, defer, or reject.  An
  erratum is accepted if all WGs vote accept, it is rejected if an
  absolute majority rejects; in all other cases it remains a proposed
  erratum.  The TCG may, unanimously, amend an Erratum an with
  redactional changes proposed in-session.

  Both accepted and rejected errata are frozen at that point, i.e., no
  further edits are allowed on their pages.  Their links on the -Next
  pages are moved by the WG chair to the Accepted Erratum section.  A
  rejected erratum is moved by the WG chair to the Rejected Errata
  section of the -Next page.  Errata deferred are unfrozen and open to
  further discussion and/or refinement.

  A list of all errata accepted for a document together with links to
  them is also maintained on the document's landing page in the IVOA
  document repository while the version in question is the most recent
  one, as well as on the cover page of the actual standard text in the
  version the erratum is written for.

  For each meeting of the Executive Committee, the TCG chair prepares a
  list of the errata passed since the last meeting of the Executive
  Committee.  The Executive Committee can withdraw an erratum with single
  majority.  Such errata will be marked as rejected in the document
  repository, possibly with a reference to a superseding erratum.

  [1] As of this writing, the page will reside in IVOA's wiki, but the
  technical details are not subject of this norm.


The rationale for requiring consensus is that if it's contentious, it's
probably not an erratum.  Keeping rejected errata will help clarify
subtle points of standards.
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.
msdemlei@ari.uni-heidelberg.de	ViewVC Help
Powered by ViewVC 1.1.26