Firefox/searchandaddon

Search and Add-ons

problem statement or why we do this project for someone brand new.

• Kev and/or Dave for info.

Project Introduction

• Team Mailing list: if applicable
• Team IRC Channel: where does this team "hang-out"
• Summary of our plans for this year
  • links back to main Firefox page - Marco to create a section on main page for team summaries.
  • Quick high-level plans for the year for Desktop management and contributors. Likely completed by Kev/Dave with EPM help as needed.
    • Here's an example of the overview from Platform team for webRTC
• Dependencies: feature, partner, resource, etc. that impact this projects ability to succeed - put links to other project pages.

Links to Current info

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

Roles and Responsibilities

The Contacts Page has the Roles and Responsibilities for Firefox teams, partner teams, and external partners.

Meetings & Communications

Meeting	Day of week	Pacific Time	Eastern Time	Central European Time	Vidyo Room	Notes
Pull Meetings	bi-weekly at the start of the iteration on ___	0:00AM - 0:30AM	0:00AM - 0:30PM	0:00PM - 0:30PM	team vidyo room	etherpad
Stand-up	Team decides	0:00AM - 0:30AM	0:00AM - 0:30PM	0:00PM - 0:30PM	Team vidyo room	etherpad
Triage	Team decides	0:00AM - 0:30AM	0:00AM - 0:30PM	0:00PM - 0:30PM	Team vidyo room	Currently Assigned, Firefox-backlog+ in areas, adding [fxsearch] query
Retrospective	Team decides	0:00AM - 0:00AM	0:00AM - 0:00PM	0:00PM - 0:00PM	team vidyo room	etherpad

• Links to mailing list or all communication channels

Development

Iteration Schedule

Note: Next update on Tuesday May 12 following the conclusion of Iteration 40.3

The Iteration Backlog is a collection of priority work the team has selected to work on in a two-week iteration.

Current Iteration - 40.3

• Duration: Tuesday April 28 - Monday May 11
• Iteration Backlog: View In Bugzilla

Next Iteration - 41.1

• Duration: Tuesday May 12 - Monday May 25
• Iteration Backlog: To Be Published on Tuesday May 12

Upcoming Iterations

Release plan when each Firefox version goes to Central, Aurora, Beta, & Release: View Rapid Release Schedule

Firefox 41 Release

• 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

• Kev and/or Dave for info

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, but it is in order of relative priority - including the work we've pulled for the sprints.

• finishing Theme 1 (large change), bug number to user story or meta bug
• Theme 2: any time constraints/dependencies
• Theme 3: quick why if not self-evident, bug number to user story or meta bug

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

• Process Improvement: Theme
• Other platform Investigation
• Tech-debt: any time constraints/dependencies
• Theme 4
• Quality: description of areas
• Theme 5

Risks

• Risk 1 : ex: Roadmap goals for the release in November are too high for ____(dev, UX, PM?) resources by x amount (bugs? points? UX resources). likely will not make any features beyond x, y, z.
• Risk 2 : ex: Dependency on a service that is not established/planned for from another team. Need help prioritizing if we should delay the feature in this project or raise the priority in the other team based on their existing backlog

Current

• Iteration Example of Current Iteration query
  • Update after Monday meeting on bugs - Marco is best at making these queries.

Past

• Example of Past Iteration Query
• Pipeline of work that has been completed and moving through Aurora and Beta to release.
• Ideally these aren't just queries, but have human readable summary so folks know what is coming in x release.
  • Update after Monday meeting on bugs - Marco is best at making these queries.

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.

Key Bugzilla Queries

• Team Product Backlog: View Bugzilla
  • Search is based on "Flags" - "contains the string" - firefox-backlog+
• [marco fill in query - Untriaged Bugs]
  • Search is based on not having the Firefox-backlog+ or Firefox-backlog-

• • • To get these will need to tag bugs with [fxsearch] and Themes
    • Will need to prioritize Themes
    • Can take existing bugs folks are working on and put towards top as well, but will clarify where existing work and Themes for the team meet.

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 this 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 "+" (or Backlog - to not be looked at for a while)
• Add whiteboard tag to bugs [fxsearch] as bugs for this team may span Product:: Component areas.
• 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:"___" || Component: "___" or "_____"
  • Team reviews for inclusion in Backlog every 2 weeks
• If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+ and set a Priority with a reason. This makes it simplest to triage those bugs quickly.
  • Before it can be given a Rank it should:
    • be in an actionable state (for the team taking it)
    • 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

Project Health

• (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).