OGF spec updates - planning for errata vs. editorial vs. respins
Below are the relevant 3 paragraphs from: http://www.ogf.org/Public_Comment_Docs/Documents/2007-10/draft-gwdc-gfsg-c1-... Our existing errata process divides into editorial things (which we just fix), minor tech issues, major tech issues which is consistent with the below. Note that the discussion suggests not a separate errata document, but that the errata must be added to the spec itself - and the notion that they are listed on the cover sheet means they are anticipating only a relatively small set of such errata compared what has happened since 2013 Sept. To me this suggests such errata are not suitable for anything one can anticipate as a "parked issue" for the future. Such things must be in a new revision of the standard. Editorial fixes applied within the first month after publication will generally not be publicly announced to the OGF community. Any other changes to a document, whether major or minor, will be announced using the same mechanism as for a newly published document (i.e., email to the OGF community, posting to the OGF Web site, etc.). Whenever a document is updated, even for minor editorial updates, the document header will be adjusted to reflect the date the document was updated. The date of the update should appear in the upper right side of the document's first page, beneath any prior date. For very minor updates, especially those within the first month after publication, no additional information needs to be added to the document. A publicly accessible archive of all old versions of the document is maintained, and accessible through the same means as current documents. For all other updates, minor and major technical fixes, an errata report must be added to the document itself. Recommended practice is to put an errata report labeled as “Document Change History” on the first page of the document, directly under the copyright statement and before the abstract. A brief report on what was changed is sufficient, along with the date. If a more discussion is desired, the Document Change History can refer to a later section where the update is discussed in detail. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>
Thanks Mike. As discussed, we should endeavour to keep errata on GFD.207 to a minimum, and defer everything non-essential to a future DFDL 1.1. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>, Date: 23/09/2014 14:44 Subject: [DFDL-WG] OGF spec updates - planning for errata vs. editorial vs. respins Sent by: dfdl-wg-bounces@ogf.org Below are the relevant 3 paragraphs from: http://www.ogf.org/Public_Comment_Docs/Documents/2007-10/draft-gwdc-gfsg-c1-... Our existing errata process divides into editorial things (which we just fix), minor tech issues, major tech issues which is consistent with the below. Note that the discussion suggests not a separate errata document, but that the errata must be added to the spec itself - and the notion that they are listed on the cover sheet means they are anticipating only a relatively small set of such errata compared what has happened since 2013 Sept. To me this suggests such errata are not suitable for anything one can anticipate as a "parked issue" for the future. Such things must be in a new revision of the standard. Editorial fixes applied within the first month after publication will generally not be publicly announced to the OGF community. Any other changes to a document, whether major or minor, will be announced using the same mechanism as for a newly published document (i.e., email to the OGF community, posting to the OGF Web site, etc.). Whenever a document is updated, even for minor editorial updates, the document header will be adjusted to reflect the date the document was updated. The date of the update should appear in the upper right side of the document's first page, beneath any prior date. For very minor updates, especially those within the first month after publication, no additional information needs to be added to the document. A publicly accessible archive of all old versions of the document is maintained, and accessible through the same means as current documents. For all other updates, minor and major technical fixes, an errata report must be added to the document itself. Recommended practice is to put an errata report labeled as “Document Change History” on the first page of the document, directly under the copyright statement and before the abstract. A brief report on what was changed is sufficient, along with the date. If a more discussion is desired, the Document Change History can refer to a later section where the update is discussed in detail. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
participants (2)
-
Mike Beckerle -
Steve Hanson