FCP process: Require 2/3 majority for FCP #114986
Comments
rustbot
added
the
needs-triage
RalfJung
added
T-lang
|
@rfcbot fcp merge |
|
Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rfcbot
added
proposed-final-comment-period
|
This seems fine to me, but why are there are only 4 teams tagged here? Presumably this impacts all teams? (The PR referenced doesn't seem to make this specific to the 4 teams FCP'ing here.) |
|
I tagged the 4 teams that have 5 members ATM. These are the only teams for which the PR changes the threshold. Sure, other teams can change their number of members in the future, but tagging all teams seemed excessive. This seemed like a reasonable balance to strike. |
|
Am I misunderstanding here? If the other teams drop to 5 members, them this policy change impacts them automatically right? If so, we should either restrict the scope of this change to these 4 teams or ask all teams I guess? |
Yes. We don't have a defined process for changing these FCP rules. Maybe (ideally?) in the future, each team can define their own threshold. For now I thought getting agreement of the teams affected now was a reasonable process that avoided a 100-people-FCP. |
|
Yes, I understand the line of thinking. I guess I'm disagreeing with it because regardless of whether other teams are affected now or not, this is still changing their policy too. And this isn't a super small thing. This is changing how the consensus itself is determined. Teams.should have to opt into that, regardless of whether they are presently impacted or not. |
That's not the only alternative. I proposed one other. There are perhaps other paths forward as well. |
|
Given that FCPs are created for sets of teams, it is unclear what a per-team opt-in even means. The bot also currently does not remember the team list for an ongoing FCP proposal, it only knows the set of people that a review was requested from. Note that this change errs on the side of caution -- it can only lead to something not being considered consensus when it was considered consensus by the old rules; it can never lead to the bot declaring consensus when the team would not expect that. |
|
This does feel more like a Council level decision. But since it moves in the conservative direction and the Council is likely to be busy with other things in the near future, delaying would only lead to more decisions being made by all these teams with what they feel is not enough buy-in. So I think it's fine to handle it this way for now; I've gone ahead and checked my box. |
|
We asked for advice from the council and they said they'd rather leave the teams' decision process up to the teams. |
|
Yes, I agree that this isn't something for the Council. Each team should own how they make decisions. That's kind of my point. This is changing how other teams make decisions. I understand this is conservative. I understand this is probably non-controversial. I understand that y'all are trying to avoid a crazy large FCP. I understand that the current tooling may not support different FCP consensus approaches. I understand that not doing this means continuing with an arguably sub-standard consensus process. I understand all of that. But the bottom line is that this is still making policy for how teams come to decisions without giving those teams a voice in that decision. That does not seem right to me. That it's hard to change the policy for all teams at once or to change the policy for only a subset of the teams does not mean we should just go ahead and do it anyway. I also don't feel like this is an urgent matter. @rfcbot concern lack-of-voice |
|
Well this is probably dead in the water then, since I don't know how to satisfy these requirements. Even the set of all teams doesn't get to decide the charter for future teams, after all. I was hoping for a bit more pragmatism. |
|
I haven't seen enough exploration of team aware FCPs that know about consensus thresholds to understand why that's "dead in the water." I also don't see why an all-team FCP will 100% fail either. Unwieldy certainly... Future teams seems like a red herring. If they come into existence they can choose at that point how they want to deal with their own consensus process. I'm perfectly happy to be pragmatic but not at the cost of deciding the consensus process for other teams. |
A concrete difficulty it has is that the "at most 2 approvals are outstanding" becomes increasingly unwieldy the more people are on the list as noted in #104385 (comment). This is especially true if we pull in teams which are largely dormant and don't often have FCPs (for example, rust-lang/rfcs#3455 (comment)). |
|
I think the council is prepared to make decisions affecting all teams precisely because they have representation from all teams. So a global decision like this would likely involve each council member reaching out to their constituent teams and subteams for feedback on the proposal and using that to decide how to respond to this FCP. I also think it should be possible to perform the check on a per team basis for an fcp. For each team in the fcp, check whether the number of checked boxes for its team members satisfies the requirement for that team. With all that said I think we're giving too much weight to the status quo, without any clear reason, if we block progress on one of those things happening. If we have an actual example of a team who doesn't want this, we can implement per-team checks now. Otherwise we can make this change now and implement per-team checks if a team that is newly affected disagrees with the change. |
Note that the council has not discussed this. Only two members shared their personal opinion. (I personally agree with them! I just want to be careful with individual opinions leading to "the council said", given how similar things have led to issues in the past. ^^) |
|
With regard an enormous FCP if all teams were included, would it make sense to require two-thirds and at most two outstanding of each team separately, rather than of the combined membership? That could apply to any multi-team proposal. |
|
This FCP has all the required checkboxes, just hasn't completed because of the concern. Maybe it makes sense to start an FCP with the other teams on a separate issue? Are there concerns about this slowing down the approval process? From a decision making outsider, it seems like usually the last one or two checkboxes can take weeks or months to get, and I only expect this to become longer as the bar gets raised (echoes @thomcc's comment in #114986 (comment)). I am 1000% in favor of requiring more consensus on FCP decisions and think it is needed, but also think some sort of expected duration should probably come with it so nearly complete things don't stall out (e.g. something like "2/3 of included members should approve, voice concerns, or otherwise make their stance known within 4 weeks of a proposed FCP" would be quite nice for the reviewees) |
|
@BurntSushi I don't 100% understand the concern -- is it that there exist teams that are not tagged on this FCP? |
|
Probably mostly T-compiler |
|
Hi, I come from Zulip. Can't read/process rn the content or intent of this proposal. Just dropping here a question: does the proposal take into account what would happen for teams with <= 5 members, where some of of them are "ghosts" (i.e. team member listed as active but factually not anymore) or would this case be out of scope / unaffected by this proposal? Not registering this as a concern, I think it's just my curiosity. |
|
Nothing changes for teams with < 5 members. For 4 members, the threshold is 3 both before and after this change. For 5 members, yes if one of them isn't active any more then now all the 4 active members have to be around after this change. Arguably those inactive members should be moved to alumni, and ideally the team re-grown to 5 active members. I don't know if the process allowing for them to just be absent for long time without that being acknowledged in the team structure is a bug or a feature. |
|
thanks @RalfJung !
Good point: as far as I know I think there is no project-wide policy defining "being active" so every team handles this the way they prefer - and I think it's fine like this. Still, it would probably an improvement if such per-team policies were drafted or discussed somehow/somewhere. Anyway: way out of scope here 🙂 |
I am not in the FCP checklist so these are just personal thoughts. But I second the concern about applying blanket policies to teams without listening to them first. I assume that everyone checking their box discussed this internally. IIUC the proposal, the intent is to "enforce a stronger will when deciding important things" and that proposal came from T-lang, for T-lang. Not to be applied project-wide, right? I mean, if T-lang feels they need this policy for themselves, that's totally fine. But I think patching the rfcbot adding a bit more logic ("if team x then majority = y else majority = z") maybe is enough? |
|
In general, I think it is good for us to have more uniformity of process between teams -- that said, I think that as long as the bot commands are the same, that's fine. Probably best if it is configured in the team repo or something though. |
You are linking to a post of mine there. I did not argue for per-team quorum treatment in multi-team FCPs -- you misunderstood my position. I merely said that if we want to have per-team quorum rules (as several people suggested here), then we need to define new rules for multi-team FCP. |
|
Given this concern, this FCP is dead in the water. If someone wants to try and turn this into an all-teams FCP (hoping that that will be considered sufficient), feel free to take over. I am mostly reminded why I usually stay out of anything involving governance.^^ Meanwhile, multiple teams that clearly want to have the changed consensus rules are blocked from having them over the concern that other teams might hypothetically have 5 members in the future and then they would fail to reach consensus without having ever declared that 3 out of 5 people agreeing to a proposal is not consensus. |
|
@RalfJung proposal cancelled. |
rfcbot
removed
proposed-final-comment-period
Sorry, I missed this ping from earlier. The concern I have is that this is deciding the consensus process for teams not in this FCP. Tagging those teams is one possible resolution of that concern, but it's not the only one as far as I know. For example, another resolution of that concern is that the tooling that manages consensus becomes aware of the fact that each team might have different consensus thresholds. If the tooling were improved, then you wouldn't need to tag other teams on this FCP because then each team could make their own decision themselves. Yet another resolution of this concern is perhaps for the Council to step in and make a decision for everyone, but I think they've already declined to do that (and to be clear, I don't necessarily disagree with that!). |
|
...Does anything change on that front? The FCP minimum of "51% and at most 2 members outstanding" was already an arbitrary bound decided arbitrarily when teams formed. Many did not exist at the time, no? |
Correct. And the status quo existed when they came into existence. It's unclear what you're suggesting here. Can you clarify please? My understanding of your comment is that this change should go through, applying to all teams, without the consent of all of the teams that are impacted by it? And that this is because the status quo was decided arbitrarily before some of those teams existed? If so, I don't think I agree with that reasoning, but maybe I've misunderstood what you're saying/suggesting. |
|
Can't we just ask the @rust-lang/leadership-council to sign off on this? |
I'm fine with that personally. As in, it would resolve my specific concern. Another approach that is less bad than "FCP for all teams" is "FCP for all top-level teams." I'm also fond of the idea of each team being able to have their own consensus rules, but maybe I am underestimating the technical challenge there. |
I think I was mostly wondering at that moment. In a sense we have violated the consent of all the 5-person teams that currently exist that were not "day 1" teams (as nebulous a concept as that is). They lacked a voice, and their feedback is that we should adopt this change. By blocking this on that, we deny them. It seems a rocky grounds to block improving current lives on future lives in a case where either condition seems arbitrary. That is, both seem to divide on preference or situation. I imagine the current teams are more widely distributed, for instance, than they may have been before. In general there is not enough labor to go around to fill all the small improvements that the project ought to receive, and thus we should dole requirements out sparingly. Making the technical change might happen quickly enough but it's energy that could also go to e.g. fixing bors, for instance. The question arises of whether this is being blocked on an actual technical fix or whether the concern is about the appearance of no ability to get a few lines merged into rfcbot to enable such an option in the future? i.e. that making the decision actively somehow would block us from changing our minds again? |
I don't agree that there was a violation. At least not in the same sense as what would be happening here.
But you aren't presenting the full picture here. In so doing, we are making a decision for everyone else not on this FCP. We'd be denying their voices. I (and others) have suggested several alternatives for moving forward here.
A technical fix is one avenue forward here. Not the only one. I don't understand the complexity or feasibility of the technical fix. |
|
"not in the same sense" how? |
|
I'd rather not dive into a philosophy of consent here. And even if I agreed they were the same, that doesn't mean we should do it again. |
This issue suggests we accept the PR at rust-lang/rfcbot-rs#315, which fixes rust-lang/rfcbot-rs#293. I propose we do this via FCP of the affected teams.
The summary is that for teams of size 5, currently 3 checkboxes are enough to consider the FCP as passed; the change is to require 4 checkboxes instead. Formally, the requirement for entering the 10-day period changes from "more than half the members" to "at least two thirds of the members" (and at most two outstanding boxes, as before).
The text was updated successfully, but these errors were encountered: