Update ACP issue template - #870
Conversation
d61dc6e to
fe0d6a2
Compare
fe0d6a2 to
f2296b0
Compare
| about: Propose an API change for the standard library | ||
| title: '' | ||
| labels: api-change-proposal, T-libs-api | ||
| labels: api-change-proposal |
There was a problem hiding this comment.
| labels: api-change-proposal | |
| labels: api-change-proposal, T-libs |
There was a problem hiding this comment.
So, initially I removed this because "we know it's libs, it's in the libs repo," but then looked at compiler's repo and realised it's for rfcbot integration. So, yes, that makes sense.
| - 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. |
There was a problem hiding this comment.
| 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. | |
| If we do think an API is worth implementing, we'll add the `ACP-accepted` label to your issue, at which point you should open a [tracking issue] on the `rust-lang/rust` repository. Once the tracking issue exists, you can 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. |
There was a problem hiding this comment.
I don't think that we should have a framing like this on the ACP template, such that it shows up in every issue. Having a mention of how we close issues as the last thing someone sees in the template seems like it sets the wrong tone.
There was a problem hiding this comment.
Hmm, honestly, you're kind of right, and I think maybe we should also move some of this into a forge policy instead of being in the template itself.
Closes #547.
Also fixes a label change post RFC 3984. Figures that the one repo I forgot to check was this one…