Clarify whether ACP process is optional

[okaneco]

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.

std-dev-guide/src/development/feature-lifecycle.md

Line 26 in 23d4ff6

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.

When contributing to std, a lot of contributors find this line and believe they don't have to file an ACP. They may submit a PR, wait days for a review, and finally get a response that the PR can't be reviewed until an ACP has been accepted.

Filing an ACP seems de facto required and would cut out a lot of wasted lead time on contributors' behalf if they submitted the ACP along with the PR instead of risking its optionality. Being told you need to write a report days or weeks after you filed the PR, while it's no longer fresh in your mind, is a demotivating and frustrating experience for contributors.

Observing new feature addition PRs since the ACP process was added, it seems overwhelmingly that these PRs require an ACP. I would like to see this clause clarified to encourage contributors to submit an ACP anyway to make the process smoother and less surprising for them.

---

As a sidenote, I needed to file an ACP for extending a pre-existing feature to another type, so perhaps that should be called out too. I don't know the policy, but for example: "Expanding the scope of an already existing feature may/will require an ACP." This way contributors won't be surprised and will be prepared to do that if the necessary.

[BurntSushi]

(This is my own take. While I'm on libs-api, I'm not speaking for libs-api.)

I'll say that I'm totally in favor of clarifying the wording here.

But I do think the current wording is correct. The ACP process is optional. The relevant text you quoted, I feel, captures this, emphasis mine:

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.

To me, that language indicates that an ACP acts as a hedge against wasting time. You could submit a PR, but you might be doing work that is wasted if the libs team wouldn't even consider it in the first place. That is, ACP is a way of asking the libs team, "without getting into the details, is this an idea y'all might be interested in?" If the answer is yes, that doesn't mean we'll end up accepting the change, but at least you'll have some signal that a PR won't be rejected on the grounds of the idea itself. Without the ACP process, we didn't have a way to get that signal, and so folks would just submit a PR and potentially waste a fair amount of work with either the PR sitting around (because sometimes saying "no" is hard) or getting rejected on the idea alone. With the ACP process, that shifts to an issue describing the idea sitting around, which is hopefully less of an investment on the contributor's end.

Being told you need to write a report days or weeks after you filed the PR, while it's no longer fresh in your mind, is a demotivating and frustrating experience for contributors.

Yeah I can definitely see how that's a bummer. But I do think this is the risk you take by not doing an ACP. We could make that language clearer in the docs. It's also possible that the ACP process is slowly evolving from "optional" to "requirement." Such things happen, but I'm not sure that we're there yet. The problem with writing down "an ACP is required for everything," is that it can introduce a lot of ceremony for smaller and less controversial things. But I confess that I don't have a good handle on just how many APIs we're stabilizing that never had an ACP. If it's very few, then perhaps the cost of requiring an ACP as a rule is much smaller than I think it is.