Establish the RFC process

[foolip]

Summary

With the wpt core team now in place, this repo will hold the process for making substantive changes. This first RFC is about establishing the process itself, to give a chance for comments on that before beginning to use it.

Motivation

web-platform-tests/wpt#11473 is the background for how the core team was established, and why we need a governance project.

Details

Please review these files:

• https://github.com/web-platform-tests/rfcs/blob/master/README.md
• https://github.com/web-platform-tests/rfcs/blob/master/ISSUE_TEMPLATE.md

[jgraham]

I think 1 week for an initial decision may be too short? Possibly it should be 2 weeks without any signal that times out the process, but with the possibility of wide agreement in less time? I'm not sure.

[foolip]

It's certainly not uncommon for someone to be away for a week so that they'd miss RFCs if the period is just one week, but I wonder if we can rely on others to spot when something is likely controversial and extend the comment period for those cases, rather than shortening it for the trivial?

[foolip]

I just added "As a last resort, the core team may decide using a 2/3 majority vote." to README.md based on previous discussion.

[foolip]

@web-platform-tests/wpt-core-team please review.

[zcorpan]

If something is non-controversial and trivial, does it need to use the RFC process?

I think 2 weeks from the time the issue is created is reasonable, and people can ask to extend if they need more time.

[foolip]

If something is non-controversial and trivial, does it need to use the RFC process?

The idea is that the conditions in https://github.com/web-platform-tests/rfcs/blob/master/README.md#when-to-use-the-rfc-process should filter out the non-controversial and trivial.

[gsnedders]

The idea is that the conditions in https://github.com/web-platform-tests/rfcs/blob/master/README.md#when-to-use-the-rfc-process should filter out the non-controversial and trivial.

I think that:

• The "substantial changes" comment should be under the "When to use the RFC process" heading.
• Some examples of what doesn't need an RFC would be useful.

[foolip]

My concern with two weeks as the default is that there will be many cases that aren't controversial, but just need people to know about the change. Most of the examples in https://github.com/web-platform-tests/rfcs/blob/master/README.md#when-to-use-the-rfc-process can be like this, where as long as we've confirmed with all downstream users they're OK with it, it's good to go.

To avoid having some threshold of consensus for when 1 week is enough instead of a default 2, how about if anyone asks for the comment period to be extended, even if they themselves don't have concerns, then it's 2 weeks?

[foolip]

@gsnedders, I sent #2 for your comments, please review.

[foolip]

All, I've sent #3 with my proposal for how to extend to two weeks in cases where needed. Can someone review?

[foolip]

For this RFC itself, let's go with two weeks an consider it done on Jan 28.

[foolip]

Alright, both PRs are merged so the state on master is again good for review if anyone's coming fresh to the issue.

[Ms2ger]

The way I read it, every issue that doesn't reach substantive agreement within two weeks would be escalated to the core team as a matter of policy. Does that make sense in a case where there's ongoing discussion in the issue that's likely to reach consensus soon anyway? Maybe we should just add a note that the core team can defer the issue back to the issue tracker for some well-defined period.

[foolip]

Good point, "A decision should be made within 1 additional week" doesn't really work. As long as real discussion is going on and the RFC sender thinks it's productive, it should just keep going. But someone saying "I disagree" every week on the issue shouldn't extend it in perpetuity.

How about if we make it the RFC sender's call when to escalate, saying only that the minimum time of discussion is one week, and that the core team may also defer back to the issue for up to... 4 weeks?

[jgraham]

I don't think it should be phrased in terms of timeouts, but in terms of whether meaningful new information is coming to light. "I disagree" isn't meaningful new information, but "there is this use case that hasn't been considered and has meaningfully different properties from the existing use cases" is. There is also supposed to be a rule that the arguments used to make a decision may only be those that have already been made on the issue, to ensure that everyone involved has time to consider all the points of view. In the case that a decision is required it seems like there should be a requirement on the core team to make a comment explaining which were the compelling arguments.

So in terms of the mechanical process, I suggest that at some point issues get tagged core-team:requires-decision and then we get to assess when the last new argument was made and whether everyone had a sufficient time to respond to it. If it's decided that such a steady state has been reached then a decision should be made, otherwise it should be deferred until such a time as the steady state is reached.

I also think "not now" is a totally reasonable decision for many things which should therefore be an explictly available option. For example if thing X is just accepted and there's a worry about the effect of X on Y which requires a decision it should be possible to defer Y rather than allowing process-abuse of forcing a decision before the interaction with X is clear.

[foolip]

Sorry, I didn't see the comment when it was made, came now to see why the discussion had died down. (It hadn't.)

@jgraham I think that makes sense. I've sent #4 trying to turn those ideas into wording. Everyone please review! In keeping with the wording there, let's extend the commend period for this RFC to one week after the last PR is merged, so no sooner than Jan 30.

[foolip]

Alright, #4 has been merged, so let's set February 7 as the new end time for this RFC. Then maybe we can get back to work on non-meta RFCs :)

[foolip]

I've sent #6, if someone wants to review that I can merge it tomorrow and we're done!