xref: /openbmc/docs/designs/design-template.md (revision ca12debc)
1____
2# Design Guidelines - *Delete this section*
3
4* Not all new features need a design document. If a feature can be
5  contributed in a single reasonably small patchset that has little impact
6  to any other areas, it doesn't need a design discussion and documentation.
7* The focus of the design is to define the problem we need to solve and how it
8  will be implemented.
9* This is not intended to be extensive documentation for a new feature.
10* You should get your design reviewed and merged before writing your code.
11  However you are free to prototype the implementation, but remember that
12  you may learn of new requirements during the design review process that
13  could result in a very different solution.
14* Your spec should be in Markdown format, like this template.
15* Please wrap text at 79 columns.
16* Please do not delete any of the sections in this template.  If you have
17  nothing to say for a whole section, just write: None
18* To view your .md file, see: https://stackedit.io/
19* If you would like to provide a diagram with your spec, ASCII diagrams are
20  required.  http://asciiflow.com/ is a very nice tool to assist with making
21  ASCII diagrams.  Plain text will allow the review to proceed without
22  having to look at additional files which can not be viewed in Gerrit.  It
23  will also allow inline feedback on the diagram itself.
24* Once ready for review, submit to gerrit and set the topic of the review
25  to "design"
26____
27
28# Example design - this is the design title
29
30Author:
31  < Name and IRC nic >
32
33Primary assignee:
34  < Name and/or IRC nic or None >
35
36Other contributors:
37  < Name and/or IRC nic or None >
38
39Created:
40  < Date initially created in Month D, Yr format (e.g. June 17, 2020 or Dec 19,
41  2019)>
42
43## Problem Description
44(1 paragraph) What are we doing and why? What problem are you trying to
45solve? What are the goals and NON-goals? Please make the objective
46understandable for someone unfamiliar with this project by including the
47necessary context, but keep it short. Elaborate on the details below in the
48Background and Requirements sections.
49
50## Background and References
51(1-2 paragraphs) What background context is necessary? You should mention
52related work inside and outside of OpenBMC. What other Open Source projects
53are trying to solve similar problems? Try to use links or references to
54external sources (other docs or Wikipedia), rather than writing your own
55explanations. Please include document titles so they can be found when links
56go bad.  Include a glossary if necessary. Note: this is background; do not
57write about your design, specific requirements details, or ideas to solve
58problems here.
59
60## Requirements
61(2-5 paragraphs) What are the constraints for the problem you are trying to
62solve? Who are the users of this solution? What is required to be produced?
63What is the scope of this effort? Your job here is to quickly educate others
64about the details you know about the problem space, so they can help review
65your implementation. Roughly estimate relevant details. How big is the data?
66What are the transaction rates? Bandwidth?
67
68## Proposed Design
69(2-5 paragraphs) A short and sweet overview of your implementation ideas. If
70you have alternative solutions to a problem, list them concisely in a bullet
71list.  This should not contain every detail of your implementation, and do
72not include code. Use a diagram when necessary. Cover major structural
73elements in a very succinct manner. Which technologies will you use? What
74new components will you write? What technologies will you use to write them?
75
76## Alternatives Considered
77(2 paragraphs) Include alternate design ideas here which you are leaning away
78from. Elaborate on why a design was considered and why the idea was rejected.
79Show that you did an extensive survey about the state of the art. Compares
80your proposal's features & limitations to existing or similar solutions.
81
82## Impacts
83API impact? Security impact? Documentation impact? Performance impact?
84Developer impact? Upgradability impact?
85
86## Testing
87How will this be tested? How will this feature impact CI testing?
88