Update README.md with contributor call out #17946
Conversation
✅ No release notes required |
| The issues in this repository can have big differences in the complexity for fixing them. | ||
| Are you getting started? We do have a label for [good first issues](https://github.com/dotnet/fsharp/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22) as well. |
There was a problem hiding this comment.
We specifically retired "good first issue" some time ago, and replaced it with "help wanted". But might be worth it to bring it back.
There was a problem hiding this comment.
I checked the repo and we had issues for both.
Classification I somewhat understood:
"help wanted" - maintainers are able to provide guidance and the motivation of the issue is "approved in principle", situation described in the issue is worth improving (which is not the case for every issue).
"good first issue" - typically a subset of "help wanted" which are also easier to accomplish.
There was a problem hiding this comment.
I think the history behind it is that we used the latter (good first issue), but GitHub and issuesof.net used the former (help wanted) to track, and we decided to use it, but didn't remove the original one from all the issues.
There was a problem hiding this comment.
I think we should only have "help-wanted" label. I read this as F# team is asking for community help to fix this and would be willing to offer guidance.
There was a problem hiding this comment.
That is indeed the case for "help-wanted" @edgarfgp .
"good first issue" is a subset of those, which is also considered easier and therefore a good fit for people new in the repo.
There was a problem hiding this comment.
I can see the distinction - although I am not sure about the practical aspect of it. In reality the lines can get blurry, since "easy" is a very subjective word :)
We want to signal that contributors' help is encouraged, so not sure if it's reasonable to "maintain" two labels and each time think if it's "easy" or not. So wouldn't mine reducing labels to one here, as Edgar proposes.
More importantly, we should keep this in mind when triaging things...
There was a problem hiding this comment.
We don't have to decide that each time - it's sufficient to have a handful of "easy ones". When it is clear that something is good for a first time users, we will apply it. If we forget or are not sure, we will simply not apply it, not a big deal.
The practical aspect is to make sure that people willing to contribute for the first time can have a preselected choice of issues, not prevent digging into things which will take months to do right.
No description provided.