I would like to propose a tweak to the RFC process, specifically aimed at ‘minor’ RFCs.
Proposal
An RFC’s shepherd may decide that an RFC PR is minor, and in that case call for a final comment period of 24 hours rather than the normal week. The 24 hours should be over a working day. As well as the usual options, members of the relevant sub-team can request that the FCP be extended to the normal length of time (either because they think the RFC is not minor or for whatever other reason).
What is ‘minor’
An RFC is minor if it is a bug-fix or clarification of a previously accepted RFC, or is an RFC which we would normally say shouldn’t have been an RFC in the first place but was left open for some reason (e.g., adding a single non-controversial method to a trait). If in doubt, we should regard an RFC as not minor. For example, I think RFC 1052 is minor.
So, thinking about this a bit more, I’m wondering whether this will need to be “part of the process” on a regular basis, or whether it’s a relatively short term phenomena? I guess that we do regularly have diffs and corrections to RFCs – it seems like a good idea to have a fast track for such cases. I had originally imagined we’d make the edits with no ceremony at all, if there is general agreement and they seem minor enough…even a day-long call for comments probably implies that the period will start on a monday (when the subteam reports come out), which seems suboptimal.
There are also the “could-have-been-a-PR-but-on-the-other-hand-perhaps-not” type RfCs. Currently it’s either make a pull request (which anyone may accept), or go full out on a ~2 week long RfC. A middle ground may be desirable.
At the moment, I don’t think there is a way to distinguish a PR that contains a trivial bug fix (requiring no review beyond what the single reviewer might do), and a PR that deserves a wider review, but might not require a full RFC (the “middle ground” that @Manishearth mentioned).
Could one possible solution be to have a process in which a PR has elevated status and visibility? I don’t have any suggestions about how this might be implemented, though (I’m not sure a github issue tag would be enough)
While I think we definitely should clarify what warrants a full RFC (see a similar thread within the libs team), I’m dubious about the idea of a 24 hour long “final comment period”.
Basically, if we feel something warrants visibility and a chance to comment from the wider community, we should try to accommodate people with other commitments and so on, and I think the standard week-long period (together with appearance in status report) strikes a reasonable balance.
OTOH, if the subteam feels that something is minor to the point of not needing community review, and there is subteam consensus on it, I think it should just be merged immediately. It seems worthwhile trying to identify some criteria for what falls into this category (and, for that matter, what doesn’t need to go through the RFC repo at all; again, see the linked libs discussion for one way that might play out.)
Trying to do something in between just seems like the worst of both worlds – not as fast as merging outright, but paying lipservice at best to full community feedback.
Sorry, I don’t think I communicated well the part of the process I’m targeting. I’m not trying to do something ‘in between’, I’m trying to formalise the process for your “OTOH…” category. I think I perhaps have a different concept of the FCP from others in this thread. With the 24 hour idea, I was (implicitly) placing more emphasis on the time-limited nature than on the public nature. I believe that in these minor cases, the RFC PR being ‘out there’ is enough publicity.
Anyway, can we instead define what “subteam consensus … merged immediately” means? I found with RFC 1052, that trying to get unanimous approval from the sub-team is impractical. My goal with the 24 hour thing is as much a deadline for the sub-team as for the community. Perhaps we could have an ‘internal FCP’ of 24 hours for the subteam once the shepherd decides the RFC is ready?
Ahh, I see – sorry for the misunderstanding. In that case, I suspect this will vary quite a bit by subteam. Prior to subteams, the core team maintained a list of RFCs in an etherpad that were essentially in a FCP-like state, with r+, r-, or abstain for each member (where r- requires commentary on the RFC itself, of course) – basically a simple way of asynchronously gauging rough consensus within the team. It still required pinging people to put down their state, and in some cases knowledge that a given person was unlikely to be interested so things could proceed without them.
Part of the role we had envisioned for subteam leader was handling precisely this kind of thing – having a little bit more global view, sense for people’s availability and interests, and thus ability to say with reasonable confidence “consensus has been reached, let’s move forward”.
I’m not sure how formal all of this needs to be, nor how common it will be for us to be in such a hurry to merge an RFC/amendment, but maybe some of the above could be adapted. (It’s also useful, for meatier RFCs, for gauging when to enter the FCP in the first place.)
I like the idea of being able to fast-track an RFC. Although I would suggest perhaps that this must accompany a PR implementing the change (if any), so that any further discussion can move directly there and focus on implementation details.
I agree with @aturon that formalizing a 24-hour comment period for “easy RFCs” may defeat the purpose of the RFC process (gaining feedback). I also agree that this seems very subteam-specific as they will likely quickly develop an opinion on whether it’s a quick RFC or not. The only part I’d change is that I’d prefer to close the RFC entirely instead of insta-merge (but commenting saying an implementation is welcome). Now on the other hand if a PR is opened and gains lots of feedback about the design, I think it’s safe to ask explicitly for an RFC to get broader consensus.
An example to me of an RFC that is minor is RFC 1123, and I’d be fine just closing and saying an implementation would be more than welcome.