Refining RFCs part 3: Async decisions

[aturon]

I've been digesting feedback and having some offline discussions over the last week, and I'm going to respond to the comments in these threads over the next day-two.

I want to start with the mechanics of async decision-making. I think the original strawman I proposed was pretty flawed:

@brson

Making the final call literally a vote (approving stabilization via 'r+') kinda makes me nervous.

@brson

There will be times where team members don't respond. What happens then? Does the process continue without their vote?

@nrc

Could we retain the consensus requirement and allow people to change votes?

@nikomatsakis

One simple thought is just to have r+ and ack -- if you respond fcp ack, it sort of implies that you have a blocking concern. If you want to abstain, you write fcp r+ (abstain) or something like that.

... etc. Interestingly, there's a push both toward making things a bit less formal/more fluid on the one hand, and toward highly fine-grained voting schemes on the other.

I agree strongly with the concern about "voting" not being in tune with our consensus process. After talking extensively with @wycats, I want to propose a revised scheme.

Dispositions

First, there's a notion of a disposition toward an RFC:

• merge
• close: reboot from Motivation, saying that we still want to solve the problem but this RFC isn't the desired route.
• postpone: essentially, put the original Motivation on hold, due to an issue that arose during the RFC process. Should be rare.

Process overview

• ... pre-RFC stages ...
• RFC PR is posted
• Discussion reaches a steady state (not necessarily consensus) and the RFC is up to date
• A shepherd/subteam member submits a Motion to FCP, along with a disposition for the FCP
  • This is the time for formal objections from the subteam
  • No fixed timeline; complete once all members have read the RFC and don't object (see mechanics below)
• FCP period
  • One week long
  • Discussion focused on any major new arguments around the disposition (not minor details)
  • Normal result: disposition becomes final
  • Before subteam member makes the decision final, they must check that all new arguments have been adequately addressed.

Mechanics

• Motion to FCP is fcp: (merge|close|postpone)
• The tool then automatically posts a comment with a checklist of subteam members ([ ] aturon), with a check meaning "I have reviewed"
• Subteam members can post a comment with fcp: r- to lodge a formal (blocking) objection.
  • Usually this is cleared only on a new commit to the RFC.
• Motion to FCP completes when all subteam members have reviewed and all blocking objections have been addressed.
  • Members can file vacations etc to not be included.

My thoughts

I think this revised proposal addresses several concerns.

• Lightweight mechanics.
• Supports consensus and encourages momentum toward a decision by avoiding any form of voting, and instead focusing on consent and blocking objections
• Allows any shepherd to move things along through a motion to FCP.
• Gives a clear signal to subteam members who might not have been following that particular RFC closely that now is the time to review for any blocking objections. Because this is done prior to FCP, the FCP period itself is expected to be relatively smooth sailing. (Unlike today, where often FCP is often where subteam members leave the most comments.)

What do you think?