'Call for participation'-issues aggregator

Learn
#1

I sometimes read the ‘Call for participation’ section in the Haskell Weekly newsletter. And a couple times I picked up an issue.

So I am wondering if there is a nice way to set up an aggregated list of github issues (from a number of haskell projects) tagged as ‘good-first-issue’, ‘help-wanted’ or smth like that.

Does this already exist maybe?

6 Likes
#2

You can search for issues like this using GitHub’s search. For example, to find issues in Haskell repositories that have the help-wanted label, you can search for language:haskell label:help-wanted.

https://github.com/search?q=language%3Ahaskell+label%3Ahelp-wanted&type=issues

5 Likes
#3

You probably want to add is:open too: https://github.com/search?q=language%3Ahaskell+label%3Ahelp-wanted+is%3Aopen&type=issues

Or maybe good first issue instead of help-wanted: https://github.com/search?q=language%3Ahaskell+label%3A"good+first+issue"+is%3Aopen&type=issues

Actually "help wanted" with a space instead of a dash gives much more results: https://github.com/search?q=language%3Ahaskell+label%3A"help+wanted"+is%3Aopen&type=issues

3 Likes
#4

That’s tempting, and I used to tag issues like that. But for whatever reason it seemed not to work -

  • they were roundly ignored
  • help-wanted implies help-not-wanted on the others; but help is wanted everywhere
  • good-first-issue or easy-issue are highly relative and when I reviewed them later they all seemed way too much to ask of someone browsing for actually easy first issues. Maybe my project didn’t have any ?
  • people able to help on issues will find them, so this seemed wasted work
2 Likes
#5

Yeah, this one’s nice!

The problem is that different people/repos use different labels which makes it a bit harder.

But I was more thinking of a way to both stimulate people creating new ‘help-wanted’ issues and make it easier to those who want to contribute finding those issues.

#6

It would be nice to find out what is actually preventing people from contributing. I guess the size of the community is a big factor here :slight_smile: but may be some other reasons?

I’d guess some people might have questions re issues in question but would just be too shy ask openly for whatever reasons. One of the reasons could be that often it’s not clear who should you ask.

A couple times I myself was in a situation where I make a PR but don’t know who exactly should I talk to about it (when no one got assigned automatically)

And then I like what @taylorfausak does with the newsletter – once I see an issue I’m like, oh, that sounds interesting. But otherwise I wouldn’t even bother going on github and filtering issues by label. Similar to how ads work.

1 Like
#7
  • help-wanted implies help-not-wanted on the others; but help is wanted everywhere

For HLS we decided to tag issues as “easy” partly as it felt a bit more objective. Of course, as you point out, it’s really not objective, but nonetheless it seems true that some issues are often easi_er_ than the bulk of the issues, and it makes sense to label them. We have used that labelling a bit - we use it to identify good issues for ZuriHac, for example. But I don’t know how useful it is overall.

#8

An example of such an aggregator (not Haskell related) launched recently.

1 Like
#9

I think this is a good idea. If I was implementing it I would start very simply, by creating a GitHub repo and using the issue tracker to manually link to “good first issues” on other projects. If it proves useful then there are various ways of automating it, but I wouldn’t put the effort into automation until its value has been demonstrated.

2 Likes