The goal would be to incentivize more contribution across various projects in the NEAR Ecosystem to improve tooling and potentially even apps and projects.
For example, there are 80+ issues in near-api-js which right now are mostly not being addressed. Offering a way to get paid to work on individual issues can attract more developers.
This will also grow the number of active developers in the Ecosystem, and will serve as a way to learn how different pieces of the ecosystem work.
- Launch dev.sputnikdao.near
- Request 20k NEAR from the NEAR Foundation
- Onboard a council from people who can source developers to work on such problems from the community.
- Establish basics of how payments will be done (how work will be evaluated)
- For developers to get paid - they should have their .near account name in their GitHub profile.
- To allow developers create a NEAR Wallet - offer a GitHub-based MainNet faucet (more discussion on this is here - Account Faucet).
- Find and pay contributors from the past.
- Encourage more contributors by posting that this is available in dev communities and in the repos itself.
Given how Sputnik works, anyone can apply to pay for something to another person.
Which means that there are three ways this can go:
- A developer themself applies for payment
- A maintainer of the repo applies to pay to a contributor
- A council member can nominate a developer to get paid
In all three options, there are ground rules around payments:
- The description should link to a GitHub’s Pull Request that was merged into master.
- This Pull Request should refer to an existing issue.
If a contributor / developer applied for a payout themself, the council can reach out to a maintainer to check how much they value such a contribution.
There are no clear baseline costs here right now. If there are suggestions, please leave a comment.
There were few options suggested in offline discussion:
- Use SourceCred or similar scoring system of the code.
- Let maintainers to attach “story points” to the issue, identifying how hard / long it would take to do something.
- Use some form of mechanism design, where a fixed amount of money gets distributed across all of the repos. This is though hard to structure as units of work are very uneven.