3 ms·
One twist on this concept that we've used effectively at Mavenlink is that there is no approval step. RFCs function more as a communication and participation p
by ahuth 8y ago
One twist on this concept that we've used effectively at Mavenlink is that there is no approval step.
RFCs function more as a communication and participation process before an effort starts, and approval just hasn't felt like a necessary part of that.
Our org is around 50 engineers and has a very collaborative culture already, and maybe approval would be necessary for other environments.
Another benefit from the RFC process in general is that it's very easy for technical leadership and management (as well as everyone at the company, really) to see all the technical efforts underway.
- weliketocode 8y agoI guess it depends on what you consider approval. Are all comments being addressed before the RFC is worked on, and are all RFCs receiving regular comments? In a small team with decent communication, RFCs can be prioritized somewhat easily. But they still should be tracked so that you can which are RFCs are being written, currently receiving/addressing comments, and which are being implemented by the team.
- ahuth 8y agoGreat question! There's no enforcement mechanism, but I can't think of any examples of comments not being addressed before being worked on. Also, so far all RFCs receive comments (between 5 and 50). Tracking RFCs is a good point, and we do it by putting them in a git repo. The document itself is markdown, and comments happen on a pull request (which also helps with notifying the entire team). So RFCs with an "open" PR are the ones currently soliciting feedback.