design-template: Organise guidelines
Add some sub-headers and rename the section to "Document Guidelines".
Do the rename because the section is guiding you on when/how to write
the document, not how to design your thingo.
Change-Id: Iddf5540e80d5af00c9ef49bd1f7077cd4dfdddaa
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
diff --git a/designs/design-template.md b/designs/design-template.md
index 55d69e4..ee2841e 100644
--- a/designs/design-template.md
+++ b/designs/design-template.md
@@ -1,26 +1,36 @@
____
-# Design Guidelines - *Delete this section*
+# Document Guidelines - *Delete this section*
+## Document Content
* Not all new features need a design document. If a feature can be
contributed in a single reasonably small patchset that has little impact
to any other areas, it doesn't need a design discussion and documentation.
* The focus of the design is to define the problem we need to solve and how it
will be implemented.
+
* This is not intended to be extensive documentation for a new feature.
+
* You should get your design reviewed and merged before writing your code.
However you are free to prototype the implementation, but remember that
you may learn of new requirements during the design review process that
could result in a very different solution.
+
+## Document Formatting
* Your spec should be in Markdown format, like this template.
+
* Please wrap text at 79 columns.
+
* Please do not delete any of the sections in this template. If you have
nothing to say for a whole section, just write: None
+
* To view your .md file, see: https://stackedit.io/
+
* If you would like to provide a diagram with your spec, ASCII diagrams are
required. http://asciiflow.com/ is a very nice tool to assist with making
ASCII diagrams. Plain text will allow the review to proceed without
having to look at additional files which can not be viewed in Gerrit. It
will also allow inline feedback on the diagram itself.
+
* Once ready for review, submit to gerrit and set the topic of the review
to "design"
____