RFCs and other major decisions go through a Final Comment Period of 10 days, during which time they are tagged and advertised. This ensures that people have a sufficient heads up to weigh in on discussions that are nearing a decision.
However, we previously required all team members to actively approve going into FCP, in addition to the 10 day period. In practice, this often means that items are left in limbo with one or two members taking a long time to get around to reviewing.
OTOH, we very much value our consensus-based decision-making process, and don’t want to lose that.
To find a better balance, we’re tweaking rfcbot so that an item can enter FCP if:
A majority of the team has actively signed off
No team-member has registered a concern
There are fewer than 3 approvals remaining
What this means is that any team member can actively withhold consent and block FCP on that basis, but RFCs will no longer be passively blocked as often.
The exact configuration here will probably need further tweaking, but I wanted to let everyone know that FCP will now be entered without requiring a full set of checkmarks.
(Also with "fewer than 3" you get all the people that perform their reviewing duties almost on daily basis (at least for the lang and libs teams), so the total comment period may shrink significantly.
It's kinda nice that the process is somewhat prolonged, no need to hurry too much with RFCs.
One failure mode this could potentially introduce that wasn’t present earlier: team members will necessarily end up seeing the notification about the motion-to-FCP, and looking at it, in some order. Let’s say the team has 6 members. If the first four who see the notification all tick their boxes, then the proposal will enter FCP before the last two have any opportunity to register a concern, even if they might’ve had one.
Of course, if the time scale this happens in is something like “one month”, then that was the whole point. But in theory nothing prevents it from taking place in the course of a day, either. If this is considered to be a cause for concern, a solution might be to modify the rule to something like “either (a) all the boxes have been checked, or (b) all-but-two have been, and at least (e.g.) a week has elapsed” (plus the other conditions from before).
(The other solution is to just @fcp cancel in that situation of course, but that might seem a bit heavy-handed depending on how frequently it happens.)
@aturon I assume the intent of this change was to approve FCPs without 100% explicit checkboxes, since empirically people don't always remember that their consent is needed for something and wouldn't object?
If so, triggering the conclusion immediately upon majority seems to give up a little too much. At least for myself, I occasionally find the "mandatory nag" caused by the previous system to occasionally cause me to become aware of concerns I want to file.
I wonder if a solution to this problem could be to avoid entering FCP with a simple majority for some amount of time (for teams with regular meetings, the meeting might be a good time bound).
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.
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.
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.
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.
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).
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.
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…).
