Firefox OS/Comms/Dialer

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.

Calendar

Instructions for Adding to your Calendar

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.

Hosting the Standup

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.

Start by pinging everyone who should be participating.

List any administrative items you have, and then ask for more from other people (look at the Etherpad).

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.

Move to individual updates. Go alphabetically, in descending order.

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.

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.

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

Sprint Planning

Retrospective

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.

Estimates

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:

Priorities

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.

Assigning

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

Demos

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.