Support/RapidRelease/DRAFT Sumo Release Planning

From MozillaWiki
Jump to: navigation, search

The content of this page is a work in progress intended for review.

Please help improve the draft!

Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.

This is a list of tasks that will need to be done for every Firefox release. I'm basing it off of what we did for Firefox 4. It's a good number of tasks for very little time and this checklist will need to be in a little bit of flux as we figure out exactly how to do it. Remember releases stack, so you're basically doing everything all the time and I think we'll need to keep checklists for each release so that we don't miss something.

Roughly in order:

Nightly stage

  • Track features that are making it into the release and make special note of any user facing/user affecting changes.
  • Try to anticipate early problems to be on the lookout for in later stages.
  • UX team check in. (mverdi)

Aurora stage

  • 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.
  • Devise a documentation strategy. Make a list of articles to change for each feature.
  • 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.
  • 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