mirror of
https://github.com/martinvonz/jj.git
synced 2024-11-24 15:18:53 +00:00
c4777e4721
This adds the basic outline of _when_ a Design Doc should be written. See the next commit in the stack for the blueprint. By adding this we hopefully can prevent unnecessary churn from new and longtime contributors, when they want to add a major feature or rewrite a core part of Jujutsu. The text is written as a guideline, not a rule.
943 B
943 B
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
- Add a new markdown document to
docs/design
, named after your improvement or project. - Describe the current state of the world and the things you want to improve.
- Wait for the Maintainers and Stakeholders to show up.
- Iterate until everyone accepts the change in normal codereview fashion.