Should libs-reviewers kick off FCP where they think it reasonable?

[Mark-Simulacrum]

e.g., in rust-lang/rust#157734 (comment), it seems like it wouldn't be unreasonable for that nomination to 'just' be an fcp merge on the tracking issue. That is now possible.

I think the main risk is that we end up canceling more FCPs if it turns out there are blocking concerns, but it doesn't seem like that's a horrible place to be in? It would hopefully encourage more asynchronous handling of things, which seems like a good thing.

Cutting this issue so libs can discuss what etiquette we'd like for this now that our tools support a broader set of capabilities.

[BurntSushi]

I'm a +1 on this. I think it's reasonable to course correct if this results in a flood of FCPs. If this helps make async more productive, I'm in favor.

[jhpratt]

For what it's worth, the proposed restructuring of T-libs allows this, as any reviewer is currently a T-libs contributor (which would then be subsumed into T-libs)

[Mark-Simulacrum]

I'm not sure there's a clear reason the restructuring changes anything here? Under all proposals I've seen there's a separate "FCP" set, the question above is essentially whether we're OK with a broader group than just that set kicking off FCPs. It sounds like the answer is 'yes'.

[nia-e]

replied synchronously during the team meeting last week - yes :D thanks for bringing this up