Difference between revisions of "Loop"

From MozillaWiki
Jump to: navigation, search
(→‎Documentation: Add new loop client release process page)
m (Fix the template!)
 
(31 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 +
{{blackboxwarning|
 +
Firefox Hello (aka Loop) is being [https://support.mozilla.org/kb/hello-status shutdown from Firefox 49].<br />These pages serve as an archive and reference.
 +
}}
 +
 
__TOC__
 
__TOC__
  
Line 5: Line 9:
 
= Overview =
 
= 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.
+
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.
  
−
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."
+
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:<br />
 +
- Asynchronous interactions<br />
 +
- Real-time collaboration<br />
 +
- Mobile support<br />
  
−
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.  
+
Hello is delivered as a Go Faster system add-on since Firefox 45, Hello releases therefore don't follow the train model.
  
−
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.
+
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.
−
 
 
−
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 [https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AlJmiyFngeSwdGJEVnItQ2NVbGx6NXdjbVBUYmIxSGc#gid=0 MVP feature list / User Stories] document.
 
  
 
== Bug List ==
 
== Bug List ==
  
−
* Bugs are filed in the "Loop" product in Bugzilla.
+
* Bugs are filed in the "Hello (Loop)" product in Bugzilla.
−
* Bugs for each iteration are [https://trello.com/b/weRHRo0X/loop-sprints tracked in trello]
+
* Queries to bugs in our [https://wiki.mozilla.org/Firefox/Iterative_Hello_Development#Product_Backlog Backlog]
  
 
= Core Team =
 
= Core Team =
  
−
* Maire Reavy - Engineering Manager
+
* Romain Testard - Product Manager IRC: RT
−
* Romain Testard - Product Manager
+
* Adam Roach - Technical Architecture Lead IRC: abr
−
* Jorge Munuera - FxOS Product Manager
+
* Ian Bicking - Engineering Manager IRC: ianbicking
−
* Rafael Rebolleda - FxOS UX Lead
+
* Shell Escalante - Engineering Program Manager IRC: shell
−
* Adam Roach - Technical Architecture Lead
+
* Mark Banner - Engineering / Technical Lead  IRC: standard8
−
* Shell Escalante - Engineering Program Manager
+
* Dan Mosedale - Engineering / Front-end IRC: dmose
−
* Mark Banner - Engineering / Implementation
+
* Mike deBoer - Engineering / Front-end IRC: mikedeboer
−
* Dan Mosedale - Engineering / Implementation
+
* Sevaan Franks - UX Lead Mozilla IRC: sevaan
−
* Nicolas Perriault - Engineering / Implementation
+
* Pau Masia Martinez - UX Tef IRC: pau
−
* Alexis Metaireau - Engineering / Implementation
+
* Michael Sanders - TokBox EPM, PM
−
* Romain Gauthier - Engineering / Implementation
+
* Alexis Metaireau - Engineering / Server
−
* Remy Hubscher - Engineering / Implementation
+
* Remy Hubscher - Engineering / Server
−
* Jared Wein - Engineering / Implementation
+
* Jose A. Olivera - Tef Engineering PM
−
* Mike deBoer - Engineering / Implementation
+
* Bob Micheletto - Engineering / Operations
−
* Darrin Henein - UX Lead
+
* Richard Pappalardo - Engineering / Test
−
* María Ángeles Oteo - FxOS Engineering Manager
+
* Fabio Rios - Marketing
−
* Fernando Jiménez - FxOS Engineering
 
−
* Borja Salguero - FxOS Engineering
 
−
* Jose A. Olivera - FxOS Engineering
 
−
* Anthony Hughes - QA Lead
 
  
 
= Documentation =
 
= Documentation =
  
 +
* [[Loop/Development]] - Get started with Loop development
 
* [[Loop/Architecture]] - Technical documentation of overall system
 
* [[Loop/Architecture]] - Technical documentation of overall system
 
* [[Loop/Architecture/MVP]] - Initial design for MVP-level product
 
* [[Loop/Architecture/MVP]] - Initial design for MVP-level product
Line 55: Line 56:
 
* [[Loop/Loop-client_Release_Process]] - Information on the loop-client release cycle and release process
 
* [[Loop/Loop-client_Release_Process]] - Information on the loop-client release cycle and release process
 
* [[Loop/UX]] - Documentation of targeted User Experience
 
* [[Loop/UX]] - Documentation of targeted User Experience
−
* [[Loop/QA]] - Documentation of the testing strategy
+
* [[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/Logging]] - What we need to know in case of failure to make calls.  
 
* [[Loop/Load Handling]] - Our plan for managing initial server load
 
* [[Loop/Load Handling]] - Our plan for managing initial server load
Line 62: Line 64:
 
* [[Loop/Reporting]] - Dashboards and Reporting
 
* [[Loop/Reporting]] - Dashboards and Reporting
 
* [[Loop/Try_Loop]] Older page on getting started with loop
 
* [[Loop/Try_Loop]] Older page on getting started with loop
 +
* [[Loop/Library Upgrades]]
  
  
 
[tbd -- other artifacts as they become available]
 
[tbd -- other artifacts as they become available]
−
 
−
= Standing Meetings =
 
−
* Watch [https://lists.mozilla.org/listinfo/dev-media dev-media] for information.
 
−
 
−
= Project Checklist =
 
−
[[Services/Loop|Loop Project Checklist]]
 
  
 
= Cross-Team Project Calendar =
 
= Cross-Team Project Calendar =
Line 79: Line 76:
 
= Communication Channels =
 
= Communication Channels =
  
−
* [https://wiki.mozilla.org/IRC IRC]: [irc://irc.mozilla.org/loop #loop on irc.mozilla.org] (Use [irc://irc.mozilla.org/media #media on irc.mozilla.org] for WebRTC discussion)
+
* [[IRC]]: [irc://irc.mozilla.org/loop #loop on irc.mozilla.org] (Use [irc://irc.mozilla.org/media #media on irc.mozilla.org] for WebRTC discussion)
 +
* [[IRC]]: [irc://irc.mozilla.org/loop-server #loop-server on irc.mozilla.org]
 
* [https://lists.mozilla.org/listinfo/dev-media dev-media Discussion List]
 
* [https://lists.mozilla.org/listinfo/dev-media dev-media Discussion List]
 +
 +
[[Category:Firefox Hello]]
 +
[[Category:Loop]]
 +
 +
== Standing Meetings ==
 +
* Watch [https://lists.mozilla.org/listinfo/dev-media dev-media] for new information.
 +
<p> </p>
 +
{| class="wikitable"
 +
|-
 +
! 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 || [https://etherpad.mozilla.org/loop-retrospectives etherpad]
 +
|-
 +
| "Cross team alignment" || Tuesday || 11:30AM - 12:00PM || 2:30AM - 3:00PM ||  ||  ||
 +
|}
 +
 +
<p> </p>
 +
==[https://wiki.mozilla.org/Loop/wiki Links to current info]==
 +
[https://wiki.mozilla.org/Loop/wiki Loop/wiki] page is the central location for current focus, Roadmap, Metrics, UX, Marketing, and more.
 +
=Triage=
 +
<p> </p>
 +
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).<p> </p>
 +
 +
==Key Bugzilla Queries==
 +
* [http://mzl.la/1KZGqPm Bugzilla Ranked list]
 +
**Searches all Hello bugs with Ranks Assigned
 +
*[http://mzl.la/1PEmKj8 Triage: Prioritized Bugs without Rank set]
 +
* [http://mzl.la/1JBkwev Triage: Bugs without Rank or Priority]
 +
* [https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboard&list_id=12373638&columnlist=cf_fx_iteration%2Ccf_fx_points%2Cassigned_to%2Cbug_status%2Cstatus_whiteboard%2Cshort_desc%2Cchangeddate%2Cpriority%2Cbug_severity%2Cresolution%2Ccomponent%2Creporter&o1=anywordssubstr&resolution=---&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&v1=tech-debt&component=Client&component=General&product=Hello%20%28Loop%29 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
 +
 +
<p> </p>
 +
*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
 +
<p> </p>
 +
 +
===Definition of Done===
 +
<p> </p>
 +
* The [https://etherpad.mozilla.org/HsVyzOogAr Definition of Done] ensures a potentially shippable product increment is released at the conclusion of a release cycle.
 +
<p> </p>
 +
* A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.
 +
<p> </p>
 +
 +
===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 '''[https://bugzilla.mozilla.org/show_bug.cgi?id=1209713 web sharing]'''
 +
* [https://bugzilla.mozilla.org/show_bug.cgi?id=1223573 '''add-ons''']: moving Hello from browser integrated to an add-on in order to reduce delay between development and release and testing flexibility
 +
*[https://bugzilla.mozilla.org/show_bug.cgi?id=1048850 '''e10s''']: not sure if this is coming in 45 or 46 - but trying to get this resolved as its in Beta in 44
 +
*[https://bugzilla.mozilla.org/show_bug.cgi?id=1178304 '''Facebook'''] improvement
 +
*Quality
 +
*[https://bugzilla.mozilla.org/show_bug.cgi?id=1187857  Shared '''Pointers''']
 +
*[https://bugzilla.mozilla.org/show_bug.cgi?id=1186905  Independent '''scrolling''']
 +
*Metrics [https://bugzilla.mozilla.org/show_bug.cgi?id=1148381 bug 1148381]
 +
*Android experience improvements
 +
*WebRTC permission prompt optimization

Latest revision as of 12:42, 19 September 2016

Warning

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

Warning

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

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

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
Retrieved from "https://wiki.mozilla.org/index.php?title=Loop&oldid=1148175"