Support/RapidRelease/DRAFT Sumo Release Planning

From MozillaWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

DRAFT
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
Retrieved from "https://wiki.mozilla.org/index.php?title=Support/RapidRelease/DRAFT_Sumo_Release_Planning&oldid=296411"