Implement an RFC process

[kamalmarhubi]

We have a couple of issues that are important to how nix will play out but which are kind of idle. In particular, I'm thinking of:

• #190 Figure out the future of nix
• #221 Revisit passing of strings: redesign and replace NixPath

In both of those issues, there's a discussion that's been going on in fits and starts for several months. There's no consistently updated "here's what we'll do" post to move towards a conclusion. I'm worried it'll be months more before we make some decisions!

Another potential place to use them would be for deciding on the evolving API conventions.

For an example of a smaller project using RFCs, the intermezzOS OS (in Rust) has an RFC repository. The first RFC is a short overview of some benefits of RFCs.

If there's consensus, I'll set up an RFCs repository under the nix-rust org.

[kamalmarhubi]

ping @nix-rust/nix-maintainers

[kamalmarhubi]

maybe that ping didn't work. ping @posborne @fiveop @utkarshkukreti @arcnmx @carllerche :-)

[fiveop]

Do I understand it correctly, that the final RFCs would be the documentation of the decisions and their content. Because that might be a bit hard to wade through as a contributor. I would prefer if we see the final RFCs as documentation of the decision, but that we also document what was decided in the appropriate place (like the CONVENTIONS.md). These places can and would be edited for quickly finding information, wheres the RFCs are usually just ordered chronolocically and all the content that describes the decision process is certainly of interest (and sould be kept!), but not at all times.

[kamalmarhubi]

@fiveop thanks for commenting, those are some really useful suggestions. Based on what you're saying, how about a process where:

• we have an rfcs repo where discussions happen on pull requests as in https://github.com/rust-lang/rfcs
• an RFC is created as a pull request on the rfcs repo
• once accepted by consensus from the core team, updates are made to the CONVENTIONS.md file or other relevant main repo documentation "immediately" (before necessarily doing implementation work on the RFC content)
• implementation work or adaptation of existing code to match the RFC can progress at a different speed

This gets us a process where decision can be made, and where the content of the decision still shows up in the main repo. The PR model also gives us a way to clearly accept a proposal: it gets committed to the rfcs repo. It also model lets us keep the "current" suggestion of an issue up to date: the author updates the content of the pull request. This is a problem I have right now with #190 and #221 in particular: it's not clear what is even being proposed anymore!

If this sounds reasonable, I'll create an rfcs repo, and write up a "bootstrap" RFC that documents the whats / whys / and so on of RFCs similar to the intermezzOS bootstrap RFC. We can then come to consensus about what that should be and move from there.

Sound good?

[fiveop]

Yes, go ahead. And we could retroactivly convert our decisions about our conventions in accepted RFCs in that repository, for completeness sake.

[posborne]

I'm on board 👍

[kamalmarhubi]

I've created the RFCs repo and the first RFC to bootstrap the process. Please take a look!

[fiveop]

You bootstraped it. Now we write the rfcs ;)