Goal Issue Template (#2360)

Author: cart

content/learn/contribute/project-information/project-goals.md

@@ -18,13 +18,14 @@ Goals are tracked on the [Project Goals Board](https://github.com/orgs/bevyengin
 - Goals are expressed as [Issues with the `C-Goal` label](https://github.com/bevyengine/bevy/issues?q=is%3Aissue%20label%3AC-Goal) in the main [Bevy GitHub Repo](https://github.com/bevyengine/bevy/).
 - Goals can be large, but they need a defined completion criteria.
 - Goals can have "sub-Goals", which are expressed as "sub-issues" on GitHub
-  - For something large like a "Bevy Editor" Goal, consider breaking it into smaller pieces (ex: Editor UI Widgets, Core Editor App Framework, Scene Editor, Editor Inspector, etc). The pieces should _still_ be Goal-like ... avoid dictating implementation details. Also avoid trying to plan out large "goal trees" in advance. "Expand" the tree lazily, as the need arises and you understand more.
+  - For something large like a "Bevy Editor" Goal, consider breaking it into smaller pieces (ex: Editor UI Widgets, Core Editor App Framework, Scene Editor, Editor Inspector, etc). The pieces should _still_ be Goal-like ... avoid dictating implementation details.
+  - Avoid trying to plan out large "sub-goal trees" in advance. "Expand" the tree lazily, as the need arises and you understand more. Generally only do this _after_ a **Goal** has been Postponed or Approved.
   - It is critical to define completion criteria for larger Goals with sub-Goals, to avoid Goals that live forever. A Goal is _not_ an **Area**.
 - Goals can organically change over time. If we learn something new and it makes sense to break up a Goal into multiple Goals, add sub-Goals, or reframe the Goal ... do it!
 - Goals inherently require _collaboration_ to bring them to completion. They are never the work of a single individual. At the very least, there is someone coming up with a design / implementation, and one or more **SME** verifying the design / implementation.
-- Goals have a short, functional name, as it would be communicated to the public. This is a market-able "feature name", like "PBR Renderer", "Relationships", etc. Avoid using things like "initial" or "MVP" in the name, as this is implied.
 - Goals are inherently `X-Needs-SME`, so they should be given that label.
 - Anything that needs a Goal, but doesn't currently have one should be labeled with `C-Needs-Goal`.
+- Goals are only created by **SMEs** and **Maintainers**. The intent behind this restriction is that Goals are a "public facing" / marketing thing, so phrasing and framing is important. Every new Goal gets added to the Proposed goal column on the public Project Goals board. Going through SMEs + Maintainers ensures redundancies are avoided, noise is kept to a minimum, consistency is enforced, templates are used, framing / public image / marketing is taken into account, etc. This is just as true for closed Goals, which exist to be a nice consolidated list of things the project definitely doesn't want to do.
 
 ## When does an Issue or PR need a Goal?
 
@@ -90,3 +91,30 @@ The SMEs staffing a Goal should be listed in the Goal's description.
 8. If the Goal is Inactive (Approved), and there is enough commitment and support from the community to form a **Working Group**, it moves into the Active (Approved) state.
 9. The **Project Lead** adjusts the priorities of the Goals (expressed via the [Project Goals Board](https://github.com/orgs/bevyengine/projects/23/views/1) order), based on the needs of the project.
 10. When a Goal is completed, the issue is closed out. A GitHub Project Workflow moves it into the Done status.
+
+## Goal Issue Template
+
+Only SMEs and Maintainers should create new Goals (see rationale in the "What is a Goal?" section above)! If that is you, copy this template when creating a new Goal. We put this template here, rather than adding it as a GitHub issue template, because we don't want normal users creating Goals.
+
+1. Name the Goal. This should be a short, functional name, as it would be communicated to the public. This is a market-able "feature name", like "PBR Renderer", "Relationships", etc. Avoid using things like "initial" or "MVP" in the name, as this is implied.
+2. Add the `C-Goal` and `X-Needs-SME` labels.
+3. Paste in the markdown template below.
+4. Fill in the template.
+
+```md
+## Goal Description
+
+In roughly one paragraph, describe from a high level _what_ this Goal is. Provide just enough to describe to the public and contributors _what_ the bounds of the Goal are. Leave the "why" and "how" to the future **Design Documents**. Avoid dictating implementation or design details whenever possible.
+
+## Goal Status
+
+This is a potential [Bevy Project Goal](https://bevy.org/learn/contribute/project-information/project-goals/). Its state on the [Project Goals Board](https://github.com/orgs/bevyengine/projects/23/views/1) determines if it is Proposed, Postponed, Blocked (Approved), Inactive (Approved), Active (Approved), Completed, or Declined.
+
+- **Staffing SMEs**: Not yet staffed
+- **Working Group Link**: Working Group not yet formed
+- **Design Documents**: Design documents not yet written
+```
+
+- If / when a Goal is approved and SMEs agree to "staff" the Goal, add them to the **Staffing SMEs** list.
+- If / when a Goal becomes "active" and a Working Group is formed, fill in the **Working Group Link** with the Working Group thread on the Bevy Discord.
+- If / when design documents are authored by the Working Group, link to them in the **Design Documents**.