8 ms·

Browse good first issues to start contributing to open source

256 points by chmaynard 7y ago

throwthisaway2 7y ago
Dont, make them pay for your services dont let corps get your work for free.
ozand 7y ago
Isn't this just filtering issues with label "good first issue" other than the one user already is viewing? Can someone explain the "machine learning algorithm" part here?
- iwritecode 7y ago
  The post links to an approach walkthrough on the GitHub engineering blog.
- miken123 7y ago
  That's explained in the post linked from the blog: https://github.blog/2020-01-22-how-we-built-good-first-issues/ https://github.blog/2020-01-22-how-we-built-good-first-issue...
  - dang 7y ago
    That seems like perhaps a more substantial post for a thread like this, so we've changed to it from https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/ https://github.blog/2020-01-22-browse-good-first-issues-to-s.... Probably a good idea to read both.
eralps 7y ago
In my experience good first issues are mostly hidden. Most of the time, big projects with large communities use that label in issues and at least for me the issues are almost never good first issue. Projects with at most one or two regular contributors often are easier to get into. They are relatively smaller and there is a higher chance that the open issue is simple but no one had time. But the label is not used in those issues. I have several contributions that are only 1-5 lines to projects with more than 10K stars. Issues were definitely good first issues but no one had time to work on them, let alone labelling them.
- tashoecraft 7y ago
  Feel like all decently used open source projects need technical PM contributors to help organize the backlog. Issues can range from no information, to incredibly detailed posts, to what belongs on stackoverflow. It must be exhausting as a maintainer to deal with this.
vortico 7y ago
If you want to volunteer for a project, just contact a project manager (through email or something) declaring the number of hours you're able to donate and your skills. They'll usually give you a good direction to start. Drive-by commits are time-consuming to maintain. I don't see why maintainers even deal with them.
- gtaylor 7y ago
  I can only speak for myself but I prefer not to manually onboard new contributors. I'd rather do a near-infinite number other things with that time. Add a contributors guide, link to it in your README. GH even has some functionality built-in to link to it these days. Help contributors help themselves and spend that time on something else.
  - vortico 7y ago
    Well the alternative is to deal with poor/unresearched PRs, or to not accept volunteer contributions at all (which is what I do with most of my own open-source projects.)
- imtringued 7y ago
  They are just as time consuming as any other code you haven't written yourself.
alexellisuk 7y ago
I'd also recommend How I built Good First Issue bot with OpenFaaS Cloud by Rajat Jindal of Proofpoint. It's already used on repos from Docker, Microsoft, OpenFaaS, JetStack (cert-manager), and Google. It's a free SaaS, just add the label and it'll tweet out for you. Bonus once you've added the label - it should be picked-up by GitHub's tool too. https://www.openfaas.com/blog/good-first-issue/ https://www.openfaas.com/blog/good-first-issue/
daenz 7y ago
This is a cool thing to support. I'm currently teaching my partner to code, and I am on the lookout for relatively easy contributions she can make to start getting interactions with the community and how things are built in the real world with other people.
dang 7y ago
The announcement post is https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/ https://github.blog/2020-01-22-browse-good-first-issues-to-s.... We changed to the technical post because it has a bit more detail.
The_rationalist 7y ago
Prior art: https://starters.servo.org https://starters.servo.org
darekkay 7y ago
Is there a platform for matching contributors with existing projects? I'm developing one of my projects[1] in public from day one, and I would love to collaborate with some people someday. Rcently, I was thinking about moving my private project tasks into GitHub issues and using tags like "good first issue" and "hacktoberfest". But I am not sure if this alone will attract people that want to really drive the project forward instead of "just" solving one task. On the other hand, I know people who are looking for a project like this to contribute, but they simply are not interested in mine. So I can sense some need for a tool for project owners to post their projects and for other people to find one to contribute. [1] https://github.com/darekkay/dashboard https://github.com/darekkay/dashboard
- mrr54 7y ago
  The platform has always traditionally been your own computer. You install programs that you find useful, fun, interesting, necessary, etc. When you have an issue with one, you contribute to it.
narenst 7y ago
> As the first deep-learning-enabled product to launch on Github.com, this feature required careful design to ensure that the infrastructure would generalize to future projects. It is surprising to see that this is the first time DL is run in production at GitHub. GitHub has a large amount of fairly structured data in the form of code, issues, etc. Plus they have been dabbling with DL for more than two years [1]. It could be that the business problems that are critical to the growth of GitHub product may not need DL. Solving problems like best-first-issues, code search are useful to the end user but may not effectively grow the business metrics. [1] https://github.blog/2018-09-18-towards-natural-language-semantic-code-search/ https://github.blog/2018-09-18-towards-natural-language-sema...
daffl 7y ago
I'd really like to hear the perspective and success stories of "Good first issue" labels and other means of encouraging open source contributions from other open source projects. In my experience it unfortunately often hasn't been a net benefit for the projects I worked on. A "good first issues" takes up a lot of time to write and often never get addressed at all or it takes even more time to review and give feedback ultimately causing more work than addressing it directly since most "first issue" contributors do not come back to contribute again. GitHub has done a lot to streamline the process of contributing to an open source project. I think what is still missing (or I don't know about) is an overall resource where you can learn about open source best practises (or just "Best Practises" since you should be using them everywhere) like writing tests, writing good docs, using conventional commits etc. outside of individual projects - and then in addition to the "Good first issue" label also indicate which one of those best practises apply to that issue, e.g. "This is a good first issue if you know about NodeJS, Mocha tests and Markdown".
- franciscop 7y ago
  As an author they have definitely taken more time than if I fixed the issues myself. But for me, that's not the point, the point was to help other fellow devs get started in OSS programming, kind of "light mentoring". At that, it has been wildly successful. I haven't had much free time to continue doing this in the last couple of years though.
  - daffl 7y ago
    Absolutely. I really enjoy helping get people involved in open source, too and help run a once-a month workshop on how to get started with open source here in Vancouver. I'm just not sure if this is something all open source projects - many of which don't have a lot of resources available - can handle. The very large open projects that already have a lot of contributors that can put in the additional time are definitely at an advantage here.
- laurent123456 7y ago
  If an issue takes a lot of time to write, then it's probably not a good first issue. For my project, I found there are all kind of small things that are easy to do but I don't have time, so instead I write a good first issue. Usually I also put some pointers on how to get started, like "check such method in such file", or "have a look at that reducer action". It doesn't take long to do this and it's been working pretty well. It's a very good way for new developers to get something done easily and to get familiar with the code base. As of now there are 40 such issues, including 28 completed: https://github.com/laurent22/joplin/issues?q=label%3A%22good+first+issue%22&utf8=%E2%9C%93 https://github.com/laurent22/joplin/issues?q=label%3A%22good...
franciscop 7y ago
"Up for grabs" is one of the first projects to do this on a wide scale in Github and that I absolutely recommend for starting contributing: https://up-for-grabs.net/ https://up-for-grabs.net/ The reason is that it's opt-in (instead of ML-found issues), so the authors of packages have expressed a strong willingness to help first-time contributors. I've used up for grabs before (as an author) and it was great.
atq2119 7y ago
In a way, I appreciate the attempt to encourage people to contribute to open source, but in another way, initiatives like this feel a lot like a cargo cult to me. I mean that in a very specific sense: Traditionally, contributors to free software and open source, especially the more prolific ones, are often good programmers. This has made its way into the collective consciousness in a way that affects hiring, e.g. by considering open source contributions as a positive signal. People who want to be software developers hear or read about this and want to replicate it, so they are looking for somewhere to contribute. Hence initiatives like in TFA, and GSoC etc. What they ignore or just don't see is that those traditional contributors to open source largely self-selected by having some issue that they wanted to solve and then just fixing it. They come to the projects with their own issues, which may overlap with issues of others out of coincidence. The difference in motivation and internal drive is significant. Of course it's still nice when people genuinely want to contribute to make the world a better place, but I'm skeptical about the support burden that these non-traditional contributors often put on project maintainers, because they tend to need more guidance on average and have less intrinsic understanding of the problem space and relevant use cases. Some projects grow structures to support it and manage just fine, but some don't and I think that also needs to be accepted.
- WilliamEdward 7y ago
  Whether someone wants to fix code because they use and have a problem with it, or they just wanted to knock out a random 'good first bug', it's not really up to you. Personally i think github shouldn't have this feature for a number of unrelated reasons, but don't start excluding one-off noob contributors. Open source is open for a reason.
  - atq2119 7y ago
    I'm not excluding them. If they do just knock out a random 'good first bug', then that's actually great and welcome. But there seems to be a pattern of people who heard that contributing to open source is good for their CV, this ends up being their only motivation, and they expect hand-holding from project maintainers or for their patches to be accepted without scrutiny (or, if they are receptive to feedback, their patches are just really low quality and require a lot of review iterations). It's those last points that can be a problem, because it can cause their contribution to become net-negative.
igorlev 7y ago
I usually bring up this research when talking about employee onboarding but there was a study done in 2015 (with Mozilla) that showed a “good first issue” approach didn’t actually lead to the intended outcome - having more folks successfully integrate into and continue to contribute to a project over a long term. To my knowledge there hasn’t been a ton of follow up or replication but still something to consider. https://cs.uwaterloo.ca/~rtholmes/papers/msr_2015_labuschagne.pdf https://cs.uwaterloo.ca/~rtholmes/papers/msr_2015_labuschagn...
j_z_reeves 7y ago
I have noticed that popular repos with "good first issue" labels on issues tend to have those issues claimed fairly quickly. There is real competition in trying to display and assert your coding credentials with open source contributions. Anecdotally, some issues that are claimed for months do not have corresponding PRs submitted. Question to those that mark labels as "good first issue", have you dealt with flaky contributors?
ndesaulniers 7y ago
I don't understand how this is supposed to work. For example: https://github.com/ClangBuiltLinux/linux/contribute https://github.com/ClangBuiltLinux/linux/contribute shows: > This repo doesn't have any good first issues, yet But I have many open issues tagged "good first issue": https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue...
- sudhirj 7y ago
  Maybe whoever trained their ML models actually thought no one would call good first issues "good first issues". Kinda like you're trying to build a cat recognizer and you suddenly feed it pictures of cats wearing signs around their necks that say "CAT" in all caps. The recognizer would probably fail.
- chewxy 7y ago
  add a CONTRIBUTING.md file?
manasvi_gupta 7y ago
If anyone is looking to contribute to Apache Kafka, they, can get started with setup that I have documented in my blog. https://medium.com/@manasvi/getting-started-with-contributing-to-apache-kafka-part-1-build-and-run-kafka-from-source-code-f900452fdc06 https://medium.com/@manasvi/getting-started-with-contributin...
abinaya_codes 7y ago
If you know basic python, checkout ROS, interesting issues to solve -> https://github.com/ros/rosdistro/contribute https://github.com/ros/rosdistro/contribute
jcelerier 7y ago
Looks correct on https://github.com/OSSIA/score/contribute https://github.com/OSSIA/score/contribute
imtringued 7y ago
I've had a weird first time contributor for one of my projects. I had decided to not use any build system for the front end. This caused issues in a subset of browsers that do not support the latest features. I accepted the extra work of testing it in several browsers and chose Firefox ESR as the minimum platform I support. But I didn't expect that there are forks like palemoon which disabled the core feature the entire project was built on, namely WebRTC. The contributer's idea was to use HLS/DASH as a fallback for passive viewers who aren't broadcasting their own video stream. He was enthusiastic and even willing to spend 4 days per week on the project but then I realized how inexperienced that contributor is. He has never written a web app, never used a relational database, no knowledge of js, css, html but clearly willing to learn. However since I just don't have the time for hand holding like that I asked him if he wants to acquire these skills to get a job as a software developer. That wasn't the case and the lack of ambition turned me off. I didn't feel like spending 100+ hours on training someone who will never use his skills outside of this project, especially when I can just tell him to go away and come back with Firefox, Chrome, Opera, Edge, anything except Palemoon.

256 points by chmaynard 7y ago

Dont, make them pay for your services dont let corps get your work for free.

Isn't this just filtering issues with label "good first issue" other than the one user already is viewing? Can someone explain the "machine learning algorithm" part here?

iwritecode 7y ago
The post links to an approach walkthrough on the GitHub engineering blog.
miken123 7y ago
That's explained in the post linked from the blog: https://github.blog/2020-01-22-how-we-built-good-first-issues/ https://github.blog/2020-01-22-how-we-built-good-first-issue...
- dang 7y ago
  That seems like perhaps a more substantial post for a thread like this, so we've changed to it from https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/ https://github.blog/2020-01-22-browse-good-first-issues-to-s.... Probably a good idea to read both.

eralps 7y ago

In my experience good first issues are mostly hidden. Most of the time, big projects with large communities use that label in issues and at least for me the issues are almost never good first issue. Projects with at most one or two regular contributors often are easier to get into. They are relatively smaller and there is a higher chance that the open issue is simple but no one had time. But the label is not used in those issues. I have several contributions that are only 1-5 lines to projects with more than 10K stars. Issues were definitely good first issues but no one had time to work on them, let alone labelling them.

tashoecraft 7y ago
Feel like all decently used open source projects need technical PM contributors to help organize the backlog. Issues can range from no information, to incredibly detailed posts, to what belongs on stackoverflow. It must be exhausting as a maintainer to deal with this.

vortico 7y ago

If you want to volunteer for a project, just contact a project manager (through email or something) declaring the number of hours you're able to donate and your skills. They'll usually give you a good direction to start. Drive-by commits are time-consuming to maintain. I don't see why maintainers even deal with them.

gtaylor 7y ago
I can only speak for myself but I prefer not to manually onboard new contributors. I'd rather do a near-infinite number other things with that time. Add a contributors guide, link to it in your README. GH even has some functionality built-in to link to it these days. Help contributors help themselves and spend that time on something else.
- vortico 7y ago
  Well the alternative is to deal with poor/unresearched PRs, or to not accept volunteer contributions at all (which is what I do with most of my own open-source projects.)
imtringued 7y ago
They are just as time consuming as any other code you haven't written yourself.

alexellisuk 7y ago

I'd also recommend How I built Good First Issue bot with OpenFaaS Cloud by Rajat Jindal of Proofpoint. It's already used on repos from Docker, Microsoft, OpenFaaS, JetStack (cert-manager), and Google. It's a free SaaS, just add the label and it'll tweet out for you. Bonus once you've added the label - it should be picked-up by GitHub's tool too. https://www.openfaas.com/blog/good-first-issue/ https://www.openfaas.com/blog/good-first-issue/

daenz 7y ago

This is a cool thing to support. I'm currently teaching my partner to code, and I am on the lookout for relatively easy contributions she can make to start getting interactions with the community and how things are built in the real world with other people.

dang 7y ago

The announcement post is https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/ https://github.blog/2020-01-22-browse-good-first-issues-to-s.... We changed to the technical post because it has a bit more detail.

The_rationalist 7y ago

Prior art: https://starters.servo.org https://starters.servo.org

darekkay 7y ago

Is there a platform for matching contributors with existing projects? I'm developing one of my projects[1] in public from day one, and I would love to collaborate with some people someday. Rcently, I was thinking about moving my private project tasks into GitHub issues and using tags like "good first issue" and "hacktoberfest". But I am not sure if this alone will attract people that want to really drive the project forward instead of "just" solving one task. On the other hand, I know people who are looking for a project like this to contribute, but they simply are not interested in mine. So I can sense some need for a tool for project owners to post their projects and for other people to find one to contribute. [1] https://github.com/darekkay/dashboard https://github.com/darekkay/dashboard

mrr54 7y ago
The platform has always traditionally been your own computer. You install programs that you find useful, fun, interesting, necessary, etc. When you have an issue with one, you contribute to it.

narenst 7y ago

> As the first deep-learning-enabled product to launch on Github.com, this feature required careful design to ensure that the infrastructure would generalize to future projects. It is surprising to see that this is the first time DL is run in production at GitHub. GitHub has a large amount of fairly structured data in the form of code, issues, etc. Plus they have been dabbling with DL for more than two years [1]. It could be that the business problems that are critical to the growth of GitHub product may not need DL. Solving problems like best-first-issues, code search are useful to the end user but may not effectively grow the business metrics. [1] https://github.blog/2018-09-18-towards-natural-language-semantic-code-search/ https://github.blog/2018-09-18-towards-natural-language-sema...

daffl 7y ago

I'd really like to hear the perspective and success stories of "Good first issue" labels and other means of encouraging open source contributions from other open source projects. In my experience it unfortunately often hasn't been a net benefit for the projects I worked on. A "good first issues" takes up a lot of time to write and often never get addressed at all or it takes even more time to review and give feedback ultimately causing more work than addressing it directly since most "first issue" contributors do not come back to contribute again. GitHub has done a lot to streamline the process of contributing to an open source project. I think what is still missing (or I don't know about) is an overall resource where you can learn about open source best practises (or just "Best Practises" since you should be using them everywhere) like writing tests, writing good docs, using conventional commits etc. outside of individual projects - and then in addition to the "Good first issue" label also indicate which one of those best practises apply to that issue, e.g. "This is a good first issue if you know about NodeJS, Mocha tests and Markdown".

franciscop 7y ago
As an author they have definitely taken more time than if I fixed the issues myself. But for me, that's not the point, the point was to help other fellow devs get started in OSS programming, kind of "light mentoring". At that, it has been wildly successful. I haven't had much free time to continue doing this in the last couple of years though.
- daffl 7y ago
  Absolutely. I really enjoy helping get people involved in open source, too and help run a once-a month workshop on how to get started with open source here in Vancouver. I'm just not sure if this is something all open source projects - many of which don't have a lot of resources available - can handle. The very large open projects that already have a lot of contributors that can put in the additional time are definitely at an advantage here.
laurent123456 7y ago
If an issue takes a lot of time to write, then it's probably not a good first issue. For my project, I found there are all kind of small things that are easy to do but I don't have time, so instead I write a good first issue. Usually I also put some pointers on how to get started, like "check such method in such file", or "have a look at that reducer action". It doesn't take long to do this and it's been working pretty well. It's a very good way for new developers to get something done easily and to get familiar with the code base. As of now there are 40 such issues, including 28 completed: https://github.com/laurent22/joplin/issues?q=label%3A%22good+first+issue%22&utf8=%E2%9C%93 https://github.com/laurent22/joplin/issues?q=label%3A%22good...

franciscop 7y ago

"Up for grabs" is one of the first projects to do this on a wide scale in Github and that I absolutely recommend for starting contributing: https://up-for-grabs.net/ https://up-for-grabs.net/ The reason is that it's opt-in (instead of ML-found issues), so the authors of packages have expressed a strong willingness to help first-time contributors. I've used up for grabs before (as an author) and it was great.

atq2119 7y ago

In a way, I appreciate the attempt to encourage people to contribute to open source, but in another way, initiatives like this feel a lot like a cargo cult to me. I mean that in a very specific sense: Traditionally, contributors to free software and open source, especially the more prolific ones, are often good programmers. This has made its way into the collective consciousness in a way that affects hiring, e.g. by considering open source contributions as a positive signal. People who want to be software developers hear or read about this and want to replicate it, so they are looking for somewhere to contribute. Hence initiatives like in TFA, and GSoC etc. What they ignore or just don't see is that those traditional contributors to open source largely self-selected by having some issue that they wanted to solve and then just fixing it. They come to the projects with their own issues, which may overlap with issues of others out of coincidence. The difference in motivation and internal drive is significant. Of course it's still nice when people genuinely want to contribute to make the world a better place, but I'm skeptical about the support burden that these non-traditional contributors often put on project maintainers, because they tend to need more guidance on average and have less intrinsic understanding of the problem space and relevant use cases. Some projects grow structures to support it and manage just fine, but some don't and I think that also needs to be accepted.

WilliamEdward 7y ago
Whether someone wants to fix code because they use and have a problem with it, or they just wanted to knock out a random 'good first bug', it's not really up to you. Personally i think github shouldn't have this feature for a number of unrelated reasons, but don't start excluding one-off noob contributors. Open source is open for a reason.
- atq2119 7y ago
  I'm not excluding them. If they do just knock out a random 'good first bug', then that's actually great and welcome. But there seems to be a pattern of people who heard that contributing to open source is good for their CV, this ends up being their only motivation, and they expect hand-holding from project maintainers or for their patches to be accepted without scrutiny (or, if they are receptive to feedback, their patches are just really low quality and require a lot of review iterations). It's those last points that can be a problem, because it can cause their contribution to become net-negative.

igorlev 7y ago

I usually bring up this research when talking about employee onboarding but there was a study done in 2015 (with Mozilla) that showed a “good first issue” approach didn’t actually lead to the intended outcome - having more folks successfully integrate into and continue to contribute to a project over a long term. To my knowledge there hasn’t been a ton of follow up or replication but still something to consider. https://cs.uwaterloo.ca/~rtholmes/papers/msr_2015_labuschagne.pdf https://cs.uwaterloo.ca/~rtholmes/papers/msr_2015_labuschagn...

j_z_reeves 7y ago

I have noticed that popular repos with "good first issue" labels on issues tend to have those issues claimed fairly quickly. There is real competition in trying to display and assert your coding credentials with open source contributions. Anecdotally, some issues that are claimed for months do not have corresponding PRs submitted. Question to those that mark labels as "good first issue", have you dealt with flaky contributors?

ndesaulniers 7y ago

I don't understand how this is supposed to work. For example: https://github.com/ClangBuiltLinux/linux/contribute https://github.com/ClangBuiltLinux/linux/contribute shows: > This repo doesn't have any good first issues, yet But I have many open issues tagged "good first issue": https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue...

sudhirj 7y ago
Maybe whoever trained their ML models actually thought no one would call good first issues "good first issues". Kinda like you're trying to build a cat recognizer and you suddenly feed it pictures of cats wearing signs around their necks that say "CAT" in all caps. The recognizer would probably fail.
chewxy 7y ago
add a CONTRIBUTING.md file?

manasvi_gupta 7y ago

If anyone is looking to contribute to Apache Kafka, they, can get started with setup that I have documented in my blog. https://medium.com/@manasvi/getting-started-with-contributing-to-apache-kafka-part-1-build-and-run-kafka-from-source-code-f900452fdc06 https://medium.com/@manasvi/getting-started-with-contributin...

abinaya_codes 7y ago

If you know basic python, checkout ROS, interesting issues to solve -> https://github.com/ros/rosdistro/contribute https://github.com/ros/rosdistro/contribute

jcelerier 7y ago

Looks correct on https://github.com/OSSIA/score/contribute https://github.com/OSSIA/score/contribute

imtringued 7y ago

I've had a weird first time contributor for one of my projects. I had decided to not use any build system for the front end. This caused issues in a subset of browsers that do not support the latest features. I accepted the extra work of testing it in several browsers and chose Firefox ESR as the minimum platform I support. But I didn't expect that there are forks like palemoon which disabled the core feature the entire project was built on, namely WebRTC. The contributer's idea was to use HLS/DASH as a fallback for passive viewers who aren't broadcasting their own video stream. He was enthusiastic and even willing to spend 4 days per week on the project but then I realized how inexperienced that contributor is. He has never written a web app, never used a relational database, no knowledge of js, css, html but clearly willing to learn. However since I just don't have the time for hand holding like that I asked him if he wants to acquire these skills to get a job as a software developer. That wasn't the case and the lack of ambition turned me off. I didn't feel like spending 100+ hours on training someone who will never use his skills outside of this project, especially when I can just tell him to go away and come back with Firefox, Chrome, Opera, Edge, anything except Palemoon.