How to contribute to bigger projects?

[droy117]

Hello, I wanted to know how do I start contributing to actual big projects like React, Django, Mastodon... without feeling super overwhelmed.

I have contributed to some smaller projects and the contributiona were often very minimal. But I want to actually contribute like a big feature or a major bug fix and so on.

Whenever I visit a project with a huge codebase I am mostly unable to understand most stuff and quit after feeling overwhelmed.

I know my question isn't very clear enough, I am extremely sorry about that😅.

But it would beneficial if someone could share there experience when they started contributing to big projects and how they learnt and understood the thing required before making a contribution.

Any response is appreciated.🙏

[cheshire137]

Hi there! I don't often contribute to big projects, but when I do, the contribution usually comes from necessity. I'll be using the library or framework myself in my own project, and find a bug or have a feature in mind that would help me. I think that's been helpful for me in terms of understanding a large project: if I'm coming to it as a user of it, I already have an idea how it's meant to work, the kind of interface it has, the kind of output it gives, etc. That gives me a head start on finding where in the large code base I might find something, because I know what it's called in the docs or the API. It also helps me have an idea if the maintainers of the project would accept the kind of change I want to make.

I think it also helps that I come to it with a specific change in mind. That lets me scope my work to a smaller contribution, which should hopefully make it easier to get merged. I also have the evidence of it being a real-world use case, which can help justify why the change should be made.

When I shipped a change to generated scope names in Rails, that came from a very specific example where the existing Rails scope-generation code didn't produce the name I wanted. Having that use case in mind helped me answer a question about how the change should be implemented. It was also a very tightly scoped (heh) change that didn't require many lines. That's much less scary to a maintainer who doesn't know you than if you come in with a big change that touches everything.

When I shipped a disable_joins argument for Rails has_one relations, I was extending an existing feature. disable_joins already existed on another kind of relation, I just wanted it to also exist on has_one relations because I'd ran into a case of needing it in my project. This helped me figure out what I should change and how I could test it. I also had the benefit of the author of the original implementation being willing to work with me, answering questions and pairing with me on the implementation.

I think it's helpful to try implementing your change, even if you know some parts of it are wrong or not pretty. Being able to show the maintainers that you're trying and are willing to put in the work goes a long way. I try to be responsive to their suggestions, too.

TL;DR: contribute to a project you've used before, have a specific change in mind, work in small chunks, communicate why you want the change, work with the maintainers when they're available.

[droy117]

Hi! First I would like to thank you for taking the time to write such a helpful response. Previously I used to just look for random popular projects and make some minor contributions if possible. After reading your reply I think I should stick to one project that I use or am familiar with for a while and start contributing to it starting from making small contributions, understanding the project more, asking the maintainers for help, and contributing more whenever I am able to.

[cdwort]

Whenever I visit a project with a huge codebase I am mostly unable to understand most stuff and quit after feeling overwhelmed.

Oh my gosh, same! This never goes away - and it shouldn't, since huge codebases are beasts! That being said, I understand the appeal - big codebases have outsized impacts on our lives as developers.

I'll echo @cheshire137 that you probably want to come into the project with a specific change you want to make and with experience using the project. But that's maybe a little hard to bootstrap. So at the risk of giving you advice you may have heard elsewhere - consider starting by working through the getting started docs. Often docs are a bit neglected, unclear, a version behind, etc. Working through the docs provides a way to immediately contribute value, get to know the maintainers and the project and start to see opportunities for improvement.

[droy117]

Hi @cdwort, thank you for taking the time to give such a nice response. It's comforting to know others also find huge codebases overwhelming. I completely agree with you mentioning @cheshire137. Her response definitely helped me get a better idea for making better contributions over time.