Firefox/Iterative Hello Development

From MozillaWiki
Jump to navigation Jump to search

Cross-Team Project Calendar

Error in widget Widget:Google Calendar: Unable to load template 'wiki:Widget:Google Calendar'

Project Introduction

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 has the release timing the 2 week iterations are based off. This is the master location for dates for when each Firefox version goes to Aurora, Beta, and Release.

Firefox 40 Sprints

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

Firefox 39 Sprints

  • Iteration 39.1: Tuesday Feb 11 - Monday March 9
  • Iteration 39.2: Tuesday March 10 - Monday March 23
  • Iteration 39.3: Tuesday March 24 - Monday March 30 (moved up 1 week to avoid holidays)

Firefox 38 Sprints

  • Iteration 38.1: Tuesday January 13 - Monday January 26
  • Iteration 38.2: Tuesday January 27 - Monday February 9
  • Iteration 38.3: Tuesday February 10 - Monday February 23

Upcoming Priorities

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.

  • market work
  • in-conversation chat

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

  • Moving Faster: add-on investigation
  • Android experience improvements
  • e10s readiness for e10s patches (e10s in Beta in 40, releases in 41 - so MUST be in for 41)
  • Link-Clicker Parity break-down based on the User Story. That already limits the scope to not include sharing from the link clicker in the first go (eventual goal - but needed to break up work).
  • Continue quality focus

Current

Iteration 39.2 (through March 23)

  • The Fx39 Release is only in Nightly for 5 weeks (normally 6) - ending on March 30th.
    • Context work broken down and starting work that can be done independently on client end this iteration.
    • Tab sharing work is wrapping up during this sprint, uplifting to Fx38. Replace track fix coming early in iteration from webRTC team.
    • Continuing CSS clean-up in SDK and how that impacts Hello code today - though may run into next iteration based on priorities
    • Functional Testing: Determine how to break up work to prioritize next focus areas. Functional tests to make sure telemetry is gathering good data is a priority.
    • Quality
      • Adam & Melih investigating session telemetry data on failures. Expect high priority work still coming for this iteration to determine or fix the issue.
      • Fx36 released with marketing - we expect bugs from that higher input.
      • Mark landed "no camera" issue fix.
    • Social Sharing: working on a reduced scope version for Fx39 (as Social Sharing is going to implement some changes over next several releases)

No results.

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


Past

Iteration 39.1 (through March 9)

  • Tab Sharing work & collaboration with TB wrapped up. SDK updates released and updated in Firefox. Determined and started additional work needed on Replace Track.
  • Break down Context work - work with FxA on timing for their portions of changes (underway)

No results.

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


Iteration 38.3 (through Feb 23rd)

  • Firefox Release 38 Goal:
    • Fx38 goal is to break down Screen Sharing and look at what can be implemented this release. Pref-off version of screen sharing (loop.screenshare.enabled), with the Windows only sharing expected early Feb. Tab sharing and Active Tab changing preparation work continues into Fx39 for uplift into Fx38 if possible. Work on potential demos for MWC will take 25%+ of development resources. 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.
    • US Holiday will take 2 days for US developers and some UI Tour uplift still occuring

No results.

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


Iteration 38.2 (through February 9)

  • Firefox Release 38 Goal:
    • Sharing prototyped, Sharing issues identified / bugs broken down, Mobile Android demo evaluation, Include new TokBox SDK (included patches for Constraint impacts), progress made on CSS improvements.

No results.

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

Iteration 38.1 (through Jan 29th)

  • Firefox Release 38 Goal:
    • Sharing prototyped, Sharing issues identified / bugs broken down, Mobile Android demo evaluation, Include new TokBox SDK (included patches for Constraint impacts), progress made on CSS improvements.

No results.

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

Iteration 37.3 (through Jan 13th)

Note: Next update on Tuesday January 13 following the conclusion of Iteration 37.3 (iteration included New Years). At the conclusion of Iteration 37.3:

  • Firefox Release 37 Goal:
    • Fx37 goal is to reduce tech-debt that has been accumulating over several iterations of quick feature additions. However, focus in 37.3 should focus on the highest impact tech-debt bugs.

  • Iteration 37.3 - Completed Work:

No results.

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

Iteration 37.2

Iteration 37.2 included Christmas - with 2 days of company holiday and many full week vacations. At the conclusion of Iteration 37.2:

  • Velocity Range:
    • 22 bugs closed, 48 points.

  • Firefox Release 37 Goal:
    • Fx37 goal is to reduce tech-debt that has been accumulating over several iterations of quick feature additions. However, focus in 37.3 should focus on the highest impact tech-debt bugs.

  • Iteration 37.2 - Completed Work:

No results.

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

Product Backlog

All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:

  • Enable work to be prioritized so that the team is always working on the most important features.
  • Support continual planning as the product emerges so the plan matches reality.
  • Improve forecasts so that the stakeholders make the best decisions about the direction of the product.

Product Backlog


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.

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.

Retrieved from "https://wiki.allizom.org/index.php?title=Firefox/Iterative_Hello_Development&oldid=1063166"