In accordance with , all dates shall be represented in the form YYYY-MM-DD as numeric digits (e.g. 2009-04-23 to indicate April 23, 2009).
+ All approval dates referenced in this Administrative Guideline shall be recorded in this form, from the systems of record identified in . +
+ + +
+ The lifecycle of a SMPTE Engineering Document involves several approval-related dates. identifies each, the event it records, and the authoritative source. All such dates shall be recorded in the YYYY-MM-DD form defined in .
+
| Stage | Date recorded | Authoritative source |
|---|---|---|
| DG approval for TC review | DG approval date | DG record (tracked loosely) |
| Pre-Ballot Review period end | Review period actual end date | Ballot app - end date |
| Pre-Ballot comment resolution | Resolution completion date | GitHub PR - merge date |
| FCD, DP, or ST Audit ballot end | Ballot actual close date | Ballot app - end date |
| Ballot comment resolution | Resolution completion date | GitHub PR - merge date |
| Disposition vote (to set aside comment(s)) | Vote date | Roster / voting app |
| Late comment resolution (any period; editorial issues, etc.) | Resolution completion date | GitHub PR - merge date; comments tracked in GitHub issue tracker |
+ Ballots are not extended except under extreme conditions; the actual close date prevails over any scheduled close. +
++ The approval date used to identify the document version (see ) and to populate the document metadata is the actual close date of the ST Audit ballot. +
- Document numbers shall be unique and uniform across all Engineering Document types. Versions of documents shall be identified by the year and month of their approval date, appended with a separating colon (e.g., for document #1020: 1020:2009-04 indicating approval in April, 2009). shows an example of the document numbering structure. The approval date of a document indicates when it was last approved by its consensus body, e.g., Technical Committee.
+ Document numbers shall be unique and uniform across all Engineering Document types. Versions of documents shall be identified by the year and month of their approval date, appended with a separating colon (e.g., for document #1020: 1020:2009-04 indicating approval in April, 2009). shows an example of the document numbering structure. The approval date is the date of the final consensus action that produced the document, typically the actual close date of the ST Audit ballot; other approval-related dates used during the development lifecycle are defined in .
The Director of Engineering shall assign document numbers (or root document numbers, in the case of multipart documents). Document numbers may be assigned at the request of the Technology Committee Chair(s) at any time after a Project is approved and shall be assigned before a Final Committee Draft ballot is issued.
- Older Engineering Documents may bear one-, two-, or three-digit document numbers or root document numbers. These numbers shall not be prepended with leading zeroes when formatted for printing, either in the document itself or in citations in other documents. Such document numbers shall be prepended with leading zeroes to fill them out to four digits, however, when used as part of an element’s filename; the purpose is to facilitate sorting into numerical order. + Older Engineering Documents may bear one-, two-, or three-digit document numbers or root document numbers. These numbers shall not be prepended with leading zeroes when formatted for printing, either in the document itself or in citations in other documents. Such document numbers shall be prepended with leading zeroes to fill them out to four digits, however, when used as part of an element's filename; the purpose is to facilitate sorting into numerical order.
- The Type of Engineering Document (Standard, Recommended Practice or Engineering Guideline) shall be denoted by prepending a Type Designator, followed by a single space, to the document’s root number. The Type Designator shall be as follows: + The Type of Engineering Document (Standard, Recommended Practice or Engineering Guideline) shall be denoted by prepending a Type Designator, followed by a single space, to the document's root number. The Type Designator shall be as follows:
- A multipart set of documents may include Parts of different types of Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines. Each Part’s number shall include the appropriate document type designation (e.g. RP 2046-2:2009-04).
+ A multipart set of documents may include Parts of different types of Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines. Each Part's number shall include the appropriate document type designation (e.g. RP 2046-2:2009-04).
- A multipart set of documents should be supplemented by an informative Part 0, informally described as an “Overview Document,” which shall describe the relationships among the Parts and may describe the relationships of the Parts to other Engineering Documents. Part 0 documents are not due process Engineering Documents; + A multipart set of documents should be supplemented by an informative Part 0, informally described as an "Overview Document," which shall describe the relationships among the Parts and may describe the relationships of the Parts to other Engineering Documents. Part 0 documents are not due process Engineering Documents;
Part 0 documents usually should be prepared by the authors of the related engineering documents in cooperation with SMPTE headquarters staff and the responsible Technology Committee and Project Group. Part 0 documents shall be maintained by the Director of Engineering in consultation with the Technology Committee Chair(s) and the author(s) of the Part 0 document. If new Parts are added to a multipart set, or if any of the Parts of the set are revised, Part 0 shall be revised at the same time. The Part 0 designation shall not be used for any Engineering Document. Part 0 documents shall not bear a Type designator (i.e. it is not an ST, RP or EG). @@ -350,22 +382,22 @@
-<group> “-“ <state> “-“ <type> “-“ <number> [ “-“ <part> ] [ <element> ] “-“
- <description> “-“ <date> [ “(“ <note> “)” ] “.” <extension>
+<group> "-" <state> "-" <type> "-" <number> [ "-" <part> ] [ <element> ] "-"
+ <description> "-" <date> [ "(" <note> ")" ] "." <extension>
Where:
<group><state><type><group><state><type><number><part><element><description><date><note><note> shall be constructed using only alpha characters, digits, “-“.<date><note><note> shall be constructed using only alpha characters, digits, "-".<extension>@@ -390,7 +422,7 @@
- File names for contributions that are not Engineering Documents shall be at the discretion of the individual or group making the contribution. The scheme in should be considered as a useful model. If these rules are used, the <state> should be “C.”
+ File names for contributions that are not Engineering Documents shall be at the discretion of the individual or group making the contribution. The scheme in should be considered as a useful model. If these rules are used, the <state> should be "C."
For a new project, the document number and even the project short name may not be known. In this event, individuals making the contributions should use their judgment when naming files. @@ -404,7 +436,7 @@
- Various document packages are needed during the development process. In all cases, a document being reviewed or voted upon shall be the current draft which is the “clean” version, generated in zip file within the GitHub release as described in . All the below described packages are auto-generated by this tooling and shall not be created by hand. + Various document packages are needed during the development process. In all cases, a document being reviewed or voted upon shall be the current draft which is the "clean" version, generated in zip file within the GitHub release as described in . All the below described packages are auto-generated by this tooling and shall not be created by hand.
In the event that any of the following is in conflict with the , the shall prevail. @@ -417,20 +449,20 @@
- For Revisions the process of converting an old document into the current template changes section numbering and alters the appearance of the original document, even though the content of the document has not changed. In this case, it is recommended that the conversion to the current template should be made before any other changes are made. The document editor should “accept all changes” to create a clean starting point (the “baseline draft”) from which to track the technical and/or editorial revisions to the document. + For Revisions the process of converting an old document into the current template changes section numbering and alters the appearance of the original document, even though the content of the document has not changed. In this case, it is recommended that the conversion to the current template should be made before any other changes are made. The document editor should "accept all changes" to create a clean starting point (the "baseline draft") from which to track the technical and/or editorial revisions to the document.
During Working Draft development (an informal process), a Project Group may provide intermediate draft documents and markups for review within the Project Group. Intermediate document packages may include an informal Comment Resolution Record or a Comment Resolution Document.
- The state of these draft documents shall be “WD.” Project Groups should follow the recommendations and styles given in this Administrative Guideline for file names. + The state of these draft documents shall be "WD." Project Groups should follow the recommendations and styles given in this Administrative Guideline for file names.
- The first step in the formal document process is the preparation of a Working Draft, which shall be marked as “WD.” This document a package is provided by the Project Group to the Technology Committee Chair(s). This review is optional; See for guidance. + The first step in the formal document process is the preparation of a Working Draft, which shall be marked as "WD." This document a package is provided by the Project Group to the Technology Committee Chair(s). This review is optional; See for guidance.
The document package shall contain a clean draft. In addition it may contain one of the following: @@ -446,16 +478,19 @@
+ See for the date recorded with this package. +
- Following Pre-Ballot Review, a Project Group should address all comments. See the comment resolution process in . When the Project Group agrees that the document is ready for ballot, it shall provide a Committee Draft ballot package marked as “CD” to the Technology Committee Chairs(s) that contains: + Following Pre-Ballot Review, a Project Group should address all comments. See the comment resolution process in . When the Project Group agrees that the document is ready for ballot, it shall provide a Committee Draft ballot package marked as "CD" to the Technology Committee Chairs(s) that contains:
A Comment Resolution Record is required when there are additional FCD Ballot(s). This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance.
- +When Comment Resolution has been successfully completed, a Pre-DP Review follows. Comment resolution may include one or more Disposition Votes. See for guidance.
+A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. In some situations the Project Group may wish to keep other records. See for guidance.
+After a successful DP vote the Draft Publication Vote Package documents shall not be edited by the Project Group participants or the Technology Committee Chair(s) with the exception of changing the document status. If new editorial issues are found, these should be documented and given to SMPTE HQ (see ).
+A Comment Resolution Record is required. This should be the electronic comment resolution records kept on the SMPTE SKN Balloting App. If the Project Group kept other records, these must be included. See for guidance.
+