Some wisdom from my Open Source experience you might appreciate 
Disclaimer - These are my conclusions, you might differ! I am writing this just to make things a bit easier for newcomers. You are completely allowed to differ from me! Also dont just read, ponder and work on the things that I wrote. You might reap a lot of benefit in the long term.
You can reach me out in gsoc-sig by username harsh-ps-2003. I will try to reply if I am available. Otherwise, org-admins are always there!
Contributing to codebase and handling the project :
-
Do you know the file structure of the codebase? Generally the tech stacks define the structuring of the codebase. Develop a general idea on code organisation. Go through Readme.md and contributions.md and learn the basics of the build tools used in the codebase. Try to imagine the links within the codebase. Maybe draw some diagrams. Mature project ideas have to be implemented keeping the future scope in mind. Also think about the technical debt that you might create.
-
You want to see how different parts of the features were implemented, use git blame (gitlens extension in vscode) to observe the timeline of feature additions in the codebase. See the PRs to observe how the PR was added, read comments on the PR. Btw use IntelliJ for java development and know your IDE really well!
-
Dont fear from imports. Throughly research what is being imported to understand why. This will be like general knowledge of the codebase and will help you navigate the methods. Be patient when starting out with the codebase. Ask for help from the mentors.
-
Debugger and tests is your best friends. read the tests of a new codebase, debug them and set breakpoints to see how they interact with an actual codebase. Dont understand how the system is working, debug the integration and end-to-end tests. Dont know how the methods are working, use Unit tests. A lot of trial and error will be involved. Patience is the key!
-
You will be surprised on how much can you do with just prolonged trying with patience and a deep self belief. Also share complete error text (pic or video only when necessary) to get your problems resolved.
-
I know you dont want to make yourself look like a joker when asking stupid questions. But not asking will surely make you a clown in the long term. Ask well researched questions! Once you feel there is a blocker (however small it may seem at first) inform the mentors. They are volunteering to help!! You are doing good if the conversation goes like this :
Mentor - “did you try this, this, this “
You - “yes! This happened when I tried this, this, this”
Mentor - “okay! What else could be the issue?”
You- “coming up with other hypothesis, otherwise bluntly telling them, you are blocked”
They will try finding the solution to your problem while you can try working on some other part of the project. They will help in code reviews to correct you also. You are not alone in Open Source.
Another thing is that, mentors are not programming gods!! They may be more experienced but you might be smarter!
-
Once the project starts, dont tinker with your development environment much (no lucrative updates and stuff) because things in development stage break fast! You dont want to be in a situation when things are not working in your local machine suddenly but is working in your mentors machine!! Also keep in mind, mentors are volunteering their time so please try to be respectful of their (and yours) time.
-
Understand the problem from the first principles before coding. Proper planning before coding always! There is no trying to fix the error by luck, why thing happened is to be known always! Read error logs thoroughly. Develop abstraction thinking.
Proposal :
- Your initial attempts of the proposals may not be good, dont worry about it. Just start ideating and Prepare the proposals like you own the project!! You have to understand the project and start creating the proposal on your own. After getting the first proposal, mentors will help you refine it. Refer to previous selected proposals and projects. The previous contributors were given exactly what you are given right now and they were able to ideate the project proposal, and you can do the same. Explain things assuming that you are explaining it to someone who does not know much about the project. If there will be anything extra, then the proposal reviewers (make sure you get atleast 1 review before final submission to google) will point it out. Ask what else can you write in your proposal to make it stronger. No chatGPT and copying from others proposals. It’s inhuman to the mentors. Dont fake knowledge, we are not expecting you know everything beforehand. We are betting on potential not knowledge (though you should have a bit working knowledge)
General :
-
No personal DMs to mentors/maintainers/org-admins. Everything in public. It’s OPEN source!
-
Open source is not a zero sum game. Helping other contributors is always appreciated! Learn from them and give constructive criticism also. It’s the not the right place for competition.
-
Overcommunication is never bad! The communication skill that you are going to learn will be directly transferrable to future roles you will take up! Dont forget to learn how long and intense technical conversations are being held.
-
Rejection is not bad! Not doing anything to improve after being rejected is!
Also dont forget to enjoy the journey. You will remember your time in the Jenkins community even after years. Maybe you will also come back to give back just like I want to because of nostalgia. Cherish life.