new decision process

[nikomatsakis]

Hello @rust-lang/lang. This is a slightly revised variant of the decision making process that we discussed in our Mar 12 design meeting and which I've subsequently discussed with all of you at various points. This replaces the previous decision making content, which was added by @joshtriplett on #113.

Highlights of this new process

• Reversible decisions only require a "champion" from the team/advisors to nominate the issue for visibility. They can't be blocked but team members are encouraged to weigh in, particularly if they have concerns.
• Consensus decisions require 2/3 to approve and no concerns. I've elaborated on the previous concept of challenging a concern in the case that consensus cannot be reached. It now requires reading a doc that explains the concern. If at the end of that meeting we cannot find 1/3 of the team to sustain the concern, it is considered resolved.

The 2/3 and 1/3 thresholds align with our current values (3 to approve FCP, 2 to sustain a concern). However, I wanted ratios that would scale as we (optimistically) grow.

I've not included the material on champions here. I think it supports this process well but it's orthogonal. I'll add it in a follow-up PR, this was meant to be focused on decision making.

I intend to move to fcp this PR, but I'll wait a bit for suggestions or feedback. I know that in our last meeting there were some concerns raised about the new process making it too easy to overrule concerns. I've tried to address those by explicitly noting what the summary document should contain and emphasizing in the axioms and elsewhere that we prefer to "find common ground". At the same time, the chief axiom is to not be afraid to do the right thing (well, the second axiom, after "no new rationale"), and I think that in the end sometimes the right thing is to move forward.

[tmandry]

Overall this looks great to me. I really like how the axioms support the process and vice versa.

[nikomatsakis]

Thinking on this more, I like the idea of having the threshold to sustain a concern be something other than S = N - R. Perhaps 1/4.

After further discussion: settled on 1/3.

[nikomatsakis]

@rfcbot fcp merge

OK, per my comments above, I think this is ready to go forward!

[tmandry]

@rfcbot fcp merge

[rfcbot]

Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

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.
See this document for info about what commands tagged team members can give me.

[traviscross]

(See also the note below about wanting to distinguish "FCPed decision" and "consensus decision", as that may be relevant here.)

Perhaps another name would be better. The problem with "reversible decisions" is that we do make certain reversible decisions by consensus. The fact that a decision is reversible is necessary for it to not be a decision requiring consensus, but calling decisions not made by consensus reversible feels like affirming the consequent.

Maybe we could call these "member decisions".

[traviscross]

(See the note below about wanting to distinguish "FCPed decision" and "consensus decision", as that may be relevant here.)

At the point it's discussed with the team, it tends to just be a consensus decision. Here's how I might frame it instead.

It's within the power of a single member to close an RFC or other issue or PR when the member estimates with some confidence that would be the consensus of the team, or at least that it's unlikely that the team would form an affirmative consensus to accept the RFC or otherwise do what is asked in the issue or PR.

That's, I think, in general the role of member decisions, is to predict the behavior of the group and save everyone some time when that can be confidently estimated. Because, at the end of the day, whatever our policy says, when one of us does something like this, it will be read as a reflection on the group and our beliefs.

For design issues, e.g. when guiding along a lang experiment, that doesn't necessarily mean only making decisions we're sure the group will accept -- that would be too constraining, and one never really knows until it all comes together and the full case can be made -- but it does mean steering people away from directions that we can say with some confidence will not be accepted.

[traviscross]

The part of this that I like is trying to find ways to push things forward asynchronously and maybe up our out-of-meeting tempo.

But conversely, the part that gives me pause here is this creating a rather ambiguous signal and uncertainty around what can go forward. I suspect we'd end up with a lot of polls without a lot of boxes checked, and a lot of questions around what that means in terms of what can go forward and when. We can say, "oh, well, it's reversible, it can go forward with just the one box checked," but that I think sends a weird signal too. I mean, we thought to ask the group. Shouldn't we wait for an answer? But now it's a month later, with no change. Etc.

We can say that, "oh, well, people on the team should do their jobs," but there are a lot of things to keep up with, and I could understand people finding it uncomfortable to check a box on some detailed question on a experiment on which one has temporarily lost context, and therefore wanting to look into it first, but that becoming unbounded in time.

I also wonder how this interacts with the last section. If in closing a clearly-doomed RFC, the idea is that a poll should first be started, I suppose I wonder why I wouldn't just FCP close it at that point. Starting a poll feels like the worst of both worlds. It lacks the speed of just closing it. It doesn't save anyone time, since it still asks everyone to have a look. And since one is signaling one's unilateral authority to close the issue, it in some ways makes it seem more rather than less pressing than a proposed FCP. That's true of just closing it, also, but at least then one buys something in exchange for taking that risk.

[traviscross]

(See the note below about wanting to distinguish "FCPed decision" and "consensus decision", as that may be relevant here.)

Probably I'd make this language a bit more encompassing or, alternatively, clarify that we're speaking to what must necessarily be decided by consensus rather than just what consensus decisions are "used for" by us.

We signal consensus for many things which are technically reversible, and i think that's good and valuable. People build up a model of us over time, and these signals are part of how people build this model.

[traviscross]

Given this definition, probably I want to just call these "FCPed decisions" or something rather than "consensus" ones. A decision that we've FCPed represents the strongest form of our consensus, but it's not the only one.

[traviscross]

Unless I'm missing a subtlety here, round(N / 3) doesn't match the above:

Sustaining a concern requires 1/4 of the lang team to agree to sustain....

[traviscross]

The rule for sustaining I'd probably expect, for teams of healthy size, would be max(2, floor(N / D)) if N >= 5 for some D. That is, I'd expect it to need a second, and otherwise to round down. For smaller team sizes, there's of course not really an alternative to just bringing everyone along, and that can just be a separate rule.

[traviscross]

The other way to frame this would be to turn it around and to state a supermajority threshold for "calling the question". That is, rather than asking for seconds to the objection, we treat overriding the objection as a separate act of the group, we state that people should be more careful about checking that box -- that it represents something more than just agreeing with the outcome -- and we set a somewhat higher fractional threshold for it.

Probably I actually do like this framing better. It's the more ordinary one. And it feels somehow more... appealingly active.

[traviscross]

Another reason for treating this actively is that, when taking an act, one of the things we're signing off on is that process has been followed. Doing this actively provides for a good place -- a good moment -- for signing off on this. It's less clear where that moment or that sign off is when doing it the other way around.

[tmandry]

The problem I have with framing it as an override is that it removes agency from the party outside the lang team who is blocked by an objection. Convincing the team to override the objection of another team member connotates a much higher social cost than convincing them not to sustain an objection.

This applies within the team as well. People within the team know each other quite well, and I expect that they will (and should be willing to) sustain one another's concerns if they think the discussion isn't over yet. Conversely, overriding another's concern is an affirmative action that comes with a high social cost, which implies any concern defaults to blocking. That would leave us much more frequently in the failure mode we see today, where a blocking concern leaves a proposal in limbo for an indeterminate amount of time, without any pressure to move the discussion forward.

The main value in this proposal to me is giving more agency to people outside the team, so I think preserving the "sustaining" framing is important.

[traviscross]

What I'm suggesting, I think, is that it is an active act regardless -- that there's no getting away from that -- and so we'd be better off to accept it for what it is so we're prepared, if needed, to take it head on.

[tmandry]

There is an active component, but in this process it's the challenge to the concern which leads to a meeting. Importantly, it is not final; the outcome of the meeting could be anything. Requiring an affirmative act with finality that comes with social costs from 2/3 of membership raises the bar too high.

[traviscross]

I don't know. It feels better to me, socially and personally, from both sides for this to be explicitly active.

Bob: I'm still not OK with this.

Alice: I get that Bob, but I think we've waited and done enough on this. I'm going to call the question. I propose FCP merge to do this despite objections.

Charlie: I understand where Bob is coming from too, and I appreciate him laying out the choice so clearly in his document, but I still think we should do this. I'm checking my box.

Etc.

To me, if I were Bob in that, I'd feel pretty heard, and I'd feel the system made sure of that. And if I were Alice or Charlie, I don't really feel put out by having to say that I want to do it anyway.

Conversely, in the passive framing, it's possible that Bob get crickets, and that I don't think would feel great socially or personally to anyone.

Doing this actively I think gives people a better sense of closure.

[traviscross]

Overall, this clearly looks like an improvement on what was there before. To summarize what's in the threads above: I think I'd prefer to call these two categories of decisions something else. I'm unclear how we'd use the @rfcbot poll mechanism, and how it fits in as a formal part of the process described. And probably I'd prefer to frame overriding an objection as an active act of the group, and to set the supermajority needed for that, rather than setting the threshold for the minority that can sustain an objection.

[tmandry]

Suggested change

	If deeper discussion does not reach a solution, a [lang team member](#definitions) can challenge a concern. This indicates that they feel they understand the concern and do not agree it is a problem.
	If deeper discussion does not reach a solution, a [lang team member or advisor](#definitions) can challenge a concern. This indicates that they feel they understand the concern and do not agree it is a problem.

I think anyone who can champion should be able to challenge a concern.

[traviscross]

In a parliamentary sense, I think this challenge is equivalent to making a motion, and so I'd say it should be anyone who can propose FCP, which is currently only team members.