No funded issue found.
Check out the Issue Explorer
Be the OSS Funding you wish to see in the world.
Looking to fund some work? You can submit a new Funded Issue here .
Time left
Opened
Issue Type
Workers Auto Approve
Project Type
Time Commitment
Experience Level
Permissions
Accepted
Reserved For
Granular Pricing Engine: Store estimated hours to complete work in the funder form in the Gitcoin data model
gitcoinco
JavaScript, Python, HTML, CSS, Shell, Makefile, Dockerfile, Smarty
### 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.
### Appendix
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.
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:
**(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.
Setup your profile
Tell us a little about you:
Skills
No results found for [[search]] .
Type to search skills..
Bio Required
[[totalcharacter]] / 240
Are you currently looking for work?
[[ option.string ]]
Next
Setup your profile
Our tools are based on the principles of earn (💰), learn (📖), and meet (💬).
Select the ones you are interested in. You can change it later in your settings.
I'm also an organization manager looking for a great community.
Back
Next
Save
Enable your organization profile
Gitcoin products can help grow community around your brand. Create your tribe, events, and incentivize your community with bounties. Announce new and upcoming events using townsquare. Find top-quality hackers and fund them to work with you on a grant.
These are the organizations you own. If you don't see your organization here please be sure that information is public on your GitHub profile. Gitcoin will sync this information for you.
Select the products you are interested in:
Out of the box you will receive Tribes Lite for your organization. Please provide us with a contact email:
Email
Back
Save
