Improve library tracking issue template

[rust.git] / .github / ISSUE_TEMPLATE / library_tracking_issue.md

diff --git a/.github/ISSUE_TEMPLATE/library_tracking_issue.md b/.github/ISSUE_TEMPLATE/library_tracking_issue.md
index 3e42594c8280dc50b93fe31713b85194e4d71f1e..cbc4465fcfe38a6d76d809a440c7097179f8dd41 100644 (file)
--- a/.github/ISSUE_TEMPLATE/library_tracking_issue.md
+++ b/.github/ISSUE_TEMPLATE/library_tracking_issue.md
@@ -33,21 +33,41 @@ For most library features, it'd be useful to include a summarized version of the
 -->
 
 ```rust
-...
+// core::magic
+
+pub struct Magic;
+
+impl Magic {
+    pub fn magic(self);
+}
 ```
 
 ### Steps / History
 
 <!--
-In the simplest case, this is a PR implementing the feature followed by a PR
-that stabilises the feature. However it's not uncommon for the feature to be
-changed before stabilization. For larger features, the implementation could be
-split up in multiple steps.
+For larger features, more steps might be involved.
+If the feature is changed later, please add those PRs here as well.
 -->
 
-- [ ] Implementation: ...
+- [ ] Implementation: #...
+- [ ] Final commenting period (FCP)
 - [ ] Stabilization PR
 
+<!--
+Once the feature has gone through a few release cycles and there are no
+unresolved questions left, the feature might be ready for stabilization.
+
+If this feature didn't go through the RFC process, a final commenting period
+(FCP) is always needed before stabilization. This works as follows:
+
+A library team member can kick off the stabilization process, at which point
+the rfcbot will ask all the team members to verify they agree with
+stabilization. Once enough members agree and there are no concerns, the final
+commenting period begins: this issue will be marked as such and will be listed
+in the next This Week in Rust newsletter. If no blocking concerns are raised in
+that period of 10 days, a stabilzation PR can be opened by anyone.
+-->
+
 ### Unresolved Questions
 
 <!--