Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC to describe the RFC process #1
The goal is to define a process to unblock issues and PRs where there is clearly a need or good contribution but no clear outcome. The hope here is that by putting down all the context it will help the community reach a consensus. I also want to keep the process lite-weight to avoid hindering the contribution process.
The proposal is mainly lifted from the Rust community. This is mainly a starting point for the discussion, we should probably adapt the RFC process to our community.
One of the big difference with our community is that we don't have paid members that can implement the RFCs. That makes it hard to "accept" a RFC and have it implemented without having a "champion" that first agrees to be working on this. So I propose that instead we should have the RFC submitter try to gain at least traction of one other community member.
There are also some open questions regarding the feedback process. What is the acceptable response period for a feedback?
Actions after merge:
Just a note, people seems to have started annotating their pull request / issues with the RFC tag:
I took the current list and sorted the issues / pull requests in 3 categories: Submittable, Draft, and Rejected. I evaluated these based on my personal opinion and the following criteria:
Submittable as RFC:
Draft (not actionable, or not described enough) RFC:
Rejected as RFC (should be an ordinary PR):
I also added NixOS/nixpkgs#10851 (submittable) and NixOS/nixpkgs#14000 (rejected) as additional examples. I classified NixOS/nixpkgs#14000 as rejected, even if the change might have been controversial, it did not had impact out-side the limited set of developers/reviewers of this code. It would have been a good RFC, but only as part of a larger plan to introduce overlays, or to add a better cross-compilation support, but not as a single set of commits.
I think this list is a good starting point to qualify precisely what belongs as an RFC or not, and help remove these RFC tags from existing pull requests / issues.
Looks good to me. The main remaining issue is that it leaves the decision procedure unspecified, but I agree we can leave that for now. The risk is that it creates the same problem as the current PR system (i.e. that PRs stay in limbo with no clear decision), but at least it's an improvement to require a general consensus, instead of the current situation where any of a few dozen committer can merge controversial changes.
Who should have write access to the rfcs repo?
Yes and not. For two different PR introducing similar changes, I have seen one stalling under controversial discussions, and the second one getting merged by another committer unaware of the discussion.
added a commit
this pull request
Mar 18, 2017
@edolstra I sent you an invite for the repo, this will let you move it to the NixOS org.
In regards to access, since RFCs are mainly a communication tool I would suggest just giving the same access as nixpkgs. I think that having a core team would be helpful to make executive decisions when necessary but that can be defined in another RFC along with their responsibilities and process to join/leave the core team.