Websites/Mozilla.org/Archive/Planning
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
- Create a more usable staging site
- What else needs to be done to fix this bug?
Content
Current Project
Future Content Updates
- Move content as needed from mozilla.com
See more:
Coding
- Clean up root .htaccess file
- Basically done; needs verification.
- Link to SVN history of page in mozilla.org footer is broken
- Fixed in staging; needs merge to trunk
- Add last modified date to footer where the current 'Page History' link is
- Fixed in staging; needs merge to trunk
- 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
- Install phpSyndication 1.0b1 site-wide
- Needs approval
- Add RSS feed for Mozilla Foundation Security Advisories
- Easy to implement if phpSyndication is installed
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
- Documentation migration priorities
- Various archiving bugs
- Various documentation migration bugs
- Archived version of site
- 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
- 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 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.
