There would be a way to just put the name of the repository and get the issues.

[dantehemerson]

There would be a way to just put the name of the repository and get the issues.

[hemal7735]

@dantehemerson Can you add more details regerding the issue? What is the expectation here? It would help everyone.

[DSchau]

Yeah - I was thinking this too. It seems like a reasonable approach would be to default to a query searching for issues with "good first issue" (as this seems to be a standard) and overriding if a custom config exists, rather than only working if a project has been added.

That's how I interpret this; am I on the right track @dantehemerson?

[hemal7735]

Falling back to good first issue can be proven a great uplift (we are already doing it in feeling-lucky, however, this requires some transparency.

We will need to show some sort of message to the user that we are gonna try to find issues with good first issue label, as it is not in our configuration. If they want they can raise a PR for overrides.

[dantehemerson]

Yes, @DSchau

I was thinking of something like:
good-first-issue owner/repo
for example:
good-first-issue nodejs/node

or if we would like to look for issues in an organization or a user
we would only pass the name:
good-first-issue nodejs (org)
or
good-first-issue dantehemerson (user)
This would look at all the owner's projects

We could also search by language:
good-first-issue -l javascript

Maybe it adds some complexity when we execute the command with respect to now, but I think it would have more scope.

We could look for the label good-first-issue, feeling-lucky, or others (as long as they are similar). The idea is to have a standard label, but while that happens we could look for the most popular labels similar to good-first-issue, if the repo does not have this label. We could inform the user the label that was found as @hemal7735 says.

What do you think?

[hemal7735]

I like the idea of giving control to users what they want to search.
GitHub API is rich enough to support some of the features proposed in the this issue.

However,
We need some sort of identifier which can identify correctly if it was meant for Org/Repo/User ? This link has some good info about it.
for example,
-u (User)
-g (Org) [-o is already taken for opening it in a browser]

This would require some good amount of work on CLI side. Might be a major ?
I'm super excited about this 😎
@bnb I know you are kinda busy this week, but we would love to hear your thoughts about this.

[bnb]

This has been suggested multiple times – definitely not opposed to it. There are also a few additional layers that may be interesting to consider:

• We have a few org (as opposed to repository) searches. Would it be possible to also pass a specific repo to those? We get into some parsing weeds here but it's something that's interesting to think about.
• I'm curious if we'd want to phone home about queries that are being run so we can get metrics on which projects would be good to add. Probably not, but it's something to consider 🤔
• Definitely +1 the concept but I also want to ensure that this module as a require()ed module is still useful without the requirement of passing a complex string, object, or array.

[JasonEtco]

I came here to suggest this as well! How about a flow that looks like this:

1. Get name of REPO_OR_ORG from `npx good-first-issue REPO_OR_ORG
2. If REPO_OR_ORG is a special project in projects.json, use that query
3. Else, check if it matches the ol' owner/repo string
4. Use org:REPO_OR_ORG or repo:REPO_OR_ORG, depending on if it matches

Happy to take a look at writing a PR for this 😊

[bnb]

@JasonEtco I'd be happy to review that PR 😄