Tips and Tricks For Fixing Your First Bug In Mozilla

So this weekend, while at the MozCamp Beta in Bangalore, I came across a lot of contributors who had tried to fix their first bug but had gotten stuck at various stages of the process. So here are some of the tips and tricks I used to be able to fix bugs when I started.

Your first point of contact: IRC

• First of all, don’t be afraid or embarrassed to ask your questions. When I started I had the feeling what I used to ask was really stupid, but if you’ve tried finding the answer for some time and haven’t yet found it, it’s certainly NOT trivial so please ask your questions. I have wasted quite some time and been stuck for days just because of not asking for help. Trust me, we’re really sweet folks and love to answer questions :)
• Once you decide to ask the question, go ahead and ask it. Don’t just say hi and wait for someone to reply to you and only then will you ask your question. Also ask the question directly instead of asking whether people would be able to answer, we won’t know if we’ll be able to unless you ask it right? Basically don’t ask to ask your questions.
• Be patient. People on the IRC channels are mostly from different timezones so everyone might not be awake when you post your questions.
• Extending the first point, use persistent IRC clients, like IRCCloud or Waartaa so you don’t miss the answers which people give when you sleep. Or you could just check the IRC Logs later.
• Try and read the instructions in the topic that we have, like on #introduction we have links to What Can I Do For Mozilla and BugsAhoy which are great resources to find bugs and projects to work on.
• Comment on the bug stating your interest to work on it, try and find the person listed as the mentor there on IRC and ping him or just tell us on #introduction so that we can find him/her for you.

Let’s get building

• When you’re having issues with building the project, pastebin the exact output you get so that we can more information to find out the reason and help you. Similarly when you’re writing a patch and it’s not working, pastebin the code instead of simply stating that you’re working on something and it’s not working, so that we might be able to spot a silly mistake you might be overlooking, if that might be the case. This last part has been stressed a lot by the people I’m working with in #instantbird and I think it’s a great tip. You could also use |./mach pastebin| after you get a build error.

Where is da code

• We try to mention the relevant code for fixing the bug in the comments or it might be inferred from the component the bug is filed in. If it isn’t clear, I follow the steps Josh mentioned so beautifully in his blog post.

Gimme moar

• If you’re looking to do long term contribution, what worked for me was finding a project or a feature being worked upon and having some bite-sized dependency bugs which I could fix. That way, I felt responsible for the implementation of the project, I had a sense of accomplishment and progress when I fixed each dependency and also I didn’t have the overhead of jumping between very different parts of the code which improved my efficiency.

If you want more detailed tips, feel free to checkout an excellent post by Manish.
These are my tips, do you have some more in mind? Feel free to comment here, email me or share them with me on twitter.