Feature Tracking: Self Assignment of Bounties

[humansinstitute]

Goal

Allow Bounty Hunters to Self Assign Bounties by placing money at risk.

1. Bounty Hunter sees a bounty they can easily resolve
2. Hunter checks timing and delivery criteria
3. Hunter self stakes 50-100% of the award dependant on the requirements.
4. Hunter gains ticket exclusivity for the next xyz hours
5. Pull request is logged against the ticket
6. Funds returned to user
7. If pull request is accept payment made
8. Results of self assignment success/fail retained for later use in reputation system.

Considerations

The following points need to be considered and design in the system.

• Timers on tickets
• Bonus for incentivised early delivery
• Staking of Funds against a ticket
• Conflict resolution (default to pay out and write better tickets)
• Tracking of results and controls for ticket squatting

[jordan-ae]

This feature sounds really interesting. What if the hunter isn't able to close the bounty or open a pr in the X amount of time he had secured exclusivity for what happens to the funds staked?

[aliraza556]

Sounds like a great feature, @humansinstitute! I like the idea of staking and self-assignment.

Self-assignment process:

I have a suggestion: When the owner creates a new issue and multiple users comment on it, the first user to comment with /attempt could be auto-assigned to the issue. The time allotted for the task could be automatically determined based on the issue type — for example, 2 days for a bug, 3 days for a normal feature, and 5 days for a larger feature.

If the assigned user doesn’t complete the task or submit a PR within the given time, the issue and Bounty could be automatically reassigned to the next user who comments.

[humansinstitute]

@aliraza556 For clarity we wouldn't want to build additional functionality into github, but this would be bounty site first. So you would want to track open bounties there and self assign.

@jordan-ae Current thought is the user places these sats at risk to gain exclusivity so funds would be forfeit on the failure lack of PR. This would need phasing and testing though I think so perhaps first phase this would be a manual decision by PM so if its a one off, or there are issues with the ticket that make it impossible / more difficult to resolve then it could be retained. Whereas if someone is squatting many tickets and not resolving then they lose the sats to discourage this behaivour.

This also wouldn't replace PM led assisgnemts completely but would allow people who are online and know they can resolve this ticket to do so without additional friction.

[aliraza556]

@aliraza556 For clarity we wouldn't want to build additional functionality into github, but this would be bounty site first. So you would want to track open bounties there and self assign.

@jordan-ae Current thought is the user places these sats at risk to gain exclusivity so funds would be forfeit on the failure lack of PR. This would need phasing and testing though I think so perhaps first phase this would be a manual decision by PM so if its a one off, or there are issues with the ticket that make it impossible / more difficult to resolve then it could be retained. Whereas if someone is squatting many tickets and not resolving then they lose the sats to discourage this behaivour.

This also wouldn't replace PM led assisgnemts completely but would allow people who are online and know they can resolve this ticket to do so without additional friction.

Hi @humansinstitute, @tomsmith8: For Bounty Site

Automated Bounty Creation:

• When the owner creates a new issue, a corresponding bounty is automatically generated using predefined fields like Bounty Title, Category, Description, Price, and Estimated Completion Date.
• The system takes these values from the issue and fills out the Post a Bounty form, assigning it to the first commenter.

Payment Process:

• Option 1: When a user's PR is merged into the main branch, the system automatically captures the PR number and processes the payment.

• Option 2: After a user's PR is merged, they can use the Claim Bounty button to submit the merged PR number. Once entered, the payment for the bounty is added to their balance, and the bounty is marked as Paid.

For example:

If PR is not maerged then get error:

If user enter wrong PR then get error:

etc.

This way, the admin only needs to create the issue, and everything else—from assign to payment—is fully automated.

[tomsmith8]

@humansinstitute i'd also like to have the option to stake or not to stake. There may be cases where you don't want to stake or need to assign to a specific hunter

Looks great though, excited about self-assignment and manual payout decisions with reputation :)