search

web-platform-tests / rfcs

web-platform-tests RFCs
76 stars 64 forks source link

Establish the RFC process #1

Closed foolip closed 5 years ago

foolip commented 5 years ago

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

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

Details

Please review these files:

jgraham commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

zcorpan commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

foolip commented 5 years ago

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 commented 5 years ago

@gsnedders, I sent https://github.com/web-platform-tests/rfcs/pull/2 for your comments, please review.

foolip commented 5 years ago

All, I've sent https://github.com/web-platform-tests/rfcs/pull/3 with my proposal for how to extend to two weeks in cases where needed. Can someone review?

foolip commented 5 years ago

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

foolip commented 5 years ago

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

Ms2ger commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/web-platform-tests/rfcs/pull/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 commented 5 years ago

Alright, https://github.com/web-platform-tests/rfcs/pull/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 commented 5 years ago

I've sent https://github.com/web-platform-tests/rfcs/pull/6, if someone wants to review that I can merge it tomorrow and we're done!