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 st

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... ;) [1] https://www.youtube.com/watch?v=vvZA9n3e5pc https://www.youtube.com/watch?v=vvZA9n3e5pc