Iggy RFC process

[justinmclean]

Hi,

#4385 adds an RFC process to Iggy. It adds rfcs/README.md with the process, an RFC template, a change to the pull request title check, and an update to CONTRIBUTING.md. This discussion is to decide whether we adopt it and what to change.

The idea is that a substantial change gets a written design that is reviewed and discussed before implementation starts. Substantial means things like a wire protocol or on-disk format change, a new storage or replication model, removing a feature, or a large SDK addition. #4404, a tiered storage RFC, is an example of what one looks like.

Some questions to start with:

• Do we want an RFC process, or are issues and pull requests enough?
• Is the bar for needing an RFC in the right place?
• Does it work to debate the design in a discussion and keep editorial review on the pull request?
• How should we decide an RFC is accepted?
• Is anything missing from the template?

Please read rfcs/README.md in #4385 and comment here.

Kind regards,
Justin

[numinnex]

The template proposed #4385 is fairly similar to how rust-lang works with couple of small adjustments. Ideally we would like to create a process that minimizes the amount of bureaucracy while preserving the rules of ASF. If you'd like to propose any changes to it keep those goals in mind.

[djanand]

Do we want an RFC process, or are issues and pull requests enough?

Right now a design conversation lives in a thread/discussions. To address substantially changes I'm inclined towards using RFC (IEP-Iggy Enhancement Proposal).

Is the bar for needing an RFC in the right place?

I think we should let maintainers/committers/PMC wave something through. A precise bar moves the argument to whether a change qualifies, which is a worse argument than the one about the design.

Does it work to debate the design in a discussion and keep editorial review on the pull request?

Yes and perhaps some leg-work/socializing of issue within discord or discussions as a pre-cursor. The gap is what happens after. Implementation will prove some part of RFC wrong, and there is currently nothing that says so. I would say add a status field to header, something like Draft, Accepted, Implemented, Superseded, and a convention that an RFC gets amended rather than left behind when the implementation diverges.
Where should a draft live while it is still changing shape? A PR works but line comments orphan when sections move. A wiki page marked draft, the way CEP-66 does it, keeps amendability without putting early feedback somewhere unarchived. Is there an Iggy space on cwiki, or do we keep RFCs in the repo as the header implies?

How should we decide an RFC/IEP is accepted?

Lazy consensus works IMO. Sits for a defined window, no objections means accepted. Keep a formal vote in reserve for when there is actual disagreement, rather than making every RFC pay the cost of the one that turns out contentious.

Is anything missing from the template?

IEP shepherd (PMC/Committer driving it), as a header field ?