Firefox OS/Comms/Dialer

From MozillaWiki
Jump to: navigation, search
Gaia Dialer App Icon

The dialer is a component of Gaia, which in turn is the front-end for Firefox OS. The dialer comprises all of the front-end code for making and receiving calls, including the callscreen, which is a separate app. The dialer team is organized under the umbrella of the communications apps team.

In addition, the dialer team is responsible for emergency calling, CDMA, USSD/MMI, DTMF tones, integration with other communications apps, and dealing with partner requirements.

Meetings/Team Communication

Vidyo Room

Quick link to join with the Vidyo app

"FxOS_Dialer" Vidyo Meeting Room

We have our own Vidyo room for meetings. Contributors and non-employees are welcome to attend all meetings. Here are the full details for joining:

"FxOS_Comms" Vidyo Room


We mostly use IRC. We're available on #fxos-dialer, and #fxos-comms.



The dialer team has a public calendar with every internal meeting.

Instructions for Adding to your Calendar

  1. Open the calendar.
  2. Click on the "+ Google Calendar" button in the very bottom right of your screen.

Note: The "Find a Time" feature will not work for other people if you import this calendar. As a consequence, others will not see that you are unavailable when attending a Dialer meeting. Please let us know if you have a solution for this. For now, we suggest either living with this, or adding the meetings to your main calendar as well.

Daily Standup Meetings

The daily standup meeting is composed of two parts: the first is async, and happens sometime before the sync meeting. Full-time dialer team members should write the progress that they've made in the last day on the dialer scrum GDoc. Part-time members and observers can optionally do the same. Additional instructions on what to write are in that section itself.

The second part of the meeting is sync, and happens over IRC at 2:30 pm GMT (10:30 am EST, 4:30 pm CEST) in the #fxos-dialer IRC channel. Here, participants should only discuss major things, blocking issues, and questions that they have for others. The goal is to keep this meeting 10 minutes long or less.

The old etherpad used for daily standups is available here.

Hosting the Standup

  • Current hosts: drs, gtorodelvalle, thills
  • Hosts rotate every week.
  1. If you're not available for a standup that you're scheduled to host, then ask for someone else to host instead for just that time.
  2. Start by pinging everyone who should be participating.
  3. List any administrative items you have, and then ask for more from other people (look at the Etherpad).
  4. Look at the list of blockers and blocker nominations and see if there's anything new or that needs action. Mention these during this time.
  5. Move to individual updates. Go alphabetically, in descending order.
  6. If someone's update is taking longer than 3-4 minutes, you should generally cut them off and ask them to talk about it after the standup.
  7. Copy the reports from the GDoc to the wiki page for that day. Use the Etherpad-to-Wiki converter to format it. You can just copy and paste the whole thing and the converter will do everything for you.
  8. Ask the person who should be hosting the week after you if they'll be available. If not, move onto the next person.

Office Hour

The dialer team has a weekly office hour where we have semi-structured time to talk about whatever we need to. It happens every Wednesday at the same time as the standup. We have the standup first, and then move into the office hour.

The agenda is posted on the office hour Etherpad. Usually, the agenda items don't take long to get through, so we use the remainder of the time for things that people think of while on the call, or day-to-day items. A summary is written afterwards which is posted with the current sprint office hour summaries.

Bug bash

We run bug bash sessions from time to time during which we revisit old bugs with the goal of closing those that have already been fixed, finding duplicates, removing the invalid or obsolete ones, etc...

The bug bash etherpad is available here.

Bug Triages



Past Sprints

Sprint Planning

Sprint planning happens every 2 weeks on Mondays, at 1:30 pm GMT (9:30 am EST, 3:30 pm CEST) in Joe Cheng's Vidyo room.


We begin sprint planning with a retrospective. This is the place where we change things. Everybody must think ahead of time about what was good and bad during the last sprint. This could be anything, and can be entirely opinion. Participants should also think of any questions that they have.

During the meeting, everybody dumps their thoughts on the sprint planning retrospective Etherpad, and then we take some time to review them. Ideally, all bad things and questions end up having action items.


We have 25 points of velocity every sprint based on 8 team members; 2 part-time. We make estimates as to how long features will take to complete in days, but we don't estimate bugs (or we assume they're 1 point).

Between 50% and 75% (depending on the moment in the release cycle) of the velocity is used for blockers. The rest of the velocity is kept for new blockers appearing during the sprint.

We take the list of bugs in the order of priority, and estimate them together. Estimates are identified by:
[planned-sprint c=X]
tag, where X is the estimated number of days, or "cost".

You can find the etherpad used for discussing estimates here.


Currently, the rough priority order is: 1.3T+ > 1.4+ > 2.0+ > 2.1+ > 2.2+ > features > nice-to-have >= dialer-most-wanted. We can have a look at the nominations (2.1?, etc) too. nice-to-have are provided by the EPM, whereas dialer-most-wanted are decided internally within the dialer team.


When we reach the available velocity, we stop. We try to take some tech debt bugs or long term projects (at least 1 per sprint would be nice), identified by blocking the dialer-most-wanted bug, bug 1036516.

Whiteboard Tags

  • [planned-sprint] - Indicates that we planned to take this at the beginning of a sprint.
    • Alternative use: any bug not in the Gaia::Dialer component but with this tag will show up in the "Redirected Bugs" page.
  • [in-sprint=vXXX] - (e.g. [in-sprint=v2.0-S5]) Indicates that we took this in a previous sprint and had to push it to a later one.

During Sprint


Features/bug fixes with any user visibility should be demonstrated by providing a before and after screenshot, or a video. These should be added as they are completed to the current sprint's "Demos" section. We recommend not waiting until the end of the sprint since it's easier to make these while you're on that feature branch and remember everything.

We also welcome adding demos for changes that aren't visible to the end user. You can choose how you want to present these. Do whatever makes you happy!

Taking more bugs

Bugs inevitably come up during the sprint, so we take them and don't apply the [planned-sprint] tag to the whiteboard. We try to keep enough velocity available to accomodate these. Ideally, and if we plan correctly, our velocity will always be the same (see the current target velocity) by the end of the sprint. We don't estimate these bugs, but we will discuss them in the next retrospective if they were features that we were unexpectedly able to take.

Current Sprint


  1. REDIRECT Firefox OS/Comms/Dialer/Sprint/v2.2-S10



  • Bugzilla query
  • Note that these are each prioritized by EPM, not internally within the dialer team.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Blockers Without an Assignee

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Blocker Nominations

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


  • Bugzilla query
  • Note that these are each prioritized by EPM, not internally within the dialer team.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


  • Bugzilla query
  • Note that these are each prioritized by EPM, not internally within the dialer team.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);


No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Mentored bugs

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Reference Materials

API/Programming Documentation

Actual code documentation should go on the Mozilla Developer Network. Currently, the documentation is very shallow and often obsolete/out-of-sync. Please consider contributing to it!

Feature/Subcomponent Documentation

UX/VD Specifications














User Experience

Visual Design


Long-Term Project Ideas

  • bug 1039131 - Improve stylesheet docs, simplicity, and organization.
    • bug 1039130 - Use StyleDocco documentation generator for stylesheets.
  • bug 1042576 Move call log to a DataStore.
    • This will help memory consumption by not opening the Dialer app after a call.
  • General redesign and refactors (a la Haidification).
  • Better support for testing emergency calls without accidentally placing them.
  • Moving more towards using HTML template fragments for more realistic testing.
  • Clean up keypad and DMTF tones code (blocked partially on platform WebAudio work)
  • Clean up USSD/MMI code, add multi-SIM support.
  • Have a platform for automated integration tests (mulet? emulator? something else?)
  • Testing CDMA in regions that don't use it, perhaps using the emulator.
  • Improve emulator use and documentation.
  • Separate communications apps into different apps.
  • Improve Kanban and our dashboard tools.
  • bug 1035153 - Prototype dialer without tab bar.
    • We should work on this more and bring it to production based on Carrie's feedback.
  • bug 1039594 - Use FontSizeUtils in shared instead of our own FontSizeManager

Ideas for Improvement

  • Do video demos of important new features.
  • Discuss vision for the future of the dialer, including the app itself, the team organization, and how we work.
  • Improve communication with VD and UX, e.g. set up progress-based meetings.
  • Improve the way we split up bugs and use metabugs to make things easier for UX and VD people.
  • Improve the way we organise files and assets in our code base
  • Integrate Kanban more into our workflow.
  • Get more contributors engaged.