The launch of PoolTogether Bounties will include a single template.
Designed with flexibility in mind. Code, Design and Content Creation bounties can all be articulated using the V1 Bounty Template.
Sections
The following sections must be included in the bounty submission.
- Abstract: high-level bounty description
- Problem: what is the problem
- Rationale: why solve this problem
- Deliverables: what is required to complete the bounty
- Specification: itemize the delivery requirements
- Estimated Budget: a breakdown of costs for itemized deliverables
- Resources (helpful materials, related bounties, implementation details, etc): other things
Abstract
Problem
Rationale
Deliverables
Specification
Estimated Budget
Resources
Bounty Section Definitions
Abstract
The abstract should describe the Bounty from a high-level perspective. In 2-4 sentences the abstract should describe a who, what and why.
User Stories are a good example of how to quickly create an abstract using a popular formula.
As [a user persona], I want [to perform this action] so that [I can accomplish this goal].
Problem
Describe in detail the problem being solved by the bounty. Now is the time to get specific about observations and motivations. Laying out a reasonable articulation for how this bounty is connected to a PoolTogether Northstar, Objective and/or Key Result.
State the current problem in context to the PoolTogether protocol.
For example “The [Bounty Name] contributes to Key Result “5+ new protocol partnerships” by communicating to potential partners key parts of the PoolTogether ecosystem in greater detail.”
Rationale
A bounty should always solve an important problem for the protocol. Explain why the bounty is important right now.
How many Users are asking for the feature?
Will the unlock new opportunities for more Contributors?
Why will potential Partners care about this bounty?
Deliverables
The deliverables section is one of the most important sections in a Bounty.
Contributors have the highest chance of success with clearly defined deliverables. It’s good for the person and it’s good for the protocol. A win/win.
The deliverables should strive for simplicity. Striving for a mid-level overview of the bounty.
In other words a bullet point list (to-do list) is a great place to start. The Specification section is where more detail and specific requirements can be defined for the deliverables.
- Deliverable 1
- Deliverable 2Specification
The greatest level of detail should be included in the specifications. When a bounty is being reviewed the specifications will be used to judge complete or incomplete status. Thus it is critical specifications clearly articulate detailed requirements so more Bounty Team members can properly evaluate a bounty.
In most case a specification will be tied a deliverable.
- Deliverable 1
- Specification 1
- Specification 2
- Deliverable 2
- Specification 1
- Specification 2
Specification 3 DetailEstimated Budget
After the bounty has been properly outlined/scoped the Estimated Budget section can include expected cost/resource for the entire bounty or also sub-items in the bounty.
For example if the bounty only includes 1 or 2 deliverables then a breakdown of costs should be a simple line item. However, in certain instances for more complex bounties it might be useful to include a breakdown of cost for each deliverable included in the bounty.
Resources
Provide context to the bounty by linking important information: document, canny post, github issue, etc... Contributors need to be able to find important information quickly.
Do not make contributors search for important information.
Products
- https://tools.pooltogether.com
- https://github.com/pooltogether/tools-ui
Issues
- https://github.com/pooltogether/tools-ui/issues/1Links should include brief description why they are included in the resources section.
