Firefox/Windows10: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 38: Line 38:
==Meetings & Communications==
==Meetings & Communications==
* Adhoc meetings for now
* Adhoc meetings for now
* Notes
* Notes - https://docs.google.com/a/mozilla.com/document/d/1VVtJeqfxpmfag_yoSjoznq-U_oMdd4GIFW7ETP58yuM/edit?usp=sharing
**
**


=Development=
=Development=

Revision as of 04:53, 20 May 2015

Project Name

During the last week of July or in early August, Microsoft will start pushing out updates to Windows 10. We don't know exactly what the update trajectory will look like. The date is important because when Firefox users get upgraded to Windows 10, they will be sold on upgrading to Edge, Microsoft's new browser. Our goal is that when Windows 10 releases start to go out, Firefox will work well enough on Windows 10 to be considered a viable choice for users not wanting to move from IE to Edge.

Links to Current info

Roles and Responsibilities

Role Contact
Product Management Bryan Clark
Project Management Sheila Mooney
UX/Design Philipp Sackl
Firefox Engineering Justin Dolske
Platform Engineering Johnny Stenback
Marketing Fabio Rios, Winston Bowden
PR Alex Shapiro
Release Management Sylvestre Ledru
BD/Partners Chris Arnold
l10n ?

Meetings & Communications

Development

Schedule

Release timing

  • First set of fixes to line up with Windows 10 release date is Firefox 40 (Aurora) - GA on Aug 11th, 2015.
  • Firefox 40 goes to Beta on June 29th, 2015
  • Firefox main release schedule is the master location for the dates when each Firefox version goes to Aurora, Beta, & Release.

Priorities

  • P1 bug list (target=40)
  • P2 bug list (target=41)
  • P3 bug list (target=42)

Current

Iteration Release#.Iteration - Uplift Date

  • Friendly summary of goals of iteration
  • Pipeline of work that has been pulled for this iteration and closed work - EXAMPLE

Past

Iteration Release#.Iteration - Uplift Date

  • Ideally these aren't just queries, but human readable so folks know what is coming in x release
  • Pipeline of work that has been completed and moving through Aurora and Beta to release - EXAMPLE

Product Backlog

Key Bugzilla Queries

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 Team to ensure new priorities are available for each Sprint

  • provides the Team: dev, UX, PM, EPM, and also Product Line owners visibility into the work and enables good conversations around trade-offs, feature priority, and rough timing.
  • helps align expectations
  • Priority works with Rank by gathering bugs into groupings that can then be ordered against similar "Priority" work. The creator of a bug or a triager may quickly set Priority and leave it for later to fit the bug above or below existing bugs in that Priority bucket using RANK.
    • RANK is discussed and re-adjusted at Planning meetings. This makes for quickly maintaining a clear bugzilla sort view of the work.
    • Priorities follow the Firefox Standard bucket guidelines:
      • 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 is used by the dev team to quickly see relative work priority and select "next bugs" (often at Planning Meetings or on-demand when needing next work.
    • Primarily set and maintained by the EPM or Eng Mgr during Triage
      • Reviewing 'THEME focuses in the sorted backlog for coming work with PM and UX before Planning meetings helps ensure alignment and that pre-work for coming bugs is ready.
    • It is not a blocker from taking new work that comes up. Dev simply marks that they've taken a bug and gives a priority and EPM will pull it into the Ranked backlog. This gives visibility to account for the full workload when Planning new focus work.
      • To keep rhyme/reason to the buzilla query sorting - Rank should relate to Priority. The "RANK" 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
  • Themes is a free form entry into the Whiteboard field, usually between brackets[].
    • Themes are not random and should reflect major work areas from PM or team focuses.
    • Setting Themes enables dev to quickly see what the focus of the work backlog is, making Planning meetings much more productive (for both choosing work and having discussion if it seems like the ordering isn't aligned with something).
    • On ordered Theme list should be reflected at a high level so the team can see and discuss and as new ideas come in - they can be added above or below existing Themes.
    • Themes will align with PM expectations, who are main contributors to setting the Theme order. As new work interjects above existing Themes in the list - PM can adjust external roadmap expectations (new work comes in - trades off moving other work out).
    • Themes give a quick way to have dialog across the area Teams and the Product Line owners to make sure we are aligned.
    • Themes allow summaries of Iteration and Release focused for anyone to see. Here is an working example of using Themes on a Team sprint management wiki
  • Iteration should be updated when a bug is being worked on during a particular Sprint. This is set at the planning meeting, updated for bugs that were not completed, and if new bugs as taken during the Sprint the dev should set this flag.
    • Caveat: not all teams are using Iteration

Visuals for Triage

  • Firefox-backlog flag is used to track bugs that are approved for the Backlog "+". This gives a simple way to separate triaged bugs from untriaged bugs. Triaged means either it has been intentionally triaged from a list of bugs or someone (dev, UX) with domain knowledge that had to create the bug filled out the fields to get it quickly into the Ranked 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.

Quickly marking a bug that is taken

  • If a bug is taken out of the normal submit, triage, assign process - it should have the "Iteration" and "Priority" set" - in addition to "Firefox-backlog".
  • "Rank" can then be easily added and the work included in the backlog, as the bug will show up visibilty with no Rank at the top of the query.
  • Also set the Firefox-backlog flag and QE-Verify
  • "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.

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 Start & Done

Start

  • It's possible not all these items need to be defined or agreed on by all members of the team, but the lack of these items should indicate red flags)
    • PRD's have been created
    • User stories created
    • UX created / reviewed
    • Above requirements are understood (including dependencies such as: access to staging, new hardware, skill set development etc)
    • Dev, QE and PM resources are mapped to intended goals
    • schedules create and agreed on
      • Shell put link to "Critical Path" excel google doc showing timing/work impact across releases.

Done

  • The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.
    • may differ by team - this is just an example

  • A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.

Project Health

IOS,Desktop Yellow Risk.png

  • (get central location for graphics from Erin)

Include clear, executive level summary that will be included at the [mana page overall view level:

  • for company goal x, we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
  • for release goal for ______ , we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).

Status Reports

example from Jenn's

  • This is an area we want to dig into further - if each team could summarize what they know in a consumable format - then one person could give an up to date overview of the larger project as needed.

Templates

Go to Templates page for sample etherpads, invite details, etc. for the following types of meetings.

  • stand-ups (daily, weekly, or other)
  • retrospective invites with questions/structure of the meeting in etherpad
  • cross-team/company meeting invites/etherpads to keep efficient and only when needed
  • postmortems

Archive

as iteration information or links get old or if this is replacing an older page and we don't want to lose path to the information...link to an archive page from here.

Reference materials

Sample bugzilla Queries

Please add your queries and descriptions of what they are doing here to help other create without having to learn bugzilla!

  • Queries to pull info for an iteration

Tools

  • area that needs more info
  • Aha - would love to get Romain's fantastic starter deck here and possibly time for him to go through with other team PM's.
  • Trello
  • https://waffle.io/mozilla/payments

Reading

Bugzilla Agile fields

Several Fields have been added this year into bugzilla for Agile tracking that you may want to leverage:

  • Iteration: right now this has the 3 previous and future 2 week sprints for Firefox release schedule - shows iteration (40.1) and uplift date.
  • Points: Fibonacci series 1,2,3,5,8,13]
  • Rank: see Rank use description under Triage Guidelines
    • Rank will not show under your Product::Component unless you request it by filing a bug with "bugzilla.mozilla.org :: Administration". You need to give a list of acceptable editors (usually the folks that can triage).

Product Backlog

  • There needs to be a way to mark the bugs you have triaged versus not. Firefox uses the flag for "firefox-backlog".
  • If you are not strictly desktop, there's also an option to add you team to the blocking-flag "backlog".
    • ex: the webRTC team uses webRTC+ for bugs they are accepting and "parking lot" for ones they are not. The queries are based on product/component - so multiple teams can use "parkinglot" and just request a new tag <team name>+ tag by filing a bug under "bugzilla.mozilla.org :: Administration"
  • ex: Bugzilla Ranked "Firefox-backlog+" list
    • Add the "Rank" Column to your results and sort on Rank to view order of work.
      • The option to "Change columns" is at bottom of search results
    • Search is based on "Flags" - "contains the string" - firefox-backlog+
  • Un-triaged bugs
    • Search is based on not having the Firefox-backlog+ or Firefox-backlog-

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Windows10&oldid=1075418"