diff --git a/docs/personas.md b/docs/personas.md
new file mode 100644
index 00000000000..0792f2bb409
--- /dev/null
+++ b/docs/personas.md
@@ -0,0 +1,125 @@
+# Personas
+
+## 1. Individual developer (first-timer)
+
+### Characteristics
+
+* Moderately experienced developer
+
+* Feels some sense of ownership over the project ("I want to share this with the world")
+
+* Sees self as ultimate decisionmaker
+
+* Still building community reputation
+
+* Has never open sourced a project before
+
+### Primary Goals
+
+* Wants people to notice their project
+
+* Wants people to actually use the project, give him/her feedback
+
+### Frustrations/Pain Points
+
+* Doesn’t know how to find an audience
+
+## 2. Individual developer (multiple projects)
+
+### Characteristics
+
+* Experienced developer
+
+* Feels some sense of ownership over the project ("I want to share this with the world")
+
+* Sees self as ultimate decisionmaker
+
+* Has a decent community reputation
+
+* Has open sourced a project before. May manage multiple projects
+
+* Likely manages projects on their own time (volunteer work)
+
+### Primary Goals
+
+* Manage personal time so project demands don’t overwhelm him/her
+
+* Find other contributors or maintainers to help with the project
+
+### Frustrations/Pain Points
+
+* Feeling burned out, exhausted from open source work
+
+## 3. Community developer
+
+### Characteristics
+
+* Experienced developer
+
+* Wants to share ownership of the project ("I want to build this with others")
+
+* Sees community, not self, as ultimate decisionmaker
+
+* Has a decent audience/reputation
+
+* Has open sourced personal projects before
+
+* Likely manages projects on their own time (volunteer work)
+
+### Primary Goals
+
+* Get people to participate, contribute back to the project
+
+* Make sure everybody involved with the project is happy and has a good experience
+
+### Frustrations/Pain Points
+
+* Managing a community is exhausting, especially when it’s volunteer work
+
+## 4. Corporate entity
+
+### Characteristics
+
+* Team of employees working at the same company. Primarily engineering, but likely multiple stakeholders across functions
+
+* Likely feels some sense of ownership over the project ("We are open sourcing this project to the community")
+
+* Company plays a clear role in decisionmaking
+
+* May not have open sourced a project before
+
+* Projects are managed by paid employees
+
+* Cares about fostering a healthy community, but does not necessarily want to share ownership in a formal capacity
+
+### Primary Goals
+
+* Improve brand and reputation
+
+    * Attract new technical talent for recruiting (make sure people hear about it)
+
+* Grow a platform (get people to use it)
+
+### Frustrations/Pain Points
+
+* Balancing community + corporate needs
+
+    * (For community: being a good corporate citizen, respecting cultural norms)
+
+    * (For corporate: adhering to company policies)
+
+* Making sure people know about the project
+
+## 5. Other personas not included
+
+* Non-developers (individual, student, community, corporate)
+
+    * People who are open sourcing projects that don’t involve code (ex. books, documents, templates)
+
+    * Can we use language that applies to both code- and non-code-centric projects?
+
+    * If we don’t tailor the handbook to them, will they feel isolated or ignored? Is there anything we’d miss about their experience?
+
+* Student developer
+
+    * Likely more interested in learning how to contribute vs. how to start their own project. Set this aside for v1 (we’re primarily focusing on who produces open source projects)