Thoughts on an RFD (request for discussion) process

[dontlaugh]

The Problem

The issues on this repo are quite active, but actual git commits aren't.

That's a problem. The longer discussion on an issue continues, consensus and resolution become harder to achieve. I believe that's because issues direct energy into unproductive areas. I believe this is this case even if the discussion is high quality. The discussions on issues in this repo are often high quality, but the UX of issues is a black hole that sucks energy.

Discussion on a PR is better than issues. A PR gives the reviewer an opportunity to discuss and resolve specific bits of language. Everyone on a PR is working towards a common goal: to make the PR more correct, less ambiguous, etc. Issues can achieve this, but the mental energy required is way higher.

Doing Things Differently

I'd like everyone to read the Oxide RFD process, and see what they think of it.

Some key differences with what we have now:

• Merging an RFD doesn't automatically sign you up for a new side job of implementing it end-to-end; it simply means an RFD has been reviewed, and the document that ultimately gets merged has value.
• Adopt a flat structure and a numbering scheme that's disconnected from issue numbers
• Redirect most of the energy going back and forth on issues towards collaborative editing and discussion on PRs
• RFDs can and should be edited after the fact; discussion can be revived; things can change

In practical terms, I think what this means for us is

• PRs get opened way way sooner
• We de-emphasize the notion of "solutions" in this repo, and instead focus on high quality writing, such as
  • Lucid, nuanced descriptions of complex problems
  • Good high level requirements
  • Good descriptions of architecture, whether existing or proposed
  • Language changes
• We de-emphasize the "who is gonna implement it" stuff

Concrete Example

Recently, Liz opened an issue that I think would be the basis of a good RFD. Here it is

#443

So imagine something like that, but as a file that lives here

problem-solving/
  rfd/
    0091-make-z-and-friends-dwim.md

---

The gambit here is that the RFD documents themselves deliver value by their very nature, because they've been collaboratively edited and discussed by community members. We already have lots of discussion (I see it on IRC and issues all day). This is a way we can leverage that energy even more.

[dontlaugh]

PS thanks to @coke for opening a PR to this repo. It got me thinking.

If people find this agreeable, I can kick things off with our own Raku version of RFD 1, the "RFD about the RFD process" :)

[niner]

I think this has merit and is worth a try!

[melezhik]

I took a brief reading on RFD doc, so the main idea as I see it is to instead of discussing / describe things in gh issue, propose an idea via git branch, make PR but still discuss in gh PR? In terms of discussion mechanism if you will, I imho, don’t see significant difference.

[melezhik]

Nobody prevents now to define changes or high level design document in any format and link it to gh issue in this repo, does not it?