Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Ethical ads to power Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
KERNEL is an 8-week, invite-only program for top tech talent looking to build relationships, products, and companies in blockchain and Web 3. 100 tal…
Heyo Gitcoiners! With an entire city of hackers, coders and blockchain innovators relocated on our platform, the atmosphere is just buzzing with crea…
Type in [[ 2- term.length]] more characters to get results
[[ result.title ]]
[[ result.description | truncate(70) ]]
No matches found
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
### User Story
As a Gitcoin admin, I'd like data on the estimated hours to complete work in the [funder form](https://gitcoin.co/funding/new) updated on the Gitcoin data model.
### Why Is this Needed
Currently, funders can price the issue based on the total price, but that doesn't give any other information on whether or not that hourly rate is sufficient for their issue to get completed. Adding an input field for hours estimation allows for an hourly rate calculation, which translates to a predicted bounty success rate. This data will be populated in our data model so we can calculate hourly rates in the future, and hopefully improve our pricing mechanism via analytics.
### Current Behavior
https://github.com/gitcoinco/web/issues/2158 has been pushed. Estimated hours of Work is present on the funder form, but the data model has not yet been updated to capture hours that have been inputted.
### Definition of Done
1. Add estimated hours of work to the data model.
2. Ensure that the data is persisted in the data model to Postgres.
### Future Discussions (NOT IN SCOPE)
[Previous strategic discussions here](https://github.com/gitcoinco/web/issues/21).
Eventually, we want to move away from modular pricing to more market-based pricing, something like a variable system that increases payout over time for bounties (e.g a "count-up" timer) that increases the incentive at a steady rate until the market finds the incentive attractive or it hits an upper cap limit. There would be additional scoping, discussion, and discovery of attack vectors to see this through.
1. What happens to the incentive if someone repeatedly starts work and then stops to stall the issue?
2. A user can also start and stop work using multiple user names to stall the issue until the incentive increases.
3. Bounty hunters might start the work prematurely but wait longer to actually hit "start work" in order to collect a higher payout. Alternatively, they can also start work, actually do the work, pretend like they can’t finish, and have a friend or another alias submit the work at a later time for greater incentive.
Based on Gitcoin data, an analysis was done that yielded a relationship:
**(0.002 x Hourly Rate) + 0.65 = Predicted Success Rate**
This gives us the ability to estimate success percentages by the hourly rate, at the granularity of a dollar (for every $ increase, we have a 0.2% percentage point increase in success rate).
The success rate curve should be made more granular but would suggest that what pops up is a change in success rate given different input values of issue payout and hours estimation for the task, not a change in hourly rates at defined points.
Of course, we need data to back this up. I converged on three main metrics to look at:
1. Success rate (for bounties priced at this range, what is the success rate? Higher is better).
2. Median time to start bounty (for bounties priced at this range, what is the time elapsed before the bounty is picked up? Shorter is better).
3. Median time to complete bounty (for bounties priced at this range, what is the time it takes to finish the bounty? Shorter is better).
Explorations on 2 and 3 yielded no significant correlations, even after segmentation by experience level, bounty types, and deadlines. I'm not comfortable here making any suggestions on pricing related to these two metrics.
![screen shot 2018-08-28 at 10 04 32](https://user-images.githubusercontent.com/7516920/44744948-2d467a80-aabb-11e8-9187-fb7ee5b66466.png)
![screen shot 2018-08-28 at 10 04 45](https://user-images.githubusercontent.com/7516920/44744952-2fa8d480-aabb-11e8-9f55-1baf72884984.png)
Success rate yielded a weak positive correlation with regression, which gives us a more granular scale on how success rates change with increasing or decreasing hourly rates:
![screen shot 2018-08-28 at 10 05 05](https://user-images.githubusercontent.com/7516920/44744960-38010f80-aabb-11e8-957b-d608b4951134.png)
**(0.002 x Hourly Rate) + 0.65 = Success Rate**
For success rates, when categorizing them into buckets, our data becomes increasingly sparse, so finding a smoothed out curve in the upper echelons has not yielded super promising results. There fore, near the higher hourly rates, this analysis breaks down due to small sample size and high variance. The relationship was established post-eliminating low sample size and extreme outlier data, so caveat emptor.
It does, however, align with @owocki's Medium analysis. Starting success rate for bounties ~ 65%, with every increase of a $/hour, we see a 0.002 percentage point increase in success rate. If we calculate success rates at the pre-defined points:
$20 ~ 70%
$40 ~ 75%
$80 ~ 81%
$120 ~ 90%
and the ability for success percentages in between, at the granularity of a dollar.