Websites/Mozilla.org/Roadmap 2011/Q2WebsiteOnsite
Contents
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
