---
# System prepended metadata

title: 100YSS Technical Design Document Template

---

---
title: 100YSS Technical Design Document Template
tags: 
---

<div class="alert alert-warning" role="alert">
<h2> 👉👉  Getting Started </h2>

<p>

</p>

<div style="display: none;">
 <i class="fa fa-gear fa-2x" style="color: #00a187;"></i> 
 <h4><i class="fa fa-info-circle"></i> How to use this template</h4>
You should have a [Product Requirements Doc]() and a [Technical Requirements Doc]()
</div>

<div>
 <ul>
  <li> Document status starts in 'draft' state. Work through each section to describe your proposed solution. </li>
  <li> Replace each block of italicized text with your content. </li>
  <li> When you're ready to gain stakeholder approval, mark status as 'in review' and submit to your reviewers. </li>
  <li> Change status to approved once all stakeholders have approved! </li>
 </ul>
</div>
</div>


# Design Doc Template

**Author(s):** [Keifer Furzland](), [Jason Batt](), [Todd Walton]()
**Last Update:** July 17 2020
**Status**:  **Draft** | <span style="color: grey;"> In Review | <span style="color: gray;"><i class="fa fa-close"></i> Approved</span>

**Personnel**:
| **Role**              | Name                  | Email              | Organization      |
| --------------------- | --------------------- | ------------------ | ----------------- |
| Principal Stakeholder | Dr. Mae Jemison, M.D. |                    | 100YSS Foundation |
| Product Owner         | Todd Walton           |                    | FAME              |
| Content               | Yema Coker            |                    | 100YSS            |
| Social Media          | Shadia Sadaqa         |                    | 100YSS            |
| Engineering           | Jason Batt            | jbatt@100yss.org   | 100YSS            |
| Engineering           | Keifer Furzland       | furzland@gmail.com | Superior Bitworks |

## Overview

### Background

- _Provide context and background needed to understand this document_

### Problem Statement

_What are you aiming to accomplish, and why?_

- Current site isn't flexible enough for rapid response
    - content changes can't happen easily
- Who are the stakeholders, specifically?
- Who are the content editors?
- Blog is via tumblr, piped into the frontend
- Multiple people who need to manage content and different roles
- Dr. Mae does not want to lose the frontend of the site - the "star map" and the "google maps view"
- The Barbarian Group (?) were the O.g. devs
- WordPress for content backend is fine, it depends on what people are comfortable with?
- multiple content sources, disparate control over accounts
- Canopus, Nexus
- previously have been a lot of hands 
- 

### Glossary

- _Define specific jargon here_

### Scope Statement

- Related issues that aren't solved *now* but are worth solving.

## Technical Architecture

_Use this section to provide detailed description of the proposed solution architecture. Remove, extend or add section headers as appropriate._

- _Provide diagrams and flowcharts. Use [LucidChart]() or [draw.io]()_
- _Walk through a user story as an example to demonstrate feasability of the solution_
- _Provide the big picture first, but then fill in **lots** of details_

### Existing Solution

_Explain the existing solution, and identify which components may be causing pain points in the user journey_

### Proposed Solution

_Outline the proposed solution at a high-level, with enough detail so that stakeholders and engineers can understand the major components involved. Save the fine-grained technical details for the detailed implementation design section below._

### Alternative Solutions

_Explain alternative solutions for the problem, and rationale for why you chose not to propose it_

### Assumptions
 _Outline any assumptions about technical stack, data throughput, expected user behavior,  etc._

### Cross-Team Impact

_Identify how the proposed solution will impact cross-team workflow_

### Security Considerations

_Document main security concerns for the solution (PII? Authn/Authz?)_

### Open Questions

_Compile any open questions here._

### Detailed Implementation Design

_This section should contain a highly detailed explanation of each component and change required to realize the proposed solution. Be as specific as possible, and ensure detail is enough so that any given engineer could read this section and implement the solution without further explanation._

<div class="alert alert-warning">
🌴 🌴 🌴 Make sure you run the vacation test on your implementation document - can an engineer sit down and implement the solution from this document if you went on a vacation to a deserted island? 
</div>

---

_Last updated_: **July 17 2020**

### Revision History

| Date         | Summary                                    | Author          |
| ------------ | ------------------------------------------ | --------------- |
|              |                                            |                 |
| July 17 2020 | Initial communications with Todd and Jason | Keifer Furzland |


