design/blueprints (#2927)

we've decided to rename design docs to blueprints to indicate that we don't intend to keep blueprints up to date once completed. instead, the final step of blueprint implementation is to archive the blueprint and update actual documentation elsewhere (potentially copying and pasting most of the blueprint). this PR updates the template and readme

docs/blueprints/README.md

@@ -1,8 +1,17 @@
-# Design Document Process
+# Blueprint Process
 
-Design documents will be checked in as Markdown files in `docs/design` folder.
+Design docs are now known as blueprints. We do not intend to keep blueprints up to date once
+the implementation has been completed. The final step of a blueprint is to update documentation
+elsewhere, such as:
+ * https://github.com/storj/docs
+ * https://documentation.storj.io
+ * https://documentation.tardigrade.io
+ * https://godoc.org/storj.io/storj/lib/uplink
+ * Other godoc documentation, etc.
 
-Design documents should have an editor, at least one discussion meeting, and at least two reviewers from the architecture board.
+Blueprints will be checked in as Markdown files in `docs/blueprints` folder.
+
+Blueprints 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,
@@ -11,7 +20,7 @@ The editor is responsible for:
 * 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 editor is also responsible for making a list of epics and tickets after the blueprint is finalized and merged. These should include archiving the blueprint when completed and updating appropriate documentation.
 
 The reviewers are responsible for reviewing the clarity and reasonableness of the document.
 
@@ -37,22 +46,24 @@ However, it is expected that there should be feedback from the engineering team,
 
 ## Template
 
-The design document uses `TEMPLATE.md` as a guide. However, it can be modified when necessary.
+The blueprint 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.
+* **Abstract** gives an overview of the blueprint 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.
+* **Background** gives an overview of the background why this blueprint exists. It describes the problems the blueprint 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.
+* **Implementation** describes the steps to complete this blueprint. It should contain a rough outline of tasks. If necessary, there can be additional details about the changes to the codebase and process.
+
+* **Wrap up** describes the steps needed
 
 * **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.
+The blueprint is intended to be read by developer contributors outside of Storj, but not the wider public. It is okay to assume some familiarity with the Storj project. Try to avoid acronyms that aren't common in the general developer community. Prefer simple sentences. Active voice is usually easier to read. Overall, be clear.

docs/blueprints/TEMPLATE.md

@@ -2,7 +2,7 @@
 
 ## Abstract
 
-[A short summary of what this design doc accomplishes at a high level.]
+[A short summary of what this blueprint accomplishes at a high level.]
 
 ## Background
 
@@ -20,6 +20,10 @@
 
 [A description of the steps in the implementation.]
 
+## Wrapup
+
+[Who will archive the blueprint when completed? What documentation needs to be updated to preserve the relevant information from the blueprint?]
+
 ## Open issues
 
 [A discussion of issues relating to this proposal for which the author does not