That time of my life…(3)

I’m not going to write about how I got into GSOC, I’ve already covered that in my last article, okay I will discuss a little about it here, but this article will mainly covers some lessons I learned, and somethings I should’ve done before- which I didn’t. So let’s get started.

1. Select an organization and the project that is right for you.
   I cannot stress this enough. If you have read my story, you know that I had been applying to get into Outreachy for past 2 years. Every time I used to select OpenStack, it’s a good organization, but it’s not for me. The projects involved in OpenStack are difficult, at least for me.
   Everyone says you should find an organization which interests you. But what if you don’t have a particular interest, but you still want to get in? I had no particular interest, but I wanted to get into Outreachy/GSOC, so I went for an organization whose projects I felt were doable.
   So select an organization and a project which you think you will be able to do, a project which is under your power. At least, this will be helpful when you’re applying for the first time.
   I really wish I had known(learned) more about Cadasta and the projects involved earlier😥. I wish we had met earlier😟.
2. Introduce , Meet and Help.
   I have read in many articles that you should stay active on the communication channel. But it’s not about competition on who stays more active on the channel(okay, maybe it is a little when you’re competing for something), it’s about meeting new people, helping them get started, helping them when they’re stuck, getting help from them, it’s about working together. These past 3 months have taught me a lot about open source and how to get involved with open source projects and communities.
   This is how I introduced myself.
   “Hey, I am Parthvi. I am interested in the project — Cadasta/cadasta-project-ideas#15 and Cadasta/cadasta-project-ideas#16 for Outreachy.
   I have done a few projects in Python, Django . I have also worked on HTML/CSS and JavaScript. I am looking for some bugs to work on, kindly help me out here 🙂”.
   And 6 minutes later, I got a reply from Shruti Singh,
   “@valaparthvi Hello, For bugs-https://github.com/Cadasta/cadasta-platform/labels/First%20Contribution%20Friendly
   I hope you will find some useful bugs here”
   It was that easy!
3. Find an issue to work on.
   Every organization have issues logged somewhere, it can be on github, or bitbucket, or launchpad, or wherever there code-base is hosted. They label these issues with different names, such as “bug” or “enhancement” or “high priority” or “easyfix” or whatever suitable name they like. For beginners, it’s good to find issues labelled as “easyfix” or “low-hanging fruit” or “First Contribution Friendly” or any suitable name there is for an easy issue. Almost every open source organizations have written a Guidelines for First Time Contributors, you can follow that to get started with your first contributions. Cadasta has this guideline.
   But before starting your work on a particular issue, make sure that anyone else is not working on the same issue, you wouldn’t want to cross/interrupt their work. I mean it’s okay to work on an issue even if somebody else is working on it, but it’s not the best practice. I like to think of it as, “I was already working on an issue, and if somebody else came along and started working on the same, I wouldn’t like it. If I don’t like it, then I shouldn’t do that to anybody else.😐”, in other words, “Treat everyone as you would like to be treated”. It’s a different case if there has been no progress in the PR for many days. It may happen that the person who said they would be working on the issue, for some reason, didn’t find the time to work on it. In such cases, ask that person politely if you could work on that issue. You can say, “Hey, I have noticed there has been no progress in this PR. If it’s okay with you can I work on this issue?”
   So before you start working on any issue, make sure you notify the author(the person who has opened that issue) that you would like to work on that issue. You can do that by simply writing a comment there, “Hey, I would like to work on this issue, if nobody else is working on it.” Once you get a thumbs up, go ahead and start working on that issue.
   Although I didn’t know about this when I submitted my first PR, but thankfully no one else was working on it, so it was okay.
4. Making your first contribution.
   So after you have selected an issue to work on, and have found a solution for it, it’s now time to make PR/patch. Cadasta has this git workflow, and I think it’s the ideal way of making a contribution to any open source project. You can read that workflow in detail here. I’ll just list out the main steps. You kinda need to be(you must be) familiar with git for this one. I’m taking Cadasta as an example to give you a better understanding.
   1.) Fork the main repository.
   ->I forked Cadasta/cadasta-platform to valaparthvi/cadasta-platform.
   2.) Create a separate working branch. You will push all the commits related to your issue to this particular branch. Give this branch a meaningful(suitable) name, so that the future you or anybody working with you can easily find all your work related to a particular issue.
   For new features: feature/organizations
For bug fixes: bugfix/123-archiving-projects, where 123 is the GitHub issue ID (if one exists).
   -> I created this repository valaparthvi/bugfix#1045.
   3.) Clone the forked repository. It’s now time to clone the forked repository to your local machine.
   -> I cloned it this way, git clone git:github.com:valaparthvi/cadasta-platform.git You will do all your work locally, and push commits from this cloned repository. I’ll write a separate article to explain detailed git workflow.
   4.) Commit changes to this working branch. Commit all your work related to your chosen issue to this branch.
   5.) Make a Pull Request. This PR must mainly include 2 things in the description — what changes have you done to the existing code base?, why did you make those particular changes?
   6.) Review the Pull Request. Once you’ve made a PR, member of the organization will review your PR. If any additional changes are required, they will let you know. You make those changes and commit to the same working branch. Once they are satisfied with your PR, they will merge it with the main master branch.
5. Give more time in building your proposal.
   After making your first contribution, it’s now time to focus on preparing a good proposal.
   Now I have read plenty of articles written by past Outreachy/GSOC applicants, where they say that you should focus on making your proposal right. I didn’t completely understand the reason behind it then, I do now😁. But if you think about it, the people who are going to select you have never even met you, they will judge you on the basis of your proposal, your proposal is your representative. Just keep yourself in their(people who’re going to select you) shoes, and you’ll understand what I’m talking about.
   So after you’re done with your first contribution, do focus on making a good proposal. Even if you think you’re not a very good programmer, chances are you will get selected if your proposal is good.
   I always thought I had to be this awesome programmer to get into GSOC/Outreachy, but it’s all about getting your proposal right(I think🤔). I mean there were so so so many fellow participants, who were definitely better programmer than I was, who I felt were more deserving, there were these people with 4–7 PRs merged😰 within a time period of one month, there were some participants I knew would be selected for sure, without any doubt, but they didn’t get in for some reason 😕.
   I’ll list out some points for making a proposal here,
   1) List out goals of the project.
   2) Write in detail about every goal. Include — what does this goal mean?, ways of implementation(you can include more than one ways to implement that goal), pros and cons of a particular implementation, include any notes, prerequisites, and in detail explanation of that particular implementation. Also include flowcharts, or wireframes, or anything that you feel is important.
   3) Write about your contributions. Write about your contributions to open source in general, and your contributions to that particular organization. This contribution can be technical and non-technical as well. Contributing to code-base or documentation, or taking a workshop related to any open source technology, or volunteering at an open source organization, all of these are considered as contributions.
   4) Write about any personal projects that you might have done.
   5) Write about your commitments. If you have exams, family vacation, or any other event during the internship(well, it’s not an internship, but it’s easier to say that way) period, then mention it. Be honest.
   6) Design the timeline. Outline your timeline week-wise. Include a list of tasks you would be accomplishing in that particular week. Make sure you design a deliverable timeline.
   7) Others. It’s a good idea to include an About Me(but obvious!) section in your proposal. Mention places where you’re socially active — your blog, website, Twitter, GitHub, LinkedIn, Facebook,etc. It’s also a good idea to mention reference links.
   To see what I mean by all the above mentioned points, take a look at my proposal, it’s here.
   If you’re an early bird and complete your proposal before the deadline approaches, you can also get a review from your potential mentors and past applicants. There is this github repository where you can get your GSOC proposal reviewed. Check it out here.
   While designing your proposal, you should think from your potential mentor’s perspective(it can be from a perspective of any person other than you). Or think of it as, um I don’t know how to exactly put this, but, will that potential mentor understand this? Should I put in a detailed explanation? How do I design my proposal so that it’s easily understandable?
   I hope you get the gist of it. If not, just mail me, and I’ll try to explain in detail.
6. Now wait for the Results. Once you’re done with proposal, it’s now the waiting period! GSOC/Outreachy, all these programs are important for me, as an ordinary student(I know it sounds negative, but it’s really not!), and who does not have much confidence in her programming skills. Such programs helps me a lot, to boost my confidence and to gain confidence as a programmer. If you’re like me, it would be important for you too. So it’s obvious that your mind would be going crazy during this waiting period. The trick is, every time your mind starts thinking about the results, tell it to…

Every time your mind goes,
“I don’t know what will happen. Will I get selected? I guess I might. But there are so many people better than me, their chances are very high. I have already told my parents and friends about this, what If I don’t get in? What if I miss out on this opportunity? But, what if I get selected😃? It would be so good! But what if I don’t😣?”

Tell your mind this,
“Dear Mind,
⏸, relax, and ▶️. It’s not that big deal(even though it kinda is). If you get selected, it would be awesome! You will learn so many things, you’ll work on a real project, you’ll meet so many awesome people, and the money🤑! But, if you don’t get selected, it’s OKAY. It’s just a baby step. Just look how much you have learned till now. You learned how to make a contribution to any project, you learned more about git, you learned about a new organization/technology that you didn’t even knew existed. You met so many new people from all around the globe, you made some new friends, you are far more better than you were 2 months ago. If you don’t get in, move ahead with your next baby step.”
I’m sure you’ll have similar conversation in your head again and again and again, until the results are announced.

There are plenty of articles on the internet to help you with this, and I can guarantee you that mine is not as organized as it should be. But I’ll list out some other well-organized articles here, take a look at it.
1) 7 things you need to know, to ace your GSoC Proposal
2) How to find your first open source bug to fix
3) How I got started with Open Source and you can do too.
4) List of proposal of past GSOC applicants.
5) FLOSS Manual on writing a good GSOC proposal
6) Quora on How to write good GSOC proposals
7) Google’s official article on GSOC proposals
Although these articles are related to GSOC proposals, you can use those points for your Outreachy proposal as well.

Phew, that’s pretty much it. I’ve covered every thing I experienced and learned in these past 3 months, before the results were announced, um almost everything🤔. I hope you find this useful😌.
Again, let me know if there are any grammatical errors, or extra use of articles🙄.