[RFC] Update the RFC process to promote faster and clearer resolutions

[zephraph]

Proposal:

Our current RFC process is a fantastic mechanism for raising important conversations around large or controversial changes. I believe there are still optimizations we implement in the process to make it even better.

1. It's easy for RFCs to lose traction and stay open without movement for long periods of time
2. Resolving an RFC is still somewhat of a murky process

I propose that we

• Introduce a state of stalled for RFCs. If an RFC goes a week without comment then it will be automatically set as stalled and closed the next Monday at 12PM EST.
• Introduce the idea of an RFC sponsor. This person will be responsible for facilitating the conversation and will ultimately be who decides how an RFC is resolved.

Edit: I've updated the proposal to remove the second part. It seems like preliminary feedback is against that, and I'm not so invested in that part of this RFC to push for it. I would still like to tackle the problem of resolving RFCs being a little murky. Open to ideas on what that might look like.

Reasoning

Introducing stalled RFCs

(props to @orta for the suggestion on this one)

This just ensures we're doing our best to resolve RFCs in a timely manner.

Introducing an RFC sponsor to our process

To describe a sponsor's role I'll borrow a part of coming to consensus from Mark Shepard:

A chosen facilitator can help consensus by keeping the discussion on track, encouraging good process, and posing alternatives that may resolve differences. But a facilitator is a servant, not a director, and assumes a neutral role. If a facilitator wishes to take a stand on an issue, the task of facilitating is handed to someone else.

So a sponsors role will be two fold:

1. Help guide the conversation and resolve differences
2. Take the responsibility for deciding the resolution state

The sponsor should be neutral in the conversation, open to any resolution, and willing to help facilitate. If an RFC loses its sponsor it's considered stalled until a new sponsor is found.

[damassi]

I really like the idea of a stalled state, though my first reaction to it (before continuing on down the page) was "this is a great way to inspire the RFC writer to follow up, keep it fresh in memory, and build consensus internally". It seems like having a sponsor might be a good next step if introducing a stalled state fails to keep everyone on top of things.

[orta]

Yeah, if we time the stalled status to be a bit after the last mention (and highlight that in the weekly status messages ) then that should be real easy to just say it's in a NOOP state. And that's OK too

[ashfurrow]

I'm 👍 on the stalled state, especially since a simple "I'm still working on this" comment would keep the RFC going.

I'm not sold on the need for a sponsor, though. At least, a sponsor who is distinct from the RFC author (all of us should be open to any resolution). I think that iterating on the existing resolution process/making it more clear/putting it more into practice would be a better way forward than to introduce more complexities to the resolution process. RFCs have always felt lightweight and I don't want to lose that.

[mbilokonsky]

What if we say that anyone who puts forward an RFC has to summarize it and its current status in every Monday standup until it's accepted or rejected? I feel like that'll exert an implicit social pressure to close it if progress isn't actively happening, but still allow a lively discussion to keep going.

[orta]

Yeah - @mbilokonsky that was kinda what we had aimed to happen with c40f63f

I think once we started hitting a critical mass of like 8-9 at once then people started to skip on giving that overview

[SamRozen]

I have 2 questions on this topic:

1. What's the definition of done of a RFC? We get to an agreement on the proposal? The follow up actions are implemented?
2. Given that A lack of response from others is assumed to be positive indifference. what gets in the way of moving fast?

[orta]

1

I think we kinda need to differentiate "agreeing we need to do the work" and "doing the work" for this, a good chunk of RFCs stay open because they're not implemented yet. ( Maybe 3 out of these?)

2

Maybe confidence that enough folks have seen or been given a chance to give feedback?

[mbilokonsky]

Hmm. When I put out an RFC, I would never interpret a lack of response as positive indifference. This may just be my own psychology I guess? But like, we're a large team! RFCs are here to allow us to make decisions as a group. When only a tiny portion of that group participates I don't see positive indifference I just see indifference, and the assumption that indifference is consent to make changes feels a lil hard to rely on for me?

So I think you've identified a real problem around definitions and state transitions!

[orta]

RFCs are Requests For Comments - effectively a way of letting people know what you'd like to do which changes our culture and gives others the chance to change/influence it. This type of process isn't aimed at building consensus among a large team, and would be bad at being used that way.

If you want consensus you need to have a synchronous tool (like meetings, town halls or round tables etc) which is why these are recommended as tools if you need consensus after a week of an RFC. Maybe the docs aren't clear enough on this on our RFC page, but if no-one is saying your change is wrong then positive indifference means that it's fine to happen.

[orta]

Re: Stalled and the addition of a new state

Maybe we should add 2 states, which I think would cover all states we've seen them in.

Stalled: The discussion in the RFC has plateaued without a definitive answer. This should be be given one last chance to get back into action and find an answer and then be resolved.

Being Implemented: It's happening, just not right now, so it can be moved into tickets and the RFC issue closed.

[zephraph]

One other idea I had:

What if we added a github checklist to the RFC template with all the potential resolutions. This a least makes sure the resolution states are always in front of the author. Once an RFC is resolved, we could just check one of those states.

[zephraph]

@orta I'm 👍 with adding the Being Implemented state. I almost see stalled as a meta state of an RFC. After it's been set at stalled and time has elapsed it's just closed as Unresolved. An RFC can be stalled and open for a brief period of time.

[sweir27]

I'm generally 🙌on the idea of helping to push along our RFCs!!

The Being Implemented state feels like a slight smell to me, just because I'm not sure an RFC is the best place to keep track of work. I wonder if we should update our RFC template to communicate that the RFC is Resolved when a decision is made on the proposed path forward. The follow-up work should be agreed-upon but won't block resolution. (So the template can contain sections like: This can be resolved when... and Once this is resolved...)

Once the creator feels 👍 about the comments they've gotten on the proposal, they can close the RFC and move forward with the plan, either alone, as part of product teams, a practice, or a working group.

[dleve123]

My thoughts on comments already made:

1. I think a stalled state is a good prompt for action.
2. I also don't think it's useful to differentiate between the RFC author and a facilitator. If the RFC author feels like the RFC is important, then they should shepherd it!
3. I agree with Myk and I strongly disagree that 2. A lack of response from others is assumed to be positive indifference. – there are so many RFCs, Slack notifications, general inbound communication to presume that a lack of reply means that someone read and tacitly agrees. I think this is particularly problematic for when an RFC changes existing behavior of a team. I highly recommend us revisiting this assumption (although out of band from this RFC :)

---

Have we thought about adding a deadline for RFCs? That could help clarify when the RFC author would like resolution, and provide a forcing function for quick feedback.

[oxaudo]

I'm in a camp that silence means positive indifference. Or just absence of opinion one way or the other. Or not having enough knowledge/context to have an opinion one way or the other.
In a lot of cases for those RFCs I genuinely have nothing to add to the discussion that has not been said already and unless I have a strong opinion one way or the other - I'm selecting not to comment.

I do agree that there is an issue of making sure that people are given a chance to comment in case they have strong opinions and/or additional context to add. But considering that we specifically call out each RFC during the team wide stand up as well as there is an easy way to get summary of RFCs in slack - I think this issue is sufficiently addressed.

And as long as we communicate clearly the outcome of RFCs I think it's safe to assume that there were a broad agreement among people that had input and the rest agreed to follow the proposed changes if RFC was accepted.

[damassi]

I'm in a camp that silence means positive indifference. Or just absence of opinion one way or the other. Or not having enough knowledge/context to have an opinion one way or the other.

Second this.

[zephraph]

For the scope of this RFC, given the positive feedback for Stalled, I'm going to isolate just that and resolve the PR as accepted. For other changes to the RFC process, we can follow up with specific items.

Thanks for the thoughts and feedback everyone! It seems like there are other clarifications that we can add to our process going forward.

[zephraph]

Resolution

Acceptance of the stalled state.

Level of Support

2: Positive feedback.

Additional Context:

The stalled state itself had support, but other parts of the proposal did not. Scrapping those and keeping this scoped and simple.

Next Steps

Will create a ticket to add a peril rule governing the behavior of the stalled state.