

Ask HN: How to get started with open source contributions? - abdelhadikhiati

I am a  computer science student and every time i go o Github and look for a project to contribute to , i find myself with a big code base that i am not able to understand how it works , neither what every piece of code means , how do you manage to understand those projects ?
======
logn
My comment pertains to the part of your question about understanding a large
code base...

\- First attempt to use and compile the project

\- Figure out where the entry points are for the app. Generally this would be
a 'main' function and any sort of event handlers. Frameworks complicate this a
bit because they're responsible for calling code and do it in any number of
arbitrary ways.

\- Get a feel for the organization of modules/packages etc. Try to find the
naming structure/patterns and how everything is laid out conceptually.

\- Focus on a few features (just a random sampling) and grok how those work.
Hopefully at this point there's some semblance or order in the project, so
that if you understand how a few parts work, you can start to build a model in
your mind how everything works, without trying to study everything in the
codebase. And an architecture diagram from the project owners would help too,
if an up-to-date one exists (doubtful).

\- Make a very simple/trivial change, compile it and try to observe the result
(that your change successfully compiled).

\- Choose a bug or very small feature to work on.

\- Success?

Edit: I just read the comment by 'fundamental' which I happened to basically
restate with bullets. Anyhow, good luck. It took me about 2 years of full-time
programming before I got comfortable reading large codebases.

------
fundamental
To answer the title question, it might be best to look for smaller projects in
a language that you're very familiar with with issues marked specifically for
external individuals to complete. Smaller scope issues should be easier and
they would give you some more experience in reading code which would appear to
be the issue at hand.

For the larger codebases, generally you would want to get a vague idea of the
architecture and then blind yourself to most of the complexity. Let's say that
you wanted to work on a network based data serialization library and the issue
marked out as 'contributor friendly' was adding unsigned integer support
building off existing signed integer support. For that target, there's a large
portion of the code that you shouldn't need to understand too deeply and
there's a section that is going to be relevant to making the modification. Try
to find the code that is relevant and trace the execution just by reading the
code.

As long as you limit the scope of your work and the codebase is somewhat
compartmentalized, you can shrink the time it takes to go through large
projects by a fairly large amount.

------
Bahamut
First, to be a good contributor, you almost always have to be a consumer of
the library. Once you understand how the library usage works, then you can
work on improving the api, fix bugs, or even just improving the documentation.

Read the source code, and see if you can find any small wins such as
optimizations or better api.

