PSA: tweaks to FCP process

[steveklabnik]

What if the FCP announcement pings those who haven’t checked the box? That could be the reminder.

[withoutboats]

Things have gone into FCP without me even having read them. For example, this stabilization PR was FCP proposed on Thursday night, and went into FCP last night. Since this was a long weekend in the US, there was effectively 1 day of work in which I could’ve read the issue and registered a concern. I don’t have a concern, but it was still disconcerting.

On the other hand, we’ve definitely had situations where several items sat in FCP proposed for weeks until a team member checked off their boxes. That was worse than this, I think, but we still swung too far.

I’d like it if the flow instead pinged the remaining people when the threshold is hit, and then gave some amount of time (72 hours?) before going into FCP.

[aturon]

Note that FCP itself lasts for 10 days, during which any team member can register a concern and take back out of FCP.

That said, perhaps the new threshold should itself only trigger if it has been some period since FCP was first proposed? I think this is what @wycats is suggesting as well.

[withoutboats]

Note that FCP itself lasts for 10 days, during which any team member can register a concern and take back out of FCP.

Does registering a concern take it out of FCP, from the bot’s perspective? It doesn’t cause the bot to do anything, like remove labels. Should I do something when I register a concern?

The bot just moved something into FCP while I was writing the comment to register a concern. I think it wouldn’t hurt anything to add a waiting period after the threshold is hit before the bot enters FCP, and it seems like the most correct solution.

[aturon]

Does registering a concern take it out of FCP, from the bot’s perspective?

I don’t think so, but it should.

[withoutboats]

I guess if that behavior would be implemented it wouldn’t make sense to add a waiting period, since there’d be no difference between being in FCP and being in proposed FCP with a threshold.

[SimonSapin]

Why is entering FCP meaningful at all? Isn’t its completion all that matters?

[withoutboats]

It sets the countdown. Once all team member concerns have been resolved, the rest of the community has 10 more days to raise further objections that could challenge the team’s consensus (if a concern is registered, the 10 days should start from whenever that concern is resolved, even if it was registered after the threshold was hit).

[bstrie]

To be clear, is the end of the FCP still blocked on 100% participation by the team members, xor does this imply that FCPs can proceed into acceptance/stabilization without 100% participation?

[aturon]

To be clear, is the end of the FCP still blocked on 100% participation by the team members, xor does this imply that FCPs can proceed into acceptance/stabilization without 100% participation?

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.

[bstrie]

Thanks for the clarification. I acknowledge the desire to remove bureaucracy on getting RFCs out the door. That said, may I suggest a compromise: proceed with the plan you describe, but block FCPs that result in stabilization from finishing without 100% team participation. IOW, hold stabilization to a higher standard, because hitting stable is the point of no return (well, to a first approximation…).

[aturon]

That seems very reasonable! Doing this will require a bit more work, since right now rfcbot doesn’t distinguish various categories.

[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.