Gaia/Dialer/Restructure

Summary

We have discovered that the dialer team could use some improvements in the areas of organization and planning. In the past, we have mostly worked ad-hoc, with little planning besides a very relaxed sprint planning session.

Please contribute to this as much as you feel/want! We can't fix this problem without you.

Good/Problem Areas

Good Areas

• Wasting very little time in meetings
• Very nimble and able to switch gears to get things done when needed
• Anthony is very vocal about UX and is a great liaison for us there

Problem Areas

• Not anticipating problems
• No clear vision for future
• Little accountability when things go wrong, not much formal retrospective or discussion about processes
• Not capable of effectively expanding to include more team members

Interviews

I (Doug) spoke with people on other teams and got some useful information about what they're doing and what's working well for them. I really wanted to talk with Julien, but unfortunately he's on PTO.

Contacts

In general, the contacts team is in the middle-ground between the dialer and messages teams. It seems that Francisco always has a pretty good idea of what everyone is doing and is able to organize things in his head without as much on-paper planning as Julien uses. This seems to work well for them, and they're experimenting with new approaches.

Everyone in the contacts team is in Europe, so they don't have as many scheduling conflicts for meetings and random chats.

Francisco (Lead)

• Daily meetings
  • This is the time to say "I have problems here" and have others help you
  • Takes less than 10 minutes
  • Helpful to know what everyone else is doing (sometimes there's overlap between work and useful tidbits)
• Starting to do estimations
  • Being relaxed on it
  • Leave some free time for important things that come up during the sprint
  • Commit to at least a specific minimum amount of work done
  • It's very motivating to look at a list of bugs and watch them fall
• Wiki articles
  • Helpful for going into the comms meeting (though this will be phased out)
  • List of global things before meet
• Planning (not just sprint)
  • Try to have long-term projects going on on the side
  • Ask people what is not working in contacts (not just retrospective)
    • Example question, "if you were going to rebuild contacts from scratch, what would you improve?"
    • Have a list of tasks to get to one of these
  • Spend time designing, ask other people about architecture decisions
    • Do prototypes, there will be unexpected problems in any big projects
  • Likes this middle-ground of planning
• People organization
  • People should focus on one task
  • Have some people working on blockers, and others workers on future things, have them rotate
• Awareness of big problems
  • Current big problems: performance (DataStore?), design (Haidification)
  • Try to make time to have people work towards these
• UX relations
  • Lets UX do their job, isn't very picky about UX decisions
  • Easier to chat with people in person about UX, liked being able to talk with Vicky when at Telefonica, but still not perfect
  • Was unhappy about VR work that happened without him there (I may have misunderstood what he meant here, so please don't judge him :))
  • Would like to have Vicky on IRC or otherwise quick to contact (Skype, Vidyo, etc)
• Random useful insights
  • "Work is not just about working, it’s also about letting other people know what you’re doing"
  • Planners look at the last time a blocker was updated
• Comms meeting
  • They take turns taking notes and going to the comms meeting to present them
• Takeaways and suggestions for the dialer team
  • Consider having our meeting later in the day (we already do this for sprint planning)
  • Work on integrating Tamara into the team
  • Identify big things that we can be working on to move dialer forward instead of just reacting

Michal

• Daily meetings
  • This is a good to get help from other people
  • They have their own IRC channel, #fxos-contacts
  • 15 minute meeting every half hour before the comms meeting
  • Every day there's someone missing, wishes everyone would attend
• Wiki articles
  • History of daily standups, who worked on what, when
  • Videos with demos of what we achieved
  • Don’t need to attend the comms standup
  • Favorite part of this process
  • Makes him feel better and being able to track his progress
• UX relations
  • Not really any relations with UX
    • Mostly Bugzilla comments, patches that need ux-review
    • Contacts refactoring is rebuilding the app from scratch, will change things

Messages

The messages team is very tightly scheduled and has many, more formal, processes to make sure that things get done. The messages team has 2 people in Europe and 1 in Taiwan, so there are significant scheduling difficulties.

Julien (Lead)

on PTO :(

Oleg

Useful links: https://etherpad.mozilla.org/sms-retrospective https://wiki.mozilla.org/Gaia/SMS/Scrum/3 https://wiki.mozilla.org/Gaia/SMS/Scrum https://etherpad.mozilla.org/sms-standup https://etherpad.mozilla.org/messages-datastore https://etherpad.mozilla.org/sms-haida

• Daily meetings
  • Done async over Etherpad: https://etherpad.mozilla.org/sms-standup
  • Doesn't think there's significant overhead to this (takes him about 10 minutes each day)
  • Likes Etherpad format
  • Mention updates in daily standup
• Estimations
  • Velocity of 8 points
  • Sometimes only assigned 1 bug with point value of 1
  • They only estimate bugs that take 1 day or more (lowest point value is 1 point which is 2 days, should be adjusted in the next sprints to be more precise)
• Wiki articles
  • Great way to get summaries
• Sprint planning
  • Every 2 weeks, same day as comms planning
  • They do retrospective first: https://etherpad.mozilla.org/sms-retrospective
  • 2 hours, too much, trying to improve
  • Done over IRC
  • Will try it over Etherpad, as IRC doesn't work well
  • Vidyo more efficient, but hard to schedule
• People
  • Everyone works on whatever
  • Doesn't like specialization on blockers, even just in terms of temporary time specialization
  • One time they tried specialization and it worked well, but he doesn't think it should happen all the time
• Awareness of big problems
  • DataStore, Haidification
  • Split into small bugs that are manageable
  • Not breaking down big bugs was not working
• UX relations
  • Mostly needinfos for UX
  • Would like to have Vicky on IRC
  • Problems with UX organization in general, mockups problems, not much discussion
  • Painful use of time, hard to get good responses
  • Really didn't like visual refresh bugs
• Action items that they've decided on and haven't been able to do
  • Estimating for people on other teams is hard and inaccurate, so invite those people to standups
  • Hard to invite people from other teams, they have own commitments
• Comms team meeting
  • People don't care about little things, focus more on high-level
• Takeaways and suggestions for the dialer team
  • Julien has an Etherpad script for making a wiki article from Etherpad

Steve

todo

Dialer

Etienne

• General
  • Agrees there's a problem within dialer
  • Optimistic about these plans in general and that people are looking into ways to restructure
• Daily meetings
  • Ok with coming to daily meetings, not super enthusiastic though
  • Would like for it to be over IRC
  • Worried when he sees people saying standups help them get unblocked
    • Thinks people should be using needinfos/IRC instead
    • Likes having time to think before responding
    • (drs/note) I mentioned that we'll be getting more people soon and not everyone is as familiar with the dialer as him, and he agreed that there's value for us there
• Vision for his role
  • Work mostly on blockers
  • Likes working on stuff he actually uses
  • Feels a bit like dialer is mostly done
  • Always worked on other stuff, didn't just suddenly decide to move out of dialer
  • There was an idea within the comms team of people rotating around inside the team but it never happened, he liked this idea
  • Was owner once most of the features were already done, module ownership came relatively late
• Estimations (bugs)
  • Bugs take constant time for him (cool!) so he doesn't think they're worth estimating
    • Only takes bugs he can repro locally
    • debug/console.log a bit
    • make a dirty fix, make a test, make a clean fix
• Estimations (features)
  • More valuable to do estimations here than for bugs
  • We don’t have a lot of practice
  • No strong opinion
  • Doesn't believe that feature work can be constant time
  • Would support it if we did it
• Wiki articles
  • management likes having this
  • Not sure how he would use them
  • Workflow is very Bugzilla-driven
  • Would start contributing to dialer docs, has wanted to for a while
• Sprint planning
  • Last one went pretty well
  • Not sure about sprints themselves, planned items are not the majority of his work
  • Likes treating blockers differently, likes the way contacts team is run
• Planning
  • Anthony and Etienne talk about the CSS and how to organize it
  • Not much planning on other things
  • The last year, biggest change was DSDS, rushed last minute
  • No strong opinion on this stuff yet (such as anticipating changes)
  • Now is first time we got the opportunity to fix stuff properly
• Long term project ideas
  • Integration testing
    • If we get better integration testing, refactors will be easier
      • ex: if we had tools, we could cover all of CDMA fairly quickly
    • Mulet (b2g desktop on firefox) inject chrome scripts to mock the telephony api
      • Implement RIL daemon in JS
      • Been discouraged on doing this because emulator coming (but waiting a while)
      • Compromise: stub the ril.js
• People
  • No opinion
  • The way the contacts team is working sounds good
• UX relations
  • Getting better
  • Doesn't need to contact UX a lot for his work
  • Progress-based meetings would be good instead of scheduled
    • In system, they have a meeting with UX designer rob where they go through everything they need to talk about
      • Once every 3 weeks during feature dev, once every week during bug fixing
• Comms meeting
  • Getting worse
  • Wasting time
  • Wants to kill it

Anthony

todo

Tamara

• Is a scrum master!
• It would be helpful to know what other people are doing.
• Being mentored by Gabriele to get started.

Gabriele (part-time)

• Daily meetings
  • Too much to have daily meetings, would get distracted from work
  • Talks directly with people when needed
  • Not a lot of overlap with other people's work
  • Works on specific components of dialer that are very self-contained
• Estimations
  • His bug take a long time to investigate, hard to estimate because of that
• Wiki articles
  • Would like to know more about what others are doing
  • Has specific components within the dialer and doesn't really see how they fit into the greater picture
  • Would like to have wiki articles, but raised that they need to be maintained
• Sprint planning
  • Last sprint planning session was his first
  • Thinks it worked ok, good for finding new bugs to work on
  • Hard to find urgent bugs to work on without this
• Planning
  • Doesn't know where the dialer is going
  • The callscreen took him by surprise, bitrotted some stuff he was working on
• Awareness of big problems
  • Would love to participate in fixing big arch problems, long-term projects
  • Sometimes has time for large refactors, but can't land something or uplift, hard to justify risk
• Long-term projects and problems
  • CDMA
    • Unit tests based on feedback from Taiwan
    • Write a patch and have someone in Taiwan test it
    • It worked fairly well but is a bad way to do development
    • It's well documented now in the Telephony WebIDL file
    • The emulator has extensive support for CDMA
    • Also possilble to do development in the emulator
    • No clue how to run emulator in this way, or with 2 SIMs, or anything like that
      • Vicamo Yang, Edgar Chen, Yoshi Huang can help here
  • WAP Push (unrelated to dialer but still nice to know)
    • Delivers special messages over SMS
    • Normally from carrier
    • Can contain links, configuration messages, full text documents with APN, configuration for data connectivity, etc.
    • Handled by Gecko as system messages
    • Originally were going to go into Messages app
    • Now a separate app, closes itself when messages are processed
    • Apps can't close themselves, so hacks needed to work around this
    • Lots of vendor-specific stuff
    • Sent using special software from vendors called NowSMS, we don't have access to this
    • Race: receive and process a message, then signal to close the app, then receive a message before app closed gets into a weird state
  • USSD/MMI
    • Numbers that start with * or #
    • Network replies with some carrier-specific information
      • ex: how much credit left, or data traffic left, enable/disable voicemail
    • Can be transactions
      • Can get a reply, interact with the reply, etc
      • Very hacky
      • Designed for single-SIM
      • UI uses window.postMessage, makes testing difficult, uses setTimeouts
    • Biggest issues: needs multi-SIM support, needs better testing
    • Special function for sending telephony.sendMMI function
      • Should use normal telephony.dial function
    • Hacks depending on the network
    • Whitelist of codes reimplemented on CDMA (normally for GSM) even though it doesn't really have it (we simulate them)
      • Covered well by unit testing
    • Biggest issues:
      • Needs multi-SIM support
      • Needs better testing
      • Replies can be mixed up
        • 1. You send a message
        • 2. Get an event reply on that connection
        • 3. System message (unrelated) triggered when you get a response
          • Juggling both is not easy
          • What we do: ignore the connection events
          • Only set an event handler for system events
          • In there we try to figure out if it was solicited or not
  • DTMF tones
    • Used by answering machines, for example, to see what number was pressed
    • The keypad code is not very nice
      • More than 50 numbers breaks down our logic for example
      • Swiping fingers over the keypad doesn't work very well
    • When user hits a button, we play the sound for that number and send over network at the same time
      • Sound is very glitchy on first play due to WebAudio blugs
      • Was a certification blocker
      • Plastered with workarounds, 2 separate hacks in keypad, should be as simple as playing a sound

German

todo

Analysis

Differences Between Teams

Category	Dialer	Contacts	Messages
Tactical Planning	None. No daily meetings.	Lots. Daily meetings, own IRC channel, lots of back-and-forth.	Some. Daily meetings done async.
Operational Planning	Very little. Mostly during sprint planning and ad-hoc.	Some. Notes taken, wiki articles, light estimation.	Lots. Burndown charts, wiki articles, heavy estimation, full scrum.
Strategic Planning	Little/some. Most ideas are discussed between Etienne and Anthony and are rarely shared.	Lots. Discussion with every team member about designs, architecture, and lots of prototypes. There are always side projects going on meant for the long-term.	Some. There are long-term pushes but they are mostly broken down into smaller chunks. *Note: This is tainted by not having talked with Julien yet.
People	Ad-hoc. People work on whatever they are generally best at, when they can. Most of the team was part-time until recently.	Rotating pushes. One person may work on a long-term push like Haidification for a week, then go to blockers. Another person may be working entirely on blockers during that time.	Ad-hoc. People work on whatever they are generally best at.

Similarities

• People don't find the comms meeting useful and want it to be killed.
• Estimations are generally working well, but are experimental on both other teams.
• Every team wants to know what's working well and what isn't for the other teams (people on both teams asked me).
• People like to know what others are working on.
• A short, daily standup has gotten very good feedback for usefulness.
• Wiki articles helpful for watching progress and retrospectives.
• Nobody is happy with the process of working with UX right now. It's not the UX people, it's just the timezone differences and lack of availability on IRC.
• Both other teams are happy to experiment with new techniques to organize themselves and do so regularly.

Moving Forward

Long Term Projects

• Carrie's redesign for sheet navigation.
• General redesign and refactors (a la Haidification).
• Testing CDMA in regions that don't use it, perhaps using the emulator.
• 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.
• Improve emulator use and documentation.

Potential Action Items

• Make a new #fxos-dialer channel on IRC (done! please join).
• Start having daily meetings. I think we can do this over IRC for a start, but be flexible with it.
• Track planning, progress, and discussions on wiki articles. Clean up general docs on dialer.
• Start estimating during sprint planning.
• Kill the comms meeting (not really in our scope but it's partly our fault that it still happens).
• Begin setting aside time for long-term projects.

Ideas

• Do video demos of important new features.
• Be more willing to experiment with things that seem like they create overhead. Be willing to kill them if they're not working.
• Discuss vision for the future of the dialer, including the app itself, the team organization, and how we work.
• Do burndown charts and scrum.