Policy for reverting RFCs

In https://github.com/web-platform-tests/rfcs/pull/184 @jgraham reverted an RFC that was accepted according to our documented process, because "In the case of no substantive disagreement the RFC is considered accepted after 1 week."

There had been out-of-band communication and a commitment to review that I was not aware of, but that is not part of our process, and not all wpt core team members are in those meetings. Any wpt core team member should be able to look at an RFC and merge it if there has been no feedback in 1 weeks, or 2 weeks if an extension was requested.

I think our policy should be, and implicitly already is, that RFC cannot have substantial changes, including their removal, without a new RFC.

In this instance, I think that expedient post-merge review and sending PRs with suggested changes on top of what was already landed would have been the way to go about this. Those changes might have required to be an RFC if not trivial, but not necessarily for questions and clarification.

On the process itself, the timeout is and important to allow progress even when some WPT core members aren't able to review. Notably absent from the process is any explicit or implicit requirement that all browser engines should chime in on every RFC.

@jgraham what's your take on this, how can we improve going forward?

Start by reading the documented RFC process and the discussion in pull request 184, then review the comments here for the competing views on reverting accepted RFCs. Done would require an agreed policy for substantial post-acceptance changes, including removal, and documentation of that decision.