Just some stuff about me.
Taken from Contributing to Complex Projects
Steps:
Become a user. Try to build something real using the project, even if it is small or simple.
Build the project. Learn how to build the project and get a working binary (or equivalent). Don’t bother with understanding the build system.
Use an approach I call “trace down, learn up.” I start with a feature or use case, and start from the outside in to trace the codepath that the feature follows. During this process, I take notes about the files, lines, and functions I’m going through, but I do not yet attempt to understand how anything works. After tracing a feature, it is time to actually learn how the various mapped subsystems work. Whereas with the tracing phase, I start at the outermost point such as the CLI or API call, with the learning phase, I tend to start at the innermost point.
Experiment with the project. During the “trace down, learn up” process, I find it very helpful to experiment and break things to learn how something works. Add new log statements, implement tiny chunks of new functionality, change existing functionality, etc. then rebuild the project and see what happens.
Read and reimplement recent commits. As a final step to learning internals, I read recent commits relevant to the subsystems I’ve studied and test that I fully understand why the change was made. I either view the commit history of the project or the commit history of a specific file or folder relevant to a subsystem I’ve studied. I then either study the solution first (the changes in the commit) or I see the bug it fixed and attempt to fix it myself and see if I arrive to a similar solution. To “work the problem”, I’ll checkout the repository at the commit just previous to the commit I’m studying. I’ll reproduce the bug it fixes (if it is a bug fix), and then attempt to implement the solution myself. Finally, I’ll compare my work to the commit done by the maintainer or contributor.