docs/design: describe process in more detail (#2817)

docs/design/TEMPLATE.md

@@ -1,5 +1,3 @@
-[This is a template for Storj v3 design docs]
-
 # [Title]
 
 ## Abstract

docs/design/design-doc-process

@@ -1,27 +0,0 @@
-Design doc process:
-
-Design docs will be checked in as Markdown files in storj/storj/docs/design.
-
-Design docs should have an editor/author, at least one design Q&A meeting, and at least two reviewers from the architecture board.
-
-The editor is the primary person responsible for the design doc - they're responsible for soliciting authors or authoring the document themselves (drafting could be in Google Docs). The editor is responsible for scheduling the Q&A meeting(s), getting the document reviewed, and getting the document merged into the repo. Editor is also responsible for making a list of epics and tickets to file once merged and posting the design doc in our [fourm](https://forum.storj.io/c/engineer-amas/design-draft)
-
-The reviewers are responsible for saying that the design doc looks good to them, have no objections, and are ready to turn the document into tickets.
-
-The Q&A meeting should have at least 3 people but no more than 6. Invitees should have read what parts of document currently exist prior and be prepared to discuss it and the design space. The reviewers should be present. There should be at least one Q&A meeting where the result is everyone is happy with the design, but potentially more if a Q&A meeting ends with unsolved problems.
-
-One of the reviewers must be an "architecture owner." At minimum, the following people currently count:
-
-  * Egon (egonelbre)
-  * Kaloyan (kaloyan-raev)
-  * JT (jtolds)
-  * Jens (littleskunk)
-  
-Until we develop our own institutional knowledge of running V3 at scale, one of the reviewers should be someone with significant external distributed systems industry experience. At minimum, the following people currently count:
-
-  * Paul (thepaul)
-  * Simon (simongui)
-  * Jeff (zeebo)
-  * Matt (brimstone)
-
-We'll list these people as GitHub codeowners, but it is expected editors solicit input from the wider engineering team, the devops team, the data science team, the UX team, and QA.

docs/design/design-doc-process.md

@@ -0,0 +1,58 @@
+# Design Document Process
+
+Design documents will be checked in as Markdown files in `docs/design` folder.
+
+Design documents should have an editor, at least one discussion meeting, and at least two reviewers from the architecture board.
+
+The editor is responsible for:
+* soliciting authors or authoring the document themselves,
+* scheduling discussion meetings,
+* finding reviewers,
+* posting the document in our [forum](https://forum.storj.io/c/engineer-amas/design-draft), and
+* getting the document finalized and merged
+
+The editor is also responsible for making a list of epics and tickets after the design document is finalized and merged.
+
+The reviewers are responsible for reviewing the clarity and reasonableness of the document.
+
+The discussion meeting should have at least three people present. Invitees should familiarize with the document prior to the discussion. The reviewers should be present. If there are open problems after the meeting, then the meeting should be repeated.
+
+One of the reviewers must be an architecture owner, currently:
+
+* Egon (@egonelbre),
+* Kaloyan (@kaloyan-raev),
+* JT (@jtolds),
+* Jens (@littleskunk),
+* unless agreed otherwise
+
+The other reviewer should be someone with significant distributed systems expertise, currently:
+
+* Paul (@thepaul),
+* Simon (@simongui),
+* Jeff (@zeebo),
+* Matt (@brimstone),
+* unless agreed otherwise.
+
+However, it is expected that there should be feedback from the engineering team, DevOps team, data science team, UX team, QA team, and the community.
+
+## Template
+
+The design document uses `TEMPLATE.md` as a guide. However, it can be modified when necessary.
+
+The template has the following sections:
+
+* **Abstract** gives an overview of the design document and what it accomplishes. It does not go into details about the problem.
+
+* **Background** gives an overview of the background why this design document exists. It describes the problems the design document tries to solve. It describes the goals of the design.
+
+* **Design** contains the solution and its parts. The level of detail should correspond to the level of risk. The more problems a wrong solution would cause, the more detailed should be the description. The design should describe the solution to the degree it is usable by the end-user.
+
+* **Rationale** section describes the alternate approaches and trade-offs. It should be clear why the proposed design was chosen among the alternate solutions.
+
+* **Implementation** describes the steps to complete this design document. It should contain a rough outline of tasks. If necessary, there can be additional details about the changes to the codebase and process.
+
+* **Open Issues** contains open questions that the author did not know how to solve.
+
+## Format
+
+The design document is intended to be read by outside of Storj, hence avoid acronyms that aren't common in the general developer community. Prefer simple sentences. Active voice is usually easier to read. Overall, be clear.