.github/ISSUE_TEMPLATE/library_tracking_issue.md

   1 ---
   2 name: Library Tracking Issue
   3 about: A tracking issue for an unstable library feature.
   4 title: Tracking Issue for XXX
   5 labels: C-tracking-issue, T-libs-api
   6 ---
   7 <!--
   8 Thank you for creating a tracking issue!
   9
  10 Tracking issues are for tracking a feature from implementation to stabilization.
  11
  12 Make sure to include the relevant RFC for the feature if it has one.
  13
  14 If the new feature is small, it may be fine to skip the RFC process. In that
  15 case, you can use use `issue = "none"` in your initial implementation PR. The
  16 reviewer will ask you to open a tracking issue if they agree your feature can be
  17 added without an RFC.
  18 -->
  19
  20 Feature gate: `#![feature(...)]`
  21
  22 This is a tracking issue for ...
  23
  24 <!--
  25 Include a short description of the feature.
  26 -->
  27
  28 ### Public API
  29
  30 <!--
  31 For most library features, it'd be useful to include a summarized version of the public API.
  32 (E.g. just the public function signatures without their doc comments or implementation.)
  33 -->
  34
  35 ```rust
  36 // core::magic
  37
  38 pub struct Magic;
  39
  40 impl Magic {
  41     pub fn magic(self);
  42 }
  43 ```
  44
  45 ### Steps / History
  46
  47 <!--
  48 For larger features, more steps might be involved.
  49 If the feature is changed later, please add those PRs here as well.
  50 -->
  51
  52 - [ ] Implementation: #...
  53 - [ ] Final comment period (FCP)[^1]
  54 - [ ] Stabilization PR
  55
  56 <!--
  57 Once the feature has gone through a few release cycles and there are no
  58 unresolved questions left, the feature might be ready for stabilization.
  59
  60 If this feature didn't go through the RFC process, a final comment period
  61 (FCP) is always needed before stabilization. This works as follows:
  62
  63 A library API team member can kick off the stabilization process, at which point
  64 the rfcbot will ask all the team members to verify they agree with
  65 stabilization. Once enough members agree and there are no concerns, the final
  66 comment period begins: this issue will be marked as such and will be listed
  67 in the next This Week in Rust newsletter. If no blocking concerns are raised in
  68 that period of 10 days, a stabilzation PR can be opened by anyone.
  69 -->
  70
  71 ### Unresolved Questions
  72
  73 <!--
  74 Include any open questions that need to be answered before the feature can be
  75 stabilised. If multiple (unrelated) big questions come up, it can be a good idea
  76 to open a separate issue for each, to make it easier to keep track of the
  77 discussions.
  78
  79 It's useful to link any relevant discussions and conclusions (whether on GitHub,
  80 Zulip, or the internals forum) here.
  81 -->
  82
  83 - None yet.
  84
  85 [^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html