From 02142a936b95c7f25673b0388497593195384864 Mon Sep 17 00:00:00 2001 From: ltdk Date: Sat, 29 Aug 2026 20:09:37 -0400 Subject: [PATCH] Update ACP issue template --- .github/ISSUE_TEMPLATE/api-change-proposal.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.github/ISSUE_TEMPLATE/api-change-proposal.md b/.github/ISSUE_TEMPLATE/api-change-proposal.md index f804ef4..28b9f4e 100644 --- a/.github/ISSUE_TEMPLATE/api-change-proposal.md +++ b/.github/ISSUE_TEMPLATE/api-change-proposal.md @@ -38,7 +38,7 @@ Could this be written using existing APIs? If so, roughly what would that look l ## What happens now? -This issue contains an API change proposal (or ACP) and is part of the libs-api team [feature lifecycle]. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months. +This issue contains an API change proposal (or ACP) and is part of the libs team [feature lifecycle]. Once this issue is filed, the libs team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months. [feature lifecycle]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html @@ -53,3 +53,9 @@ Second, if there's a concrete solution: - We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.) - We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed. + +If we do think an API is worth implementing, we'll add the `ACP-accepted` label to your issue, at which point a [tracking issue] on the `rust-lang/rust` repository should be opened. Once the tracking issue exists, we'll close the issue as completed. + +[tracking issue]: https://github.com/rust-lang/rust/issues/new?assignees=&labels=C-tracking-issue%2C+T-libs&template=library_tracking_issue.md&title=Tracking+Issue+for+XXX + +In general, we prefer that authors close their own ACPs instead of the team rejecting them, since generally, the solution to a problem is "not now/differently," not "never, in no possible way." However, if an ACP ends up being merged in some other form (e.g. a similar one is accepted) or an ACP cannot be done without breaking stability guarantees, we may close it for that reason.