For a while now I've felt that we could do better in documenting how pieces of the julia system come to be like they are. I do love that Julia runs on a "show me the code" philosophy, but this doesn't scale to big changes and many contributors. Here are some problems I've observed:

• The outcome of long design discussion threads is rarely summarized, with the initial issue description containing only the starting point. People have to read through the entire discussion to understand the final design.
• New contributors have little context for the larger design decisions made in the language. Instead, they have to sift a somewhat unstructured pile of github issues, commit messages and code to extract the buried wisdom. This leads to confusion and wasted effort.
• Core contributors become a bottleneck in sharing design direction. This leads to frustration as less experienced developers become blocked, and can be an inefficient use of core contributor's time. Better design docs provide a scalable one-to-many solution to this issue.
• Knowledge about design rationale is lost over time as people move on. A curated repository of design documentation helps avoid this problem. For example, Python's PEP documentation is a fantastic resource. Not just to the Python community, but to everyone interested in related problems in programming language design.

In my experience, the Juleps repository has not been successful in stimulating design discussion, and in any case is too heavyweight for initial triage of an idea and for many small changes. In contrast, the main JuliaLang/julia repository issue tracker has been a good venue for discussion, but is a poor place to curate design documentation for the longer term.

I've recently discovered the golang proposals repository, and I'd like to propose that we adopt something similar to their process:

1. A julep starts life as a short description in JuliaLang/julia issue tracker.
2. It is discussed with the aim to either accept, decline or ask for a full design document. If accepted or declined, the process stops.
3. If a full design document is desired, the author writes it in the Juleps repository and works to address any issues brought up in the initial discussion. Feedback continues on the original issue.
4. Once the comments and revisions wind down there's a final discussion where the proposal is accepted or rejected.

The intent is to keep our low overhead informal process in the github issues, but to preserve the hard work of design in a more digestible form, regardless of whether it is ultimately accepted or rejected.