RFC: Process for Creating RFCs

[waxlamp]

This is the first official Multinet RFC. It lays out the procedure for creating RFCs, soliciting feedback, and making them official.

TODO:

• [x] require adding the "rendered" link to the PR description

Rendered

[waxlamp]

Looks like GitHub is no longer allowing requests for multiple reviewers without upgrading :angry:

@JackWilb please check this out and review.

Anyone else on the team, please feel free to review as well!

[JackWilb]

Looks like GitHub is no longer allowing requests for multiple reviewers without upgrading angry

@JackWilb please check this out and review.

Anyone else on the team, please feel free to review as well!

Weird, it let me add myself as a reviewer

[waxlamp]

Looks like GitHub is no longer allowing requests for multiple reviewers without upgrading

@JackWilb please check this out and review.

Anyone else on the team, please feel free to review as well!

I found out this morning that those limitations are connected to non-paid, private repositories. So I just made this repository public. I don't have any issue with our thinking on Multinet design being public, seeing as it's an open source project to begin with.

[waxlamp]

Generally looks good, I've got two main concerns:

1. I worry that if we want to just document something, without it necessarily being an RFC, that we'll be discouraged from placing that here, as we would then need to formalize it. Does it makes sense to have a section for miscellaneous notes, and then a section for RFCs? An example of something that could be represented in a misc note would be the DNS entries. This leads me to my next point...

I would argue that documentation that is specifically not an RFC should not be placed here.

If you mean that you want a section in this repository for unstructured notes, etc., I might be convinced that's a good idea, but I'd prefer to think we should simply fold that sort of thing into our actual documentation (in the multinet-docs repo).

2. How should we handle sensitive information? I'm not sure if we have much of that, or if there's an interest in keeping that information here, but it would keep our internal docs centralized. If we keep sensitive information here, then we're not able to effectively share this repository with non-collaborators. I'm not sure if there's a desire for that or not, or if we would simply give someone access if they needed it. However it seems to me that these would more represent developer docs, and that anyone trying to develop plugins/spin up their own instance would find this repo useful.

We shouldn't keep any sensitive information on GitHub (even in a private repo, commits are not really secret in the sense that we would require for actual sensitive info). I think sensitive info should be kept in whatever safe spots are appropriate: LastPass for passwords, etc.

However, we can still keep our docs centralized by collecting pointers to sensitive info in, e.g., our developer docs. The dev docs can mention things like "the Heroku password is kept by Roni Choudhury in a LastPass account; contact him if you need it".

[jjnesbitt]

If you mean that you want a section in this repository for unstructured notes, etc., I might be convinced that's a good idea, but I'd prefer to think we should simply fold that sort of thing into our actual documentation (in the multinet-docs repo).

Good point, that addresses my concern.

We shouldn't keep any sensitive information on GitHub (even in a private repo, commits are not really secret in the sense that we would require for actual sensitive info). I think sensitive info should be kept in whatever safe spots are appropriate: LastPass for passwords, etc.

However, we can still keep our docs centralized by collecting pointers to sensitive info in, e.g., our developer docs. The dev docs can mention things like "the Heroku password is kept by Roni Choudhury in a LastPass account; contact him if you need it".

That sounds good to me :+1: