docs: Formalize our design docs process a bit.

docs/contributing.md

@@ -64,6 +64,12 @@ your company's interests, do feel free to approve it.
 This project follows [Google's Open Source Community
 Guidelines](https://opensource.google/conduct/).
 
+## Contributing large patches
+
+Before sending a PR for a large change which designs/redesigns or reworks an 
+existing component, we require an architecture review from  multiple 
+stakeholders, which we do with [Design Docs](design_docs.md), see the 
+[process here](design_docs.md#process).
 
 ## Contributing to the documentation
 

docs/design_doc_blueprint.md

@@ -0,0 +1,56 @@
+# Title
+
+> A cool name for your Project
+
+Author: [Your-Name](mailto:[email protected])
+
+> If there are multiple authors, just list them all
+
+## Summary
+
+A short summary of your project/re-design/component and what problems it 
+addresses in about 3-10 sentences.
+
+## State of the Feature as of `$VERSION` (optional)
+
+The state of the feature you want to improve and where it currently falls 
+short. If there's nothing to compare to, leave it out.
+
+## Prior work (optional)
+
+Does this feature exist somewhere else and which tradeoffs it made. 
+
+> If there's no prior work, then use the related work section below.
+
+## Goals and non-goals
+
+Direct goals of the project and features deemed not worth pursuing.
+
+## Overview
+
+A detailed overview of the project and the improvements it brings.
+
+### Detailed Design
+
+The place to describe all new interfaces and interactions and how it plays into
+the existing code and behavior. This is the place for all nitty-gritty details 
+which interact with the system.
+
+## Alternatives considered (optional)
+
+Other alternatives to your suggested approach, and why they fall short.
+
+## Issues addressed (optional)
+
+A list of issues which are addressed by this design.
+
+## Related Work (optional)
+
+If there's a feature in another VCS which shares some similarities to your 
+proposed work, it belongs here. An example would be Jujutsu sparse workspaces 
+and Perforce client workspaces.
+
+## Future Possibilities
+
+The section for things which could be added to it or deemed out of scope during
+the discussion.

docs/design_docs.md

@@ -0,0 +1,28 @@
+# Jujutsu Design Docs
+
+Jujutsu uses Design Docs to drive technical decisions on large projects and it
+is the place to discuss your proposed design or new component. It is a very 
+thorough process, in which the design doc must be approved before PRs for the
+feature will be accepted. It shares some similarities with [Rust RFCs] but 
+mostly addresses _technical_ problems and  gauges the technical and social 
+concerns of all stakeholders.
+
+So if you want to start building the native backend or the server component for
+Jujutsu, you'll need to go through this process. 
+
+## Process
+
+1. Add a new markdown document to `docs/design`, named after your improvement 
+   or project. 
+1. Describe the current state of the world and the things you want to improve.
+1. Wait for the Maintainers and Stakeholders to show up. 
+1. Iterate until everyone accepts the change in normal codereview fashion.
+
+
+[Rust RFCs]: https://github.com/rust-lang/rfcs 
+
+## Blueprint (Template)
+
+You can find the base template of a new Design Doc 
+[here](design_doc_blueprint.md).
+

mkdocs.yml

@@ -128,6 +128,8 @@ nav:
 - Contributing:
       - 'Guidelines and "How to...?"': 'contributing.md'
       - 'Code of conduct': 'code-of-conduct.md'
+      - 'Design Docs': 'design_docs.md'
+      - 'Design Doc Blueprint': 'design_doc_blueprint.md'
 
 - 'Design docs': 
     - 'git-submodules': 'design/git-submodules.md'