From MozillaWiki

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



[tbd -- other artifacts as they become available]

Cross-Team Project Calendar

Communication Channels

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

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

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: