Firefox/Input/Feedback Strategy

From MozillaWiki
< Firefox‎ | Input
Revision as of 02:02, 4 April 2011 by Adesai (talk | contribs) (Created page with "== Background == * Firefox 4 success for user feedback with tens of thousands support threads and millions of pieces of feedback on Input. * Unfortunately, we didn't integrate ma...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Background

  • Firefox 4 success for user feedback with tens of thousands support threads and millions of pieces of feedback on Input.
  • Unfortunately, we didn't integrate many other feedback mediums that offer more information about key aspects of the browser (i.e. stability, features, responsiveness, usability and performance).
  • Mozilla encompasses many different mediums such as Socorro, Test Pilot, news sources, Bugs, Social Networks (i.e. facebook, twitter) and ADU's.
  • The new rapid release process will require new feedback strategies to quickly enlighten drivers on the status quo of the browser across multiple channels
  • We aim to formalize a group of feedback medium leads throughout the organization to support the release of our browser products through the new development process.

Needs per Channel

  • Central - The value of this channel is to shows bleeding edge features that may or may not end up in the release, but give a glimpse into Firefox's strategy/vision.
    • Bug Finding -
    • Stabiility -
  • Aurora -
    • Feature Quality Criteria
    • UX Feedback
    • Stability
  • Beta
    • Feature Quality Criteria
    • UX Feedback
    • Stability
    • Website/Plugin/Addon Compatibility
  • Release
    • Website Compatibility
    • Top Issues (website/addon/plugin/3rd-party application)
    • Chempsill Go/No-Go

Objectives

  • To form a group of feedback leads throughout the organization
  • Create a comprehensive picture of what users are saying on a regular basis

Plan

Initially, we want to meet once a week to coalesce our findings for the needs over each release channel. The final output of each meeting will be a comprehensive report of all the feedback summaries.

Responsibilities

As the new rapid release process introduces four channels to be active concurrently, we'll need additional people to read through these feedback mediums. The following responsibilities are identified due to their experience and capability to handle the triage of this information.

  • SUMO
    • Read through Beta threads on the forum
    • Read through top Release threads on the forum
    • Collecting SUMO metrics (how many people are coming to support and magnitude of volume)
  • QA
    • Read through Input Themes over past 7 days across each platform
    • Weekly triage of unconfirmed bugs merged with Input search
    • Read through Input Sites over past 7 days for Issues
  • Marketing
    • FILL THIS OUT
  • PR
    • FILL THIS OUT
  • Metrics
    • Report ADU changes on a weekly basis
    • Report number of users jumping between channels
    • Report clustered twitter themes
  • User Research
    • FILL THIS OUT
  • Project Management
    • Report major crash reports over the past 7 days
    • Report already filed blocker bugs and if feedback triage is necessary

Open Questions

  • Normalize counts across feedback channels?
  • Reporting rates across feedback channels?
  • How do we take TP data into account?
  • How does press coverage work into this reporting system?
  • What about bugs filed which are the most critical, but are not fixed?
  • What is being mentioned on Twitter per channel? Is it important enough to mention here?