Firefox Hello (aka Loop) is being shutdown from Firefox 49. These pages serve as an archive and reference.

Loop is the codename for the Firefox Hello project.

Overview

The Hello project (code name Loop) started as a video calling solution built into the browser (experience up until FF44) and has now pivoted to addressing Firefox user needs to share Web content. We’ll do so by providing a simple solution which blends web browsing, real-time communication, collaboration and content storage.

Hello uses an incremental delivery approach building on top of an initial basic implementation which will focus on real-time sharing. Moving forward we’ll extend this first implementation with the following capabilities:
- Asynchronous interactions
- Real-time collaboration
- Mobile support

Hello is delivered as a Go Faster system add-on since Firefox 45, Hello releases therefore don't follow the train model.

Additional features will be prioritized and implemented as we progress development and collect user feedback to help shape what will provide the greatest value to our users.

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 IRC: pau
• 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]

Cross-Team Project Calendar

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.

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
  • Searches all Hello bugs with Ranks Assigned
• Triage: Prioritized Bugs without Rank set
• Triage: Bugs without Rank or Priority
• 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.

Themes

As we plan what's coming next, these are areas being discussed. This is not a commitment to the next projects - just our scratch area.

Things we want to do - but parking lot until the highest priorities are done:

• New User Journey - which is moving to starting from web sharing
• add-ons: moving Hello from browser integrated to an add-on in order to reduce delay between development and release and testing flexibility
• e10s: not sure if this is coming in 45 or 46 - but trying to get this resolved as its in Beta in 44
• Facebook improvement
• Quality
• Shared Pointers
• Independent scrolling
• Metrics bug 1148381
• Android experience improvements
• WebRTC permission prompt optimization