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.

Audience

  • 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!

Appendix

  • 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.

Acknowledgement

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.

Tips and Tricks For Fixing Your First Bug

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.