Disincentives For Bad Deliverables

[0x4007]

Sometimes a pull request isn't fully tested properly in the review process, and issues are discovered long after the hunter gets paid.

This idea needs more refinement, but, we could pressure the bounty hunter to redo the bounty they were already paid for by not letting them get assigned to another bounty.

Perhaps we can make a bot command that will lock a bounty hunter to a specific bounty until they are "unlocked" to proceed with solving other bounties?

Inspiration: ubiquity/ubq.fi#12

[rndquu]

we could pressure the bounty hunter to redo the bounty they were already paid for by not letting them get assigned to another bounty

Right now we don't limit max number of issues that can be assigned to a single bounty hunter (I've just successfully self-assigned 3 issues in a row). If we introduce a new bot config parameter responsible for max number of assigned issues to a single bounty hunter (smth like BOUNTY_HUNTER_MAX_OPENED_ISSUES) then in case a bounty hunter needs to redo an issue he was already paid for we could simply reopen the issue and the bounty hunter wouldn't be available to take new ones.

[0x4007]

I think it should default to a single issue assignment UNLESS they already have a pull request in review (they could be waiting for several days for feedback.)

I think it's a bad idea to split a hunter's focus. Its optimal to assign another hunter instead (horizontal scaling.)

[rndquu]

We have to split a hunter's focus if we want him to redo an issue. The "lock/unlock hunter to an issue" mechanism also splits focus.

My point is that the BOUNTY_HUNTER_MAX_OPENED_ISSUES parameter and logic are easier to implement than "lock/unlock" mechanism because the latter introduces a role based access control feature within an organisation.

[0x4007]

I guess I was trying to solve two problems with one solution.

The other problem I didn't clearly articulate here is that sometimes our core team members take too long to process pull request reviews. It's in the organizations' best interest to allow the bounty hunter to continue to be productive if they are willing to, while the core team finishes up accepting (or rejecting) the deliverable.

I think it is unfortunate if the bounty hunter wants to contribute more but they are locked in place due to a low performing core team.

[rndquu]

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.

[0x4007]

I think it sounds like a plan. We just need to test, observe, and potentially iterate.

#245