Developer DAO

Near Community and nodes
,
1

Developer DAO

This is a proposal to launch a developer DAO based on Sputnik DAO tech. More details you about Sputnik DAOs can be found here - Account Faucet.

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.

Logistics

  1. Launch dev.sputnikdao.near
  2. Request 20k NEAR from the NEAR Foundation
  3. Onboard a council from people who can source developers to work on such problems from the community.
  4. Establish basics of how payments will be done (how work will be evaluated)
  5. For developers to get paid - they should have their .near account name in their GitHub profile.
  6. To allow developers create a NEAR Wallet - offer a GitHub-based MainNet faucet (more discussion on this is here - Account Faucet).
  7. Find and pay contributors from the past.
  8. Encourage more contributors by posting that this is available in dev communities and in the repos itself.

Work evaluation

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.

Initial council

  • illia.near
  • vlad.near
  • buildlinks.near?
  • zavodil.near?
6 Likes
2

It terms of the budget it may be better to start with 50K NEAR, if you will also reimburse work previously done.

It seems story points would be a good way to go as hourly rates can differ by region.

Can council also submit dev related proposals for payment? That would help determine the council members.

2 Likes
3

Agree with using story points as an intermediary reward calculation system. We are also considering a similar points system for guilds.

The formula for the final $ or token comp could be:

Final comp= [(story) points] x [geo/skill adjusted hourly/daily wage] x [1-3X multiplier as bonus - speed of delivery, reach on Twitter, quality of work] x [1.2-1.5X multiplier depending on how much of the payment is in $NEAR tokens]

Cc @shreyas @3UN1C3 FYI re Guild points calc! #daos #guilds

1 Like
4

Re SourceCred. I think this could be great for evaluating long term maintenance but it’s not great at rewarding initial work. They have added boosts but it’s unnecessary and could be replaced by just creating open bounties.

Question to you/dev of Sputnik: can we create open pre-funded bounties with target account left open/empty? This will basically turn sputnik into a decentralised bounty network/gitcoin!

1 Like
5

Yes, that was the plan for v2. There is actually a piece of code already for that, just need to hook it up.

1 Like
6

I suggest we break down developer DAO into smaller more thematic DAOs:

  • AssemblyScript DAO;
  • Documentation DAO;
  • DevX DAO;
  • etc.
    The reason is that we want to have different council for each of them, based on the people’s expertise.
1 Like