Firefox/Iterative Hello Development
Cross-Team Project Calendar
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 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
Firefox 37 Sprints
- Iteration 37.1: Tuesday Dec 2 - Monday Dec 15 (week added to 36.3)
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.
- FxA and Server work for Context should be done this iteration. Bug 1132293
- Tab sharing work is wrapping up during this sprint, uplifting to Fx38. Replace track fix coming early in iteration from webRTC team.
- Functional Testing
- Discussion this iteration on how to break up work to begin. Functional tests to make sure telemetry is gathering good data is a priority.
- Continuing CSS clean-up in SDK - though may run into next iteration based on priorities
- 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 - so we expect to handle bugs from that higher push.
- Mark working on camera issue fix.
- Context work broken down and starting work that can be done independently on client end this iteration.
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Past Iterations
Iteration - 39.1
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Iteration - 38.3 Performance
- Firefox Release 38 Goal:
- Fx39 goal is to break down Screen Sharing and look at what can be implemented in the near term. 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. 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 Performance
- 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 Performance
- 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 Performance
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 Performance
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.
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
Product Backlog
- 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+
- Add the "Rank" Column to your results and sort on Rank
- untriaged bugs
- Tech-debt bugs priority based on etherpad discussion - though if you want one that's lower priority but impacting you - grab it
Backlog Triage
Triage Guidelines
- 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.
- MUST set Firefox-backlog to "+" (Shell will set all P1 and P2, as QE filters on this)
- "Iteration" should be set if you are taking a bug during a specific iteration. EPM will clean up if bugs are closed before being taken into an iteration.
- "Points" should be set when known
Triage Backlog
- View Bugzilla for untriaged
- Adding Bugs to Triage
- Open a bug under Product:"Loop" || Component: "General" or "Client"
- The Blocking-Loop flag is defaulted to "---", which will go into our list of bugs to Triage next
- Hello team reviews for inclusion into a release backlog every 2 weeks
- If there is a bug that should be considered for taking ASAP - you can mark Blocking-Loop at "backlog ?"
- Before it can be "backlog ?" 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
- Before it can be "backlog ?" it should:
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.
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.
Links
The Loop/wiki page has updated links to project relevant information
Communication
General
- Team Mailing list: Firefox/dev-media
- Team IRC Channel: #loop
Meetings
| Meeting | Day of week | Pacific Time | Eastern Time | Central European Time | Time zone conversions |
|---|---|---|---|---|---|
| "Daily Stand-up" | Monday, Tuesday, Wednesday, Thursday | 8:00AM - 8:30AM | 11:00AM - 11:30PM | 5:00PM - 5:30PM | AWMY |
| "Retrospective" | Fridays | 8:00AM - 9:00AM | 11:00AM - 12:00PM | 5:00PM - 6:00PM | AWMY |
- Duration: 1 hour
- Vidyo Room: "webRTC-Apps"
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.