BOUNTY_HUNTER_MAX_OPENED_ISSUES Configuration

[0x4007]

BOUNTY_HUNTER_MAX_OPENED_ISSUES environment variable to override the maximum amount of issues that a bounty hunter can simultaneously work on. Set the default the value to 2. This is intended to accommodate the following scenario:

• A bounty hunter begins working on a bounty.
• The bounty hunter opens their pull request and waits for the review.
• The bounty hunter continues on the second issue.
• The bounty hunter handles the pull request review adjustments and closes, while opening the pull request for the second issue.

---

Then set BOUNTY_HUNTER_MAX_OPENED_ISSUES to 2 or 3. This way a bounty hunter has a plenty of space in terms of issues he wants to solve.

Example:

1. BOUNTY_HUNTER_MAX_OPENED_ISSUES=2
2. Bounty hunter creates a PR that solves issue 1
3. Bounty hunter starts issue 2
4. Project team merges PR for issue 1
5. Project team reopens issue 1 because bounty hunter has to redo it
6. Bounty hunter creates a PR that solves issue 2

At this stage a bounty hunter has 2 opened issues and has to redo issue 1 because he is not allowed to self assign more than BOUNTY_HUNTER_MAX_OPENED_ISSUES=2 issues.

Originally posted by @rndquu in #277 (reply in thread)

---

          We still need to create the feature to enforce this DevPool rule inside of the bot logic.

Originally posted by @pavlovcik in #134 (comment)

P.S. When this task is ready we should also add the BOUNTY_HUNTER_MAX_OPENED_ISSUES to the config generation page

[seprintour]

/start

[ubiquibot]

@seprintour The time limit for this bounty is on Thu, 04 May 2023 06:39:37 GMT

Your currently set address is:
0x3623338046b101ecEc741De9C3594CC2176f39E5
please use /wallet 0x4FDE...BA18 if you want to update it.

[seprintour]

This is intended to accommodate the following scenario:

• The 3rd issue will be rejected

Will the second issue be rejected too and an exception if a PR is linked to the first issue already? @pavlovcik

[rndquu]

This is intended to accommodate the following scenario:

• The 3rd issue will be rejected

Will the second issue be rejected too and an exception if a PR is linked to the first issue already? @pavlovcik

Keep it simple, don't check linked PRs, simply check how many open issues a bounty hunter already have. If a bounty hunter prints /assign then if number of opened issues >= BOUNTY_HUNTER_MAX_OPENED_ISSUES then the bot should show an error like Too many opened issues.

[seprintour]

/start

[ubiquibot]

@seprintour The time limit for this bounty is on Thu, 04 May 2023 22:34:57 GMT

Your currently set address is:
0x3623338046b101ecEc741De9C3594CC2176f39E5
please use /wallet 0x4FDE...BA18 if you want to update it.

[seprintour]

Keep it simple, don't check linked PRs, simply check how many open issues a bounty hunter already have. If a bounty hunter prints /assign then if number of opened issues >= BOUNTY_HUNTER_MAX_OPENED_ISSUES then the bot should show an error like Too many opened issues.

Okay, made a PR with the check

[Steveantor]

it should check for linked PRs, sometimes PRs stay open a lot longer (awaiting reviews or team unavailability)
this will slow down the overall development,
2 is also a very limiting number

[seprintour]

it should check for linked PR

Because a PR is linked, doesn't mean the hunter is done with the task.. so it can be exploited

But yea, we can look at the max number

[seprintour]

I just think PRs should be handled more quickly, its really slow

[Steveantor]

it should check for linked PR

Because a PR is linked, doesn't mean the hunter is done with the task.. so it can be exploited

But yea, we can look at the max number

I don't think so, trying to abuse that system will result in a ban,
aside from that, they can't steal any permits in such a way.

[0x4007]

will result in a ban

The benefit of our setup is that we have core contributors who keep common sense in the system (and can easily notice hunters attempting to exploit the system) while we have the bot handle the rest.

[0x4007]

I just think PRs should be handled more quickly, its really slow

@0xcodercrane

[ubiquibot]

[ CLAIM 200 DAI ]

0x3623338...176f39E5

[0x4007]

An improvement idea is to check all of the open pull requests of the bounty hunter, and then check the state of the pull request review.

If they have a pull request open but no review started, then it counts against their quota.

If they have a pull request opened and also have a "review" in progress (perhaps there is an api to get a Boolean for this) then they are able to start working on another bounty.

Next level beyond could be a
one day "cool down". If there's longer than a 24 hour delay by the core team/reviewers, then "unlock" the bounty hunter to work on another issue.

[Steveantor]

An improvement idea is to check all of the open pull requests of the bounty hunter, and then check the state of the pull request review.

If they have a pull request open but no review started, then it counts against their quota.

If they have a pull request opened and also have a "review" in progress (perhaps there is an api to get a Boolean for this) then they are able to start working on another bounty.

Next level beyond could be a one day "cool down". If there's longer than a 24 hour delay by the core team/reviewers, then "unlock" the bounty hunter to work on another issue.

And maintainers/members should be exempted from the limits.

[0x4007]

Technically they can override this behavior as they are able to use the GitHub UI to assign themselves!

But I know that multitasking is less efficient than single tasking for producing high quality work.