2014 was crazy. It had a lot of epically lousy parts, but also had some good
parts. Like 2013, I don't know what I did with my 2014 goals.

2013 involved a lot of projects. 2014 involved fewer.

dennis: Lots of development on
Dennis. It's really come along as a tool, though I wish I had more
users since that would help flesh out issues.

denise: A web front-end for
dennis. I did some work on it, but it needs some more to remove some
of the sharp edges.

ernest: Everyone has a
Bugizlla front-end--this is mine. I work on this with Mike, Ricky
and Rehan. We made some solid improvements in 2014. Having said
that, it's still pretty hacked-together and it's not generally
useful to anyone else.

denton: A bunch of us keep a
log of what we've worked on day-to-day in Standup. Denton pulls the
weekly data and throws it into an email. It doesn't sound like much,
but it runs on a RHEL 5 system with an aged Python 2.6 and it's a
pain in the ass to use. Given that, Denton has virtually no
dependencies and sports its own (mildly terrible) template
parser. It continues to be a mildly fun hobby project to tinker with
periodically.

elasticutils: I did a
ton of work on ElasticUtils so that people could use it and get over
the Elasticsearch 0.90 -> 1.x hump. After talking with Honza,
Jannis, Erik and Rob at PyCon US 2014, we decided it wasn't worth
keeping ElasticUtils going. Honza built elasticsearch-dsl
does some of the things ElasticUtils does, but better. Several
Django-focused shim libraries that sit on elasticsearch-dsl have
appeared since then. In January 2015, I deprecated the project and
no longer work on it.

richard,
steve and
pyvideo: I did a bunch of work on these
three right after PyCon US 2014 and then I totally burned
out. Sheila took over admin of pyvideo. I tried to reduce my role to
fixing architectural problems with richard and steve. I haven't
spent much time on either, though. I'd like to spend more time on
them, but now I'm having difficulties finding free time to
spend. These projects are currently struggling.

I also spent time on a bunch of other projects:

peep: I helped a bunch on peep
adding support for github tarball urls which we use a lot for Input
and SUMO. I'm now a maintainer and help out with project
maintenance.

Sandstone: Schalk
built this project as a Bootstrap version of Mozilla Sandstone look
and feel. I was thinking I'd use it, but it seriously lacked documentation
so I helped work on that for a while.

elasticsearch-dsl-py:
I spent a portion of PyCon US 2014 sprints talking with Honza, Rob
and Jannis about what I liked about ElasticUtils and we worked out
parts of the elasticsearch-dsl-py API. Since then, I very occasionally
comment on issues. I'd like to spend more time on this project, but Input
and SUMO are still stuck on Elasticsearch 0.90, so I don't have anywhere
to use it, yet.

The sec-champs group fizzled out. I continue to help manage Django security
updates across the various Mozilla web-sites. (Security)

I continue to work on l10n issues by improving the Dennis PO/POT linter.
I also wrote Denise which anyone (particularly translators) can use without
having to install Dennis. (L10N)

I got around to writing a site-health dashboard for Input. This
makes it much easier to spot issues after deployments and code
changes. (IT)

I wrote a smoketests test suite using Selenium for Input. This reduced
goofs with feedback that we had periodically. (QA)

We set up Fjord to work with Vagrant. The vagrant provisioning
script is a bash shell script and isn't idempotent which is a bit of
a drag occasionally. However, this system has made it a lot easier
for new people to contribute to Fjord/Input development. L. Guruprasad
helped a ton here. (Community building)

I overhauled the feedback forms on Input making them more responsive,
accessible and generally better. (UX/UI)

I wrote a translation system for Input which does automated machine and
human translation. It's currently using Gengo, but the system is modular
so we could write modules for other translation companies. This translates
incoming feedback in non-English languages allowing our analysis tools
to operate on everything in English. (Software engineering)

I started a Dashboards for Everyone project which coupled an API for
querying feedback on Input with some examples using d3 for converting
that code into dashboards. I thought this project would do a lot to
alleviate peoples' needs for data, but as far as I can tell, it never
caught on. (Software engineering)

Early in 2014, I started working on a data retention policy for Input
data. Over the course of 2014, this policy gelled and was implemented.
(Privacy)

In 2014, I committed to writing up project plans for the bigger
Input projects and
maintaining them in public. The thinking was that this lets other
people follow along and correct missteps. Also we have a record of
why we did certain things the way we did them. In reality, I don't
think anyone really cared and/or looks at them. Still, it
occasionally helps me, so that's probably good enough. (Project
management)

Challenges for the year:

I think I'm easier to work with than I was in previous years. I
spent some time fixing how I did things. Over the course of 2014,
the indications that I was hard to work with have mostly
disappeared. It's entirely possible that's because I switched
projects and work with different people now. As a side note, User
Advocacy group at Mozilla is amazing to work with.

I'm still working on too many things. I continued working on fixing
this. I retired ElasticUtils which was taking a lot of time. I
retired from working on playdoh, funfactory and friends. Still,
there are projects I want to work on that I haven't/can't, so that
bums me out.

Two roommates is still crazy. It'll be like that for a while, I think.

Wearing lots of hats on the Fjord/Input project really took a toll:
project manager, architect, lead/solo developer, QA, deployer, ... I
do it all. I learned I can do this, but that it's exhausting and I
spent most of 2014 feeling overwhelmed and like I can't move fast
enough. I really appreciate Ricky, Rehan and Mike helping with
reviews and technical questions I have, else I would be sunk.

In 2015, I want to:

Spend time working on pyvideo, richard, dennis and ernest and get them
to better places.

Overhaul my blog. Douglas is great, but the blog theme has issues and
has since I last overhauled it in like the mid-2000s.

Find more time to tinker. I had like zero tinker time in 2014--it was just
too crazy. No tinker means I'm falling behind (or at least feeling like
I'm falling behind).

Blog more. I did a few impressive things. I wish I had blogged about them
so that there's a record of me doing those things and also so that others
could learn from my experiences. It's hard to find the time, though.

Both IE and Chrome Are to Support asm.jsInfoQ.comThe modern.IE Platform Status indicates that now asm.js is in Development. According to Microsoft, the Chakra engine in Windows 10 will support asm.js, and Microsoft has been collaborating with Mozilla to implement it faster. Chrome is going to support ...

February 7 ,2015 has been a really special day in event life.I had shared my experience as an OPW intern at Mozilla Web Maker Party organised at Rajagiry School of Engineering and Technology,Kochi. Thank you Rebecca Billings for connecting me with the mozilla reps in my region and thanking Vigneshwar Dhinakaran who trusted me to take the session.

It was my first ever conference in which I handled a session, and it was next to awesome.The maker party gave me an opportunity to network with other mozilla people at my region. Further in this post I shall my experience of the event.

I reached the venue at 9.00 a.m.and met Vigneshar Dhinakaran.Vigneshwar is the Mozilla rep and main organiser of the event.He proved to be friendly host and smart organizer. RSETians where waiting with enthusiasm to for the event.A few hours later I met another team of Mozilla reps who co-organised with Vigneshawar including Nidhya,Praveen,Abid.Praveen was GSOC intern in one of the previous round. Praveen blog is quite informative. Click here to read his blog

The session started with transforming ideas into prototype,followed by an introduction to web technologies and mozilla web maker,after that Praveen and myself shared our experience as an intern at Mozilla and SMC(Swantantra Malayalam Computing).We spoke about opportunities like Google Summer Code , OPW and Rails Girls summer code.

We both explained our respective projects Oneanddone. It was interesting to know about his project developing and adding support for Indic language layouts for Firefox OS.

I spoke about the upcoming opw round, and gave some tips to get started.We talked about irc,encouraged them to subscribe to mailing list,use irc and learn github. We were able to help them in finding resources for learning like openhatch,trygit etc.

We found that students really doesn’t get a chance to contribute in open source projects. There is a popular misconception that open source projects has place only for highly skilled developers.We presented open source as a platform for developing skills.I gave a brief description about how they can be a part of documentation,quality and testing etc.

To conclude open source is an important part of technical education.But students are not aware of how they can contribute in open source. Providing them proper mentorship could help them bringing to forefront. Opportunities like OPW and GSOC could be a good dive into open source.To achieve this the mozilla reps has decided to organise a boot camp in the upcoming week.Stay tuned

The second episode is up! We seem to have solved the resolution problem this time around – big thanks to Richard Milewski for his work there. This time, however, my microphone levels were just a bit low for the first half-hour. That’s my bad – I’ll make sure my gain is at the right level next time before I air.

The second episode is up! We seem to have solved the resolution problem this time around – big thanks to Richard Milewski for his work there. This time, however, my microphone levels were just a bit low for the first half-hour. That’s my bad – I’ll make sure my gain is at the right level next time before I air.

Next month, Johnathan Nightingale will step down as a full time Mozillian after 8 years of distinguished service. We’d like to thank him for his countless contributions to the Mozilla project and leading Firefox through periods of intense competition and change.

In the last year Firefox turned a corner. We achieved positive growth again and dramatically reset our global search strategy – and we now have a much stronger foundation from which to build, grow and pursue our mission. Related, recently we have been exploring how we can integrate client software on desktops and mobile with cloud service approaches to evolve what Firefox can do for people. In an effort to support this vision, it’s a great time to hand over leadership to someone deeply experienced in mobile and cloud services.

So today we combined our group focused on cloud services with the group focused on our Firefox desktop and mobile browsers. Mark Mayo, who has been running our Cloud Services team for the past 4 years, will be taking over leadership of the combined group.

A bit about Mark: he is well known as an elite technical leader not only within Mozilla, but in our industry. Further, Mark’s entrepreneurial drive coupled with his holistic thinking, market orientation, and exciting vision for the future of Firefox make him the ideal person to lead this new team. He’ll be stepping in as Vice President & General Manager of Firefox.

Next month, Johnathan Nightingale will step down as a full time Mozillian after 8 years of distinguished service. We’d like to thank him for his countless contributions to the Mozilla project and leading Firefox through periods of intense competition and change.

In the last year Firefox turned a corner. We achieved positive growth again and dramatically reset our global search strategy – and we now have a much stronger foundation from which to build, grow and pursue our mission. Related, recently we have been exploring how we can integrate client software on desktops and mobile with cloud service approaches to evolve what Firefox can do for people. In an effort to support this vision, it’s a great time to hand over leadership to someone deeply experienced in mobile and cloud services.

So today we combined our group focused on cloud services with the group focused on our Firefox desktop and mobile browsers. Mark Mayo, who has been running our Cloud Services team for the past 4 years, will be taking over leadership of the combined group.

A bit about Mark: he is well known as an elite technical leader not only within Mozilla, but in our industry. Further, Mark’s entrepreneurial drive coupled with his holistic thinking, market orientation, and exciting vision for the future of Firefox make him the ideal person to lead this new team. He’ll be stepping in as Vice President & General Manager of Firefox.

Today I wrote this post describing my difficulties in getting started with Ember.js, a quite well known open source project.

Normally, when I find small issues in an existing project, I try to help by sending a PR–some things are just faster to describe by coding them than by writing a bug report. But the case here was something that requires way more involvement than me filing a trivial bug. I tried to offer constructive feedback, and do that in as much detail as possible so that the authors could understand what happens in somebody else’s mind when they approach their project. From a usability and information design perspective, this is great information to have!

Shortly after, Tom Dale contacted me and thanked me for the feedback, and said they were working on improving all these aspects. That was great.

What is not great is when other people insta-ask you to send PRs or file bugs:

@supersole as the core would say, those are considered bug reports so feel free to file them on github! it really helps the writers as well

Look, I already gave you A FULL LIST OF BUGS in excruciating detail. At this stage my involvement with the project is timid and almost insignificant, but I cared enough to give you good actionable feedback instead of just declaring that your project sucks in a ranty tweet.

The way you handle these initial interactions is crucial as to whether someone decides to stay and get more engaged in your community, or run away from you as fast as they can.

A response like Tom’s is good. He recognises I have more things to do, but offers to listen to me if I have feedback after they fix these issues. I can’t be sure I will work more with Ember in the future, but now I might check it out from time to time. The potential is still there! Everyone’s happy.

An entitled response that doesn’t acknowledge the time I’ve already invested and demands even more time from me is definitely bad. Don’t do this. Ever. What you should do instead is act on my feedback. Go through it and file bugs for the issues I mentioned. Give me the bug numbers and I might even subscribe to them to stay in the loop. I might even offer more feedback! You might even need more input! Everyone wins!

This is the same approach I use when someone who might not necessarily be acquainted with Bugzilla or Firefox tells me they have an issue with Firefox. I don’t just straight tell them to “FILE A BUG… OR ELSE” (unless they’re my friends in which case, yes, go file a bug!).

What I do is try to lead by example: I gather as much information from them as I can, then file the bug, and send them the bug URL. Sometimes this also involves building a test case, or extracting a reduced test case from their own failing code. This is work, but it is work that pays off.

These reporters have gone off to build more tests and even file bugs by themselves later on, not only because they saw which steps to follow, but also because they felt respected and valued from the beginning.

So next time someone gives you feedback… think twice before answering with a “PATCHES WELCOME” sort of answer—you might be scaring contributors away!

For the past few months I’ve been working on a sub-project of Treeherder called Perfherder, which aims to provide a workflow that will let us more easily detect and manage performance regressions in our products (initially just those detected in Talos, but there’s room to expand on that later). This is a long term project and we’re still sorting out the details of exactly how it will work, but I thought I’d quickly announce a milestone.

As a first step, I’ve been hacking on a graphical user interface to visualize the performance data we’re now storing inside Treeherder. It’s pretty bare bones so far, but already it has two features which graphserver doesn’t: the ability to view sub-test results (i.e. the page load time for a specific page in the tp5 suite, as opposed to the geometric mean of all of them) and the ability to see results for e10s builds.

Green is e10s, red is non-e10s (the legend picture doesn’t reflect this because we have yet to deploy a fix to bug 1130554, but I promise I’m not lying). As you can see, the gap has been closing (in particular, something landed in mid-January that improved the e10s numbers quite a bit), but page load times are still measurably slower with this feature enabled.

From time to time, Firefox developers encounter errors which only appear on our build machines. Meaning -- after they've likely already failed numerous times to coax the failure form their own environment -- they must resort to requesting RelEng to pluck a system from our infrastructure so they can use it for debugging: we call this a slave loan, and they happen frequently.

Firefox is a huge open source project: slave loans can never scale enough to serve our community. So, this weekend I took a whack at solving this problem with Docker. So far, five [of an eventual fourteen] containers have been published, which replicate the following aspects of our in house build environments:

On top of our Mock configs, we further specialize build chroots via build scripts powered by Mozharness. The specifications of each environment are laid out in these mozharness configs. To make use of these, I wrote a simple script which converts a mozharness config into a Dockerfile.