Zebra: Add a section on how the RFC process works to the book

[teor2345]

we should probably add a section on how the RFC process works to the book but we've definitely finished figuring out our design process.

_Originally posted by @yaahc in https://github.com/ZcashFoundation/zebra/issues/569#issuecomment-673750033_

[nathan-at-least]

Hello, glad to see this issue!

I had one question after skimming over the RFC 0000 template and not seeing it addressed there:

• How does the scope of Zebra RFC relate to Zcash ZIPs?
• How does the process and collaboration of Zebra RFC relate to ZIPs?

I started wondering about this while reading about Stolon and wondering: "hm, why not make this a ZIP?"

My personal suggestion is that there need not be a hard-and-fast rule, and the two processes can proceed with very loose coupling, with ZIPs/RFCs refering to each other where useful. So for example, I would expect a Stolon ZIP to appear sooner or later and it can refer to or quote the RFC.

Does this match the thinking of the Zebra RFC contributors? Now I'm off to link to this comment over in the ZIP context.

[daira]

I propose to reserve ZIP numbers 600-999 to correspond to Zebra RFCs 0000-0399. That is, any ZIP that is basically a copy of an RFC, and is potentially implemention-specific, will have that number mapping. Note that ZIP numbers 400-599 are already reserved for implementation-specific ZIPs.

[yaahc]

How does the scope of Zebra RFC relate to Zcash ZIPs?

This is just my take and not the opinion of the entire Zebra team but my preference would be that Zebra RFCs are an internal process used by our team for design discussions and documentation and are specific to zebra the software rather than zcash the protocol. The reason we introduced the RFC process was primarily to help with coordinating discussions in an almost entirely async working environment, not to give these discussions any sort of official weight.

My personal suggestion is that there need not be a hard-and-fast rule, and the two processes can proceed with very loose coupling, with ZIPs/RFCs refering to each other where useful. So for example, I would expect a Stolon ZIP to appear sooner or later and it can refer to or quote the RFC.

:+1:

I propose to reserve ZIP numbers 600-999 to correspond to Zebra RFCs 0000-0399. That is, any ZIP that is basically a copy of an RFC, and is potentially implemention-specific, will have that number mapping. Note that ZIP numbers 500-599 are already reserved for implementation-specific ZIPs.

I doubt there will be enough RFCs being converted to ZIPs to justify this.

[dconnolly]

not to give these discussions any sort of official weight

That is, outside of Zebra the software project. Discussions and proposals about Zcash the protocol are the domain of ZIPs which do have 'official weight' as moderated by the ZIP editors, etc.

One could replace all instances of the name 'RFC' with 'design document' here, as that name is entirely copy-pasted from the Rust process of the same name. We are not 'requesting comments' from anyone except each other, the engineers writing Zebra software, as opposed to 'the Zebra community' or 'the Zcash community', so I can see why the name and its relationship to ZIPs may be misleading.

[daira]

Right, but I think part of the confusion is that some Zebra RFCs, such as the Stolon RFC for example, are definitely describing protocols that other clients might want to interoperate with.

[nathan-at-least]

I understand that Zebra RFCs are a format+process focused on Zebra design & development, and so I expect for most RFCs this issue won't ever come up.

I still think it's likely to come up in some cases. The case study of Stolon is useful here:

• as it matures and becomes adopted across codebases, we'll want zcashd and various light wallets and so forth to follow that protocol (esp. because where there's a privacy network effect we want consistent usage across the ecosystem),
• meanwhile it's natural and better, IMO, for something like Stolon to arise out of a smaller team/process and then spread out, so I definitely don't want to interfere with that (so for example, I wouldn't personally like a restriction like "if anything might interact outside of Zebra itself it should be in a ZIP rather than an RFC").

I just thought it might be useful to bring up this intersecting grey area as soon as I noticed it. I'm also fairly comfortable leaving cases like this unspecified. I think for me the absolute minimal improvement is just to make sure the ZIPs and RFC instruction docs point out the existence of the other with a quick blurb, just so new-comers learn about them.

(Tangential topic: I would like to see zcashd adopt some similar kind of design process & format, and it would have the same kind of "grey area intersection" issue.)

[dconnolly]

I think for me the absolute minimal improvement is just to make sure the ZIPs and RFC instruction docs point out the existence of the other with a quick blurb, just so new-comers learn about them.

If we deploy Stolon and by our experiments with it think it is worth proposing as a ZIP, we will do so. In such a ZIP, we will point to code and whatever other documents about the Stolon design and experiments that are useful to inform and motivate the ZIP, which may or may not include the Zebra RFC.

But Zebra RFCs are specific to Zebra. We do not want to encode things about our project-specific design process into/within the ZIP process, like number allocations. The 'coupling' between a Zebra RFC and any future ZIPs should be minimal at best, the same level as a link to a GitHub issue or a webpage for another project, nothing formal.

[daira]

Ok, understood.

[nathan-at-least]

+1 for minimal entanglement. Thanks for humoring me and hope this wasn't too much noise.

[teor2345]

No worries at all - it's good to be upfront about how different processes interact.

Otherwise, if we all make different assumptions, it could lead to a lot of confusion.