As a hunter, I do not want to see 'Open' issues on the Issue Explorer that are actually closed on Github so I can save time finding issues.
To help clean up the 'Open' section of the Issue Explorer
Type: Feature
There are some issues which are 'Closed' on Github, but 'Open' on Gitcoin.
Automatically hide bounties which are listed as 'Open' on Gitcoin, but are closed on Github.
Reviewers: @owocki @mbeacom @PixelantDesign
Hey i'm taking a look at this.
Thanks.
Hi all I forked & cloned the gitcoinco/web code last night, noticed a broken link in the StyleGuide while reviewing the Contributing docs and so I created my first Issue #2460, fixed it and submitted my first PR, just to get my feet wet :-)
I did not get my local dev environment docker container fully up and running tho -- am working on that today -- but would like to tackle this next, if possible!
thanks!
-dave
@CPPDevCrypto All you should have to do is automatically filter on is_issue_closed from the API.
As i got into this, I realized it only seems to make sense to automatically hide Bounties whose GitHub Bugs are closed when the Project Status: "Open" checkbox is checked!
When the user has selected any other Status option (Work Started/Submitted/Done, Expired, Canceled or even "Any") then I think they'd want to also see Bounties whose Bugs had been closed. To do otherwise would create new user experience bugs such as "I started work on a Bounty but now it has disappeared entirely from the Explorer!" when the repo owner closes the bug on Github... right?
So my whole "can't think of a case where anyone would want to see Bounties for closed bugs" really only applies to Bug Bounty Hunters looking for new "Open Bounties" to work on. If you've checked any of those other Status values, you are clearly looking for something else -- something in progress or historical.
So now I think I should only add the is_issue_closed=0 filter to the url when the idx_status=open. Thoughts?
@davidkaufman
I've edited the definition of done...please let me know if you have any questions!
As i got into this, I realized it only seems to make sense to automatically hide Bounties whose GitHub Bugs are closed when the Project Status: "Open" checkbox is checked!
Is there a reason we should only apply this to bugs and not all closed issues?
When the user has selected any other Status option (Work Started/Submitted/Done, Expired, Canceled or even "Any") then I think they'd want to also see Bounties whose Bugs had been closed. To do otherwise would create new user experience bugs such as "I started work on a Bounty but now it has disappeared entirely from the Explorer!" when the repo owner closes the bug on Github... right?
can you clarify ^?
So my whole "can't think of a case where anyone would want to see Bounties for closed bugs" really only applies to Bug Bounty Hunters looking for new "Open Bounties" to work on. If you've checked any of those other Status values, you are clearly looking for something else -- something in progress or historical.
ok
So now I think I should only add the is_issue_closed=0 filter to the url when the idx_status=open. Thoughts?
I defer to @mbeacom @SaptakS on implementation.
@PixelantDesign
Is there a reason we should only apply this to bugs and not all closed issues?
I believe he referred to all issues as bugs !
@davidkaufman
So now I think I should only add the is_issue_closed=0 filter to the url when the idx_status=open.
Yup ! In my head that sounds about right!
When the open filter is checked in -> we should not show issues who's github issues are closed
If any other filter is selected it should be the same behavior as we have now ^_^
Is there a reason we should only apply this to bugs and not all closed issues?
I believe he referred to all issues as bugs !
That's right -- I was using the term Bug to refer to GitHub any GitHub issue...
@davidkaufman
So now I think I should only add the is_issue_closed=0 filter to the url when the idx_status=open.
Yup ! In my head that sounds about right!
When the open filter is checked in -> we should not show github issues which are already closed.
Other states it should be the same behavior ^_^
Great -- will do it this way... I'm playing with the Github API now to see how to do this (neither is_issue_closed=0 or is_issue_closed=false seems to be doing the trick :-) but don't spoil the fun by telling me! I'll dig into the API source if necessary... heheh
hey there @davidkaufman - did anything ever work out regarding the api? :-)
Most helpful comment
That's right -- I was using the term Bug to refer to GitHub any GitHub issue...
Great -- will do it this way... I'm playing with the Github API now to see how to do this (neither is_issue_closed=0 or is_issue_closed=false seems to be doing the trick :-) but don't spoil the fun by telling me! I'll dig into the API source if necessary... heheh