Add > 50 stars criteria to feeling-lucky

[bnb]

In testing https://github.com/bnb/good-first-issue/pull/57, I noticed that 5 of the first 7 runs of the good-first-issue feeling-lucky command were all repos with only a few issues and two of them were total spam issues created within the last day.

To help ensure that we're actually sending users to Good First Issues that they'll be able to make a meaningful contribution to, how do we feel about setting a filter for ⭐️s to 50?

If we want to ensure that there's still a way to pull from the full set of "Good First Issues" I'd not be opposed to adding an "All" command in the same release that the filter is shipped.

[hemal7735]

This will require heavy change on the issues search side, as I don't see a way to tell GitHub API to "search only in repos having X number of stars". We will be doing what we are doing currently with filtering locked issues. The chances of not finding any such issues from the current page go high as we put more and more filter from our side.

I see 2 approaches here to tackle:

1. Increase the number of issues per_page (this can increase the odds of finding such issues)
2. Search in next/previous page (this will require some heavy changes on search functionality)

---

I was thinking about the downside of putting filters on our-side the other day. We should ask GitHub to provide issues having no:assignee, rather than filtering from our-side. https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-missing-metadata

[bnb]

There is the stars filter but it doesn't seem to apply to Issues 😭

Query

stars:>1000 is:issue is:open label:"good first issue"

Result

• 51k issues
• 17k repos

Query

stars:>100 is:issue is:open label:"good first issue"

Result

• 51k issues
• 113k repos

Until this filter applies to Issues (or we hear it won't) I don't think we should implement this feature 😢

[boneskull]

seems like you could coax that out of github using the graphql api.