SMPTE AG 33
Administrative Guideline

Document Process and Workflow

Draft - Fri May 01 2026 00:46:07 GMT+0000 (Coordinated Universal Time)

Copyright © 2026, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.

Warning: This document is an unpublished work under development and shall not be referred to as a SMPTE Standard, Recommended Practice, or Engineering Guideline. It is distributed for review and comment; distribution does not constitute publication. Recipients of this document are strongly encouraged to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

Table of contents🔗

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 Mapping meta tags to Document Status
  7. 6 GitHub PR (Pull Request) Guidelines
  8. 7 Document Workflow
    1. 7.1 General
    2. 7.2 Roles
    3. 7.3 WD-draft — Initial draft / DG drafting
    4. 7.4 WD-pub — Pre-FCD TC review
    5. 7.5 CD-draft — CD comment resolution
    6. 7.6 CD-pub — Committee Draft (private)
    7. 7.7 CD-pub-public — PCD period (public)
    8. 7.8 FCD-ballot — FCD ballot period
    9. 7.9 FCD-draft — FCD ballot comment resolution
    10. 7.10 FCD-pub — Pre-DP review
    11. 7.11 DP-ballot — DP ballot period
    12. 7.12 DP-pub — Draft Publication
    13. 7.13 ST-audit — ST audit period
    14. 7.14 PUB-draft — Awaiting publication
    15. 7.15 PUB-pub — Published

Foreword🔗

The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.

For more information, please visit www.smpte.org.

This Standards Administrative Guideline forms an adjunct to the use and interpretation of the SMPTE Standards Operations Manual. In the event of a conflict, the Operations Manual shall prevail.

1 Scope🔗

This document describes the process and workflow for the development and publication of SMPTE Engineering Documents using the GitHub-based authoring tooling defined in SMPTE AG 26.

2 Conformance🔗

The following keywords have a specific meaning in the context of this document:

3 Normative references🔗

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

4 Terms and definitions🔗

No terms and definitions are listed in this document.

5 Mapping meta tags to Document Status🔗

Table 1 maps the required content values of pubState, pubStage, and pubConfidential as defined in SMPTE AG 26 during the various stages of document development. These values represent the naming convention(s) as defined in SMPTE AG 02 and flowcharts as defined in SMPTE AG 07

Table 1 — Mapping content values for meta tags to Document Status🔗
Document Status pubStage value pubState value pubConfidential value See
Initial draft or revision (Working Draft) in:
Draft Group (DG)
Study Group (SG)
Working Group (WG)		 WD draft yes 7.3
>> Document moves to TC >>
Pre-FCD (Final Committee Draft) review WD pub yes 7.4
>> If pre-FCD comments received, back to DG/SG/WG >>
Pre-FCD comment resolution ongoing CD draft yes 7.5
Pre-FCD comment resolution complete CD pub yes 7.6
>> Document moves to TC >>
PCD (Public Committee Draft) period CD pub no 7.7
PCD comment resolution ongoing (moves back to DG/SG/WG) CD draft yes 7.5
PCD comment resolution complete >> Back to Pre-FCD (Final Committee Draft) review >>
(OR)
Ready for FCD ballot CD pub yes 7.6
FCD ballot period CD pub yes 7.8
>> If FCD ballot comments received >>
FCD ballot comment resolution ongoing FCD draft yes 7.9
FCD ballot comment resolution complete FCD pub yes 7.10
Pre-DP (Draft Publication) review FCD pub yes 7.10
DP ballot period FCD pub yes 7.11
(ELSE)
FCD ballot passes, no comments DP pub yes 7.12
DP ballot passes DP pub yes 7.12
Ready for ST (Standards Committee) Audit DP pub yes 7.12
ST Audit period DP pub yes 7.13
ST Audit complete PUB draft yes 7.14
Waiting for publication PUB draft yes 7.14
Published PUB pub no 7.15

See Clause 7 for the workflow utilizing these statuses.

6 GitHub PR (Pull Request) Guidelines🔗

Changes to a document shall not be made directly on the main branch. All changes shall be made on a separate branch and merged to main via a Pull Request, so that the tooling can produce the required redlines (see SMPTE AG 26).

Each PR shall have at least one approver who is not the PR author. Approval requirements that vary by document stage are specified in Clause 7.

7 Document Workflow🔗

7.1 General🔗

At any moment, a document is in one of the statuses listed in Table 1. The document's pubState, pubStage, and (during the PCD period) pubConfidential metadata values determine which one, as defined in SMPTE AG 26.

A pub status (pubState=pub) lives on main, marked by an auto-drafted release. A draft status (pubState=draft) lives on a feature branch with an open Pull Request, which is the work container for that status — the PR accumulates commits while work is ongoing, and the tooling generates redlines on each PR build per SMPTE AG 26. The document advances by merging that PR to main; merges that result in pubState=pub trigger the tooling to auto-draft a release per SMPTE AG 26.

Each status is described below in a card with the same fields: Description, Metadata, Branch, Latest release, Redline, and Notification. After the fields, each card lists numbered procedures for entering and leaving the status, following Clause 6. Each procedure step that requires a specific role is tagged with the role identifier defined in 7.2; steps without a role tag (such as merging the PR or publishing the auto-drafted release) may be performed by any party with appropriate permissions.

NOTE —⁠ Editors and Chairs should be aware of the general guidelines provided in SMPTE AG 31.

7.2 Roles🔗

Roles are as defined by SMPTE Standards Operations Manual. The identifiers below are used in this clause to tag procedure steps with the responsible role.

Document editor
The person designated by the project to edit the document.
DG chair
The chair of the Drafting Group, Study Group, or Working Group developing the document.
TC chair
The chair (or one of the chairs) of the parent Technology Committee.
GitHub admin
The person responsible for repository administration per SMPTE AG 31.
SMPTE HO
SMPTE Headquarters Office, including the Director of Engineering.

7.3 WD-draft — Initial draft / DG drafting🔗

Description
Drafting work in DG / SG / WG. Both initial drafts and revisions begin here.
Metadata
pubState=draft, pubStage=WD, pubConfidential=yes
Branch
YYYY-initial-draft (new document) or YYYY-revision (revising), branched from main
Latest release
None for an initial draft. For a revision, the prior YYYYMMDD-pub release of the previous edition.
Redline
pub-rl.html versus the prior published edition (revisions only)
Notification
None — internal DG iteration.

Entering this status:

For an initial draft:

  1. GitHub admin: Set up the document repository per SMPTE AG 26.
  2. Document editor: Branch YYYY-initial-draft from main.
  3. Document editor: On the new branch, set pubState=draft, pubStage=WD, and pubConfidential=yes per SMPTE AG 26.
  4. Document editor: Add the initial draft content.
  5. Document editor: Open a Pull Request from the branch to main. The PR build generates redlines per SMPTE AG 26.
  6. The document is now in WD-draft. Drafting work continues as additional commits to this open PR.

For a revision:

  1. Document editor: Identify the prior published release tag YYYYMMDD-pub.
  2. Document editor: Branch YYYY-revision from main (which contains the prior published state).
  3. Document editor: On the new branch, set pubState=draft, pubStage=WD, and pubConfidential=yes per SMPTE AG 26.
  4. Document editor: Make the initial revision changes.
  5. Document editor: Open a Pull Request from the branch to main. The PR build generates redlines including pub-rl.html versus the prior published edition.
  6. The document is now in WD-draft. Revision work continues as additional commits to this open PR.

Leaving this status:

When the DG declares drafting complete:

  1. Document editor: On the open PR, set pubState=pub.
  2. Document editor: Set pubDateTime to the date drafting was completed (format: YYYY-MM-DD).
  3. DG chair: Reviews and approves the PR.
  4. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-wd release.
  5. Publish the auto-drafted release per SMPTE AG 26.
  6. DG chair: Notifies the TC chair the document is ready for Pre-FCD review.
  7. TC chair: Requests/starts Pre-FCD review from SMPTE HO.
  8. The document is now in 7.4.

7.4 WD-pub — Pre-FCD TC review🔗

Description
2-week TC review of the completed Working Draft.
Metadata
pubState=pub, pubStage=WD, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-wd
Redline
release-rl.html versus the prior dated release (when present)
Notification
The TC chair sends the release link to the TC for the 2-week pre-FCD review.

Leaving this status:

If pre-FCD comments are received:

  1. Document editor: Branch YYYYMMDD-cd1 from main.
  2. Document editor: On the new branch, set pubState=draft and pubStage=CD.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.5. Comment resolution work happens as additional commits to this open PR; the PR is merged when leaving CD-draft.

If no pre-FCD comments are received:

  1. Document editor: Branch YYYYMMDD-cd1 from main.
  2. Document editor: On the new branch, set pubState=pub and pubStage=CD.
  3. Document editor: Open a Pull Request from the new branch to main.
  4. DG chair: Reviews and approves the PR.
  5. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-cd1 release.
  6. Publish the auto-drafted release per SMPTE AG 26.
  7. The document is now in 7.6.

7.5 CD-draft — CD comment resolution🔗

Description
Comment resolution — either pre-FCD comments from the TC or PCD comments from the public period.
Metadata
pubState=draft, pubStage=CD, pubConfidential=yes
Branch
YYYYMMDD-cdn from main (n increments per iteration: cd1, cd2, …)
Latest release
The prior YYYYMMDD-wd or YYYYMMDD-cdn-1 release.
Redline
release-rl.html versus the prior CD or WD release
Notification
None.

Leaving this status:

When comment resolution is complete:

  1. Document editor: On the open comment-resolution PR, set pubState=pub.
  2. Document editor: Set pubDateTime to the date resolution was completed (format: YYYY-MM-DD).
  3. DG chair: Reviews and approves the PR.
  4. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-cdn release.
  5. Publish the auto-drafted release per SMPTE AG 26.
  6. The document is now in 7.6.

7.6 CD-pub — Committee Draft (private)🔗

Description
A CD release awaiting next steps. Covers Pre-FCD comment resolution complete and Ready for FCD ballot at the same metadata.
Metadata
pubState=pub, pubStage=CD, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-cdn
Redline
release-rl.html
Notification
None.

Leaving this status:

If the document is to undergo a PCD (Public Committee Draft) period:

  1. Document editor: Branch from main.
  2. Document editor: On the new branch, set pubConfidential=no.
  3. Document editor: Open a Pull Request from the new branch to main.
  4. DG chair: Reviews and approves the PR.
  5. If the merge will occur on the same calendar day as the prior YYYYMMDD-cdn release, include [force-release] in the merge commit message per SMPTE AG 26.
  6. Merge the PR to main. The tooling auto-drafts a release (with a -2, -3, … suffix when [force-release] was used).
  7. Publish the auto-drafted release per SMPTE AG 26.
  8. DG chair: Notifies the TC chair the document is ready for PCD.
  9. TC chair: Requests PCD publication from SMPTE HO.
  10. SMPTE HO: Publishes PCD.
  11. The document is now in 7.7.

If the document is to undergo a FCD (Final Committee Draft) ballot:

  1. DG chair: Notifies the TC chair the document is ready for FCD Ballot.
  2. TC chair: Requests/starts FCD ballot from SMPTE HO.
  3. The document is now in 7.8.

7.7 CD-pub-public — PCD period (public)🔗

Description
Public Committee Draft period. The CD release is made publicly available; pubConfidential reflects this.
Metadata
pubState=pub, pubStage=CD, pubConfidential=no
Branch
Status lives on main.
Latest release
The release auto-drafted on entry — typically the same YYYYMMDD-cdn tag as the originating 7.6 release, possibly with a numeric suffix if [force-release] was used (see SMPTE AG 26).
Redline
release-rl.html (unchanged from CD-pub)
Notification
SMPTE HO announces the PCD period to the public.

Leaving this status:

When the PCD period ends:

  1. Document editor: Branch YYYYMMDD-cdn+1 from main.
  2. Document editor: On the new branch, set pubState=draft, pubStage=CD, and pubConfidential=yes.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.5 — back to Pre-FCD (Final Committee Draft) review. Any PCD comments are addressed as additional commits to this open PR; the PR is merged when leaving CD-draft.

7.8 FCD-ballot — FCD ballot period🔗

Description
The TC conducts the FCD ballot. The outcome determines whether the document advances directly to Draft Publication or returns for FCD comment resolution.
Metadata
pubState=pub, pubStage=CD, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-cdn
Redline
release-rl.html
Notification
The TC chair sends the release link to the TC for the FCD ballot.

Leaving this status:

If the FCD ballot received comments:

  1. Document editor: Branch YYYYMMDD-fcd-cr from main.
  2. Document editor: On the new branch, set pubState=draft and pubStage=FCD.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.9. Comment resolution work happens as additional commits to this open PR; the PR is merged when leaving FCD-draft.

If the FCD ballot passed without comments:

  1. TC chair: Requests DP/ST Audit package from DG.
  2. Document editor: Branch YYYYMMDD-dp from main.
  3. Document editor: On the new branch, set pubStage=DP. (pubState remains pub.)
  4. Document editor: Open a Pull Request from the new branch to main.
  5. DG chair: Reviews and approves the PR.
  6. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-dp release.
  7. Publish the auto-drafted release per SMPTE AG 26.
  8. The document is now in 7.12.

7.9 FCD-draft — FCD ballot comment resolution🔗

Description
Resolving comments raised during the FCD ballot.
Metadata
pubState=draft, pubStage=FCD, pubConfidential=yes
Branch
YYYYMMDD-fcd-cr (or similarly named comment-resolution branch) from main
Latest release
The prior YYYYMMDD-cdn release (the FCD ballot zip).
Redline
release-rl.html versus the prior CD release
Notification
None.

Leaving this status:

When comment resolution is complete:

  1. Document editor: On the open comment-resolution PR, set pubState=pub.
  2. Document editor: Set pubDateTime to the date resolution was completed (format: YYYY-MM-DD).
  3. DG chair: Reviews and approves the PR.
  4. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-fcd release.
  5. Publish the auto-drafted release per SMPTE AG 26.
  6. DG chair: Notifies the TC chair the document is ready for Pre-DP review.
  7. TC chair: Requests/starts Pre-DP review from SMPTE HO.
  8. The document is now in 7.10.

7.10 FCD-pub — Pre-DP review🔗

Description
FCD comments resolved; the TC reviews the document before the DP ballot is called. Covers FCD comment resolution complete and Pre-DP review at the same metadata.
Metadata
pubState=pub, pubStage=FCD, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-fcd
Redline
release-rl.html versus the prior CD or FCD release
Notification
The TC chair sends the release link to the TC for Pre-DP review.

Leaving this status:

When the Pre-DP review is complete:

  1. DG chair: Notifies the TC chair the document is ready for DP Ballot.
  2. TC chair: Requests/starts DP Ballot from SMPTE HO.
  3. The document is now in 7.11.

7.11 DP-ballot — DP ballot period🔗

Description
The TC conducts the DP ballot to determine whether the document advances to Draft Publication.
Metadata
pubState=pub, pubStage=FCD, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-fcd
Redline
release-rl.html versus the prior CD or FCD release
Notification
The TC chair sends the release link to the TC for the DP ballot.

Leaving this status:

When the DP ballot passes:

  1. TC chair: Requests ST Audit package from DG.
  2. Document editor: Branch YYYYMMDD-dp from main.
  3. Document editor: On the new branch, set pubStage=DP. (pubState remains pub.)
  4. Document editor: Open a Pull Request from the new branch to main.
  5. DG chair: Reviews and approves the PR.
  6. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-dp release.
  7. Publish the auto-drafted release per SMPTE AG 26.
  8. The document is now in 7.12.

If the DP ballot does not pass:

  1. Document editor: Branch YYYYMMDD-cdn+1 from main.
  2. Document editor: On the new branch, set pubState=draft and pubStage=CD.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.5 — back to the DG as a CD. Resolution work happens as additional commits to this open PR; the PR is merged when leaving CD-draft.

7.12 DP-pub — Draft Publication🔗

Description
DP release awaiting ST audit. Covers FCD ballot passes (no comments), DP ballot passes, and Ready for ST audit at the same metadata.
Metadata
pubState=pub, pubStage=DP, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-dp
Redline
release-rl.html versus the prior FCD or CD release
Notification
The TC chair sends the release link to DoS for ST audit.

Leaving this status:

When the document is ready for ST audit:

  1. DG chair: Notifies the TC chair the document is ready for ST Audit.
  2. TC chair: Requests/starts ST Audit from SMPTE HO.
  3. The document is now in 7.13.

7.13 ST-audit — ST audit period🔗

Description
The Standards Committee (ST) conducts the audit to verify the document is ready for publication.
Metadata
pubState=pub, pubStage=DP, pubConfidential=yes
Branch
Status lives on main.
Latest release
YYYYMMDD-dp
Redline
release-rl.html versus the prior FCD or CD release
Notification
None — audit is in progress at DoS.

Leaving this status:

When the ST audit completes:

  1. Document editor: Branch YYYYMMDD-pub from main.
  2. Document editor: On the new branch, set pubStage=PUB and pubState=draft.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.14. Any final preparation happens as additional commits to this open PR; the PR is merged when leaving PUB-draft.

If the ST audit does not pass:

NOTE —⁠ An ST audit failure typically indicates a process issue rather than a content defect. No dedicated fall-back path exists at present; the procedure below routes the document back to CD-draft for resolution as a temporary measure.

  1. Document editor: Branch YYYYMMDD-cdn+1 from main.
  2. Document editor: On the new branch, set pubState=draft and pubStage=CD.
  3. Document editor: Open a Pull Request from the new branch to main. The PR is the work container for the next status; do not merge yet.
  4. The document is now in 7.5 — back to the DG as a CD. Resolution happens as additional commits to this open PR; the PR is merged when leaving CD-draft.

7.14 PUB-draft — Awaiting publication🔗

Description
ST audit is complete; the document is held awaiting final publication.
Metadata
pubState=draft, pubStage=PUB, pubConfidential=yes
Branch
The YYYYMMDD-pub branch used to enter this status persists; the leaving change is made on this same branch.
Latest release
The prior YYYYMMDD-dp release. No release is auto-drafted on entering this status.
Redline
None on entry; the next release will produce pub-rl.html versus the prior published edition.
Notification
None — internal hold.

Leaving this status:

When ready to publish:

  1. SMPTE HO: Creates an issue in SMPTE Document Library to request the publication package from @TC/DG chair.
  2. Document editor: On the open PR, set pubState=pub and pubConfidential=no.
  3. DG chair: Reviews and approves the PR.
  4. TC chair: Reviews and approves the PR.
  5. Merge the PR to main. The tooling auto-drafts a YYYYMMDD-pub release.
  6. Publish the auto-drafted release per SMPTE AG 26.
  7. TC chair: Sends release package to SMPTE HO, as a comment to the issue created.
  8. The document is now in 7.15.

7.15 PUB-pub — Published🔗

Description
The document is published. The final release artifact is delivered to SMPTE HO for inclusion in SMPTE Document Library. This is a terminal status for the current edition.
Metadata
pubState=pub, pubStage=PUB, pubConfidential=no
Branch
Status lives on main. Terminal — no further outgoing branch is created.
Latest release
YYYYMMDD-pub
Redline
pub-rl.html versus the prior published edition
Notification
The TC chair sends the release link to SMPTE HO for publication in SMPTE Document Library. Automation for this step is planned for a future date.

Leaving this status:

None — this is a terminal status. A subsequent revision begins a new lifecycle from 7.3, working from this YYYYMMDD-pub release as the baseline.