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	volute@g-vo.org	2972	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	marco.merot@gmail.com	3013	created. This page will have four sections:
7	volute@g-vo.org	2972
8			* Accepted Errata
9			* Rejected Errata
10			* Proposed Errata
11			* Proposed Features
12
13	marco.merot@gmail.com	3013	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	volute@g-vo.org	2972	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	marco.merot@gmail.com	3013	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	volute@g-vo.org	2972
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