At Gitcoin, we’ve been listening to feedback on how to make the bounty process clearer. Here’s how we’re improving.

Growing Gitcoin has been a community effort. We’re lucky to have a vibrant Slack community focused on building in the blockchain space.

Our community isn’t afraid to challenge the status quo, and that means being open about feedback. We’ve learned a lot from our community, both formally and informally. Of all the feedback, we’ve heard a couple things quite often.

• As a Gitcoin funder, I’d like to approve candidates for bigger or more complex bounties.
• As a Gitcoin developer, I’d like clarity on when a task is mine to run with so I don’t unnecessarily compete with other bounty hunters.

As the portfolio of work on the platform grew and use cases for Gitcoin became more nuanced, we began thinking through different use cases for types of bounties on Gitcoin. In short, we listened.

Introducing Project Types

We broke out three different types of projects we’ve seen on Gitcoin.

• Traditional: One worker works a bounty at a time, one worker is paid out.
• Contest: Many Gitcoiner’s work a bounty, one gets paid.
• Cooperative: Many Gitcoiner’s work at a time, many are paid.

We expect the “Traditional” scheme to continue to be used in most cases — a repo owner wants an issue completed and it takes one qualified person to get a PR together.

Breaking out ‘Contests’ and ‘Cooperative’ bounties helps us abstract two important use cases which each represent ~10–15% of total bounties.

• We expect Contest bounties to be used for hackathon’s and related contests, where a prize is provided to the best submission.
• Cooperative bounties represents larger, more complex bounties which should be split amongst multiple Gitcoin developers and designers.

In total, this helps answer the above concern from developers.

I’d like clarity on when a task is mine to run with so I don’t unnecessarily compete with other bounty hunters.

An important note: A normal bounty on a Github repo should not be competitive. We aim to avoid spec-workand redundant efforts on the platform. While we do think Contest bounties have their place in the ecosystem (especially for security bounties and hacakathons), open source is inherently collaborative. We’ll make sure each contribution which is made on the platform is valued. Plus — there’s lots to do!

We also just launched ‘Permissions’!

We’ve also given funders the ability to choose to mark their bounties ‘Approval Required’.This allows funders to decide whether they’d like to screen applicants for a particular issue.

This feature does two things.

1. Gives funders more security when posting large, complex issues.
2. Aims to address an anti-pattern in which someone starts work on a bounty with a lot of enthusiasm, but without the ability to see it through.

We’ve noticed our funders doing this themselves — a clear sign for us to bring it into the platform. Here’s an example.

Conclusions

We expect these changes to do a few things for both sides of the Gitcoin marketplace.

1. For developers, working on bounties will be a clearer process
2. For funders, posting (especially larger, more complex) bounties is easier, and less risk

Project Types Is Live

If either of the above issues created pause for you before, perhaps now’s an opportunity to try again. We’d appreciate the second look.

Feedback Is A Gift

We would appreciate any and all feedback you have! We look forward to growing open source alongside you.