RFC Process - update proposal

Proposal

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 Process Diagram

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:

RFC Timeline

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.

10 Likes

This all seems fine. The main difficulty in the past wasn’t with process though IMO, it was a lack of ability for Maidsafe to respond. Hopefully the larger team will help with this.

5 Likes

Yes, this was the main issue and did cause all RFC authors some frustration. If that happens now, then we can ping @DGeddes to chase people up. I think this will be much more effective.

5 Likes

Hi @happybeing,

@dirvine beat me to the punch while I was getting distracted by my massive lunchtime yogurt.

I’m hoping that the sins of the fathers can be pushed to the side and I can look to avoid them creeping in again by being a constant annoyance by banging on about RFC status at each and every opportunity.

DG

4 Likes

@DGeddes I’m sure you are very capable. :wink:

2 Likes

So far I’ve been doing half of Teddy Roosevelt’s famous foreign policy but the other half is there in the waiting :wink:

1 Like

Hi all,

I have updated the text on the GitHub repository.

Looking forward to driving this forward!

DG.

1 Like