---
id: 000-template
title: Swarm Template
status: draft
created: YYYY-MM-DD
category: core
lead-contributor:
contributors:
    -
    -
    -
exit-criteria: no
success-metrics: no
clear-roles: no
future-iteration: no
roles-needed:
    - QA
    - PM
    - UXR
    - Clojure dev
    - Go dev
    - Contracts dev
    - Designer
    - Community
okrs:
    -
    -
---

## Preamble

    Idea: <to be assigned>
    Title: <title>
    Status: <Draft | In Progress | Closed >
    Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
    Requires (*optional): <Idea number(s)>
    Replaces (*optional): <Idea number(s)>

## Summary

> "If you can't explain it simply, you don't understand it well enough." Provide
> a simplified and layman-accessible explanation of the Idea.

## Swarm Participants

> Here all roles in swarm are defined and filled, one of the contributors should
> responsibility of the Idea as Lead.
>
> Lead Contributor is the Owner of the Idea. If required, they can get support
> from a PM, but should be responsible for end to end execution of the Idea.
> This includes ensuring appropriate resources are allocated, setting realistic
> timelines and milestones, and any post-launch metrics or bug fixes that are
> attributed to the Idea
>
> A swarm requires at minimum 3 contributors. For user-facing swarms
> PM/UX(R)/Eng functions have to be present.
>
> For swarms lead by core contributors, swarm lead is evaluator by default.
>
> 'Contributor' should be replaced with a descriptive role type.

- Lead Contributor:
- Evaluator (defaults to lead contributor):
- Contributor:
- Contributor:
- QA:
- PM (required for user-facing):
- UX(R) (required for user-facing swarms):

## Product Overview

> A short (~200 word) description and motivation of the Idea. Without clear
> explanation the Idea should not proceed.

### User Stories

> What user stories are you solving?

### Requirements & Dependencies

> Are there bugs or feature requests in other repositories that are part of this
> Idea?

### Security and Privacy Implications

> If the security and privacy implications of the idea are non-trivial,
> elaborate on the problem space and a plan for resolving it here.

## Dates

> Description of deliverables at a given date, for example each Town Hall (default).
> Add more iterations as required.
>
> Evaluator accepts responsbility to checkin at Goal dates, forces discussion to
> continue implementation or recommend disband and post-mortem.
>
> Upcoming Town Halls this quarter:
> 2018-04-23, 2018-05-07, 2018-05-21, 2018-06-04, 2018-06-18

### Minimum Viable Product

> Mandatory, completes the Idea in the fastest route possible, can be hacky,
> needed to feel progress. See https://imgur.com/a/HVlw3

Goal Date:

Description:

### Iteration 1

Goal Date:

Description:

## Success Metrics

> Assuming the idea ships, what would success look like? What are the most
> important metrics that you would move?
>
> Example: Onboarding conversion rate. Target >30% full funnel

## Exit criteria

> Example: Launch new onboarding UI flow

## Supporting Role Communication

> Once Requirements and Goals are fleshed out, then it should be communicated to
> supporting organelles if required

## Copyright

Copyright and related rights waived
via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).