But not every Github Issue is a good candidate for a bounty. If you are an OSS repo maintainer, and want to maximize our Return on Investment (ROI), you might spend some time thinking about:

Return — The value received for delegating work to someone else. This can be:

1. The deliverable you, the Funder, has envisioned.
2. A new developer, that could possibly blossom into a long-term contributor relationship.
3. A new developer, but without the overhead of a full time hire.
4. More market traction for your OSS repo.

Investment — The resources put into delegating the work to someone else. This can be:

1. The time spent specifying desirable outcomes for your project.
2. Time spent selecting a bounty hunter, or answering questions.
3. Scarce financial resources(whether ETH, DAI, or any other ERC20 token) spent on the bounty.

Using Gitcoin, We’ve seen OSS repo owners:

• Accelerate their development without the overhead of hiring anyone new
• Form long term contribution relationships
• Build things that their core team doesn’t know how to, or doesn’t have time to, do.

So how do we leverage incentivization mechanics to accelerate OSS?

In order to leverage Gitcoin’s crowd-sourced development incentivization tools, lets talk about some best practices for maximizing ROI of the tool:

Start with the Scope

In our experience, the following are great candidates for bounties:

• Bug Hunts or Bug Squashing
• Security Bounties
• Documentation Bounties
• New Features, if well specified
• API Clients
• Increase Code Test Coverage
• Inserting Analytics Tracking Code
• An issue that’s well specified, but has been on the backlog nonetheless.

In our experience, the following are not good candidates for bounties:

• Core Architecture
• Anything that requires a high degree of situational awareness of the product/market fit (unless that is all documented)
• Anything that requires privileged access (like SSH access, prod private API keys)

Best Practices

Here are some best practices we’ve seen from some of our 2018 Case Studies:

1. Treat the counter-party like a budding relationship

At surface level, you might think that bounties are a transaction. That might be true in some cases, but we’ve found that some of highest ROI bounties that we’ve seen thus far on Gitcoin are also the highest empathy bounties.

This means that, from the funder side, you can start off on the right foot if you:

1. Fund fairly.
2. Thoughtfully specify.
3. Promptly answer questions.
4. Communicate expectations upfront.
5. Maintain the appropriate scope.

It also means that from the development side, you can expect:

1. Prompt turnaround of work.
2. Work is low on technical debt.
3. Developer is communicative.

2. Great Specifications

Some of this is Software Management 101, so if you’re got a background in Agile Stories, it might be worth skipping this part.

Here are some features we’ve seen of great specifications:

1. Define Acceptance Criteria Upfront — One great way to make sure the scope of the bounty is well understood by both parties is to think through exactly what you want, and then over communicate or anticipate gaps.
2. Provide Supporting Documentation — Depending upon the type of issue you’re funding, this can mean supporting wireframes, architecture diagrams, links to documentation
3. Remove Blockers — Actively think through what could be blocking the implementation of this scope, and be prepared to remove those blockers.
4. Over-communicate — Someone from across the country (or world) may not have the same skills, professional history, or communication style as you. For this reason, it’s a best practice to over-communicate.

Please feel free to use this github issue template for your github issues!

3. Contribution Guidelines

This is an Open Source Software Best Practice, and it also happens to be a OSS Incentivization Best Practice too.

We’ve found that all of the above really help:

1. A well written README.md file
2. A well-specified Code of Conduct
3. Contributor Standards — Code standards including linting standards, tests, PR templates, etc

For more inspiration in this area, check out this README.md template.

4. Save budget for iteration

In the past, we’ve seen new features (especially those with qualitative aspects to them) go through a process like this:

1. (Core Team) Specification / Wireframe
2. (Crowd) Design
3. (Core Team) Specification Architecture
4. (Crowd) Implementation
5. (Core Team) Deployment / v2 Specification
6. (Crowd) v2 Implementation

If you’ve saved some budget for tipping a contributor or for follow-on bounties, that’s a great way to keep up momentum on your project.

A journey of a thousand miles begins with a single step

If the above seems like a lot to remember, do not worry! Rome was not built in a day, and building an OSS community won’t happen in a day either.

Take the first step today and put a bounty on Gitcoin. If you start small, stay reasonable, and are responsive — thats a great place to begin.