Support/RapidRelease/Firefox 5 post mortem

From MozillaWiki
Jump to: navigation, search

Now that Firefox 5 is out, a recap of the process.

Responsibilities

Throughout the Firefox 5 process, here were my main responsibilities:

  • Gather feedback from input (and to a lesser degree, SUMO) and report in the relevant meetings. (We did this with a weekly feedback meeting, in the future, this is going to be offline with a get together in the feedback meeting to make sure everyone is on the same page).
    • File bugs for discovered issues and make sure that they get acted on.
    • Gather extra feedback or offer opinion from a user/support perspective on features. (In this cycle, I was only asked about graphics changes and channel switcher but as we push more features, I suspect more will show up.)
  • Attend the status meetings for each channel.
  • Attend tracking bug triage for each channel.
  • Notice features/changes/bugs that would require documentation (KB) changes and communicate them to Michael.
  • Communicate the status of Firefox (release dates, transition dates, plans for merges etc) to the team.

The following responsibilities were around the final release timeframe of Firefox 5:

  • Summarize known issues for community.
  • Release day events and making sure that nothing was terrible. We did four RRRT posts in 2 days.

Overall, I'd say the workload steadily increased as the process went on but that's likely because things were really hectic at the beginning and much of the time was just spent figuring out how things would even work rather than doing things. There was also a bunch of time as the people running the meetings kept shifting that it wasn't clear who was responsible for what.

What worked well

  • Attending triage meetings. While it can sometimes be technical and many bugs don't concern support, bugs that are marked for tracking during the aurora or beta periods are usually very user-facing and often urgent -- or landing them could have potential user implications. While it's lots of hours of meetings a week, I actually found those hours to be particularly valuable near the end of the process when we were rejecting fixes. Also, it's sometimes necessary to have a user perspective on things -- do users actually do X or do people actually care about Y. The weeks I missed triage meetings, I ended up missing bugs and then they weren't talked about for 4 weeks and so they were a surprise.
  • Feedback reporting at the end of the cycle. By the end of the beta period, we were flagging website issues regularly and getting traction on some of them.
  • Documentation. Michael did a stellar job tracking and leading the documentation effort even on the short cycle and with last minute changes. I felt that we communicated well.

Areas of improvement

  • We pulled the channel switcher feature late after we'd already done the documentation for it. This is probably likely to happen in the future too but we may have saved some effort if we waited for a while before starting documentation.
  • Balance communication vs accuracy. Things moved really fast and what was decided in one meeting would be different in the meeting two days later. It's hard not to tell the team/community something that might be definitive only to reverse course the next day. I need a better way of communicating the status of the Firefox project without it sounding like the final word on things.
  • For feedback, we need more users on the non-release channels. We got a lot better at the end of the beta period but we didn't really get into the rhythm of reporting solid findings until very late.
  • Communicating documentation status. I was asked a few times from Sid whether we'd documented the move in the do-not-track preference. I didn't have a place to point him to say "its on our radar". (I will probably use Support/Article_Tracking#Updates_for_Firefox_5 in the future).
  • Extension compatibility support. We knew this was going to be a problem but I didn't think track the status of the extensions that I knew were major until two weeks before the end. This turned out to be a big deal.
  • Be more closely involved in the Aurora process. Early on, a lot of the things in aurora, I didn't care about because they had no direct SUMO impact and there was no input. However problems in aurora became problems in beta and it's harder to get fixes landed in beta.
  • Attend fewer meetings.

Implications for Firefox 6+

There will be a full post mortem of Firefox 5 with all the release drivers and related teams this week. I think a LOT of the processes are going to change. For example, I suspect feature pages are either going to get a LOT better and be tracked much more tightly or they're going to get dropped. I think the following are goals for support for each "train" but exactly how they're accomplished is probably not going to be much like how they were accomplished for Firefox 5.

  • Track bugs/features in Aurora/Beta and document or alert the community about major ones.
  • Gather, report, file bugs for feedback/issues from users
  • Advocate for appropriately scoped fixes from a user perspective.
  • After release: report issues promptly.
Retrieved from "https://wiki.mozilla.org/index.php?title=Support/RapidRelease/Firefox_5_post_mortem&oldid=1236635"