Personal tools

Mozilla.com

From MozillaWiki

(Difference between revisions)
Jump to: navigation, search
(Mozilla.com SVN Source)
 
Line 20: Line 20:
 
* [https://wiki.mozilla.org/Mozilla.com/Newsletters Newsletters]: Responsys integration and a centralized email service
 
* [https://wiki.mozilla.org/Mozilla.com/Newsletters Newsletters]: Responsys integration and a centralized email service
  
= Roadmap  =
+
= Docs =
  
For Q2 the following projects are going on:  
+
Please view http://readthedocs.org/docs/bedrock/en/latest/php.html for all the documentation for mozilla.org. It explains how to install it, what the merge is, how to rollout code, how our workflow works, and more.
 
+
'''Execute Phase 1. of the .com/.org (including Europe) Firefox Product merge''' ''(goal: brand awareness, simplify # & version(s) of static product pages)''
+
 
+
*Complete [https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0AlGDfFgIIbD9dFVuX2h5aU1KeTlBV1N4Ti01Y1RqR2c&output=html content inventory] & audit of pages on .com (including Europe) that will be redirected to .org
+
*Redirect .com pages specified in the [https://spreadsheets.google.com/spreadsheet/pub?hl=en&hl=en&key=0AlGDfFgIIbD9dFVuX2h5aU1KeTlBV1N4Ti01Y1RqR2c&output=html content inventory] to .org
+
*Complete IA review & user/design research & finalize revised IA for .com/.org (including Europe) merge (eliminating/retiring redundant or irrelevant content)
+
*Begin (possibly complete) design update to .com skin that will become the new skin for all .org pages noted in the content inventory for this visual update
+
*Analyze current workflows: [http://etherpad.mozilla.com:9000/mozilla-com-dev-cycle http://etherpad.mozilla.com:9000/mozilla-com-dev-cycle]
+
*Continue discussing infrastructure & overall strategy that will inform Phase 2. of the .com/.org merge
+
 
+
(*Chrissie running content audit/inventory)<br>
+
 
+
'''Produce Firefox Product pages that are Relative to Mobile Users''' ''(goal: produce an excellent mobile experience, reduce need to maintain separate mobile-only site)''
+
 
+
*Create [https://wiki.mozilla.org/Mozilla.com/MobileStandards design/coding standards] for making sites mobile-friendly
+
*Use metrics to determine pages to focus on
+
*Begin implementing design/coding standards for mozilla.com
+
 
+
'''Improve [https://wiki.mozilla.org/Mozilla.com/Tests mozilla.com automated test] coverage'''
+
 
+
*<strike>Deploy [https://github.com/AutomatedTester/mcom-tests Raymond's tests] and get them running on Hudson</strike>
+
*Write tons of more tests
+
 
+
For background on these goals &amp; projects check out [https://wiki.mozilla.org/Mozilla.org/Roadmap_2011/Q2WebsiteOnsite Q2 onsite meetings].
+
 
+
And, see the following page for more general [https://wiki.mozilla.org/Mozilla.org/Roadmap_2011/Q2 Q2 goals]
+
 
+
= Workflow  =
+
 
+
Work is developed, tested, and reviewed on trunk, pushed to staging if needs thorough testing, and pushed to a production branch to go live.
+
 
+
We use the whiteboard to track SVN revisions. All the work for a bug is done in these revs. Example:
+
 
+
r=10000,10005,10010 b=trunk
+
 
+
"r" is a list of comma-delimited revision, and "b" is the branch they live on. If things have been pushed to stage, it would be a list of revs for the stage branch.
+
 
+
# dev works on a bug and makes a commit to trunk with bug number, updates/creates "r" field on bug's whiteboard field with the revision (r=#####), and possibly leaves revision in a comment for code review
+
# work is reviewed and when fixed, bug is marked "resolved fixed"
+
# add keyword "qawanted" to bug to move to testing
+
# bug is tested and re-opened if not fixed, marked "qa-verified-trunk" if fixed
+
# dev merges all changes into "stage" branch, updates whiteboard with staging revisions
+
# if change is a one-off, add keyword "push-needed" for immediate rollout
+
# bug is rolled out individually (push-needed) or with milestone (staging is merged onto production)
+
# and "push-needed" keywords are removed
+
# QA checks on production, marks "verified fixed"; if there's a problem, re-opens bug, dev might revert changes on production if problem is critical
+
 
+
Here are a few example SVN commands one might use:
+
 
+
commit to trunk (r100)
+
  svn commit -m 'bug 60000 - spread happiness around'
+
+
merge to staging (r50)
+
  svn merge --ignore-ancestry -c100,104 trunk tags/stage
+
  cd tags/stage && svn commit -m 'r100,104 from trunk for bug 60000'
+
+
merge to prod (r40)
+
  svn merge --ignore-ancestry -c50 tags/stage tags/prod
+
  cd tags/prod && svn commit -m 'r50 from staging for bug 60000'
+
+
revert on prod
+
  cd tags/prod && svn merge -c-40 .
+
 
+
The important point in this process is that the developer can commit what he/she wants to trunk, but he/she is responsible for merging those changes into stage to be rolled out.
+
 
+
QA usually tests on trunk (http://www-dev.allizom.org/).
+
 
+
= Mozilla.com SVN Source  =
+
 
+
The source behind mozilla.com (PHP, HTML, images, CSS, javascript, etc.) is hosted and managed in Subversion. For details merging from trunk to stage, see the [[Webtools:SVN Guidelines|SVN Guidelines]].
+
 
+
*'''Trunk''' - the main development version of mozilla.com. Most work happens here.
+
**SVN location: https://svn.mozilla.org/projects/mozilla.com/trunk
+
**viewvc: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/
+
**Preview URL: http://www-dev.allizom.org/
+
 
+
*'''Stage''' - When changes are ready in trunk, they are [[Webtools:SVN Guidelines#Tagging_for_Staging_.2F_Production_using_svn_merge|merged to stage]] for review before going to production.
+
**SVN location: https://svn.mozilla.org/projects/mozilla.com/tags/stage
+
**viewvc: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/stage/
+
**Preview URL: https://www.authstage.mozilla.com/
+
 
+
*'''Production''' - The live website. Beware!
+
**SVN location: https://svn.mozilla.org/projects/mozilla.com/tags/production
+
**viewvc: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/production/
+
**Preview URL: https://www.mozilla.com/
+
  
 
= Bugs  =
 
= Bugs  =
  
 
[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Websites&component=www.mozilla.com&resolution=---&chfieldto=Now See all bugs related to mozilla.com]
 
[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Websites&component=www.mozilla.com&resolution=---&chfieldto=Now See all bugs related to mozilla.com]
 
= Docs  =
 
 
*[[Mozilla.com/UpdatingProductDetails|How to update product-details]]
 
 
= Archive =
 
* [[Mozilla.com/Localization|Localization of mozilla.com]] (archived because last edited in 2009)
 

Latest revision as of 16:37, 11 January 2012

mozilla.com was launched on November 29, 2005 with the Firefox 1.5 release with the goal of simplifying the experience of obtaining Mozilla products.

The mission of mozilla.com is to:

  • provide a quick and easy path for obtaining our software
  • educate visitors about the advantages of our software
  • connect users with other Mozilla web properties they may be looking for

The audiences for mozilla.com:

  • End users of Mozilla products (both consumers and power users)
  • Current Firefox and Thunderbird users looking for upgrade information
  • Visitors interested in information about Mozilla Corporation

[edit] Projects

  • Bedrock: A new platform for mozilla.org in Python
  • 2011 Rebranding Project: Merging sites under the .org domain name
  • Automated tests: Writing Selenium tests to run in Jenkins to make sure the live site works as expected
  • Newsletters: Responsys integration and a centralized email service

[edit] Docs

Please view http://readthedocs.org/docs/bedrock/en/latest/php.html for all the documentation for mozilla.org. It explains how to install it, what the merge is, how to rollout code, how our workflow works, and more.

[edit] Bugs

See all bugs related to mozilla.com