Design/Living style guide/Requirements

Previous work
Currently, Wikimedia has two "Living Style Guides":
 * We have a styleguide automatically generated from our LESS using kss-node. This styleguide is pretty, but it's focussed around documenting our CSS (notably, it doesn't document our OOUI widgets), and it still feels quite 'static'.
 * We have an OOUI demo page which gives us a bit more of a dynamic feel, and shows us OOUI widgets correctly, but doesn't document our CSS, and doesn't allow us to put more 'tech writing' type of content in (i.e., content not directly related to a specific widget, but about general principles.

Inspiration and work by others

 * Google's Material Design Guidelines are excellent.
 * They are nicely designed themselves.
 * They include copious examples.
 * They are easy to navigate.
 * One problem: there isn't any discussion of implementation; however, there is the Polymer Project.
 * Atomic Web Design
 * Anchoring Your Design Language in a Live Style Guide, UX Magazine
 * A list of existing libraries.
 * I don't really like GitHub's style guide (generated with KSS).
 * It's very implementation-specific, yet doesn't really give clear implementation steps.
 * It's not very well organised (there isn't really a sense for what's important and what isn't)
 * There's no overarching structure or tech writing that tells us anything about GitHub's philosophy or architecture.
 * It doesn't feel complete.
 * Mozilla's is okay.
 * It's easy to navigate
 * It's dynamic and has plenty of examples.
 * The amount of tech writing is variable. The Firefox OS section has plenty of justification, the Forms page under Sandstone gives you a list of labelled form elements and that's it.
 * There's no link to implementation.
 * I really like MailChimp's styleguide:
 * It's easy to navigate and pretty.
 * Almost every example is accompanied by code.
 * It has explanation of the history and vision behind the framework.

Goals
Our living style guide should be:
 * Living. It's okay to take sections and tech writing as external input, but the sections about components should be generated dynamically from the same code that runs the website. If it needs to be maintained, it will get out of date.
 * Structured: We don't want to take the approach of just documenting each widget