RFC 1: The Quilt RFC Process

Forkk commented 3 years ago

This RFC describes the process for handling RFCs for the Quilt project.

Since we haven't created any particular teams yet, and this will affect every team, we should have all members of the project in consensus before this particular RFC is approved.

Once that happens, the README should be replaced with the contents of the "Quilt RFC Process" section.

See the rendered document here

Forkk commented 3 years ago

The template for future RFCs has been added. Here is the rendered version. Obviously it is also open to comments and suggestions.

ToffeeMax commented 3 years ago

I am seeing no overall mention in the template document/ rfc process list of mentioning if an RFC alters another?

I getting a sense from a few statements that this is implied that it could happen/ is wanted that one RFC can change another. Do we want to include in the template a section on "Alters RFC-" and some more specifics on how that would work in practice?

Scotsguy commented 3 years ago

I am seeing no overall mention in the template document/ rfc process list of mentioning if an RFC alters another?

I getting a sense from a few statements that this is implied that it could happen/ is wanted that one RFC can change another. Do we want to include in the template a section on "Alters RFC-" and some more specifics on how that would work in practice?

RFCs just describe features, they are not the features themselves. If I want to edit the quilt mod json format, I wouldn't say "amends RFC 2", I can just say that my RFC edits the quilt mod json format.

ToffeeMax commented 3 years ago

I am seeing no overall mention in the template document/ rfc process list of mentioning if an RFC alters another? I getting a sense from a few statements that this is implied that it could happen/ is wanted that one RFC can change another. Do we want to include in the template a section on "Alters RFC-" and some more specifics on how that would work in practice?

RFCs just describe features, they are not the features themselves. If I want to edit the quilt mod json format, I wouldn't say "amends RFC 2", I can just say that my RFC edits the quilt mod json format.

This is a fair point; I am thinking in terms of Pythons "peps" here and misremembered what I was aiming for.

Slightly related, should we have a "replaces" flag in a document if it does so? eg here:

This building on your "Replaces/ Edits Quilt Mod Format Replaces: RFC-0002"

Scotsguy commented 3 years ago

Slightly related, should we have a "replaces" flag in a document if it does so?

We don't have any other metadata, so I doubt this would be particularily useful. Just say it in the text. Plus, PEPs have slightly different semantics than RFCs.

Forkk commented 3 years ago

Rust RFCs do have metadata. I didn't add any to the template because I wasn't sure what it would be used for, but it's probably something we should consider.

i509VCB commented 3 years ago

My concern with the PEP like replaces scheme is it allows for issues where some older RFC may not refer to the proper new RFC for a specific topic. I think for things that involve schemas, formats, specifications and protocols should be put in a readme in their own repository or we maintain a central schema, format, specification and protocol repository.

gdude2002 commented 3 years ago

Haven asked me to bring this over from Discord, so everything's in one place

It seems overkill and potentially more harmful than helpful:

Contributors are required to be able (and have a willingness) to write RFCs, which people living in areas with lower standards of education, higher rates of poverty, or just without native English, will have trouble with

The RFC process is too slow and means that development will slow to a crawl around anything non-trivial, especially with the 10-day wait "after enough discussion has happened"

RFCs are too technical and impossible to format in a manner that suits things like community policy, and the (essentially) two-week wait to rewrite parts of community policy to fix issues is far too much

The RFC process discourages experimenting and implementation-first approaches to development, requiring RFCs to be written before implementation happens (otherwise the PR is just going to be closed) - why try things out if the RFC ends up going in another direction?

RFCs are not immune to bikeshedding, they just move the burden to an internal team - an approach needs to exist where RFCs can succeed without every member of a team approving them - and even then, how do you decide when "enough discussion has happened"?

There's been discussion since then, but I don't have time to summarize it at the moment

Haven-King commented 3 years ago

I am moving this back to in-review, and would like additional comments on the revised portions.

TheGlitch76 commented 3 years ago

In general, I feel like I am no longer in love with the RFC process idea for Quilt. The goal of Quilt, as I see it, is to encourage meaningful discussion. This process does that quite well. However, the RFC process does not follow the fundamental why of having this goal, and in fact goes against what I believe the true purpose of Quilt is. Though we say our purpose for this is to bikeshedding, the real reasoning behind this is to make a system where contributing isn't overwhelming. In Fabric, this presents itself as endless arguing and bikeshedding with nobody ever giving a final say, which slows progress of PRs to a crawl and discourages entire systems from ever being attempted. The RFC process is going to make this issue worse, just in a different way.

Comparison

A Fabric PR for a large module looks something like this:

Write an implementation
It gets teared to shreds
Rewrite it
Endless arguing over if your new solution is good enough
If you spend hours defending yourself the PR may enter a week-long last call, but this just needlessly delays your PR because all meaningful discussion has ended (see: API API) before last call is entered.
Otherwise your PR is ignored or goes into review hell.

This is how I predict a similarly large PR for Quilt going:

Prototype an implementation
Spend at least an hour (significantly longer if you are not a native speaker, or just not good at writing what is essentially an essay) writing an extremely long-form justification
It gets teared to shreds
Repeat steps 1-3 indefinitely, except it takes twice as long now compared to Fabric
Spend weeks defending it and telling others off for being unproductive (e.g. speculating implementation details)
After consensus is reached (or forced), wait an additional ten days where no actionable concerns are raised
Write your implementation, again.
Spend weeks defending the implementation of your accepted idea, because the API is mostly set in stone now.
After consensus is reached (or forced), wait an additional week where no significant concerns are made.

Alternatives

I believe something akin to RFCs can be a useful way to develop ideas, but currently this system makes any contribution larger than a bugfix or small addition from new developers extremely unlikely, and activating that contributor (making them want to come back) even more rare.

Format specifications and Community Policy

These can be handled by simply making a PR with the content of the specification to the specifications repo (as per RFC 4, which is a perfect example of what I am saying about slowing down contribution). There is no point in reviewing a specification twice, so all discussion can just happen there.

New modules, new major systems, etc.

In the case that comments are wanted for some new API or system, this can be handled by creating an issue in the place it is most important. For example, the QSL (meta or mono) repo can have issues if a new team wants to be created for a library, Quilt Loader can have an issue for ASMR, etc.

Some of the ideas currently used in the RFC process--making final decisions with a dedicated final comment period, heavily regulated discussion, can still be accomplished in issues. We are a team of twenty, not two hundred, and we don't need to require this level of formality for development.

Haven-King commented 3 years ago

You may have noticed that in my revised version the term "bikeshed" is not mentioned even once, and in fact avoids specifying anything related to technical projects. RFC's should really be primarily for organizational changes. Technical teams may specify different processes, which should be done in a separate RFC. Such processes may make use of issues, PR's, RFC's, or any combination of such systems.

Earthcomputer commented 3 years ago

I think RFC's are mainly appropriate for large systems. For small systems, RFC's should be reactive, not proactive, i.e. if a non-large change triggers significant debate, then an RFC can be made for it.

Where an RFC is needed, contributors should have the option readily available to have the RFC written entirely for them, only having to answer questions from the writer for clarification.

Most important of all, new contributors need to be aware of the RFC system, and they need to be aware of how easy it is to get an RFC written for them, if needed, and they need to be aware of which situations it's needed and which it isn't.

QuiltMC / rfcs