Firefox/Iterative Hello Development

Project Introduction

• Team Mailing list: Firefox/dev-media
• Team IRC Channel: #loop

Links to Current info

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

Roles and Responsibilities

The cross-team Loop/Contacts Page has the Roles and Responsibilities for Hello, webRTC, partner teams, and external partners involved in this project.

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	etherpad
"Retrospective"	Friday	8:00AM - 9:00AM	11:00AM - 12:00PM	5:00PM - 6:00PM	webRTC-Apps	etherpad

Development Iterations (Sprints)

• Firefox main release schedule is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.

Firefox 40 Release

• Iteration 40.1: Tuesday March 31 - Monday April 13
• Iteration 40.2: Tuesday April 14 - Monday April 27
• Iteration 40.3: Tuesday April 28 - Monday May 11

Firefox 41 Release

• Iteration 41.1: Tuesday May 12 - Monday May 25
• Iteration 41.2: Tuesday May 26 - Monday June 8
• Iteration 41.3: Tuesday June 9 - Monday June 29
  • Note: IT 41.3 is a 3-week iteration.

Firefox 42 Release

• Iteration 42.1: Tuesday June 30 - Monday July 13
• Iteration 42.2: Tuesday July 14 - Monday July 27
• Iteration 42.3: Tuesday July 28 - Monday August 10

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.

• finishing Context work (large change: server API changes, FxA and encryption design, client end UX and storage components, server storage/retrieval components, UX change across areas)
• market work

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

• in-conversation chat bug 1108893
• Prevent Link-clickers from clicking on themselves bug 1154251
• Friendlier more inviting Shareplane bug 1155603
• Metrics bug 1148381
• Starting Visual Refresh bug 8587058
• e10s readiness for e10s patches (e10s in Beta in 41, releases in 42 - so MUST be in for 42)
• Moving Faster: add-on investigation
• Android experience improvements
• Link-Clicker gets desktop UI bug 1066019
• Continue quality focus
• WebRTC permission prompt optimization

Risks

• List out risks that we are working on or on our radar

Current

Iteration 41.1 (through May 25)

• Context work: should move to testing with this iteration and uplift. All strings needed were uplifted.
• Affiliate work: working on and ideally landing this iteration - barring unforseen surprises
• Chat: test of the SDK functionality was successful - UX not implemented to design.
• Functional test work broken down - and only top 2 items are 100% blockers to be addressed in 41.1
  • If time, telemetry patches (marked Metrics in Backlog). They are low risk/small changes and vital to making informed decisions, we will be requesting uplift to 39 for those landing in this iteration.
• Adam and Martin met for couple of days and did initial theory design for IM persistent storage [shell link to early architecture]. Still several months out from implementation - but moving ball forward.

All bugs marked with this iteration

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Past

Firefox Release 40 Dev stage (ended May 11)

• Context work:
  • Server end: 0.17.4 has hit bumps with updated module causing failure and is currently diagnosing 503 errors before deploying.
  • Client-end: Continues through at least this iteration. Discovered issue with encryption key generation that will require re-authentication after upgrade, working on UX change now.
• Quality focus this release on reviewing results of data gathered and identifying likely causes/implementing fixes.
• Shareplane landed and verified and uplifting to Fx39.
• Added more Google Analytic metrics for stand-alone client (link clicker)
• Continuing CSS clean-up in SDK and how that impacts Hello code. starting landing small pieces - as it's pretty tangled - and keep spinning off and landing more.
• Functional test work broken down - these are areas that help speed development and lower risk, making it simpler to catch errors and regressions sooner.

All bugs in this Release

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Firefox Release 39 (ended March 30)

The Fx39 Release is only in Nightly for 5 weeks (normally 6) - ending on March 30th.

• Context work started in this release. This work required implementing a changes across many systems: client front-end code, Link clicker, UX changes in both, FxA Server (Bug 1132293), and Server work (Bug 1141105). Changes that touch multiple systems add integration cost/risk and testing complexity.
  • Preliminary design for encrypted room context came with this bug. This encryption work will enable future features.
• Tokbox made some changes in the SDK that gave an option to not take the SDK CSS rules. Today the app uses CSS and then TB applies CSS rules as well - making for complex development, testing, and sometime unpredictable results. There was a cost with every SDK upgrade that often UX that was working, stopped and required debugging because of CSS conflicts. Starting work on impact/changes needed for reduced SDK CSS - with the primary goal of FASTER DEVELOPMENT by simplifying.
• Fx36 released with marketing - we are watching/working on the high occurrence bugs from that higher input.
• Social Sharing, AKA SharePlane landed and was backed out - working to re-land during Fx40
• Continue to land telemetry improvements
• Fixing and uplifting Screen Sharing bugs
  • Tab sharing work completed this sprint, uplifting to Fx38. Replace track fix coming early in iteration from webRTC team.
• Updated to new SDK with data channel support

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Firefox Release 38 (ended Feb 23rd)

• Firefox Release 38 Goal:
  • Fx38 goal is to break down Screen Sharing - and work to implement. Pref-off version of screen sharing (loop.screenshare.enabled), with the Windows only sharing available early Feb. Tab sharing and Active Tab changing preparation work continued into Fx39 and was uplifted back to Fx38. Tokbox delivered an SDK change needed to enable Tab Sharing.
  • Work on demos of Hello on Android for MWC took 25%+ of development resources.
  • Progress made on CSS improvements (organically growing code has gotten complex to develop and test). Discussion with TB on simplification options, patched client code to better respect constraints and aspect ratios.
  • Continuing to reduce tech-debt that has been accumulating over several iterations of quick feature additions is still a priority, especially to aid in QA coverage to avoid regressions as new features are added.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Release 37 (ended Jan 13th)

• Firefox Release 37 Goal:
  • Fx37 goal is to reduce tech-debt that has been accumulating over several iterations of quick feature additions. In Fx37 we ended up working on many uplifts to Fx35 Beta to complete the Room feature and the First Run Tours.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Product Backlog

Key Bugzilla Queries

• Bugzilla Ranked "Firefox-backlog+" 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 "Flags" - "contains the string" - firefox-backlog+
• Un-triaged bugs
• Tech-debt bugs priority based on etherpad discussion - though if you want one that's lower priority but impacting you - grab it

The goals of the 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).

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 follow the Firefox Desktop Standard:
  • Priority 1 - Blocker, must-fix before shipping.
  • 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: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way 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 - default to mid-range value.
  • P1 Rank options=1-19, default 15
  • P2 Rank options=20-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 go in "backlog-" area

• The Firefox-backlog flag is used to track bugs that are approved for the Backlog "+"
• 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:"Loop" || Component: "General" or "Client"
  • Hello team reviews for inclusion into a release backlog every 2 weeks, and will mark "firefox-blocking" accordingly
• If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
  • Before it can be given a Rank it should:
    • be in an actionable state
    • for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
    • for feature requests or enhancements, it means that there's a clear problem statement or suggestion
    • has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months

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.

Contribute to Hello Development

Good First Bugs

These are tagged as [good first bug] in a bug's Whiteboard field. The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. We are working on better documentation to help you get started with Hello (expect an update Q1 2015), and the #introduction IRC channel exists just to help people getting started as contributors.

• Hello Backlog Good First Bugs - View in Bugzilla

Objectives

The Iterative Development Model implemented for Firefox Desktop aims to accomplish six key objectives:

• Transparent - Who is working on what, when, and why.
• Predictable and Repeatable - Know what to expect from the process.
• Inclusive - Include all key participants (Eng, UX, QA, Security, Product) and stakeholders in the process.
• Clear Direction and Decision Making - Know what we should do and who makes the call.
• Clear and Stable Priorities - Be clear on what is most important for each iterative cycle.
• Innovative - Provide flexibility to engage in experimental and original projects.