(Disclaimer: all of this is focusing on the question of "how" and ignoring the question of "if"; this shouldn't be taken as agreement yet.)
- I'd suggest using the normal
rfcbotprocess, just without paying attention to the usual 10-day delay after consensus. For instance, this is a tool we can apply during a regular weekly meeting, in which case if there are enough people present, we'd FCP and check the boxes for everyone present, and it'd immediately go into FCP, at which point we proceed. - It'll depend on the feature and how much usage we expect it to get. Generally, I'd guess either 6 weeks or 12 weeks would work, for any feature that actually requires changing Rust code to take advantage of it. For features that just involve passing an option and seeing the result, as little as 2 weeks may suffice. That said, given your point about continuity, we may want an amount of time that'll be slightly longer than the time until the next release, so something like 8 weeks might be preferable.
- One approach would be for the feature-enablement configuration to be in a file together with dates, and CI could compile in only those features whose dates haven't passed. That way, if we forget to prune an entry, it's still disabled on time. That also makes it easy for the scripts that generate meeting agendas to add near-future dates to the agenda.
- I'd hesitate to push that too hard. I understand the desire for continuity, but anyone using the testing channel is helping with an experiment, and needs to understand that they may need to roll back any changes they make. For that matter, we may end up changing or evolving a feature on the basis of experience reports.
We should also have a loose upper bound on the number of features we're testing concurrently.