If you have already applied for GSoC or Outreachy this year or you are planning to apply in future, this guide is going to be very necessary for you. I am going to write collectively the things that I did wrong and some borrowed from other people’s experience. So, let’s begin.
Do not EVER top post while communicating with your program coordinators/mentors/fellow participants. This is one thing that no one is going to teach you but everybody expects you to know as this counts as one of the basic etiquette to converse/communicate. You should ALWAYS use inline mode of communication. What’s that? See below.
Suppose you receive this message in your inbox:
So, while replying, select plaintext mode and click on the three dots (…) in your reply box to the see the received message with (>) prefixed.
Now, inline means reply to this message as you’d answer a question in an exam i.e. write your answer below the question.
That’s it. No rocket science required.
Sending out untested patches
Who likes to break the rhythm of testing…OK…Applied.? Whenever you write a patch, make sure you ALWAYS build test it. This is the basic step that HAS to be followed in every work. DO NOT TAMPER WITH THE EXISTING INFRASTRUCTURE. Also, it makes maintainers upset to see a big mistake like this. When I was in my application period, Greg always told that such patches make a maintainer grumpy as they have to reinitialize the whole process. After all,
$ sudo make install
is not a very big thing to do.
Writing patches with styling errors
Now, think of a code looking like:
But, look at it. My eyes cannot even bear the pain void would be bearing being so distant from main! OK. Not a good joke, I get it. You do get the idea now, right? I do agree that the code you’re going to write is not going to be this severely style-affected but the kernel developers do follow a certain scheme regarding the coding style. How do you know if your code is correct? Simple. Use checkpatch.pl to detect coding style problems with your code. You can do it in two ways:
- Configure git to always check problems with your code before commit.
You can do this by editing .git/hooks/pre-commit, add up the following code to it:
#!/bin/sh exec git diff --cached | scripts/checkpatch.pl --no-signoff - || true
Now, make the file executable by doing
chmod a+x .git/hooks/pre-commit
This should work.
- Run the checkpatch script on your file and look up for warnings/errors on the line numbers where you made edits.
OK, this is one thing that all of us have been affected with. But, when you’re applying to such big programs, you ARE evaluated on the basis of your behavior. Being patient is A BIG part of it. Now, what level of patience do you think is expected out of you? Advanced. You have to be really patient when your mentor does not reply (a week is not really a big deal), you have to be patient when some senior developer takes out faults in your code. Arguing is NEVER a good thing, be it real life or these programs. This certainly does not mean that you should not try to make your point clear if the other person is misunderstanding it. Do it but patiently and with all the manners involved.
Sometimes, it might happen that your mentor writes an incorrect thing to you, now the reasons for this can be- misunderstanding or typo. If you get the idea your mentor wants to convey, you do not have to keep on telling them that they wrote a wrong thing. After all, your mentors are
- Mostly maintainers of some big tree. They have A LOT of patches to review and A LOT of contribution to make.
- They do have a job other than checking your patches.
- They too have a LIFE.
- They are humans of course.
Apart from this, if you’re communicating with an entire mailing list, make sure that you are not creating noise for other people subscribed. Ask ONLY relevant questions.
Asking questions with an obvious answer
If you have to have a good image and want your mentor to be happy with your work, ask questions once you’re completely satisfied that googling it or digging on the code is not going to help. If you do not do like this, it is going to reflect very badly on you.
When you’re accepted to these programs, you are supposed to have a sense of responsibility which includes proficiently using google and reading the code, doing some analysis on your own. Sometimes, it is tough to understand a thing but the git tree might leave you a lot of hints.
Unless explicitly asked for your knowledge about some particular thing, accept calmly and courteously the knowledge that your mentor is imparting to you. You might know that thing already but it is possible that your mentor tells you an amazingly hidden feature of it. You do not have to present your knowledge by showing off like that, writing good code with minimum mistakes possible would be the best way to show your knowledge and talent.
Do NOT lie under any circumstances. If your mentor is asking you to do some work, tell them you can do it if you really can do it, tell them you’ll need their help if you’d need it, tell them you cannot do it with the correct reason for that.
COMPLETELY AVOID BEATING AROUND THE BUSHES. If you have been asked a question, tell the answer to it only if you know it, say you’re not sure if you are not sure and accept that you do not know it if you do not really know it. You’re not getting insulted in any way, your mentor is just evaluating where to start training you. It is ALWAYS good to tell the truth. You will be conversing about the code with the people who CREATED it, you can NEVER get away by telling a wrong thing. Be truthful. ALWAYS.
I did some things from this list but I was very lucky to have an amazing mentor, he is a very very patient guy, he taught me the right way to write code and communicate. You might not always be that lucky. So, better if you keep your reputation up following this guide.
So, that’s pretty much my list, you think I’ve missed something you experienced? Write in the comments below. Share your experience.
Thanks for reading.