I'm hoping to update the current SAFE RFC process to reflect the current RFC process used in the Rust language. My argument is that the current process was based on the original Rust process and it makes sense to me that we update it to the current method.
So what's changed?
How I'd summarise the changes:
- Added some more guidance on reviews and edits to the RFC.
- Introduced the 10 day FCP (Final Comment Period) concept.
- Dropped mention of single Shepherd and refer more to the project subteam (multiple shepherds).
- “Postponed” label: rejected (for the time being) on grounds of priority
Read more about the processes here:
What will the new process look like?
In all honesty it's not that much different to what was in place: Someone thinks about their proposal; discusses with others in the community to see if the idea is something that they could get behind; creates an RFC proposal document; the development team triage the proposal (thumbs up/thumbs down); there's a discussion phase where the community have a chance to comment on the proposal which gets updated in response to the comments; there's a final decision taken on what to do with the finalised RFC; it gets scheduled for implementation or rejected.
I've had a stab at showing this here:
RFC Example timeline
As an indication of how long I'd see the process taking I've thrown a rough little sample timeline together here:
The review period is hard to pin down to a time scale as discussions could take some time but a nominal figure of 10 days has been used here to give some kind of indication as to how long an RFC could take to go from submission to merge. In practice I’d imagine that things could go a couple of ways:
- an RFC may be well formed and agreed with during the prep phase and as such the team could push for FCP during the triage following submission.
- discussions could go on for quite some time (which I guess is why the dev team will push for the FCP).
RFC Document Template
At the moment I'm not suggesting changing the format of the
0000-template.md document to mirror the Rust one which has i) two design sections [guide-level and reference-level] while we've got the simpler one section [detailed] and ii) an additional 'Prior art' section. I'm not opposed to changing the content if anyone wants to argue the case. Have a look at the two options:
Cutting to the chase
Does this sound okay to everyone? I'd be interested in your opinions.