Support/RapidRelease/Firefox 5 tracking page

From MozillaWiki
Jump to: navigation, search

This is a page tracking support tasks for Firefox 5 shipping.

Roughly in order:

Nightly stage

  • [DONE] Track features that are making it into the release and make special note of any user facing/user affecting changes.
    • This was done by calling into product meetings but in the future should be done by tracking the Features/Release Tracking page.
      • Two user-facing features are on this train: Channel switching. Moved the DNT pref to the privacy pane.
  • [DONE] Try to anticipate early problems to be on the lookout for in later stages.
    • There was nothing of note here.
  • [DONE] UX team check in.
    • Michael is calling into weekly UX meetings.

Aurora stage

  • [ON TRACK] Gauge user's initial response to a feature when it's introduced (via feedback). Highlight any red flags. If there's any confusion points, take note of them for documentation focus.
    • Doing weekly aurora feedback triage with aakash and team. Currently there's not enough usage on aurora for much feedback. We need to reevaluate for Firefox 6.
  • Devise a documentation strategy. Make a list of articles to change for each feature.
  • [ON TRACK] Attend triage meetings to know if a feature is going forward to beta or is staying on experimental. Note any bugs found that may be "shippable". Give feedback on the expected support experience.
    • Ongoing, there are two two-hour triage meetings a week. This needs to be cut back.
  • Check in with QA to see if there are issues they've identified that we should keep an eye out for.
  • Right before ship: Brief community on potential beta issues.

Beta stage

  • Weekly feedback roundup (from input and support forums)
  • Summarize top SUMO and input issues for dev teams to help inform planning meetings
  • Write feature documentation (host KB sprint?)
  • Alert localizers (or do l10n on a schedule)
  • Localize feature documentation.
  • Update beta start page to highlight new features
  • Anticipate top issues that will likely crop up that we will ship with based on input and sumo
  • Track down owners of issues and get workarounds if possible. Or use SUMO threads to see what workarounds have been helping users.
  • Document top issues and link from front page

Right before release

  • Update start pages to reflect new docs written
  • Update AAQ flow to reflect new common issues
  • Report back on l10n status(es)
  • Update showfor to work with new versions
  • Get list of top incompatible add-ons
  • Get list of incompatible websites off of input/SUMO/QA
  • Brief community on top anticipated issues and workarounds

Day of release

  • Track support issues
  • Party along with everyone else
  • End of day: Email RRRT with any issues that are seen

Day of release + 2 days

  • Support report summary of top issues, counts, severity.
  • Work with release drivers on figuring out if we need to chemspill

Day of release + 1 week

  • Collect launch day/first week metrics
  • Thank community members

Post release, ongoing

  • Do support!
  • Regular support reports