With our goal being direct improvement of the open-source project by the community via donations and development, we rely on direct users of the application to submit bounties for feature implementations/bug fixes that are important to them.
Difference between a bounty and a feature request/bug report:
A feature request/bug report is simply a report of a desired functionality or a report of a bug.
A bounty is where you (or more) people from the community list a feature on this site that you want implemented or a bug that you want fixed AND raise funds for this feature/bug fix specifically. Then a developer can fix/implement the bounty and will be paid the bounty amount.
Bounty listing process
- You submit your bug/feature bounty below.
- It gets reviewed by our team.
- We email you back once it’s added to the bounties page. If there is an issue with your bounty submission (e.g. it’s duplicate, or already something implemented/planned, or impossible) then we’ll let you know via email.
- Other people can fundraise the bounty and track it’s status via the bounty listings page.
A goal is listed for each bounty, and once that $ goal is reached, we can find a knowledgable developer to start working on it and pay them the amount once it’s DONE and TESTED (so no funds are wasted).
To list a bounty, please email the following information to
- your name and email address
- how much you WILL contribute to the bounty (a bounty isn’t just a feature request/bug report so there actually needs to be $ to fund it’s implementation)
- goal bounty $ amount (how much in total you think this bounty will cost for someone to implement/fix)
- the bounty tier (see below)
- bounty description
- bounty type (is it a feature or bug?)
Bounty tiers
We have decided to group bounties into tiers depending on their impact, code quality, and complexity. This will bring more stability to our program.
| Tier 1 Regular small tier bugs or fixes that improve existing functionality. |
| Tier 2 For medium features, refactorings, improvements. Medium refactors or optimizations of the code or additions of small non-essential features. |
| Tier 3 Large features or large performance improvements. An example would be optimizing some parts of the Core for improved performance of a specific function, fixing a larger bug, or implementing a new feature. |
| Tier 4 Really large feature additions, possibly performance improvements if they really make a big difference (e.g. SSO). Examples of this include extending API functionalities, resolving structural issues that cause circular dependencies, or adding a new bigger feature to our codebase. |