Loop

Loop is the codename for the Firefox Hello project.

Overview

At a high-level, the Loop project aims to create a user-visible real-time communications service for existing Mozilla products. This initially includes two major user-facing components: a Desktop portion, integrated with Firefox Desktop; and a Firefox OS Application intended to be used with Firefox OS 2.0 and later.

A good starting point for roughly understanding the user-facing behavior of these components is that the Desktop behavior will be roughly like "Skype, but integrated into the browser;", while the Mobile behavior will be roughly like "Facetime for Firefox OS Devices."

On Desktop, users will have an address book that can be used to initiate calls to other Firefox users, as well as to receive calls based on email identifiers. Video windows can be docked in front of the current tab, or "popped out" into their own window. In both cases, the call can continue while users change tabs and navigate around the web.

On Firefox OS, the client will use the built-in address book for contact information, and will allow initiating calls to other users as well as to receive calls based on mobile phone numbers.

In terms of project deliveries, the Loop project is using an incremental approach of delivering a minimal initial product consisting of simple voice and video communications. Additional features will be prioritized and added after the initial version is headed towards release, and as we gain more experience with what is most likely to provide the greatest value to our users.

A more complete list of the features planned for the "Minimum Viable Product" (MVP) release can be found in the MVP feature list / User Stories document.

Bug List

• Bugs are filed in the "Hello (Loop)" product in Bugzilla.
• Queries to bugs in our Backlog

Core Team

• Romain Testard - Product Manager IRC: RT
• Adam Roach - Technical Architecture Lead IRC: abr
• Ian Bicking - Engineering Manager IRC: ianbicking
• Shell Escalante - Engineering Program Manager IRC: shell
• Mark Banner - Engineering / Technical Lead IRC: standard8
• Dan Mosedale - Engineering / Front-end IRC: dmose
• Mike deBoer - Engineering / Front-end IRC: mikedeboer
• Sevaan Franks - UX Lead Mozilla IRC: sevaan
• Pau Masia Martinez - UX Tef
• Michael Sanders - TokBox EPM, PM
• Alexis Metaireau - Engineering / Server
• Remy Hubscher - Engineering / Server
• Jose A. Olivera - Tef Engineering PM
• Bob Micheletto - Engineering / Operations
• Richard Pappalardo - Engineering / Test
• Fabio Rios - Marketing

Documentation

• Loop/Development - Get started with Loop development
• Loop/Architecture - Technical documentation of overall system
• Loop/Architecture/MVP - Initial design for MVP-level product
• Loop/Architecture/Rooms - Initial design for room ("conversation")-based user experience
• Loop/Architecture/Context - Preliminary design for encrypted room context (name, description, etc)
• Loop/Desktop & Standalon/Code Style & Structure
• Loop/Data Collection - Information to collect about the functioning of the system
• Loop/Loop-client_Release_Process - Information on the loop-client release cycle and release process
• Loop/UX - Documentation of targeted User Experience
• Loop/Test - Loop testing reference / QA
• Loop/Automated Testing - Loop automated testing reference
• Loop/Logging - What we need to know in case of failure to make calls.
• Loop/Load Handling - Our plan for managing initial server load
• Loop server API - Documentation of the REST API used by the Loop server
• Loop/OAuth Setup - Information about adding OAuth client credentials to Firefox
• Loop/Reporting - Dashboards and Reporting
• Loop/Try_Loop Older page on getting started with loop
• Loop/Library Upgrades

[tbd -- other artifacts as they become available]

Communication Channels

• IRC: #loop on irc.mozilla.org (Use #media on irc.mozilla.org for WebRTC discussion)
• IRC: #loop-server on irc.mozilla.org
• dev-media Discussion List

Standing Meetings

• Watch dev-media for new information.

Meeting	Day of week	Pacific Time	Eastern Time	Central European Time	Vidyo Room	Notes
"Daily Stand-up"	Monday, Tuesday, Wednesday, Thursday	8:00AM - 8:30AM	11:00AM - 11:30PM	5:00PM - 5:30PM	webRTC-Apps		]
"Retrospective"	Friday	8:00AM - 9:00AM	11:00AM - 12:00PM	5:00PM - 6:00PM	webRTC-Apps	etherpad
"Cross team alignment"	Tuesday	11:30AM - 12:00PM	2:30AM - 3:00PM

Links to current info

Loop/wiki page is the central location for current focus, Roadmap, Metrics, UX, Marketing, and more.

Triage

The goals of the Prioritized Product Backlog and dynamic Planning are to:

• Simplify prioritization & planning so the team is always working on the most important features.
• Improve visibility to everyone to clear priorities - so we make the best decisions about the direction of the product (call out risks early, relative priorities, trade-offs).

Key Bugzilla Queries

• Bugzilla Ranked list
  • Add the "Rank" Column to your results and sort on Rank
    • The option to "Change columns" is at bottom of search results
  • Search is based on bugs which have the Ranked field
• Un-triaged bugs
• Tech-debt bugs

Triage Guidelines

The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.

• Priorities: if you are filing a bug - based on your knowledge of the bug feel free to set a priority for consideration based on the following criteria:
  • Priority 1 - Blocker, must-fix before shipping in the next release.
  • Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping.
  • Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product.
  • Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
  • Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.

• RANK: Not needed when filing a bug, set during weekly Triage meetings. As priority buckets start to have a large amount of bugs in them, the Rank field can be used to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - use default
  • P1 Rank options=1-10, default 5
  • P2 Rank options=11-29, default 25
  • P3 Rank options=30-39, default 35
  • P4 Rank options=40-49, default 45
  • P5 Rank options=50-59, default 55
  • any that we don't think we can get to in the next 6 months should be set to 100

• QE-Verify is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
  • "+" means that QE should look at the bug and it can be verified with human eyes
  • "-" means QE should not look at
    • Typically goes with in-testsuite set to "+", to show testing via another method.
• "Points" should be set when known (if nothing set - assumed a "1" or very small). Most relevant if taking a bigger bug so we know when bugs are large bits of work.
• "Iteration" should be updated when a bug is being worked on during a particular Sprint.

Filing a bug

• Open a bug under Product:"(Hello)Loop" || Component: "General" or "Client"
  • We triage weekly - it helps if there is a priority as a starting point and a reason

Definition of Done

• The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.

• A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.