Web: Bounty doesn't cancel when an issue is closed via Github

[ConnorChristie]

User Story

As a funder, I want my bounty to be cancelled when the Github issue is closed

Why Is this Needed?

Summary: When an issue is closed via Github, the bounty remains open on Gitcoin. Users still think the bounty is open when in-fact it isn't.

Description

Type: Feature

Current Behavior

Bounty remains active when an issue has been closed.

Expected Behavior

Bounty should be marked as cancelled when Github issue is closed.

Reproduction

Example bounty: https://gitcoin.co/issue/ethereum/solidity/4081/387
Github issue: https://github.com/ethereum/solidity/issues/4081

Solution

Summary: Mark the bounty as cancelled when a Github issue is closed

Definition of Done

• The bounty is marked as cancelled
• Deposit is refunded to bounty funder

[mbeacom]

@ConnorChristie At the moment, we intentionally don't alter the Bounty if the associated github issue is closed.

[ConnorChristie]

Is there any reason why it doesn't close the bounty?

[vs77bb]

@ConnorChristie The closed status on Github may also be a sign that a PR is completed and should be paid out, as opposed to cancelled.

However, I agree with the ethos of this request. If a PR is closed, perhaps it should escalate to us in order to prompt the funder to take a look 🤔

[davidkaufman]

Makes sense that you wouldn't want to cancel the bounty if someone is working on it, especially if they have submitted a pull request, and are maybe just waiting to et paid!

But... in a case such as this:
https://github.com/paritytech/parity/issues/8909

No one ever claimed the bounty, no PR was submitted (because the work was canceled), so I guess my wish is that:

As a developer looking for work in the Gitcoin Explorer, I'd expect that "closed github issues" would be filtered out of the default view (especially since that default view is named "open" :-), though I understand that the bounty may still be open even though the github issue is closed) since, regardless of whether the GitHub issue is closed because no work is to be done, or closed because the work is already done, there is no "open" bounty to be claimed, no money to be made and, in this case, having to read all the way through that very long issue thread to discover there was no money to be made there, seems like a waste of time that the gitcoin explorer might have save me :-)

[davidkaufman]

PS: if you put a bounty on THIS issue, I'd be happy to make this my first bounty: adding a checkbox to the gitcoin explorer filter-tweaker that says "Show Open Github Issue Only" and is pre-checked by default!

[owocki]

@PixelantDesign what do you think about the resolution that @davidkaufman proposed here?

[owocki]

id be fine bountying it if we can come to product direction that we all agree upon

[davidkaufman]

Well this bug struck again in a particularly awful way this week, this time in the form of the email blast that went out on 10/4 to all of us wannabe Gitcoin contributors with the lightning-bolted subject line:

⚡️ 7 New Open Funded Issues worth $12088.23 matching your profile

Sadly, the bulk of that admirable and exciting ten-grand-plus funding total was completely bogus, wrt to the words “New”, “Open” and “Funded” that preceded it in the subject line (at least in the way that Gitcoin devs interpret those adjectives).

ChainshotDapps: Merkle Tree Lesson
Amount: 45.00 ETH ($10087.56)
Posted: 3 hours ago
Keywords: JavaScript

I’ll admit I may have been over-excited to see that big number, thinking maybe Gitcoin actually could become a full time job for me some day soon! …and I’ll admit that’s an increasingly desperate hope for me lately, after having been laid off from my comfortable programming job of 13 years recently, and having been struggling for months to find a new place in a completely changed workforce of younger programmers and new technologies after having myself already attained fallen headlong past the half-century mark of life on this Earth :-) (but I digress -- this is about Gitcoin, not me (or my starving family (lol)))

But at least this time I know I’m not the only Gitcoin Bug Bounty Hunter that fell victim to this cruel bug, because no less than EIGHT other developers applied to work on it, most posting detailed proposals and asking thoughtful questions:

On this CLOSED GitHub BUG: https://github.com/ChainshotDapps/content/issues/1
With this perplexingly OPEN Gitcoin BOUNTY: https://gitcoin.co/issue/ChainshotDapps/content/1/1347

And we may never know how many other devs like me -- how many emails went out? Probably all of us -- read the entire thing, and it’s pretty long, and saw all the others applying to work on it and knowing that no one had YET been selected, getting happier and happier that we still might have a shot at this big payday… only to be bitterly disappointed when the funder finally posted his apology and announcement that the the developer had already been selected, and in fact the work was already done. Then, it just adds insult to injury to, as developers ourselves, realize that this horrible waste of time, effort and optimism was caused not by forgiveable human error -- but a software design bug. If it feels like a bug in the user experience, it's a bug.

Kevin, you’re right — there are certainly larger issues lurking beneath this bug! But they are not technical issues, they are basic design decisions, and i don't think that intelligently resolving those serious, long term big-think issues precludes or should in any way block progress on fixing this simple, very visible bug that is frustrating Gitcoin users (developers), possibly running off people who were looking to become Gitcoin Bounty Hunters, and IMO making the project look bad and potentially damaging its reputation. The underlying Big Issues seem to me to stem simply from a bad choice of words. You see, to end users (be they the developers or the funders) the difference between a Gitcoin bounty and its underlying GitHub issue are simple and clear: we all know what a software bug is, and what it means for a Bug (GitHub issue) to be “Open” or “Closed”, but Gitcoin muddied the waters by choosing to apply those same terms (the words “open” and “closed”) to apply to the very different, more subtle, complex and unfamiliar states of a Bounty (Gitcoin Issue) associated with that Bug, which has a lifecycle and workflow of its own, and a state -- a status attribute -- of its own that is separate but intertwined, interrelated and interdependent of the status of the associated Bug.

So I think the crux of the fix (for the thorny underlying Gitcoin design issues) will be abandoning the use of the words Open and Closed to describe the states of a Bounty in any way at all (for the sake of user clarity) and probably a complete rethink of ALL of the possible states that a Bounty can validly be in, what they should be called (WITHOUT overlapping or overloading the Bug’s own pre-existing, well-defined and well understood state names!) and what transitions that a Bounty may/should/must undergo in direct response to the state changes of the Bug that are external to Gitcoin. It’s like nine times harder to code a Finite State Machine for Bounties when they must interact in sensible, well-defined ways with an external Bug software system that is out of its operational control or design domain. BUT!! It's a hundred times easier (than most such interplay projects) because the particular external System we must interface with is GitHub, a very heavily used, and so well documented system that its almost 100% transparent, has awesome API’s and, most of all, is unlikely to change very much beneath our feet!

All that said, THIS bug is not deep, complicated, or thorny at all. IMO there should be no debate or discussion needed whatsoever! This bug is a simple band-aid (which may grow to become a whole box of bandaids, the longer it takes to fix the underlying design issue!) that should be applied quickly to mitigate the worst user experience consequences of the actual underlying problem.

The technical problem is that (to say it all agile-like):

As a developer, I don’t want to see Bounties whose underlying Bugs are “Closed” in my search results, when I use the web-based Gitcoin Explorer to search for “Open” Bounties (because again, as a developer, although I’m smart enough to understand the subtleties, I shouldn’t have to think about and consciously exclude the disheartening edge case of "a Bounty that is Open for a Bug that is Closed", when looking for work so I can put food on the table to feed my family :-) Right?

And after this new email debacle, I’d add a second “story” band-aid:

As a wannabe Gitcoin Bounty Hunter, I don’t want to see "Open" Bounties whose underlying GitHub Issue Bugs are “Closed” in my email inbox either, especially misrepresented as “New Open Funded” Bounties -- I know, "the Bounties can be Open even tho the bugs are Closed" but, to me, that is a bug, not an argument!

So again I’d propose the simple technical band-aid fix of filtering OUT the tragic and confusing edge case of Open Bounties whose Bugs are Closed when choosing which Bounties are to be included in the email you send to developers looking for work, and most especially, when computing the big DOLLAR sum total amount of what the included New Open Funded Issues are “worth”, that we we brag about in the email subject line.

And I’m still happy to make this my first Bounty !! Because tho I may be a dinosaur when it comes to dApps and crypto proofs and smart contracts and tokens... I can still fix web apps and bulk email systems!

Thanks!

-dave

[owocki]

@davidkaufman thanks for the thoughtful feedback. i really appreciate it when yall speak up, feedbcak is a gift.

@davidkaufman @PixelantDesign as far as product changes that we can do immediately for this.. perhaps we should remove any issues that have github issues that are closed from the daily "X new issues worth $YYYY" email.

As a developer, I don’t want to see Bounties whose underlying Bugs are “Closed” in my search results, when I use the web-based Gitcoin Explorer to search for “Open” Bounties (because again, as a developer, although I’m smart enough to understand the subtleties, I shouldn’t have to think about and consciously exclude the disheartening edge case of "a Bounty that is Open for a Bug that is Closed", when looking for work so I can put food on the table to feed my family :-) Right?

to David's point above, perhaps we could also have a 'filter out closed github issues' checkbox on the issue explorer that is checked by default.

And I’m still happy to make this my first Bounty !! Because tho I may be a dinosaur when it comes to dApps and crypto proofs and smart contracts and tokens... I can still fix web apps and bulk email systems!

@davidkaufman hehe... smart contracts and tokens are not all that hard.. when i started gitcoin i just commited to learning a new thing (or 3) every single day! want to shoot me a DM on slack to chat a little more? you seem like youre thoughtful, articulate, and you care for gitcoin -- so i want to brainstorm on this together

[PixelantDesign]

@davidkaufman thanks for the feedback and I'm very sorry to hear about the frustrating experience. I just reviewed all of the open issues myself and noticed the pattern of closed GitHub issues showing open repeatedly on the issue explorer. I agree with the thoughts above on a few immediate improvements that we could make.

1. Remove closed Github issues from the daily "X new issues worth $YYYY" email.
2. Remove closed on Github issues _from the issue explorer_.
3. We prevent frustration so that contributors don't click on an issue to find later on GitHub that it has been closed.
4. Funders who want to find these issues again can use the Created by Me in the left panel.
5. If internal team members need to access these issues, we are able to do so through the moderation panel on the left for fund retrieval, etc.

Thoughts?

[davidkaufman]

:thumbsup: @PixelantDesign

Agreed 100%

I had proposed adding a checkbox to the left nav, that was initially checked by default, labeled something like "Open GitHub Issues Only" that would let anyone access them, but looking at it again now, I don't see an obvious place for it, and adding a new collapsable, group of options containing just this one option seems awkward and, more importantly, I can't think of a single use case where a visitor would want to see Bounties whose Bugs were closed...

So yes, it would be simpler and cleaner just to filter them out behind the scenes, with no UI changes needed at all

-dave

[owocki]

So yes, it would be simpler and cleaner just to filter them out behind the scenes, with no UI changes needed at all

interesting idea.. i could see it

[vs77bb]

Created a fresh issue for this here -- great feedback + discussion, appreciate your thoughts @ConnorChristie @davidkaufman! https://github.com/gitcoinco/web/issues/2458

[thelostone-mc]

Closing this out as we've got another ticket following this up as mentioned ^
( Duplicate tickets end up being chaotic 😅 )