Purpose of this Document

The aim of this document is to serve as a set of guidelines, implemented in a checklist format, to which parties launching web marketing campaigns can easily refer as they move the project from concept to a quality, successful, and timely launch, with the assistance of Web Development, IT, and QA.

[Open Issue]: After writing this, it feels a little disjointed. The checklist feels marketing-internal, while the "what's next?" section might best be written as its own document outlining the process of launching a campaign, delineating responsibilities. Thoughts? - stephend

I think that this works as a starting point -- both the checklist and whatsnext section are important components of launching marketing campaigns and both outlines should be kept in one area. Even though the checklist is more "internal", it's important to keep the QA and product requirements in mind as this will greatly affect the test plan. - D-Rol

Checklist before a Hand-off to QA/WebDev/IT

1. Have IT, WebDev, and QA been given advance notice?
   1. Early involvement might change the approach as feasibility is determined (this is particularly true with dynamic pages and anything that depends on the visitors' locale/browser/etc. If in doubt, ask webdev)
   2. All parties should agree on a tentative schedule, and prioritize as needed
2. What level of traffic is expected?
3. What happens in the JavaScript-disabled case? (Is functionality lost? Are there layout issues?)
   
4. What level of support does this project have on non Firefox-based browsers?
   
5. Have the appropriate Accessibility accommodations been made?
6. Is it code-complete at hand-off, or will it need work from Web Development (CSS fixes, link populating, etc.)
   
7. Is this project tied to a specific hard date, or coinciding with a product release?
8. Have all potential partners been notified of the rollout?
9. Is there a roll-back plan put in place? (this really should be decided by all parties, I'd imagine; that's what we did for Rock your Firefox) - stephend

I think the design work is ready to be tested; what's next?

1. Double-check (if you're able) that you've considered the issues in the checklist, or know whom will address them
2. If the project already has a Bugzilla component, file a bug there, assigning it to the appropriate QA contact, with a summary such as "QA [project name]" (if in doubt, email qa-execution@mozilla.org with the bug # and background)
   1. If the project has no such component, please file in the "Websites" product, under the "www.mozilla.com" component.
   2. In the bug, note any contingencies/dependencies
   3. Be clear as to what work is already completed, what will eventually need to be pushed where and when (the actual call to push is a separate bug), and what still needs to be implemented
3. QA and WebDev will investigate whether the project is yet testable, and if so, QA will write a test plan incorporating a testing approach, support for various browsers, and staging URLS.
4. QA will make a run-through of the project, noting the testing results--depending on the amount and types-- either directly in the bug or in the test plan (usually both)
5. An empowered member of Marketing (usually they who are leading the project) will--after consulting with QA/WebDev/IT--make the call as to whether to ship
   1. When consulting with WebDev, please let them know whether you are shipping. They will then merge the changes to the production tag of the site and let you know when IT can update.
6. Marketing will file an IT ticket asking that the approved changes be pushed to production (please CC the people involved with your project)

Contacts

QA

Stephen Donner stephend@mozilla.com

Web Development

Wil Clouser clouserw@mozilla.com
Mike Morgan morgamic@mozilla.com
Justin Scott fligtar@mozilla.com
Ryan Doherty rdoherty@mozilla.com
... or just webdev@mozilla.com