FirefoxOS grew quickly to be a super active project under constant global development by hundreds of people around the world (employees and volunteers in Mozilla). Over the past two years we developed a fully fledged open source mobile operating system based on web technologies. Naturally the least thing you could do as a Mozilla contributor is to try to keep track of what is happening, and arguably this has been really difficult from the start.
On one hand this is understandable. The pace the project is moving is lighting-fast, with requirements and dates changing constantly. On top of that, our partnership with companies of the industry (OEMs, OBs, chipset manufacturers etc) has made the tracking of things even more complex.
On the other hand, the successful end result (and engagement of new people) is a hint (or a proof?) that there might be a way to track things for us mere mortals. With this post I will try to describe the discovery and tracking procedure I am using to keep myself engaged and updated about FirefoxOS. The info I am looking for are one or all of those: dates, owners, projected ETA, code, specs, mockups.
Disclaimer: This is by no means an official guide to feature-tracking but rather a documentation of my personal experience and definitely tailored to my tracking needs. Hopefully this can be proven useful to other people and I will get some suggestions in comments, so comment away!
Let’s start with the basics. Bugzilla is your central source of information about everything happening in Mozilla-verse. But we will need more than that to be successful. We need to be able to understand how things are tracked within Bugzilla. My focus has been Gaia (as the most FxOS-unique part of FxOS stack) so let’s say for the sake of this guide that we are looking for more info on a Gaia feature. (e.g. Custom ringtones)
Our first stop is Gaia wiki. Wiki.mozilla.org is used for all high-level tracking of FxOS features (and pretty much for all other Mozilla projects too)
Navigate through the page and you can find all different major areas of Gaia (Apps, System and their sub-parts) Once you locate the section that your feature is under (in our case System>Sound) click through to land in the wikipage specific to the area of the project. Although the Gaia (and generally FxOS) team has done a fantastic job of updating the wiki with status of features and roadmap you might end up in a not-so-helpful wiki page (like in our example).
Stepping back a bit, our goal is to find more info about a feature. For every feature you might think of there are three different scenarios:
Scenario 1: Feature is a planned, detailed and committed one.
If the feature is something that the Gaia team is committed to deliver (approved in meetings) then one of the following can happen:
- The easiest case is that all the info you need is on the wikipage we just explained how to find. Boom you are done!
- A slightly trickier case is that the info is not yet on the wiki so you need to search bugzilla for it. Before you do that make sure to check out the UX specs making sure that your feature is part of the committed ones. (Bonus: get lost in the fantastic work that UX team has done!) Searching bugzilla you should use “Advanced Search” with “Boot2Gecko” as the Product and make sure you search for both NEW-ASSIGNED(generally open) *and* RESOLVED status. FxOS team is delivering like crazy and your feature might be already delivered! You can easily identify the “official” commited bugs by their title ([User Story] something_here) and/or their priority/severity (P1/blocking etc)
Once you find the bug you are looking for you can get all the info you want or cc your self to get more info as they come (m0Ar bugmail please!)
Scenario 2: Feature is a proposed one.
In this scenario the feature is something already proposed by someone and there is an active (or not!) discussion around it. Bugzilla is your only help here. Follow the instructions above on Bugzilla search. Most of those bugs will be UNCONFIRMED or NEW (definitely not ASSIGNED and hardly RESOLVED as INVALID or WONTFIX) so tweak the bugzilla search accordingly. Make sure to be constructively involved in the discussion around the feature (based on your expertise) so you can make sure that your lovely FxOS device will soon have your killer feature!
Scenario 3: Feature is not even a proposed one. (It’s all in your head!)
You know the story… File a BUG! But wait! Before you go ahead and file a bug, opening the flood-gates of bugmail, make sure to do the following: Check with UX guidelines to see if you missed something. There might be a case that something is already spec’ed out in UX designs but not translated to a bug. In that case ping UX people on IRC channel #gaia for follow-ups. If UX designs prove to be unaware of your awesome idea you might want to have a look at project Haida. Project Haida is the UX project for proposed features and designs for future versions of Gaia.
If everything fails and you are the sole person in the world thinking about this cool feature, you might as well go ahead and file a bug (following bugzilla guidelines and etiquette) under Boot2Gecko Product and the Component that fits your proposed feature category.
Extra channels: As always make sure to drop by Mozilla IRC on #gaia (or #b2g if that’s suitable) and ask for help if you are stuck. Mozillians there as *awesome* and super responsive.
Hopefully this over-view of my workflow as a non-member of FxOS team will be useful to some other Mozillians out there Please go ahead and comment with ideas and enhancements (or corrections!) of the process. Special thanks to Fredy for his countless hours standing by me navigating through FxOS code, and asuth for his responsiveness on any Gaia related questions we had