Clarify required sections of the project proposal template

project-management.md

@@ -24,12 +24,14 @@ At minimum, projects require the following resources to be successful:
   These two sponsors should be from different companies.
 * A group of designers and subject matter experts, dedicating a significant amount of their work time to the project. These participants are needed to design the spec, write a set of OTEPs, and create multiple prototypes. This group needs to meet with each other (and with their sponsors) on a regular basis to develop a successful set of proposals.
 
-To propose a project, a**project document** must be created using the [project proposal template](project-template.md) as a guide. This document will be used as the initial proposal for the project.
+To propose a project, a **project document** must be created using the [project proposal template](project-template.md) as a guide. This document will be used as the initial proposal for the project. With the exception of sections labeled as "Optional" or "Post-Approval", all sections of the template must be filled out.
 
 A project proposal can then be submitted by placing the project document in the [projects](projects/) folder and making a pull request against the community repo.
 
 As the project progresses, the project document should be kept up to date, and the community [README](README.md) should be updated to include any new project meeting information (see [contributing guide](https://github.com/open-telemetry/community/blob/main/CONTRIBUTING.md#updating-sig-information-on-the-readmemd)).
 
+The project template may be updated and new or existing sections may become required for new projects. Existing projects are not required to update their project documents to the latest template.
+
 Project leads are encouraged to define timelines for any work which will require public review, and to provide updates to the community in the form of [GitHub Project updates](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/sharing-project-updates). We have found that having scoped deliverables leads to an increased cadence in project work, and helps resolve debate. Timelines also help with getting a more coherent public review, as they allow the review community to plan on making themselves available. If timelines prove to be unrealistic, they can be always be updated.
 
 ## Project Lifecycle
@@ -46,4 +48,4 @@ The project lifecycle is as follows:
   * **_On Track_**: The project is making progress, and leads consider the timelines currently defined in the project document achievable with the current resources. Updates may contain information about recent achievements on the project.
   * **_At Risk_**: The project is at risk of not meeting its currently defined timelines. Leads and their GC liaison should discuss actions to bring the project back on track, which may include extending previously agreed timelines or re-scoping deliverables.
   * **_Off Track_**: The project does not have the necessary resources to continue to meet the desired deliverables in a timeline manner, or participation is too low to continue. Leads and their GC liaison should address the level of interest and commitment from the community to re-scope deliverables and timelines, and consider closing the project if not satisfactory, removing the project document from the list of active projects and cancelling meetings and other logistics (e.g. GitHub teams).
-  * **_Completed_**: The project is complete. The project document is moved to the [completed projects](projects/completed-projects/) folder, meetings and other logistics are cancelled, and the corresponding GitHub project is closed.
+  * **_Completed_**: The project is complete. The project document is moved to the [completed projects](projects/completed-projects/) folder, meetings and other logistics are cancelled, and the corresponding GitHub project is closed.

project-template.md

@@ -22,7 +22,7 @@ In general, OTEPs are not accepted unless they come with working prototypes avai
 
 Who is currently planning to work on the project? If a project requires specialized domain expertise, please list it here. If a project is missing a critical mass of people in order to begin work, please clarify.
 
-### Industry outreach
+### Industry outreach (Optional)
 
 Who (people, companies) in the industry should be aware of this effort? Was there an attempt to get them onboard? What did they say?
 
@@ -39,11 +39,11 @@ Projects cannot be started until the following participants have been identified
 
 What is the expected timeline the project will aim to adhere to, and what resources and deliverables will be needed for each portion of the timeline? If the project has not been started, please describe this timeline in relative terms (one month in, two weeks later, etc). If a project has started, please include actual dates.
 
-## Labels
+## Labels (Optional)
 
 Issues should be properly labeled to indicate what parts of the specification it is focused on. List here the labels applicable to this project, and consider adding them to corresponding GitHub Project automation to include them automatically into the project backlog.
 
-## GitHub Project
+## GitHub Project (Post-Approval)
 
 Once approved, a project should be managed using a GitHub project board (see [open projects](https://github.com/open-telemetry/community/projects?query=is%3Aopen)). This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones.
 
@@ -59,7 +59,7 @@ See [project management](project-management.md#project-lifecycle) for more infor
 
 Once created, please add a link to the project board here.
 
-## SIG Meetings and Other Info
+## SIG Meetings and Other Info (Post-Approval)
 
 Once a project is started, its corresponding SIG should meet regularly for discussion. These meeting times should be posted on the [OpenTelemetry public calendar](https://github.com/open-telemetry/community#calendar) and automatically recorded.