Websites/Mozilla.org/Archive/Planning: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Changing order of top-level sections and cleaning formatting)
m (moved Mozilla.org/Planning to Websites/Mozilla.org/Archive/Planning: moving old pages to archive)
 
(212 intermediate revisions by 4 users not shown)
Line 1: Line 1:
This page is being used to create a plan for www.mozilla.org to address comments raised in [https://bugzilla.mozilla.org/show_bug.cgi?id=345664 bug 345664].  This plan has also been discussed in the following meeting notes:
This page is being used as a planning document for updating the [http://www.mozilla.org www.mozilla.org] site.  A high-level [[Mozilla.org:Big_Picture|big picture]] document is also available that gives information about the goals and vision for the site.


* [http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/43a9e855115c3bde/495d9b379ccac968#495d9b379ccac968 Notes from www.mozilla.org planning meeting on 1/23]
= Planning Meetings =


== Establish Identity ==
These meetings are no longer being held since they dealt with the previous mozilla.org site from before the mozilla.org/.com merge.  Going forward, anyone interested in these meetings should join #www on IRC and have discussions there and find out about meetings at


''A discussion about the vision for www.mozilla.org is taking place on mozilla.dev.mozilla-org.  See:''
* https://wiki.mozilla.org/One-Mozilla-Project#Meetings


http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/96b7a4237ee25830/8980d110bb081a44#8980d110bb081a44
= Open Issues =


If a page on www.mozilla.org does not fit with the vision for the site, there are three options: archive it, migrate it or update it.  Deleting a page is not one of the options because we feel that it is impossible to know what might be useful for someone in the community and we also want to preserve a record of past contributions to the Mozilla site.
These issues are the agenda for the next planning meeting.


== Archive Obsolete Pages ==
== www.mozilla.com and www.mozilla.org merge ==


Owner: David Boswell
* [[Mozilla.org/Roadmap 2011/Domain change]]


Actions:
== P1 Bugs ==
* First, we take a snapshot of the site ([https://bugzilla.mozilla.org/show_bug.cgi?id=395669 bug 395669]) and make it available somewhere (archive.mozilla.org or wherever).  At some point, we may put together a curated history page or section that makes the historically relevant information easier to find on the archive site.


* Second, we post a page on the wiki where we list all of the pages currently under consideration for archiving.  To make things easy to manage, we should start by posting only a small batch of pages (5 or 10?).  Once we have the process working more smoothly we can post larger batches of pages.
* {{bug|525522|Create a more usable staging site}}
** What else needs to be done to fix this bug?


* Third, after a certain period of public discussion (2 weeks maybe?) these pages will be removed from www.mozilla.org's CVS and a redirect set up to the archive site.  We may need to set up some sort of archive landing page or header so that people are aware that the content they are seeing is no longer considered current.
== Content ==


If you would like to suggest a page for archiving, please add a link to the [[Mozilla.org:Archiving Suggestions]] page.
'''Current Project'''


''More detail is needed in this process, specifically: we need to have a page somewhere detailing the process (i.e. what newsgroup to post about the proposed-for-deletion pages, how do we identify and notify the interested parties about those documents, etc.) Right now there's no way to even start the removal/archival process (short of convincing someone with www access to kill the doc), and no estimates when this will change -- this discourages some contributors.''
* [http://kildare.stage.mozilla.com/ Home page redesign]
* [http://intothefuzz.com/leetom/Mozilla.org/JPG/ Sub-page designs]


''For background, a discussion about how to handle archiving or removing content from www.mozilla.org is available on mozilla.dev.mozilla-org. See:''
'''Future Content Updates'''


http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/2c2079dc764fa8e2/0fd4ff627edad777#0fd4ff627edad777
* Move content as needed from mozilla.com


== Migrate Content ==
See more:


Owner: Sheppy
* [[Mozilla.org/Content_priorities|Content priorities list]]


Action Items: Move developer content to developer.mozilla.org and identify other content that may belong on other community sites.
== Coding ==


* Suggestion: Maybe we should set up a sandbox-like area on MDC to copy developer-related articles from Mozilla.org to; from there, they can make their way to the main MDC site as they're vetted and updated as appropriate, while remaining available with some sort of "This article may be obsolete" banner across the top of the page.
* {{bug|636032|Clean up root .htaccess file}}
** Basically done; needs verification.
* {{bug|619842|Link to SVN history of page in mozilla.org footer is broken}}
** Fixed in staging; needs merge to trunk
* {{bug|521706|Add last modified date to footer where the current 'Page History' link is}}
** Fixed in staging; needs merge to trunk
* {{bug|569624|Set up customizable auto-response for different project areas listed in Get Involved form}}
** Needs patch; has been assigned to Paul Osman since 2010-07-15 with no progress
* {{bug|583627|Install phpSyndication 1.0b1 site-wide}}
** Needs approval
* {{bug|504882|Add RSS feed for Mozilla Foundation Security Advisories}}
** Easy to implement if phpSyndication is installed


Having heard no objections to that plan, I think that's what we should do.  I'll look at organization for this next week.
=== New Workflow Plan ===


== Update Content ==
Presumably our workflow will be at least somewhat superseded by the Mozilla.com/WebDev workflow after the merger, but, depending on when that's scheduled to occur, we should probably come up with a new workflow for Mozilla.org.


Owner: Simon Paquet
The basic structure would probably be as follows:
* File a bug
* Create a patch
* Get patch reviewed
* Commit patch to staging
* Bake patch on staging
* Commit patch to trunk
* Mark bug as RESOLVED FIXED
* Bake patch on trunk
* Mark bug as VERIFIED


Action Items:
This is not an especially revolutionary workflow (I believe it's basically what many other sections of the community are using—not sure about WebDev specifically), but it's one that has not been followed much at all for the Mozilla.org codebase. What's especially troublesome is the fact that many patches bypass staging altogether, which makes it very difficult to keep the staging and trunk codebases in sync. In fact, the ideal situation would be to never have to merge ''from'' trunk ''to'' staging—something that happens all too frequently (when somebody remembers to do it, that is).
* Reorganize the [http://www.mozilla.org/projects/ Projects] page
** by removing projects, which are clearly inactive or outdated
** Determine the activity/validity status of other projects, whose project pages were not updated within the last 18 months
** Remove/archive all content of inactive/outdated projects
** create a valid definition of what constitutes a mozilla.org project and what does not. Remove all items, which do not fall under that category.
** [http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/5e496665ce51eea0 Proposal] posted to mozilla.dev.mozilla-org
** [https://bugzilla.mozilla.org/show_bug.cgi?id=393447 Tracking Bug - Bug 393447]


== Reorganize Structure ==
==== Reviewers ====


Owner: TBD
It's not clear to me who are the active members of the team or what their skills or qualifications are. This isn't a particularly big deal, but it makes it hard to determine who is available (or who is required) to review what patches. I'm OK with simply having us all review each other's patches (just so that each patch has another set of eyes on it before it enters the wild), since there appear to be so few of us, but we should establish that explicitly.


Action Items: The structure of the site should be reviewed and possibly updated to reflect the content that is still being hosted on the site. Here is a proposed new set of top-level sections and pages in each section:
I also think it's time to reduce our reliance on Reed. He's clearly very busy right now—and even when he's not busy, he's still busy, given all his different responsibilities at Mozilla—and when he's not available, it seems a significant portion of the workflow comes to a grinding halt. Now, I'm not suggesting we banish him from the team or anything ridiculous like that, but, IMO, we can no longer afford to require everything to go through him before it can be completed. (Obviously, not ''everything'' goes through Reed, but a significant portion of the technical stuff does.)


===Top-Level Navigation===
==== Priorities and Triage ====


* Projects
It may be to our advantage make better use of the priority field in Bugzilla. Of the 244 bugs open at the time of this writing, only a handful (~25) have priorities marked. One example of an area that could benefit by getting a default priority might be the bugs generated by the various HTTP error links. To make it even easier, we could just add it to the fields set automatically for the visitor by the link. (There are likely other categories that bugs fall into, but that was the only one off the top of my head.)
** Featured Projects
** Mozilla-Based Applications
** ''Any active project that hasn't moved to the wiki, MDC or their own site''
* Developers
** ''I'm not sure what content in this section still belongs on the site instead of MDC, so feel free to make suggestions for this section''
* Foundation
** About the Foundation
** Activities
** Careers
** Licensing & Trademarks
** Public Documents
** Statement of Direction
* Contribute
** ''Links to Donate page and other ways to get involved''
* About
** Fast Facts
** Get Involved
** History
** How Free Is Mozilla?
** Mozilla Manifesto
** Roles and Leadership
** Timeline


===Footer Links===
Also, the range of these open bugs goes all the way back to 2001. It's probably time we did some triage to see what was still relevant.


1st row:
== Localization ==
* Community Blogs
* Support Options
* Security Updates
* Contact Us
* Privacy Policy / Terms of Use / Other legal stuff (do we need any of these?)


2nd row:
* [https://bugzilla.mozilla.org/show_bug.cgi?id=601945 Need staging server for testing integration with Verbatim]
* International Affiliates: Mozilla Europe - Mozilla Japan - Mozilla China


Note: I don't think we need a Site Map since they easily become stale and can confuse people.  I also thought moving Support from the top-level links to the footer might make sense since providing support may not be part of the vision for the site (if so, we can just link to mozilla.com's support section)
Planning:
* Determine objectives for localizing content (eg, increase traffic on Manifesto page)
* Determine [[Mozilla.org/Localization_wishlist|what we want to localize]] and what's ready to be localized
* Look into alternatives for dynamic content (either find language-specific replacements or degrade pages gracefully)
* Finalize and implement our l10n system


===Home Page Content===
Other


The home page can be used to call out some items that we want to highlight but that don't belong in the top nav or footer.
* {{bug|479085}} – Turn off language negotiation for Mozilla Manifesto translations


* Install Firefox call-out
== Stats ==
* Store call-out
* Support information
* News
* Other???


== Select Owners ==
* Note: Urchin script removed, no longer being used but available as archive.


Owner: TBD
* We've moved to WebTrends -- seems better but needs configuration.


Action Items: A module owner for the site needs to be identified that will make sure the site is following the identity established in this plan.
Relevant Links:


This is a pretty critical task. Until there's an owner, there's going to be a lot of indecision on the parts of people who are trying to work on this stuff about whether or not they're doing the right thing. --[[User:Sheppy|Sheppy]] 14:13, 13 September 2007 (PDT)
* [http://jlongster.com/s/mozorg-stats/ SVN repository stats]
* [[Mozilla.org/Stats|Mozilla.org stats page]]
* [[Metrics|Community Metrics page]]
 
== Archiving/Migrating ==
 
* [[Mozilla.org/Doc_migration|Documentation migration priorities]]
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=archiv&product=Websites&component=www.mozilla.org&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Various archiving bugs]
* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=migrate&product=Websites&component=www.mozilla.org&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Various documentation migration bugs]
* [http://www-archive.mozilla.org/ Archived version of site]
* [http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/2c2079dc764fa8e2/0fd4ff627edad777#0fd4ff627edad777 Removing content from www.mozilla.org]
 
''Note: For migrating docs, maybe we should set up a sandbox-like area on MDC to copy developer-related articles from Mozilla.org to; from there, they can make their way to the main MDC site as they're vetted and updated as appropriate, while remaining available with some sort of "This article may be obsolete" banner across the top of the page.''
 
== Back-end ==
 
* {{bug|487108|Look into replacing Doctor with ACE as editor for www.mozilla.org}}
** This has been sitting dormant since 2009; is it still desired?
 
== Testing ==
 
How can we improve the ongoing testing we're doing for the site?  Some ideas to discuss:
 
* Announce call for testers and owner for www.mozilla.org QA
* Triage [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&product=Websites&component=www.mozilla.org&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED open site bugs]
* Hook in to existing [[QA/Execution/Web_Testing|Web QA]] team and processes
* Set up automated tests for site  (See [https://developer.mozilla.org/User:Sheppy/MDC_unit_testing MDC unit testing] and [http://seleniumhq.org/ Selenium])
* Other things we should be doing?
 
== Getting New People Involved ==
 
Open Issues:
 
* [[Mozilla.org|Identify good getting started projects]]
* [[Mozilla.org/How_to_Work_with_Site|Improve getting started documentation]]
 
Relevant Links:
* [http://www.volunteermatch.org/search/org96493.jsp VolunteerMatch job descriptions]
 
=Resolved/Inactive Issues=
 
Previous items on this page have been moved to the [[Mozilla.org/Planning/Archive|Archive]] page.

Latest revision as of 22:15, 1 October 2012

This page is being used as a planning document for updating the www.mozilla.org site. A high-level big picture document is also available that gives information about the goals and vision for the site.

Planning Meetings

These meetings are no longer being held since they dealt with the previous mozilla.org site from before the mozilla.org/.com merge. Going forward, anyone interested in these meetings should join #www on IRC and have discussions there and find out about meetings at

Open Issues

These issues are the agenda for the next planning meeting.

www.mozilla.com and www.mozilla.org merge

P1 Bugs

Content

Current Project

Future Content Updates

  • Move content as needed from mozilla.com

See more:

Coding

New Workflow Plan

Presumably our workflow will be at least somewhat superseded by the Mozilla.com/WebDev workflow after the merger, but, depending on when that's scheduled to occur, we should probably come up with a new workflow for Mozilla.org.

The basic structure would probably be as follows:

  • File a bug
  • Create a patch
  • Get patch reviewed
  • Commit patch to staging
  • Bake patch on staging
  • Commit patch to trunk
  • Mark bug as RESOLVED FIXED
  • Bake patch on trunk
  • Mark bug as VERIFIED

This is not an especially revolutionary workflow (I believe it's basically what many other sections of the community are using—not sure about WebDev specifically), but it's one that has not been followed much at all for the Mozilla.org codebase. What's especially troublesome is the fact that many patches bypass staging altogether, which makes it very difficult to keep the staging and trunk codebases in sync. In fact, the ideal situation would be to never have to merge from trunk to staging—something that happens all too frequently (when somebody remembers to do it, that is).

Reviewers

It's not clear to me who are the active members of the team or what their skills or qualifications are. This isn't a particularly big deal, but it makes it hard to determine who is available (or who is required) to review what patches. I'm OK with simply having us all review each other's patches (just so that each patch has another set of eyes on it before it enters the wild), since there appear to be so few of us, but we should establish that explicitly.

I also think it's time to reduce our reliance on Reed. He's clearly very busy right now—and even when he's not busy, he's still busy, given all his different responsibilities at Mozilla—and when he's not available, it seems a significant portion of the workflow comes to a grinding halt. Now, I'm not suggesting we banish him from the team or anything ridiculous like that, but, IMO, we can no longer afford to require everything to go through him before it can be completed. (Obviously, not everything goes through Reed, but a significant portion of the technical stuff does.)

Priorities and Triage

It may be to our advantage make better use of the priority field in Bugzilla. Of the 244 bugs open at the time of this writing, only a handful (~25) have priorities marked. One example of an area that could benefit by getting a default priority might be the bugs generated by the various HTTP error links. To make it even easier, we could just add it to the fields set automatically for the visitor by the link. (There are likely other categories that bugs fall into, but that was the only one off the top of my head.)

Also, the range of these open bugs goes all the way back to 2001. It's probably time we did some triage to see what was still relevant.

Localization

Planning:

  • Determine objectives for localizing content (eg, increase traffic on Manifesto page)
  • Determine what we want to localize and what's ready to be localized
  • Look into alternatives for dynamic content (either find language-specific replacements or degrade pages gracefully)
  • Finalize and implement our l10n system

Other

  • bug 479085 – Turn off language negotiation for Mozilla Manifesto translations

Stats

  • Note: Urchin script removed, no longer being used but available as archive.
  • We've moved to WebTrends -- seems better but needs configuration.

Relevant Links:

Archiving/Migrating

Note: For migrating docs, maybe we should set up a sandbox-like area on MDC to copy developer-related articles from Mozilla.org to; from there, they can make their way to the main MDC site as they're vetted and updated as appropriate, while remaining available with some sort of "This article may be obsolete" banner across the top of the page.

Back-end

Testing

How can we improve the ongoing testing we're doing for the site? Some ideas to discuss:

  • Announce call for testers and owner for www.mozilla.org QA
  • Triage open site bugs
  • Hook in to existing Web QA team and processes
  • Set up automated tests for site (See MDC unit testing and Selenium)
  • Other things we should be doing?

Getting New People Involved

Open Issues:

Relevant Links:

Resolved/Inactive Issues

Previous items on this page have been moved to the Archive page.

Retrieved from "https://wiki.mozilla.org/index.php?title=Websites/Mozilla.org/Archive/Planning&oldid=475294"