Blog

Please nitpick

When working with Open Source, some of the best learnings come from code reviews. When I first started coding on projects with strict code reviews Launchpad), I was uncomfortable getting nitpicked. I (wrongly) thought the goal was to have a code review that has absolutely no nitpicks (crazy right?). Whenever someone had a nitpick with my code, I felt like I couldn’t code properly. That’s when I read this excellent mail from Jeroen Vermeulen to the launchpad-dev team:

A rubber-stamp approval can save you minutes or more in the short term, but it does nothing for your longer-term development. A rubber-stamp approval leaves you without proof that the reviewer has read and understood the branch. A rubber-stamp approval sets no performance bar, no communicable standard for reviewers to live up to. A rubber-stamp approval does not tell you whether your branch was excellent, so-so, or too hard to read. A rubber-stamp approval buys you time that you could use towards the self-improvement you’re missing out on, but fails to tell you where you need it most. A rubber-stamp approval deprives you of a chance to harmonize your part of the codebase with our best practices. So I don’t like getting rubber-stamped any more than I like to rubber-stamp others. Good reviews take time, and that’s not time I put in for the sheer fun of it.

It changed my world. I’ve had epic nitpicky code reviews after that. Its even changing how I do my code reviews; I’m warming up to be more nitpicky. Lesson learnt – code reviews are one of the strongest takeaways from open source. So, if you’re reviewing code, please nitpick. Don’t rubber stamp. The professional development of the person whose code you’re reviewing depends on it!

PS: For acceptable levels of nitpick 😉

2011-10-30
How I Got Involved With Mozilla

There have been a fair number of responses to David Boswell’s post about how he got involved with Mozilla. Most of the responses have been from fairly established contributors and contributing for a while. I thought I’d share my experience since I’ve been around for hardly 4 months now and moderately active.

My first attempt at contributing to Mozilla was a disaster. It was around January 2011 and I tried to contribute to addons.mozilla.org (AMO) before its cleaned database was publically available. It took me a while to set the whole thing up and eventually when I did have things setup, I couldn’t properly reproduce bugs since I had no data and I had trouble adding new data. Eventually, I gave up out of frustration and I had lesser time available and my interest died out. Things have definitely changed since, the database for AMO is now downloadable and I’m pretty sure my setup troubles were my lack of experience; thank you Wil Clouser for being patient with me back then.

Around June 2011, I applied to a web developer opening at Mozilla. The email which confirms my application said this, ‘If you’ve gotten this far, we’re certain you care about the future of the web. It’s easy to get involved and further that mission.’ I think this struck a note in me (whoever thought to add it, great job!). I wanted to give it another shot. This time, I just joined #webdev and asked if any projects needed help. Dave quickly responded saying that Input could use some help and I started checking out the code and setting it up. By July, I had cleaned up most of the easy bugs on Input and I continue to help fix bugs. I ended up not getting picked for the position I applied for, but I’m really glad to be contributing.

Things have changed since my attempt in January. There is now a significant interest in making virtual machine images available via either vagrant or some other means so setting up a dev environment is much easier (See posts by tofumatt, lochard, and groovecoder). This reduces the barrier of entry and frustration levels significantly. A frontend person need not be a linux sysadmin anymore to be able to fix a small CSS bug. Another good thing about this is, since everyone will be on the same environment, we’re reducing the chances of a weird environment problem.

Is the route I took still possible? I’d definitely say yes. If you know Python and Django or PHP or CSS or JavaScript, there are a bunch of webdev projects, and just asking in #webdev channel could guide you to projects that need help. It’s probably a good idea to ask during UTC–8 working hours since working hours of most of Mozilla WebDev overlap significantly around that time.

2011-10-16
Monkeypatching Django Admin

When I started contributing to Mozilla Webdev, I started with Input. The bug that was always a mystery to me was bug 658658. The login page to Django’s admin worked in Django 1.2.3, but didn’t work with 1.3, which is what was in the input vendor. At that time, I didn’t know about monkeypatching Django well enough, or care enough to fix this. Last night, I was scrolling through bzhome (Thanks again Heather!) to find this bug again.

This is how it looks before I fixed it

After 3 hours of working with folks in #webdev, especially jsocol, peterbe), and r1cky, we finally fixed it. The problem was that the monkey patching didn’t catch one case, the login and logout views which where not in django.contrib.admin but in django.contrib.auth. Thanks to everyone’s patience (especially r1cky, since we spent about 1 hour trying various combinations of things), the bug is fixed and I now know a little more about monkeypatching.

2011-10-14
User Days Poll

User Days were created to be sets of classes offered during a one day period to teach the beginning or intermediate Ubuntu user the basics in order to get them started using Ubuntu. User Days were born out of a discussion at the Ubuntu Developers Summit in November 2009 regarding Ubuntu Open Week not being targeted enough at users. User Days is hosted over the weekend for many hours at a strech so everyone will be able to participate at some point. Open week, however, is hosted during the week at the fixed time-range.

This, however, is now changing. From this cycle on, Ubuntu Open Week will be targeted at users. As the organizers of User Days for the past 4 cycles, we’ve been wondering what the community thinks about this – Should we continue User Days or should we not. Please mark your opinion in a quick poll that I’ve created.

2011-09-29
Launchpad bug titles are everywhere!

A while back, I wrote about smart autolinkifying in bugs. Last week, at the urging of Brian Murray, I built on top of the work that I’d already done. This time, it grabs all the bug links and sends to the linkchecker and, in addition to the set of invalid bugs, it also returns a set of valid bugs with bug titles! The after effect is a ‘bug 1245’ link in the body of Launchpad like in bug tracker, merge proposals, etc, where bug 1245 is a valid bug number will have its ‘title’ attribute set to the bug title.

2011-09-20