As a funder, I want to changeBountyFulfillmentAmount() for contest/cooperative bounties, so I can pay out multiple submissions

[owocki]

User Story

As a funder, I want to changeBountyFulfillmentAmount() for contest/cooperative bounties, so I can pay out multiple submissions

See this method in standardbounties: https://github.com/Bounties-Network/StandardBounties/blob/master/contracts/StandardBounties.sol#L444-L452

Why Is this Needed?

Summary:
This is needed so that funders can pay out their bounties to multiple people in contest/cooperative bounty types.

Description

Type:
Feature

Current Behavior

Only can payout the total amount to one person

Expected Behavior

Can payout any amount to n people

Solution

Summary:

For cooperative / contest bounties ONLY:

• Add a new form that implements changeBountyFulfillmentAmount(). You may copy the 'increase payout' form. This form should have an input that allows the user to select the number of payees, and the payout amount will be auto-calculated and estimated in the form as an HTML element.
• When the user submits the above form, the bounty details page will update with the following new pieces of info: (1) the number of payees and (2) amount paid per payee
• In the 'accept fulfillment' form, the user will be reminded what the payout amount for the fullfillment they are accepting is
• The bounty will only be work done if num_payees >= num_accepted_fulfillments

Definition of Done

above is implemented

Additional Information

Project Schemes just launched https://medium.com/gitcoin/we-listened-announcing-project-types-965a02603559

Bounty Instructions -- IMPORTANT

• This feature is due in 2 weeks.
• Don't apply if you're not going to follow through.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 1.0 ETH (586.42 USD @ $586.42/ETH) attached to it.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $21,243.48 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

Work has been started.

These users each claimed they can complete the work by 8 months, 3 weeks ago.
Please review their action plans below:

1) darkdarkdragon has started work.

will ask question after checking current code

Learn more on the Gitcoin Issue Details page.

[owocki]

from @mbeylin

remember you can only call that when it’s in draft mode

so this might torpedo the entire project

[mbeacom]

Yikes. Any other details? Sounds like we'll have to wait for standard bounties 2.0 or modify this bounty to build out a batch "tipping" mechanism tracked as bounty fulfillments or something similar.

[owocki]

heres the convo with mark

sounds like the only action path available to us is to figure out the number of contributors in the new funder form and to insert that into the bounty upfront on gitcoin.co/new

[kyriediculous]

This will need a completely new bounty implementation which I see as perpetual or batch bounties.

We're implementing this in a private setting so for us it's easy, perpetual bounties can only be issued by team managers who have the authority to mint tokens.

When implementing it in a public setting a issuer would have to approve a multiple of tokens that are rewarded for one completion. When submitting a new proposal it should check if there is still tokens in approval, for each submission a temporary balance of the available approved funds would be kept.

This would require a change in ERC20 tokens to be a hard approve instead of a soft approve, otherwise the approved tokens can be spent and not be available to accept proposals (free answers for the bounty issuer). This would be compliant with the hollywood principle , whereas just calling transfer() isn't considered a good idea. Another option is adding transferAndCall and a tokenFallback (see ERC223)

[darkdarkdragon]

sounds like the only action path available to us is to figure out the number of contributors in the new funder form and to insert that into the bounty upfront on gitcoin.co/new

looks like this will not solve original problem - to be able to pay to a random number of developers
so, what should we do with this task?

[austintgriffith]

I'd like to keep my ears open for updates on this.

First of all, what is the progress with a new version of Standard Bounties? Is there anything I can do to help with that? There are a handful of things I'd like to see added to the standard.

Second, I'm thinking of building something that would leverage Colony.io to divide a large Standard Bounty into smaller domains and tasks. It would require a middleware contract to accept the Standard bounty funding and divide it up between active token holders of the colony: JoinColony/colonyHackathon#39

I've discussed this briefly with @owocki, but this was before "community" bounties were released. It might also not be needed so I was hoping to get some feedback on direction not only on my work but also the new standards.

[owocki]

First of all, what is the progress with a new version of Standard Bounties? Is there anything I can do to help with that? There are a handful of things I'd like to see added to the standard.

cc @mbeylin on this ethereum/EIPs#1081 is where it lives

[owocki]

i'm canceling this bounty since it seems like the way its written is infeasible. will post a follow up ticket shortly

[owocki]

#1422

[gitcoinbot]

Issue Status: 1. Open 2. Cancelled

---

The funding of 1.0 ETH (522.28 USD @ $522.28/ETH) attached to this issue has been cancelled by the bounty submitter

• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $24,843.83 more funded OSS Work available on the Gitcoin Issue Explorer