Mozilla Code Sprint, August 2014

We organized the Mozilla Code Sprint on 23-24 August, 2014 at three location throughout India which were Delhi, Bangalore and Hyderabad. We also had Sankha doing a local code sprint in his college, IIT Jodhpur.

Mixing it up a bit

We decided to change the event format, where earlier we used to have events in colleges which were attended by people from that institution only. Instead we decided to host city wide events by asking people to register for attending the event and then tried to accommodate as many serious contributors at the onsite venues as possible. For the rest of them, we hosted a remote event using IRC, email and other forms of communication so that those participants get our full support as well. Remotely, at home and on our own is how most of conducting this event got started. So we knew it was totally possible. We wanted to get quality people who were passionate about doing things, even though that number might be lesser (than when we host institute specific events). This was partly encouraged by our learning from the past, doing developer events in India and has recently been echoed by David Boswell from the Community Building Team.

On to some numbers

We got a tremendous response from the community! We invited 23 at Delhi, 18 at Bangalore and 28 at Hyderabad to attend onsite at the respective venues. Out of them, 13 in Delhi, 11 in Bangalore and 14 at Hyderabad could attend onsite (others either couldn’t come or had to backout at last moment due to various reasons). I’m really excited and proud to say 10 patches in Delhi, 16 patches in Bangalore and 6 patches in Hyderabad were submitted. In Jodhpur, 3 people were able to successfully submit a patch. That means almost everyone submitted a patch (some even submitted multiple patches) and the others were well on their way to get one done really soon! These are contributors who had mostly no familiarity with the Mozilla projects a few days back :) For a 16-hour overnight event, I think this is really good output.


We had a lot of learning from this event. What worked was :

  • Attendees going through What Can I Do For Mozilla and interacting with us about their interests, what they feel passionate about, what they have prior experience with, setting up their systems with the code base of the project they decide to hack on during the event BEFORE coming to the event.
  • We had shortlisted and found out some of the easier bugs among the ones BugsAhoy shows, so that contributors don’t spend time going over bugs in BugsAhoy which are blocked due to various issues.
  • What also worked is having the event overnight. We had folks from India, who had expertise in different areas, from mozilla-central to gaia to Thunderbird to Kuma. We luckily also had folks online sometimes (which might be probably due to letting them know beforehand about the event) from other countries, mentors some of them, who came in at the right time to review bugs or provide help/quick feedback. The time of the event (from 6pm IST Sat to 10am IST Sun) was also during the daytime of western countries which was helpful sometimes.
  • I also thought of documenting the work contributors do during the event because a lot of time is spent in setting up system, fixing the issues while doing this, then finding a good bug to work on, understanding it or figuring out the blocker and then moving on or lack of enough information in the bug to fix it. All of this takes time, a lot of time. It’s not just the final number of fixed bugs which matters. So we decided to document all of this so that we can draw inferences and do a better job next time.

What didn’t work or could’ve worked better :

  • The event being on a weekend, because of which not everyone was online on the IRC channels.
  • Since there was so much enthusiasm, we had a couple of times multiple people submitting the patches for the same bug or having spent time fixing the same bug.

Next steps

As David aptly points out, retention is a very important key and now we also need to focus on it. We’ve documented the details of all of the participants and intend to follow up with them periodically to make sure they aren’t stuck anywhere.


Here are the pictures from the Hyderabad event. Pictures from Bangalore and Delhi are here!


In Delhi, we had a lot of fun, food and obviously contributions :) Thanks to Akshay, Akshay, Santosh, Rishab, Pankaj, Sudheesh, Girish, Galaxy and so many others, basically the entire team to pull this event off so well. In addition, we are really thankful to ThoughtWorks for providing an awesome venue (with all the infrastructure) and free food and drinks!

GSoC Progress Report

It’s been quite a long time since I blogged about my GSoC work.

Here’s what I’ve been working on :

  • I have the patches on the adding file transfer support in js-xmpp bug in a pretty good state now (and hopefully should be ready to land). This took quite some time, with me learning more about Promises and Task, which I didn’t have any experience from before. It took me quite some time getting a hang of it.
  • I also worked on integrating the Firefox Downloads Panel in Instantbird. I’ll have a WIP soon.
  • I rebased my FileLink patch and am now trying to fix some issues with the signing in.

I’ve not had a lot to show in this time, with various things coming in like the World Cup, issues in patches which tool unexpectedly more time to debug and breaks on a few days. I’m planning to ramp up the work and get back on track with my schedule.

BugStrips: Bitstrips but about Bugs and with cute Dinos

The problem

The problem I recently noticed was that my work related to Mozilla was so specific that I couldn’t share it with my non-technical friends even though my work might be something they ended up using (like the Per-Window Private Browsing feature in Firefox). So I needed a way to share what I’m working on or what I’ve worked on, easily and in a fun manner, which appeals to both my technical and specially my non-technical friends.

The possible solution

BugStrips, bitstrips but about bugs and with cute dinos. Bitstrips as some of you might know and/or have used, is this quite popular means of sharing a comic about your friends and you, using these hilarious illustrations showing various scenes you might have yourself into, like eating a pizza, or watching World Cup.

The idea of bugstrips is instead to share what bugs or features you’re working on, on the social networks of your choice and having little cheeky, funny dialogues between characters. Right now, I think the dialogue between the kid and the dino (like in Sean Martell’s art) would be awesome. The costume of the dino and/or the kid, the background and other things could be customized based on the bug we’re talking about. For example when we’re talking about privacy, the dino might be wearing a Domino mask or when we’re talking about freedom, the dino and the kid could be flying, something like that.

Advantages of such a project

  • Brand Awareness: We will be able to increase awareness about the new features we implement or bugs which new contributors help fix.
  • On boarding of new contributors: There might be people who find out about Mozilla, Open Source and it’s projects, in the social networks that these strips are shared in and eventually end up as contributors.
  • Contributor recognition: Appreciation is an important factor, I believe in sustained contribution. We try and appreciate, recognize the efforts of volunteers. If this appreciation comes from the contributors own circles, that would be even more great. I personally feel delighted every time someone likes something I post (I know what you think about me now ;) ) and I think others do too so this might appeal to them.

Things to keep in mind

  • The art should be good.
  • The text should be cheeky, hilarious, fun, anything which has appeal, like for example we have on What Can I Do For Mozilla.

In the User Centered Design session at MozCamp, Holly told us to define the audience and success metrics for such a project.


  • Developers who would use this to share BugStrips to their social networks.
  • People who would view the BugStrips on the social networks.

Success Metrics

  • Developers keeps fixing bugs or fixed more bugs because of this.
  • Number of views or clicks or comments on these strips.
  • Number of people who end up on our getting started resources or BugZilla because of these strips.

Implementation Details

It makes sense to implement this as a separate site where you could see the list of bugs you’ve fixed and the bugs you’re currently working on, instead of trying to integrate it into BugZilla in the first go.

UX Prototype

Here’s a really raw UX prototype of how the entire thing would flow: Click Me!


  • Cute Dinos: I really love Sean Martell’s art, specially his dinos. (You can download a wallpaper of these here).
  • Awesome Art: You can make something so interesting as BugZilla, moar interesting by such beautiful art. Other such beautiful art are always an inspiration.


My brother for pointing out that he didn’t understand what I was working on all this time. Larissa for brainstorming on this idea with me during MozCamp’s UCD session. Holly for teaching us the framework on which to evaluate and think about ideas/apps/products.

Got any feedback, suggestions, snide remarks? Feel free to comment here, email me or let me know on twitter. Now let’s build this thing, shall we?

On MozCamp Beta 2014 - Bangalore, India

So I attended the MozCamp Beta that took place from 20th-22nd June, 2014 in Bangalore, India. This was a different experience compared to the Mozilla Summit 2013 in Santa Clara(there was no bacon being served or giant roller coasters) and the MozCamp Europe 2012 (people here spoke Kannada instead of Polish).

On a serious note, the agenda was altogether different. We were focused much more on Evangelism, Design and Engagement, since the launch of FirefoxOS phones in India is right around the corner (yay!).

Day 1

We started with some icebreaker exercises by Amira and which were really helpful to get everyone to come out of their shells and get the juices flowing. Then we talked about AppMaker and I found out quite a few good things about it. I really like the colored pipes being used for events listeners, which just makes it so intuitive. We gave feedback on AppMaker, then had a brainstorming session about what we wanted to build with it. Me and Rishab came up with the idea to create a brick for plugging in geolocation in your apps built using AppMaker. We started with implementing geobrick but couldn’t get much further due to all the sessions and interactions, but we plan to work on this. The teaching kit for the AppMaker session is available, feel free to remix it and use it for your local events. During dinner I interacted and discussed quite a few interesting things ranging from the new proposed Volunteer Agreement to Texas cowboys to Music and so on.

Day 2

We started early on Day 2 with a discussion on story telling and how we need to be more clear about explaining what Mozilla is, going forward. We had some exercises which led to quite a few interesting discussions. We then headed on with our showcase of local experiments/formats/ideas which had worked and feedback on that. Then came the obligatory awesome group photo (and other “extended” selfies which shall not be shown here). Throughout these sessions we had these little exercises which made it interactive and acted as nice icebreakers. image

We then headed to the various sessions. I decided to attend the User Centered Design session by Holly since that’s something I’ve been interested in. We learned about the importance of user study, the kind of insights it can give us, how to go about interviewing them, prototyping ideas and defining success metrics for them. Due to the shortage of time we had to wrap this up pretty quickly but it was a lot of fun and learning. A blog post about the ideas we came up will be up soon :)

The day ended on a sober merry note. Onto day 3.

Day 3

We started with the lightning talks. I gave one about #introduction, the importance and effectiveness of helping someone remotely over IRC and best practices for getting started. I had never given a lightning talk before so it was a new experience and me getting to play Hotel California in the end just sweetened it. (Note: if you want to watch an epic lightning talk, watch this).

We then swapped sessions. I had the option to choose between Developer Relations and Engagement. I wanted to attend both but ended up choosing Engagement since with the upcoming launch, it made quite a lot of sense. We started with discussing ideas that other launch countries had used for promoting and brand awareness during and after the launch. We then divided ourselves into 4 groups and brainstormed about possible local solutions and ideas to do this in terms of Social Media, Community Events, Students and FSA’s and Developer Events. There were quite a few interesting ideas that came up like banners behind auto-rickshaws for promotion, street plays etc.

What I <3’ed about this MozCamp

I loved the amount of brainstorming that we did, the kind of hands on session design that we had which gave us space to think, ideate and collaborate. I also really appreciated the icebreaker exercises which were really important for the brainstorming sessions to be productive.

What I didn’t like about MozCamp

The lack of time, because of which we had to wrap up some really cool sessions.

Report: 23 June - 27 June

So I had gone to attend the MozCamp Beta India 2014 from 20th - 22nd June because of which I didn’t work much on my GSoC. Coming back on 23rd, I was still a bit occupied with post event followup so not much work has been done this week.

  • I addressed Patrick’s comments on my first patch.
  • I found out a DOS issue with my patch and fixed that.
  • I’m working on getting the error messages to the UI as notificationbar items instead of throwing them to the console.
  • I have also clarified with Patrick on how to write the xpcshell tests required for my XMPP implementation. I’m working on that too.