SMPTE   AG   06
Administrative Guideline

New Project Form Instructions

Approved - Approved: 2025-03-25

Copyright Β© 2025 , 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.


Table of contents πŸ”—

  1. Foreword
  2. 1 Scope
  3. 2 Conformance
  4. 3 Normative references
  5. 4 Terms and definitions
  6. 5 General Instructions
  7. 6 Instructions for Project Details
    1. 6.1 Title (Table 1)
    2. 6.2 Proponents (Table 2)
    3. 6.3 Details (Tables 3 and 4)
      1. 6.3.1 Notes for Table 3
      2. 6.3.2 Notes for Table 4
      3. 6.3.3 Notes for Table 5
  8. Additional elements
  9. Bibliography

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 Administrative Guideline provides instructions for completing a New Project Form , which is available at Element a , in Clause a .

NOTE 1 —⁠ New Project Forms , once approved, will be added to the collection of other approved AG forms posted to a location specified by the SMPTE Director of Standards Development.

NOTE 2 —⁠ No projects may be created without filling in a copy of a New Project Form . This document is intended to help collect information so that a Technology Committee Chair may start the New Project Process detailed in the SMPTE Standards Operations Manual

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 General Instructions πŸ”—

All new projects submitted as of 2025-06-01 shall utilize the HTML Workflow as defined by SMPTE AG-26 and other AGs, with the explicit exception of Registered Disclosure Document (RDD).

NOTE —⁠ Support for RDD Document types will come at a future date, TBD.

6 Instructions for Project Details πŸ”—

6.1 Title (Table 1) πŸ”—

The title of your project should be short and descriptive title starting with the TC parent group. This appears on all project lists.

NOTE —⁠ As soon as you have chosen your title, replace the text β€œAG-06 New Project Form” with that title and save this file with a filename of the form:

<TC>[-<update>]-<type>[-<number>][-<part>][<element>]-<description>[(<note>)]

which is similar to the work-in-progress document naming convention ( SMPTE AG-02 ). Where:

<TC>
is the Group that authored the document e.g. 31FS
<type>
is the output document type ST | RP | EG | RDD | AN | ER | OV | AG
<number>
is the optional SMPTE HQ staff-assigned document number
<part>
is the optional part number
<element>
is the optional element letter
<update>
is the word Revision or Amendment or is absent
<description>
is a brief indicator of subject, such as an abbreviated name of the project, constructed using only alpha characters, digits, space (β€œ β€œ) and "-"β€’
<note>
is an optional string that can be used to annotate the project, e.g. coordination . The <note> shall be constructed using only alpha characters, digits, β€œ-β€œ

EXAMPLE 1 —⁠ 21DC-ER-Perpetual Motion Picture Generator

EXAMPLE 2 —⁠ 31FS-RDD-97-MXF Custom Metadata Mapping For Space Craft

EXAMPLE 3 —⁠ 35PM-Revision-ST-2067-2-Core Constraints 2022 update(from-Github-issues)

EXAMPLE 4 —⁠ XX-ST-My New Project of Unknown TC

6.2 Proponents (Table 2) πŸ”—

The SMPTE Standards Operations Manual Β§6.3 requires one or more Proponents, who are SMPTE Standards Members agreeing to be actively involved in the Project . Proponents are individuals and not organizations. The first listed proponent will become the publicly visible main contact for the project. The proponent’s field is not publicly visible but can be seen by Standards Community members. Please extend the table as needed.

6.3 Details (Tables 3 and 4) πŸ”—

6.3.1 Notes for Table 3 πŸ”—

Description
A short description of the project’s purpose and objectives. This text is aimed at the public who will read it and thus should be able to understand the Project in general terms. There may be extra requirements for this field for the Public CD Process ( SMPTE AG-22 )
Problem to be solved
A short statement about the problem to be solved. Ideally phrased in terms of requirements such that when those requirements are met, the document is complete. There may be extra requirements for this field for the Public CD Process ( SMPTE AG-22 )
Project scope
A short description of the scope of work that will be done and optionally elements that are out of scope. A narrow scope often results in a faster, more controlled project lifecycle. An example would be β€œRevision of standard ST xxx to roll-up amendment ST-xxx-Amd-1 and to update the normative references” . This limited scope is intended to restrict the work to just the details in the scope without opening the document up for redesign.
Specific Tasks
A high-level list of tasks that need to be completed as the work progresses. Consider test materials, sample bitstreams, sample software, data schemas, validation criteria, problem decomposition, liaisons with other organizations etc.
Type of Output
Check one or more boxes where:
ST – Standard                    RP  – Recommended Practice             
EG – Engineering Guideline       Rev – Revision                     
ER – Engineering Report          RDD – Registered Disclosure Document
Existing Version of Doc
For revisions, HTML Pub indicates there is an HTML published base doc as defined by SMPTE AG-26 . This is to ensure there is a proper redline that will be generated as part of the revision process. PDF/Word indicates extra time will need to be allocated to the generation of an HTML base doc, as none such exists.
Link to PDF/Word
If the above is marked PDF/Word , an SKN link shall be provided to the source PDF/Word (and all related documents elements; zip as needed), so that the working group can ensure the generation of HTML base for revision is as close to possible to the source document.
HTML Training
As all documents must be published in HTML as defined by SMPTE AG-26 as of 2025-06-01, indicate if there will need to be time allocated to training on this workflow.
Public CD
Please indicate if you intend to use the SMPTE AG-22 process. This decision can be changed at any time.
Dates

Estimation of the start and end dates of the project. Consult with TC Chair or SVP or Engineering Director for help.

If the project is a Revision and the Existing Version of Doc is marked PDF/Word , extra time shall be allocated to creation of an HTML base doc.

If HTML Training is checked Yes extra time shall be allocated for said training.

Known References
Complete this section if there are known documents or bodies of work critical to the project e.g. SMPTE mapping of an ITU or ISO/IEC standard.
External Liaisons
Known entities to be informed that the project has started. The Group should draft the liaison letter for the SVP and submit via the TC chairs.
Additional Liaisons
Additional Liaisons not in the list above.
TC Liaisons
Check the TCs with which documents should be shared or communications maintained.

6.3.2 Notes for Table 4 πŸ”—

Project Group Name and Existing Group question
The submitter may make a request here for a new or existing Project Group to support the Project. It may be modified if the SVP decides that the work should go elsewhere. If the Group already exists, enter its name exactly as shown in Teams. If a new Group is required, enter the proposed name and fill out the fields below for the new group to be set up. Individual – for projects with only a single person doing the work and therefore needing no Teams resources.
Project Type
Check one of these boxes where:
WG – Working Group typically for larger projects with several subgroups doing drafting
DG – Drafting Group for drafting an individual document
SG – Study Group to create an Engineering Report (internal to SMPTE or for publication)
TF – Task Force for study groups involving multiple TCs or active participation by 
     external organizations
Parent TC
The TC this project reports to. The applicant can make a request or leave blank; final assignment made by SVP.
Editor
Member of the Standards Community who will edit the document.
HTML Editor Expert
Member of the Standards Community who has experience with the HTML workflow as defined in SMPTE AG-26 , to assist the Editor and/or Group Chair as needed. This may be the same person as Editor and/or Group Chair .
Group Chair
Member of the Standards Community who will Chair Group meetings.
Group Secretary [optional]
Member of the Standards Community to perform secretarial tasks.
GitHub UserName
Editor , HTML Editor Expert , and Group Chair have fields for GitHub UserName that are required. This is to map the Standards Community member to their GitHub user account, and ensure the user has the proper access and permissions on GitHub and assigned to the correct GH Team and Repos. It is highly advised the Group Secretary also have a GitHub Username , as there are GH processes they may have to manage.

6.3.3 Notes for Table 5 πŸ”—

Approval date
The end of the ST and TC approval period.
Revisions notes and dates
Occasionally, during the lifetime of a project, the Group decides that project details such as the Scope need to be changed. The actual change should be applied in Table 3 but a brief note and date of TC approval should be added to Table 5.

Additional elements πŸ”—

The following are the non-prose elements of this document:

  1. a . SMPTE AG-06, New Project Form (normative). file: < AG-06a-New-Project-Form-2025-02-27.docx >.

Bibliography πŸ”—