[Music]
um we've got a a bunch of amazing
speakers for you and we're going to
start with Stephanie Mullen um who's
here all the way from New York thank you
um where she tackles tough problems in
information security particularly those
revolving around data wrangling
visualization building tools and
Gathering data and knowledge sharing um
and she's going to tell you all about
the cool books she's written and the
work she's done developing numpy do and
um she's got a Bachelor's degree of
Science in operations research from
Columbia University's F Foundation
School of Engineering and applied
science that is a lot of words it's a
very long we called it C's C's C's like
the seven C's
ah got a sh it somehow yes um and she
enjoys traveling the world and inventing
new recipes and leting new languages
spoken among both people and
computers uh so I'm going to let
Stephanie get
[Applause]
started all right all right good
afternoon everyone welcome to getting
started with open- Source contributions
again my name is Stephanie Mullen uh a
software engineer at Bloomberg in New
York City and I'm a core developer of
the numpy do package which I'll tell the
story about how that came to be in this
talk and I'm also the author of Hands-On
data analysis with
pandas so I want to start by dispelling
some myths around open source
contributions so the first is that only
professional developers or maintainers
can contribute to open open source
projects and just like you don't have to
be a professional developer or
maintainer to use those projects you
don't have to be one to contribute there
are ways to contribute regardless of
your experience level and many projects
accept help in a variety of
forms and the second myth is that only
experts can contribute something
meaningful so again there's a way to
contribute in a variety of ways and this
can vary depending on your level and
there are actually certain cases where
not being an expert in tool is actually
a preferred way for you to get some
contributions in you think about
newcomer documentation right who's going
to be in the best position to write
something that will understand where all
the newcomers trip up than someone who
is just a newcomer themselves it is very
hard for experts to put themselves in
the shoes of a
newcomer okay so now that we've had
those myths dispelled uh we're going to
talk about how you find a project to
work on and this is by far are the
hardest part of actually contributing to
open source you have essentially an
infinite number of projects out there
and infinite number of things you could
potentially be looking at how do you
find the one or the few that makes sense
for you to get
started and again there are variety of
ways to contribute it doesn't have to be
adding some fancy new feature to a tool
it can be something like improving the
documentation translating documentation
adding better examples making tutorials
building a community around a project
reporting bugs
there are a variety of ways so the first
thing I like to do is sit down and
brainstorm potential projects and at
this point I just write down what are
projects I've used recently no extra
criteria just that have I used this
recently write it down later on you will
look through the list and evaluate for
suitability so the first level just
whatever comes to mind you write it
down and then once you have that list
you can evaluate those projects for
suitability I like to do this with five
criteria the first thing is I look at
the software license that it's
distributed with and this for a variety
of reasons one might be that your
employer has restrictions on what types
of projects you can contribute to based
on that license so that's a very easy
way to weed things
out the next is to look at recent
activity so if a project hasn't had any
releases or nobody commenting on it
talking about it Etc then maybe it's
been replaced with something else or
it's not being used or people you know
moved away from it you want to avoid
those projects you want ones that are
still active right if it's active people
will be using it also contributing to it
and someone will probably come and
review what you work on as
well the next is the codebase size so a
smaller code-based project it will be a
lot easier for you to get a foothold
right there's less code that you need to
review how it works to understand what
you can contribute to or or how to even
you know add from a developer standpoint
to that project and then on the flip
side something that has a much larger
code base will then be a lot harder to
find your foothold there's a lot more
code that you have to go through and
understand however I like to think of
the code base in combination with the
text stack so for an example like if
something has a really big code base and
maybe you're not familiar with that
particular tool but you know that that
tool is built on top of something else
that you are very familiar with you're
now in a very good position to
contribute to that so example of
something like that would be Seaborn the
data visualization Library maybe you've
never really looked at how Seaborn works
but you're really really familiar with
map plot lib you are now in a fantastic
position to contribute to Seaborn just
from understanding that because it's
built right on top of
motet and the final thing is repository
access so you need to be able to find
the public repository for the code it
does not have to be on GitHub but if
it's not public obviously you can't you
can't control
contributed okay so now that we have
those brainstormed projects and
hopefully we filtered down you have some
projects that you can look further into
I'm going to walk you through five
strategies that I've used to get started
contributing to various python uh open
source
projects and the first one is to
participate in Sprints and you're all
very lucky that at this event there are
Sprints so Monday and Tuesday and there
is availability from what I hear uh I
will be uh on Monday with my project
data more so be sure to check it out but
I did my first Sprint at europython in
July of
2022 and I have to use my mouse because
my clicker died so hopefully NOP you
can't see that's great so I am in the
back left where the arrow is pointing so
that was me and directly across from me
were two of the S kit learn
maintainers and what they had us working
on most of us had never contributed to
pyit learn before so they had us working
on their documentation and making sure
that all their dock strings were
compliant with the numpy do
standard
and yeah the C okay it's not going to
work so um making sure that we're
compliant with numpy standard so each
one of us would take one particular
class or one particular function update
the doc string make a PR and I had
gotten a few of those already emerged
and then I started to have a problem it
was telling me their script that they
had to test that the changes were were
working it was telling me that the dock
string was not ending in a period and I
looked at it and it very much looked
like the end of the period I called over
one of the maintainers we stared at it
for a bit couldn't figure out what it
was so I decided just delete the whole
thing and and start over and it turned
out it was a trailing white space at the
end of the period so something that was
not visible looking at from from our end
as humans so I asked the maintainer how
how do I not have this happen in the
future and the suggestion was to just
install pre-commit now that was another
thing that I hadn't heard of at that
point and at this point I did have to
leave so I went when I went home and I
researched about pre-commit got that set
up uh for my personal projects for work
and then also ended up making several
contributions to other open source
libraries adding pre-commit setups for
them so you'll see that a lot if you
contribute to a larger project you're
going to be exposed to tooling and
things that they use and small projects
could really benefit from that but maybe
they don't have it set up and there's a
big opportunity for you to transfer that
knowledge so overall I think this my
first Sprint was definitely a fantastic
experience I will say that Sprints do
vary depending on where you go and which
projects and it is a bit of finding the
good affinity for yourself but I have
contrib I have participated in Sprints
both as contributors several times and
more recently this year as a maintainer
and it is a great experience from from
either side you definitely you will
always learn something so some tips to
make the most out of your Sprint
experience the first thing is to pick a
project that interests you you are
limited in which projects are actually
there you can start your own even if
you're not a maintainer and you can just
gather group of people that are
passionate about some project and want
to contribute to it but finding
something that interests you will help
you be motivated to stick with it
throughout the Sprint but then also
afterwards to continue contributing to
it
the next tip would also be to look for
beginner friendly projects now beginner
friendly is subjective so if a project
says they're beginner friendly it might
mean that they can support people new to
the project beginners to the project or
beginners to coding entirely now
everyone's very friendly at these events
you can ask if you're entirely new to
coding you're just starting out with Git
or you've never used GitHub before you
can just ask see which projects are able
to support that kind of
contribution and if you do need help at
any point you're going to be sure to ask
the maintainers for any support that you
need so most of the time maintainers
will come to these events with a goal in
mind so in the case of of pyit learn
they wanted to get their dock strings up
to par with numpy do so they are they're
invested in getting that done and they
want to help people help them get that
done right so both sides are very
willing to help each
other and it's important that you go
into this experience with an open mind
it doesn't matter how much experience
you have going in you will definitely
learn something right you can use this
opportunity to ask the developers how
they maybe how they navigate a massive
code base what kind of tools they use
how is their you know what's their IDE
of choice what extensions do they have
uh you're just exposed to more things
that you might not bump into on a
day-to-day basis and on the flip side
you might be using something that you
think's really cool that other people
haven't seen and you can share that as
well so the second strategy is to
contribute examples to the documentation
so I'm sure everyone in this room has at
some point looked at a Project's
documentation and not quite understood
how to use it and it may have been that
there were no examples but it could also
have been that the examples just weren't
super helpful for me maybe some super
expert on the topic wrote the examples
doesn't see how a newcomer might get
tripped up on it right and then you as a
newcomer didn't understand so in my case
I was using Pol the polom degree
function from numpy and there were no
examples at the time and I was trying to
figure out a couple things what happened
when there were trailing zero
coefficients in the polinomial what
would the degree result in and then what
order I even needed to put the
coefficients in I'm I didn't major in
math I don't know if there's a standard
but there wasn't anything explicitly
saying that around the function that I
needed so I had to go open up python try
out a bunch of things just to figure out
what actually was happening right and so
I didn't stop there because surely
someone else at some point potentially
in the past or in the future would
probably have similar if not the same
questions that I did so I packaged up
the examples and put them in the
documentation and I sent a PR to numpy
and they were very grateful to receive
that so there is a documentation Paradox
right every project needs good
documentation but it's very time
intensive to write it which then means
that maintainers might need to
deprioritize writing the documentation
in order to keep moving the project
forward now that's not necessarily a bad
thing right because then as people
coming from the outside you now have a
very good in to participate in that
project and one thing I like to do is
you can take a a big project something
like numpy and you can poke around in
parts of the library that maybe you
haven't used before maybe there won't be
examples there either so then you can
figure out how it works by creating
those examples and then add those
examples to the documentation so now
you've learned more about how that
Library works and then you've also made
a cont contribution right so then the
next person that comes along can just
learn from your
example the third strategy is to browse
open issues for ideas and here's where I
really need that laser pointer so uh
bear with me so here is the a screenshot
from the GitHub issues tab in psyit
learn now if you look up to the top
where it says issues in this screenshot
at this moment in time there were about
1,600 issues for site kit learn now I
said browse open issues I definitely
don't mean read 1600 issues that's no
one's going to do that so you need to
understand how to filter things down to
something that is manageable so in the
screenshot what I'm doing here is I've
selected just the ones that are labeled
good first issue now you have to be
careful with that because that label is
something that is available when you
create a new GitHub repository but
there's no requirement for the project
to keep it or keep even keep it with
that exact same name so if that's not
there then you can click and I would
also recommend doing this in general so
just to the to the right of the search
bar there's a labels button and in this
case there are 100 labels so 100 is much
much less than 1600 right so you can do
a quick scan through those 100 labels
which are how they're classifying their
issues and a lot of times there will be
a description so you can kind of get a
fla flavor for it by scrolling down you
might see that oh there's a lot of of
these labels that are just mapping to a
module in the library so I'm not going
to worry about looking at those but then
I maybe see some that are saying
beginner or meta issue or you know you
can see the module one on the bottom or
documentation right so you can figure
out what makes sense what's in your
wheelhouse and what you want to focus on
and then use that to filter down the
issues once you have those filtered down
the last thing I like to do is before
clicking into anything if you look all
the way to the right there's comment
counts so in general I like to look for
things that have little to no comments
and this is because if something has
more comments it might mean that it's
not clear what is actually to be done
there might be disagreements people
going back and forth or someone may have
claimed it right and you don't want to
be wasting your time on those now the
one caveat to that is the middle issue
here if you look it has
227 comments and that is actually a very
good good one to take and the reason
here is that pyit learn has these meta
issue which is the second label on there
and the this again labels are defined by
the repository but something similar in
this similar vein would be something to
look for when you scan those labels so
this meta issue is psyit learn wants to
apply a change across a massive part of
their API potentially the whole thing so
think of the numpy
example right so they want to apply that
over over the whole thing they don't
want to put one massive PR touching
everything so instead what they do is
they break it down they might have a
giant checklist or something saying here
are all the spots we want to apply this
change and then it's divide and conquer
which means you find something like this
you probably have several example PRS
you can consult that have already been
reviewed merged doing the exact changes
slightly you know slightly different of
what you need to do so this is a
fantastic thing to look for so tips on
being successful with this strategy
so you can look for labels like beginner
easy good first issue again keeping in
mind that everyone will have different
ones and also grain of salt with
beginner and easy right that might
that's entirely subjective and depending
on the developer who puts that tag it
might mean beginner to the project it
might mean you know beginner or easy as
in it's not it's hard for or sorry hard
might mean something like it's hard for
the developer but maybe not for
everybody to do I've had um success with
a library called uh Yellow Brick which
does um visualizations for psych learn
models and they had an issue we'd really
love to have a pre-commit set up and
they tagged it hard and that's because
everyone that was a core developer at
that time did not know how to do it so
it was hard so grain of salt on on the
beginner and and easy
ones and then it's also important that
you don't disregard old issues so just
like with a search engine people might
not go to the second page of results the
third the fourth and the case I just
mentioned with that pre-commit one I
think that issue was four years old when
I took it and then they were super super
thankful that it was done because it was
hard for them right in the case of
Seaborn I've also had success going to
the end of the backlog I found an issue
that was 9 months old no comments but it
was created by the creator of Seaboard
and when I read it I was like this is
just map plot lib a for Loop and map
plot lib and and the important thing
here is that you just ask hey are you
still interested in this I would like to
work on it you get a yes and then you're
good to go and so that actually led to
the reference line functionality for
grid plots of facet grid and Joint plot
if anyone has used
that and again those meta issues if you
see some tag or some label related to
that definitely go and check those out
those are great ways to get
started and if anything that you find
that it does interest you always make
sure that you com ment on that issue
that doesn't mean that someone else
won't just beat you to it it's still
possible but at least you've announced
your intention and people who respect
you know the etiquette of that won't go
and and try to do that and that's also a
good spot for you to ask if you need
help you can also volunteer that you
want to work on something even if you're
not sure how to do it and I have more
tips in the article I've linked here the
slides are on my website uh for more
tips on how to navigate the issue
tracker so the fourth strategy is to
identify and fix a bug so this is now
going to require a heavier use of the
project it's still possible that you're
reading the docs and you find a typo or
an Omission right and that's something
that you can fix you know with little
experience but to kind of bump into the
spots where it's not working correctly
you do need to be more of a heavy user
so if that's the case then you would
file a bug report and that's what I have
up here so in my case I had been using
pandas and I had bumped into this this
bug several times where I was trying to
make a quick horiz izontal bar plot and
I wanted to label the x and the Y AIS
and every time I put the x-axis label it
ended up on the y- AIS and I put the y-
access label and it just went nowhere
and I had bumped into this on multiple
versions and eventually just got
frustrated and went and saw if anyone
had reported this now Panda's very very
popular Library why wasn't this fixed
that was kind of my question right but
plotting functionality is I would say a
lesser known functionality of pandas and
so maybe it hadn't really been bumped
into another possibility is that someone
could have potentially put in the bug
report but it was deprioritized by the
maintainers so that's a very interesting
thing to think about you're bumping into
a bug volunteering to fix it means you
now control the priority of when that
actually gets fixed which is very
nice so when you're going to report a
bug first make sure that it hasn't
already been reported you don't want to
be wasting the maintainer time so you
should be checking the latest version
and also the main branch of that
repository checking that it's doesn't
still exist also check the open and
closed issues so it's possible someone
has already done it they decided it was
a feature not a bug and so you know
consider
that when you do put in that bug report
you want to make sure that you're
detailed with what you're putting in
there and also you provide a
reproducible example so that the
maintainers can look at that and make an
accurate decision of whether that should
be fixed or
not also you can volunteer to fix it
right that's you you found a bug you can
go and fix it and again that's your way
of prioritizing that it gets done right
away and also if you don't know how to
do it but you want to fix it because it
impacts you and it bothers you right you
can ask them i' love to work on this I'm
not sure how to get started can you give
me some
pointers okay and the final strategy is
to propose and Implement a new feature
so now again you need to be even more of
a heavy user what are the pain points of
using this software uh is there
something that could be done in a better
way is there a feature
missing so in my case coming back to
numpy do once I had learned about
pre-commit I was surprised that there
wasn't a pre-commit hook for numpy do so
it seemed to me that would be much nicer
especially in the S learn case that
every time you were adding code or
something it was checking are you still
following the stock string standard that
you want to follow so I had built that
on my own and then I approached the
numpy team by putting in a feature
request asking if they were interested
and they were and then eventually that
did lead to an invitation to become uh a
core
developer so just like with the bug
report you want to make sure that it Al
hasn't already been requested so this is
harder right because you might use very
different words to describe something
than someone else so best effort look
through open and closed
issues and then when you're describing
in your feature your feature request
make sure that you're very detailed you
know show examples of what how you want
it to work and you know what kind of
effect it would have on your on your
workflow again you can volunteer to do
that change you're clearly invested in
it you're interested in it but it's
important that you go in again you know
there is a possibility that they don't
want that right it is a lot of work for
the maintainers to then maintain foreign
code that maybe they weren't new they
were new to um and it's also possible
that it just doesn't fit with the road
map so be polite about it and you can
also I mean if you want to good for you
can create your own project that's
that's totally fine I've also linked to
a very good talk from europ python that
gives you more of an idea about the
maintainers perspective and why they
might not want to make certain or accept
certain feature requests like
that okay so those are the five
strategies and they were in order of the
least experience to the most experience
you would need to have with a given
project but there is no best strategy
you just tailor it to whatever you're
you're comfortable with because no
contribution is too small
okay so I'll talk a little bit about
being successful when you actually make
your contribution
now so I've said this a few times I'll
say it again if there's an issue up
there always let the world know that
you're working on it comment on it and
say that you're working on it say if you
need help if the project has set up
instructions for getting your Dev
environment up and ready please follow
those right that's going to help you
actually be able to not get frustrated
when you're working on it but you might
also run into problems where those setup
directions don't work and now you
actually have your first PR right right
there fixing it before you even get to
the hard
stuff if you are new to development then
definitely try out documentation based
contributions because that gets you
comfortable with Git and GitHub without
the extra overhead of of the
coding and if you have the opportunity
if you're around tomorrow definitely
attend the
Sprints and make sure that you're polite
and patient in all of your interactions
this is public and people will remember
if you're not polite later
on and also remember that maintainers
are doing this many times outside of
their work so be patient and allow them
time to get to
things so once you've had that first
contribution then it's about keeping up
the momentum and I alluded to this
before but look for opportunities to
share knowledge across projects maybe
one project you're working on has this
really neat GitHub action workflow that
does something that another project
would benefit from look out for those
that's a great way to get started to get
your foot in the
door you can also help others contribute
so I'll talk about the case of of the
psyit learn meta issue so if you've
already had a PR merged or a couple PRS
where you've had comments on and you see
someone else putting in a PR towards
that same meta issue or towards
something else and the CI is failing
maybe you know why you can comment on
that issue and let them know hey I think
you need to fix you know this thing over
here or you can say oh you know they've
pointed out this particular thing to me
in the past you might want to address
this and all that kind of stuff whether
or not it's contributing code or just
being active in that Community will
definitely get you noticed by the
maintainers they will start recognizing
your name your GitHub handle if you meet
them at conferences they will come up to
you and I've had that happen with um
several different projects and that's
really nice to meet people in person
after all those interactions
online and you know that was also how
again the numpy do core developer
invitation came around it was just
caring about the project and
contributing things so you know
consistently okay so I hope I inspired
you to start your open- Source Journey
um if you do end up using any of these
strategies or making your first
contribution I'd love to hear about it I
will celebrate with you on LinkedIn or
sorry on social media it doesn't have to
be LinkedIn uh anything and you can let
me know on the left I have a QR code for
feedback to let me know what you thought
of this talk and on the right there are
links to follow me and I hope to see you
at Sprints tomorrow thank you
[Applause]