This meta post on documenting architecture decisions describes a format very much like Rust's RFCs: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions …
-
-
Replying to @englishm_
Perhaps extending the "context" section with a subsection making explicit as many assumptions as possible could help.
1 reply 0 retweets 0 likes -
Replying to @englishm_
Giving names to the assumptions and groups of assumptions used in decisions would also let us further document what they rest on.
1 reply 0 retweets 0 likes -
Replying to @englishm_
We could start to form a shared vocabulary and collaboratively document shared chains of reasoning.
1 reply 0 retweets 1 like -
Replying to @englishm_
Things like RFCs or Python's PEPs cover some of this, but what if we factored out some of the "shortcuts"
@wycats describes?1 reply 0 retweets 0 likes -
Replying to @englishm_
@englishm_ my belief is that "kernels" are an encoding of these shortcuts, and each part of the kernel should explain why.1 reply 2 retweets 0 likes -
Replying to @englishm_
@englishm_ I mean a generalization of an operating system kernel.1 reply 0 retweets 0 likes -
Replying to @wycats
@englishm_ the kernel and userspace separation in particular.1 reply 0 retweets 0 likes -
Replying to @wycats
@englishm_ the basic idea is that you're encoding the stable assumptions in kernel APIs, and use semver rules as the "moving" policy2 replies 1 retweet 1 like
@englishm_ my recent talk about the 6 week release process and stability without stagnation (https://speakerdeck.com/wycats/stability-without-stagnation-lessons-learned-from-shipping-ember-dot-js …) is a tactical guide
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.