-Introduction paragraph -- why are we doing anything? A single paragraph of
-prose that operators can understand. The title and this first paragraph
-should be used as the subject line and body of the commit message
-respectively.
-
-Some notes about the process:
-
-* The aim of this document is first to define the problem we need to solve,
- and second agree the overall approach to solve that problem.
-
-* This is not intended to be extensive documentation for a new feature.
-
-* You should aim to get your spec approved before writing your code.
- While you are free to write prototypes and code before getting your spec
- approved, its possible that the outcome of the spec review process leads
- you towards a fundamentally different solution than you first envisaged.
-
-* But, API changes are held to a much higher level of scrutiny.
- As soon as an API change merges, we must assume it could be in production
- somewhere, and as such, we then need to support that API change forever.
- To avoid getting that wrong, we do want lots of details about API changes
- upfront.
-
-Some notes about using this template:
-
-* Your spec should be in ReSTructured text, 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
-
-* For help with syntax, see http://sphinx-doc.org/rest.html
-
-* To test out your formatting, build the docs using sphinx
-
-* 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. The reason for this is that the tool used to review specs is
- based purely on plain text. Plain text will allow 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.
-