IPFS Microgrant + per-project payouts #186
Open
opened 2020-02-18 22:27:18 +00:00 by raucao
·
4 comments
No Branch/Tag Specified
master
new-final-deploy
new-final-deploy-2
reimbursement-export
staging
legacy
addresses/rsk-testnet-raucao-1
ipfs-defaults
deletemewhendone
feature/184-improve_withdrawal
tests/contracts-contribution
tests/contracts-kit
kit/add-vault-app
feature/ipfs_hash_in_add_response
chore/bootstrap-on-travis
chore/remove-direct-aragon-cli-dependency
chore/update-dependencies-1
fix/ipfs-config
apm-hack
wtf/package-lock
feature/contributor-balance
feature/constructor-options
v7.5.0
v7.4.0
v7.3.0
v7.2.0
v7.1.0
v7.0.0
v7.0.1
v7.0.0-beta.0
v6.0.0
v5.5.0
v5.4.0
v5.3.0
v5.2.0
v5.1.1
v5.1.0
v5.0.0
v4.0.2
v4.0.1
v4.0.0
v3.0.2
v3.0.1
v3.0.0
Labels
Clear labels
good first issue
ipfs
rsk
scaling
bug
dev environment
docs
duplicate
enhancement
feature
idea
invalid
kredits-1
kredits-2
kredits-3
question
security
ui/ux
wontfix
Good for newcomers
Something is not working
Config, builds, CI, deployment, etc.
Documentation
This issue or pull request already exists
Improving existing functionality
New functionality
Something to consider
Not a bug
Small contribution
Medium contribution
Large contribution
Looking for an answer
release
major
release
minor
release
patch
All your base are belong to us
User interface, process design, etc.
This won't be fixed
Milestone
No items
No Milestone
Projects
Clear projects
No projects
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kredits/contracts#186
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Maybe we could apply for one of these for the upcoming IPFS work: https://github.com/ipfs/devgrants/blob/master/MICROGRANTS.md
A general question/problem, which came up a few times already, is how we can reward contributions to specific parts of the project, e.g. only Kredits or only Chat, or in this case only IPFS-related work.
I just had a quick thought: what if, instead of payouts per project, it works the other way around? As in, the dividend payout would draw from project-specific vaults, according to how much was done for that project? This way, you could still work on anything you want, but if too much work would be done on things that there's no budget for, then everybody would earn less. Thus giving contributors an incentive to get the right vaults filled for things they deem important, while donors/customers can meaningfully signal their preferences and priorities as well.
I like the general idea!
I am just a bit concerned about the complexity to implement it and would first want to have the reimbursements and a normal vault running. :)
Yes, the comment is not about planning priorities, and is completely separate of reimbursements. It is purely about the design of contributor dividends.
Let's try to imagine how it could actually work, without being scared of implementation details during what is still brainstorming phase for dividends. ;)
... also, the same as for reimbursements still applies: we can try the concepts with zero contract implementation first, to validate it and see what the implementation would actually require.