[RFC] Update the RFC process to promote faster and clearer resolutions about readme HOT 18 CLOSED

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.

from readme.

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.

from readme.

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.

from readme.

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.

from readme.

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.

from readme.

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

from readme.

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

from readme.

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?

from readme.

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?

from readme.

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!

from readme.

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.

from readme.

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.

from readme.

@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.

from readme.

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.

from readme.

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.

from readme.

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.

from readme.

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.

from readme.

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.

from readme.