From 612b3adb850fe105e25d89ed54cabc16c867f98b Mon Sep 17 00:00:00 2001 From: Oskar Goldhahn Date: Fri, 19 Jul 2024 02:00:07 +0200 Subject: [PATCH 1/3] Mention that any reviewer might request a FCP --- src/development/feature-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/feature-lifecycle.md b/src/development/feature-lifecycle.md index ce51bce..654a06d 100644 --- a/src/development/feature-lifecycle.md +++ b/src/development/feature-lifecycle.md @@ -23,7 +23,7 @@ be merged and pass its eventual FCP. You can create an ACP in the `rust-lang/libs-team` repo using [this issue template](https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29). This should include a sketch of the proposed API, but does not have to be the final design that will be implemented. -Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature. However do note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process. +Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature, possibly after a reviewer requests an ACP first anyways. Also note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process. ## API design exploration From 8ae1562017a9c090775a384a984fc269dbbc7b30 Mon Sep 17 00:00:00 2001 From: oskgo <92018610+oskgo@users.noreply.github.com> Date: Fri, 19 Jul 2024 14:19:57 +0200 Subject: [PATCH 2/3] Update src/development/feature-lifecycle.md Co-authored-by: scottmcm --- src/development/feature-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/feature-lifecycle.md b/src/development/feature-lifecycle.md index 654a06d..a4c49d9 100644 --- a/src/development/feature-lifecycle.md +++ b/src/development/feature-lifecycle.md @@ -23,7 +23,7 @@ be merged and pass its eventual FCP. You can create an ACP in the `rust-lang/libs-team` repo using [this issue template](https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29). This should include a sketch of the proposed API, but does not have to be the final design that will be implemented. -Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature, possibly after a reviewer requests an ACP first anyways. Also note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process. +Most standard library additions should start with an ACP. That's particularly true for things with substantial ecosystem impact, like traits that other libraries would be expected to implement, or expansion of the standard library into new areas. An ACP is not strictly required: reviewers may approve small things in existing areas. But while you can just go ahead and submit a pull request with an implementation of your proposed API, it's common that a reviewer will decide to ask for an ACP anyway. Note also that the library team can end up rejecting a feature in the later parts of the stabilization process, regardless of accepted ACPs or PRs. ## API design exploration From 19cc5b34c31f9e45e80a1e619cfff762e646fc21 Mon Sep 17 00:00:00 2001 From: oskgo <92018610+oskgo@users.noreply.github.com> Date: Fri, 2 Aug 2024 17:24:47 +0200 Subject: [PATCH 3/3] Remove double spacing Co-authored-by: Fredrik Enestad --- src/development/feature-lifecycle.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/development/feature-lifecycle.md b/src/development/feature-lifecycle.md index a4c49d9..02704fc 100644 --- a/src/development/feature-lifecycle.md +++ b/src/development/feature-lifecycle.md @@ -23,7 +23,7 @@ be merged and pass its eventual FCP. You can create an ACP in the `rust-lang/libs-team` repo using [this issue template](https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29). This should include a sketch of the proposed API, but does not have to be the final design that will be implemented. -Most standard library additions should start with an ACP. That's particularly true for things with substantial ecosystem impact, like traits that other libraries would be expected to implement, or expansion of the standard library into new areas. An ACP is not strictly required: reviewers may approve small things in existing areas. But while you can just go ahead and submit a pull request with an implementation of your proposed API, it's common that a reviewer will decide to ask for an ACP anyway. Note also that the library team can end up rejecting a feature in the later parts of the stabilization process, regardless of accepted ACPs or PRs. +Most standard library additions should start with an ACP. That's particularly true for things with substantial ecosystem impact, like traits that other libraries would be expected to implement, or expansion of the standard library into new areas. An ACP is not strictly required: reviewers may approve small things in existing areas. But while you can just go ahead and submit a pull request with an implementation of your proposed API, it's common that a reviewer will decide to ask for an ACP anyway. Note also that the library team can end up rejecting a feature in the later parts of the stabilization process, regardless of accepted ACPs or PRs. ## API design exploration