Websites/Mozilla.org/Roadmap 2011/Q2WebsiteOnsite

From MozillaWiki
Jump to: navigation, search

Session Meeting Notes

Launch Retrospective Phase 1

Pain Points

  • Would be good to have a checklist of what needs to happen on release day and who needs to do it (steven g)
  • Coordinating with IT better
  • Version Control
  • Product Details Library
  • Good Things
  • How we've used version numbers
  • How we've labeled "Fx4Launch" bugs

The Good Things

  • How we've labeled releases

Future

The emphasis on version number will decrease - we need to figure out the way to reorganize the website for the rapid release schedule

Make the site more dynamic to help support these rapid release cycles

Take time during dev cycles to tackle infastructure problems (Anthony Suggestions. Talk more about in tomorrows retrospective part 2) -- Great idea!

Have a web based interface to know which changes were in one branch vs. another? (Anthony suggestion)

Possibly commit changes when you're done instead of waiting for the end of the 2 week cycle

Have a tracking bug for whole releases to help us get an overview of the big picture of the release

Have a tracking bug for similar sub-tasks within a milestone. A wiki page would also be helpful, if for nothing else to have a wiki page with a link to the proper query.

Q2 Goals Session

Morgamic: Overview of How to Set Goals

Everyone should know what the mission is: to promote innovation, openess and opportunity on the web.

From there, you have two areas: Strategic (steering comitte, exec team) and Operational (take high level goals and make them happen)

Goals ARE YOURS. If you don't understand how goals map to you it's your responsibility to make that clear. Ask us!

Hitting 100% of your goals may not be a good thing. You're not setting goals that are hard enough.

Goals should be measurable - easy to quantify

John: Web Team and Engagement Goals Draft: https://wiki.mozilla.org/Mozilla.org/Roadmap_2011/Q2 (read those)

From a WebDev Perspective:

Goals: moving the to GIT and fixing the Product Release Details libraries.

Feedback:

  • Seems like a lot. How do we track and manage what we're doing? A quarter is only 3 months.
  • How are incoming Mozilla.com bugs triaged? (Let's talk more about that tomorrow during the release cycle post-mortem)
  • Prioritization will also be super important throughout
  • Possibly deeming pages that we know will end of life
  • Seems like the merge will affect a lot of things - we haven't yet defined a "merge owner" - us as a team should figure out who that  person is EOW
  • Infastructure Architecture needed before the merge (Morgamic)
  • Figure out the right sequencing of these goals - it could be that this quarter is a lot of storyboarding and planning

Release Cycle Retrospective

Find meeting notes here

404 Page Hacking

We came up with a slew of ideas and have decided to do the following:

Phase 1: Steven and Mike keep hacking on adding simple elements into the page to make it more functional, like download button, and HTML5 coolness to headline. Rik will start tackling the top 10 404 error causes.

Phase 2: Laura and Tara to work with DDL to come up with a custom character that will blow the fail whale out of the water...oh wait...


IT discussion

Agenda:

  • Ask IT for overview of live site infrastructure
  • How can we improve our process?
  • How does the .com/.org merge affect IT?
  • Ask IT about git transition

IT overview:

  • SVN is updated every 15 minutes
  • Zeus usually updates every 10 minutes
  • static resources are cached heavily
  • we can flush Zeus after releasing
  • we can't flush the CDN
  • .com/.org work basically the same, merging is fine
  • git is feasible, possibly this quarter

webdev should:

  • tag resources with version #s

Mozilla.com/.org merge meeting

Notes at http://etherpad.mozilla.com:9000/mozilla-site-merge-plan