This repo is where we publish, track and document the bounty system for the Joystream platform. Anyone is free to propose to propose a bounty, and anyone is free to compete for them.
Keep in mind this is a WIP, and it should be expected that changes to the process will be made as the project grows.
Contributors to the Joystream platform shall, if applicable, try to follow the guidelines outlined here in our landing repo.
Below is a list of the active and previous proposals.
Non-exhaustive list of Categories
- Marketing
- Governance
- New feature(s)
- Project management
- Improvements
- etc.
Number | Title | Link | Category | Start date | Assignee (if applicable) | Size of bounty |
---|---|---|---|---|---|---|
#0 | N/A | N/A | N/A | yy.mm.dd | N/A | $N |
Number | Title | Link | Category | Start date | Ended | Status | Claimant(s) | Size of bounty |
---|---|---|---|---|---|---|---|---|
#0 | N/A | N/A | N/A | yy.mm.dd | yy.mm.dd | N/A | N/A | $N |
This depends on who initiates the bounty. Sometimes, the proposal bounty will be identified and decided by a member of Jsgenesis team. In other cases, it may be community driven.
A bug, improvement, marketing campaign, etc. is discovered and identified, either internally or someone else. An issue will be opened, and structured as follows depending on the magnitude and importance of the bounty.
If the scope of work around the bounty is fairly well contained and defined, the issue need only contain:
Bounty # - Descriptive Title - $N
Description of the problem/task and goals.
- If applicable, include link and reference the issue in the repo it was first reported
- Well defined scope of work, including any potential:
- Deliverable(s)
- Constraints
- Deadlines
- Some information on whether it's first come/first served, how many can claim, etc.
If the scope of work is large, complex, and perhaps largely undefined, the structure will be quite different.
Bounty # - Descriptive Title - $N
Note that for Larger Bounties, this will just be a rough estimate
High level description of the problem/task and goals.
- If applicable, include link and reference the issue in the repo it was first reported
A brief summary of the anticipated:
- Stages
- Deadline(s)
- Milestones
- Deliverables
The structure will probably differ quite a lot from time to time, but the body should at contain the following with some level of detail:
- Stages
- Deadline(s)
- Parameters
- Budget(s)
- Milestones
- Deliverables
- Additional requirements
- Reporting
- Documentation
- Payout structure
- xyz
Community members, new and old, should not be afraid to propose bounties. At some point, we hope to create a system either similar to the BIP process for bitcoin and/or to the FFS system for monero.
JIP - Descriptive Title
Provide a description of the problem or improvement you wish to see implemented. Ideally, this should not just be random suggestion, but something that is:
- Feasible, both from a technical and economical point of view
- In line with, or at least not orthogonal, to the goals outlined in either:
- The project manifesto
- The project whitepaper
- Our long or short term OKRs
- Referring to an issue from one of our other repos
If you have a proposal that this not really fit under any of the above, feel free to gauge the interest and relevance in a more informal manner, eg. in one of our communication channels, such as rocket.chat, telegram, or the forum, after it has been introduced in Acropolis.