search

ethereumproject / bountyetc

Fund Github issues for Ethereum Classic development using ETC
Apache License 2.0
1 stars 3 forks source link

Initial bounty issue contract PoC implementation #2

Closed sorpaas closed 7 years ago

sorpaas commented 7 years ago

Loosely follow #1, but change assessClaim to approveClaim for proof of concept simplicity.

laddhoffman commented 7 years ago

Awesome! I will need to set up a dev environment and check this out.

laddhoffman commented 7 years ago

I made progress on setting up my environment. I should have this reviewed soon

sorpaas commented 7 years ago

Thanks! Some online Solidity compilers might also work if setting up environment locally is not convenient. Like https://ethereum.github.io/browser-solidity

👍

laddhoffman commented 7 years ago

Ok, I at least got it to compile. Haven't tried running it yet.

I note that you have it set up so that each donor can independently approve claims, up to the max they have donated for the issue. That makes sense.

Looks like a good start, thanks!

sorpaas commented 7 years ago

Thanks for the review! I'm going to merge then. Let's not keep PRs staled. 😃

laddhoffman commented 7 years ago

I was just about to approve it :) I wrote some unit tests, will submit soon.

splix commented 7 years ago

Want to add $0.02. Please don't focus on bounties for Github Issues. It's better to make it more general, for independent projects.

If we'll make it for github issue, then we should figure out which issues should be paid, which should not. Because it will be unfair if someone will spend day of development for free, but someone with 1hr job will receive money.

I think it could work better for larger independent projects. Say 2-8 weeks project for a small team. Something specific and with a clear scope. For example "make a Windows Mobile version of Emerald Wallet". Some agency specializing on Windows Mobile can do that if you'll setup a good bounty.

sorpaas commented 7 years ago

(@splix mind to move our discussions to #1? It would be easier for people who want to join the discussion to find all related comments and arguments. 😄)

Agree with you on that point. If it can work for a general case, it's certainly better. The contract level would be the same -- it would just be that issueUrl now points to a description url instead of a Github issue.

For the frontend, if we want to save time, it can just be a general dapp that lists all the current contracts and points to the given issueUrl. If it is a Github issue, then it links to Github. If it is a proposal for "make a Windows Mobile version of Emerald Wallet", then link to the description for the complete task. I would think of this as something like the Dash Budget Proposal, but without central funding, and each doner uses his or her own donations to indicate the voting.

sorpaas commented 7 years ago

(I would actually worry less about figuring out which issues should be paid. Each doner decides which issue he or she wants to fund. So it relies on the rationality of the ETC economics. But I might be wrong about this.)