I read this in earnest and think it's pretty cool. I really like Bryan Cantrill.
I couldn't fully grok the flow between ideation and prediscussion. I found that a little "fine grained". My understanding was hindered by the typos in the ideation section.
Thanks for the kind words! This process is actually the work of a bunch of folks, and the result of quite a bit of iteration at Oxide. The difference between ideation and prediscussion is both the maturity of the idea and its ownership: an RFD in ideation will be very loose (and, to my earlier comment, the kind of thing that one might find historically on a Wiki) and without an owner per se. It's essentially a way of trying to create a yet-lighter kind of document for things that are very primordial. We haven't used it too much, but all of this is still pretty young, and over time I would expect more ideation RFDs.
As for the typos: thank you! Fixed them in both the RFD and in our blog post!
Interesting idea. I can see this working with a small team of the right people, but I can also see it being counterproductive in some ways.
Specifically, the amount of process described in this document is massive. Printed out, it becomes 9 pages of process. Surely competent engineers can pick up on it quickly by following the guide, but what benefit does all of this process have over simply creating a Wiki page and having each team member write their discussion in their own section?
These things always feel fun at small companies within the teams that conceived them, but it's easy to lose track of how unwieldy these process- and tech-heavy solutions to simple communication problems are for newcomers.
So, believe it or not, we have spent quite a bit of effort trying to make this process lightweight -- and having gone through it a bunch myself (and having a strong aversion to unnecessary process!), it doesn't actually feel unduly arduous. The reason a wiki won't work for us: it's far, far too loose for describing the things we're building and discussing the trade-offs. We're a computer company[1]: we are building a ton of hardware and low-level systems software that needs to be pretty well described and carefully considered (with revisions formally tracked). It's not aerospace or biomedical devices, but... it's also not a SaaS that is amenable to an MVP. So we do need more formalism than might be suitable elsewhere.
In terms of newcomers: I actually think that's a tremendous strength of the RFDs: unlike many startups, we have a lot written down -- and newcomers (and indeed, even prospective Oxide employees) are able to read the stuff that often exists in people's heads.
All of that said, it's definitely not perfect! If we could get a Google docs (or equivalent) in which the underlying artifact were stored as AsciiDoc and every modification appeared as a git commit (and the comments themselves were also tracked via a git commit), that would almost assuredly be better than the GitHub + custom infrastructure we've built. But already having outrageously broad ambition, we drew the line at not reinventing design document management... ;)
4 comments
[ 2.7 ms ] story [ 24.4 ms ] threadI couldn't fully grok the flow between ideation and prediscussion. I found that a little "fine grained". My understanding was hindered by the typos in the ideation section.
As for the typos: thank you! Fixed them in both the RFD and in our blog post!
Specifically, the amount of process described in this document is massive. Printed out, it becomes 9 pages of process. Surely competent engineers can pick up on it quickly by following the guide, but what benefit does all of this process have over simply creating a Wiki page and having each team member write their discussion in their own section?
These things always feel fun at small companies within the teams that conceived them, but it's easy to lose track of how unwieldy these process- and tech-heavy solutions to simple communication problems are for newcomers.
In terms of newcomers: I actually think that's a tremendous strength of the RFDs: unlike many startups, we have a lot written down -- and newcomers (and indeed, even prospective Oxide employees) are able to read the stuff that often exists in people's heads.
All of that said, it's definitely not perfect! If we could get a Google docs (or equivalent) in which the underlying artifact were stored as AsciiDoc and every modification appeared as a git commit (and the comments themselves were also tracked via a git commit), that would almost assuredly be better than the GitHub + custom infrastructure we've built. But already having outrageously broad ambition, we drew the line at not reinventing design document management... ;)
[1] https://www.youtube.com/watch?v=vvZA9n3e5pc