PSA: tweaks to FCP process

[bstrie]

Making rfcbot smarter would be nice, though I don’t think it’s necessarily a critical priority because what we’re really guarding against is the actual act of stabilization carried out by PRs to rust-lang/rust, and rfcbot only interacts with tracking issues there. As long as the people approving the stabilization PRs understand the distinction everything is fine. Though one small extension to rfcbot that would be useful in all contexts now would be to alter its “the FCP is over” comment message to make light of when a FCP has ended with <100% of sign-offs.

[wycats]

Good question! With this change, nothing is passively blocked on 100% participation (but at most two checkboxes can be missing). But acceptance can always be actively blocked by any team member. As above, we may need to make tweaks to other aspects to make sure that core stakeholders have ample time to review, but the primary motivation here is to avoid blocking on people who are not invested in an issue but haven’t managed to review it yet.

My concern with this change is that it eliminates a strong motivation for people to track me down and make sure I’ve quickly reviewed any actions requiring my participation. I agree that the current system puts too much onus on the person who’s responsible for tracking people down, but the new system eliminates the motivation to make sure people providing “passive consent” have had an opportunity to review RFCs before they advance.

My ideal system would have a timeframe for participation to address the issue @withoutboats experienced. During this time, the system would nag me to participate, giving me a clear deadline to reply, therefore eliminating the need for a person to track me down and ensuring that I don’t inadvertently slow the process down indefinitely.

[withoutboats]

My concerns with this change have only grown with time. I feel like a lot of things are happening in domains I’m ostensibly responsible for without me even being aware of it. Decisions are just made now before I’ve even been able to filter through my email.

[SimonSapin]

Is the 10 days period not sufficient?

[withoutboats]

An RFC was merged this morning that I wanted to raise concerns on because I didn’t realize how quickly it had moved through the process & I was busy last week on other things.

Probably what I really need is a better way to be informed of the ongoing FCPs than being tagged in the threads. Right now, I would say roughly 80 different GitHub issues that I am tagged in get updated each day, I don’t even bother scanning them most days. I need an easier way to distinguish the FCPs from other GitHub issues.

[SimonSapin]

For what it’s worth I have an Sieve email filter on if header :is ["X-GitHub-Sender"] ["rfcbot"]. There’s also https://rfcbot.rs/.

[Centril]

An RFC was merged this morning that I wanted to raise concerns on because I didn’t realize how quickly it had moved through the process & I was busy last week on other things.

My apologies for that; I’ve been merging RFCs rapidly these days after the FCP has completed =) Hopefully the concerns can be dealt with for this RFC during the stabilization process?

One thing you can do besides @SimonSapin’s suggestions is to look at the PRs labeled as “Final Comment Period” and filter out those that are not.

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.