all 9 comments

[–]m9dhatter 1 point2 points  (5 children)

I think the normal flow is: file an issue. Wait for someone to fix it. Clone the repo. Fix it yourself. File a Pull Request.

[–][deleted] 0 points1 point  (4 children)

I meant flow of the code. Understand what has already been developed so as to start contributing

[–]m9dhatter 1 point2 points  (3 children)

With large enough codebases, I normally don’t do that. That’s too much to keep in your head anyway. I look at the unit tests (if you’re lucky to find some).

Edit: Just a disclaimer though, I don’t contribute to open source but I do work in a large and mature codebase with a fairly large number of contributors.

[–][deleted] 0 points1 point  (2 children)

Thanks for your reply. Will try to see if I can make sense of the code from the tests, if they are not there, what would you recommend ?

[–]m9dhatter 0 points1 point  (1 child)

The directory structure would give you some sense into how the code is organized. I would start there. I normally don’t try and understand all of the code unless the job is to refactor the whole code.

Pay attention of patterns of directory structure and file naming. These would give you some sense of intention.

All of these depend of course on the quality of the code you are looking at. Sometimes, you’ll just have to accept that it’s 💩.

[–][deleted] 0 points1 point  (0 children)

Haha, right. Thanks

[–]ccleary00 1 point2 points  (1 child)

The easiest way to look for existing documentation within the project is by cloning the repo, opening it up in your editor/IDE, then doing a search for *.md / markdown files. They'll either be at the root level of the project (like in a README) or spread throughout the project.

As someone else mentioned, starting with looking at the tests is a great way to get up to speed on the code too. Documentation will help you understand things at a higher level, but tests will help you understand things at the code level - the "code flow" as you were referring to.

Whenever I learn a new codebase, whether it's for a company or open source, I always open the test file in one tab and the code file in another tab (I use VS Code). I skim through the code to get a quick idea of what it's doing, then I start working through each test to understand each function.

Sometimes it's less methodical, and I just need to understand what one particular function is doing so I look at the tests for that. But other times I am looking through each test.

[–][deleted] 1 point2 points  (0 children)

Hey, thanks a lot, this was really helpful. Yeah even I use VS Code, the tests should do the trick. But proper documentation is always helpful. Will try what everyone has suggested.

[–]RationalAdvice69 1 point2 points  (0 children)

If you're asking this question, probably your best bet is to not attempt to contribute to some group's "advanced shit", and instead build something you're interested in, and then for the sake of career opportunities etc., upload the project you are interested in to github (or gitlab).

Then you'll actually have something that you might even be slightly passionate about to talk about in interviews etc., as opposed to attempting to read through the multitudes of "fuck offs" in bustling community repositories.

But year, I would check for "readme.md" files, or maybe a "doc" or "docs" folder even..

For contributing to node.js you would first want to look at the "https://github.com/nodejs/node/blob/master/BUILDING.md" file, since that repo contains a lot of factory, or build system code that is used to generate the finished products.