Websites/Mozilla.org/Archive/Planning

From MozillaWiki
Jump to: navigation, search

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"