
Browse good first issues to start contributing to open source - chmaynard
https://github.blog/2020-01-22-how-we-built-good-first-issues/
======
atq2119
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
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
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.

~~~
AndrewThrowaway
I kinda understand the point. However at what point one can call himself a
"good prolific programmer" which has no time for "hand-holding", can judge if
contribution is sincere attempt by some thirteen year old who wants to learn
or just being done for CV.

One can argue that every kid with their "low quality patch" is net-negative as
their teacher/project maintainer would be better spending time writing actual
"good" code.

At what point one just starts sounding like elitist thinking that open source
should just be left for exclusive prolific programmers?

~~~
oefrha
> ... can judge if contribution is sincere attempt by some thirteen year old
> who wants to learn or just being done for CV.

To me it’s no different. Whether they’re thirteen or thirty, I’m not obligated
to donate time to help them grow. In fact I’d say “student drivers” deserve
less of my time — I’m not a free tutor unless I explicitly agreed to such.

That said, I deal with one-off contributors with respect and handhold out of
kindness when necessary (assuming they’re not rude). But I don’t feel like
explicitly setting the expectation that I will handhold, especially on trivial
patches that’ll take me less time on my own.

------
eralps
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
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.

------
daffl
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".

~~~
gus_massa
When there is an issue with a clear bug report that can be fixed in on of two
lines and the solution is very clear, I like to answer something like:

" _Thanks for the report! The problem is in link-to-file-in-GitHub. Do you
want to send a PR to fix it? If not, we can fix it._ "

Sometimes they accept the proposal, sometimes not. It is a little more work to
fetch the change, rebase, and merge it. But some people like the opportunity
and perhaps may become a contributor in the future.

(If they don't accept, fix the problem soon and say thanks again with a link
to the fix in case they want to see the change.)

~~~
daffl
A big challenge I'm seeing is when it comes to tests. Even though it is
documented in the contribution guide and - I'd like to think - fairly easy to
get running (Clone, `npm i`, `npm test`) many first time bug-fixes or features
do not include tests.

------
igorlev
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_labuschagn...](https://cs.uwaterloo.ca/~rtholmes/papers/msr_2015_labuschagne.pdf)

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

------
alexellisuk
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/)

------
darekkay
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
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.

------
imtringued
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.

------
j_z_reeves
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?

------
vortico
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
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
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.)

------
ndesaulniers
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...](https://github.com/ClangBuiltLinux/linux/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)

~~~
sudhirj
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.

------
ozand
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?

~~~
miken123
That's explained in the post linked from the blog:
[https://github.blog/2020-01-22-how-we-built-good-first-
issue...](https://github.blog/2020-01-22-how-we-built-good-first-issues/)

~~~
dang
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-s...](https://github.blog/2020-01-22-browse-good-first-issues-to-
start-contributing-to-open-source/). Probably a good idea to read both.

------
franciscop
"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.

------
manasvi_gupta
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-
contributin...](https://medium.com/@manasvi/getting-started-with-contributing-
to-apache-kafka-part-1-build-and-run-kafka-from-source-code-f900452fdc06)

------
The_rationalist
Prior art: [https://starters.servo.org](https://starters.servo.org)

------
daenz
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.

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

------
narenst
> 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-
sema...](https://github.blog/2018-09-18-towards-natural-language-semantic-
code-search/)

------
jcelerier
Looks correct on
[https://github.com/OSSIA/score/contribute](https://github.com/OSSIA/score/contribute)

