Refining RFCs part 3: Async decisions

I’m all for this.

Making the final call literally a vote (approving stabilization via ‘r+’) kinda makes me nervous. While it does reflect how Rust decision making effectively works today, it’s a big thing to encode into the process. Not something we can likely roll back.

I don’t see it in your description, but I imagine that the T-$team tags indicate to the bot which teams to expect responses from.

There will be times where team members don’t respond. What happens then? Does the process continue without their vote?

Offhand I can’t recall the difference between “approving/disapproving FCP” and “approving stabilization/RFC merging”. Isn’t FCP the last thing that happens before something is ‘done’. So e.g. doesn’t ‘fcp r+’ mean that an RFC is accepted? If so, what does plain ‘r+’ mean on an RFC PR? Oh, maybe “approving FCP” means the team has to vote publicly just to enter FCP?

https://github.com/dikaiosune/rust-dashboard/issues/61 is about some of the automation necessary.