Genesis RFC

[crtahlin]

The RFC for specifying the process of RFCs in general has been commited under code "0000", aka genesis RFC.

I'm opening the floor for comments. The sub-team to finally approve it would consist of @nugaon @plur9 and @crtahlin.

Specific topics to address and comment on:

• should all FDS tooling be included in this process or just Fairdrive stack? I would keep all tooling (repos in FDS) included, although the Fairdrive stack/Protocol RFCs would be specifically called Fairdrive improvement proposals or FIPs.

• how many sub-teams would we need? I see the need currently for a

1. process sub-team (tackling this document)
2. Protocol sub-team
3. Quality assurance sub-team

Each sub-team has a specific (optional) document, where the process can be specified in more detail. (We would populate those in the next steps.)

[nugaon]

I like this genesis document, good wording.

some comments regarding to the genesis RFC:

The life-cycle states are a bit vague from the text.

Fairdrive protocol changes,
FDS quality requirements changes.

These links are dead.

Additions only likely to be noticed by other developers-of-FDS, invisible to users-of-FDS.

what does it mean concretely? If something is noticeable by developers of FDS then it should affect for users of FDS as well, shouldn't it?

The most common preparations for writing and submitting an RFC include talking the idea over on our [TBD], discussing the topic on our [Github Discussions], and occasionally posting "pre-RFCs" on the developer forum.

Where is the developer forum?

Reacting to your question, I would not mix the needs towards the toolings with the protocol proposals. It can be created within their own repository with using unified issue templates if needed.
Also, it is not really clear for me when a developer should write an RFC about the FD toolings or just create an GitHub issue there.

Regarding to the template:
the header consists of an Issue and RFC PR that I don't completely get. There is no requirement to have an issue to every RFC and every RFC should be submitted as PR, so I don't see why it is needed to mark there.
Nevertheless, it could include the gotten RFC number and the name of the author with their contact info.

Its format may be better in this form:

---
FIP: <to be assigned>
title: Fault tolerant and flexible streaming of feeds
author: Viktor Levente Tóth (@nugaon)
status: Draft
created: 2021-09-13
---

The license could be also placed at the end of the template document.

[crtahlin]

"The life-cycle states are a bit vague from the text."
Yes - that bothered me also, though it seems Rust (our example) manages to do it that way. But let's define them, taking our process into account, as well as an existing lightweight process.

Informal discussion phase, if the authors feel the topic could be a valid RFC, they issue a PR. The document goes through following phases.

DRAFT : Author(s) are still working on the document. (Document enters as PR at this state.)
DISCUSSION : Author and the relevant sub-team as well as possibly larger audience, build a consensus about the topic.
One of the sub-team members will issue a motion for "final comment period" and a disposition proposal (MERGE, CLOSE, POSTPONE) with all sub-team members approving start of this phase.
FINAL COMMENT PERIOD (FCP): The state is advertised widely and all stakeholders can issue comments.
After discussion / amendments the document can become:
CLOSED : Removed from the process as not suitable as an RFC.
POSTPONED : Might be suitable as an RFC, but current work has stopped (for an unspecified period of time).
Or merged, in which case the PR is merged and the document becomes:
ACTIVE : The RFC was accepted.

As we plan to do reference implementations, we should add the following phases, possible from after the document becomes ACTIVE.
IMPLEMENTED : A reference implementation exists.
DROPPED : No longer relevant.
SUPERSEDED : A newer, more relevant document exists. (I should be referenced.)

I will continue to add this in a sensible way to the document.

These links are dead.
Fixed with 1f0ca5a.

what does it mean concretely? If something is noticeable by developers of FDS then it should affect for users of FDS as well, shouldn't it?
True, since its users are also developers. Removed the sentence.

Where is the developer forum?
We don't have one currently. Reworded.

Reacting to your question, I would not mix the needs towards the toolings with the protocol proposals. ...
Yes, that would be cleaner. I will remove everything but the protocol from the RFC process ...

Formating the header
Agreed, changed.

License
Added CC0 waiver at bottom.

[crtahlin]

To make it clearer, I think these states would be needed / we had in mind for FIPs:

@nugaon , would you agree?

[crtahlin]

All the text has been rewritten, simplified, CC0 added. The diagram is now included.

[plur9]

Looks great!