Closed Bug 345664 (mozilla.org) Opened 18 years ago Closed 16 years ago

Deciding the future of www.mozilla.org

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: reed, Unassigned)

References

(
URL
)

Details

www.mozilla.org has no owner, and its content is just a big mess. Something needs to be done.

From the enlightening discussion between mconnor, kairo, and myself in #bmo@irc.m.o, these are some of the high points (all mainly ideas, no real definites):

* Need a plan first and then an owner

* mozilla.org should become a portal to other Mozilla sites/pages with some static content left on it (such as module ownership, drivers, cvs access policy)

* Small/new/etc. projects should be moved to a new projects.mozilla.org site

* More mature projects should be moved to separate domains (caminobrowser.org, for example); hosted by MoFo hopefully

* Stuff like bonecho could remain on www.mozilla.org

* Download links could still be on mozilla.org (such as /downloads/<project>/<release>/) [download pages/links and release notes for projects] (as it's a pain to deal with updating version numbers on wikis)

* All documentation should move to developer.mozilla.org (MDC) [what about old documentation?]

* Maybe move some stuff to an "ancient.mozilla.org"? (not sure; would hurt bookmarks; maybe use redirects?)


Again, these are just some ideas. Please spill your heart and soul out about this issue, and let's start putting a plan together to implement. :)
This all already sounds like a good plan to me!

> * More mature projects should be moved to separate domains (caminobrowser.org,
> for example); hosted by MoFo hopefully

If this, esp. the latter point, can be done, the SeaMonkey project would probably like to take that chance and move its current pages from mozilla.org to such a separate, MoFo-hosted site. We also can take the seamonkey-project.org host name for that, as we (I) already own that one...
(In reply to comment #0)
> * Stuff like bonecho could remain on www.mozilla.org

I don't really see the reason to host beta versions of a browser in a different place to the release versions.

> * Download links could still be on mozilla.org (such as
> /downloads/<project>/<release>/) [download pages/links and release notes for
> projects] (as it's a pain to deal with updating version numbers on wikis)
> 
> * All documentation should move to developer.mozilla.org (MDC) [what about old
> documentation?]

Plenty of old documentation has already been migrated to MDC so I don't see why the remains can't as well.

> * Maybe move some stuff to an "ancient.mozilla.org"? (not sure; would hurt
> bookmarks; maybe use redirects?)

archive.mozilla.org already exists and its only current purpose is for downloading old builds, so old pages could easily be put up there I imagine.

(In reply to comment #2)
> (In reply to comment #0)
> > * Stuff like bonecho could remain on www.mozilla.org
> 
> I don't really see the reason to host beta versions of a browser in a different
> place to the release versions.

The way I've understood it is that mozilla.com is the "corporate" side of things with the stable releases, etc. It doesn't have any development information on it at all.

> > * All documentation should move to developer.mozilla.org (MDC) [what about
> > old documentation?]
> 
> Plenty of old documentation has already been migrated to MDC so I don't see
> why the remains can't as well.

Sounds good, but we'll need more people helping move stuff. Maybe ask for assistance in one of the big blogs?

> > * Maybe move some stuff to an "ancient.mozilla.org"? (not sure; would hurt
> > bookmarks; maybe use redirects?)
> 
> archive.mozilla.org already exists and its only current purpose is for
> downloading old builds, so old pages could easily be put up there I imagine.

I like that idea better, but we'll have to see if this is feasible. Justin / justdave: Would something like that be possible on archive.m.o? Is there room to put some old sites that have no other place to go?
I've cc'd gerv and zach and deb and ben on this bug, all of whom likely have ideas -- if not time -- about where mozilla.org should be going. I, of course, have thoughts:

(In reply to comment #0)
> * Need a plan first and then an owner

I would amend this to say that you need a direction, and a strong statement of what you want the site to be, and then a driver/owner for that direction. Who is it for, what sort of things will you put there. We've not really seen any movement because coming up with a strong plan for the site takes a lot of time; I think we should start moving and amend the plan as we go along.

> * mozilla.org should become a portal to other Mozilla sites/pages with some
> static content left on it (such as module ownership, drivers, cvs access
> policy)

The portal approach is good, but I'd rather we focus on redirecting people to resources. We should have portals for every Mozilla topic. For example, want to know about development of Firefox? "Well, go to the planning pages on the wiki or check dev.apps.firefox or dev.planning for release dates, and the code's here and here's the build instructions and these are the people who are the module owners ..."

IMO, the goal should be for mozilla.org to be the page where you go to learn more about getting involved in the Mozilla project which includes any Mozilla subproject.


> * Small/new/etc. projects should be moved to a new projects.mozilla.org site

Who decides what's small/new? And what value is obtained from this segmentation? I'd rather have a list of all projects, put the "big" (ie: famous in terms of queries or google searches) ones in a section at the top, but still make mozilla.org the home for all mozilla related projects. Heck, I'd even have pages for mozilla.org/songbird which talk about mozilla-derivative projects.

> * More mature projects should be moved to separate domains (caminobrowser.org,
> for example); hosted by MoFo hopefully

I would think that this is something that would be done by the drivers of those mature projects. Mozilla can make it known that we're happy to provide some resources in the way of web hosting here, but we should still have a mozilla.org/camino page that then says "camino is blah blah blah, go here to find out more about it".

> * Stuff like bonecho could remain on www.mozilla.org

As with Camino above, Bon Echo (or any in-development mozilla project) deserves a page on mozilla.org that points to the related resources.

> * Download links could still be on mozilla.org (such as
> /downloads/<project>/<release>/) [download pages/links and release notes for
> projects] (as it's a pain to deal with updating version numbers on wikis)

We're trying to move as many things to bouncer as possible; just to keep that in mind. But yes, I agree, we should make it easy for people to download our software :)

> * All documentation should move to developer.mozilla.org (MDC) [what about old
> documentation?]

MDC is for developer documentation, not end-user documentation nor redistributor documentation (as per shaver and deb). We'd still need a place for those sorts of docs.

(In reply to comment #2)
> I don't really see the reason to host beta versions of a browser in a 
> different place to the release versions.

When Mozilla releases Firefox or Thunderbird, we do so with some statements about support, trademark on the product name and product itself, privacy policy, etc, etc. Those things don't necessarily apply to pre-release versions, so I'm actually pretty strongly in favour of keeping the idea of pre-release versions being "projects" that will become released "products" and keeping the websites separate.
(In reply to comment #0)
> * More mature projects should be moved to separate domains (caminobrowser.org,
> for example); hosted by MoFo hopefully

This (and other statements) are starting to define what MoFo is alright with doing. Instead of presuming, I'd like to get Frank in on some of this discussion, so CCing him as well...
Thanks for cc-ing me on this. I have an interest in this, because one of the things I'd like to see is a separate www.mozillafoundation.org site splitting off some of the content currently on www.mozilla.org. Some semi-random thoughts:

* I agree that the key function of www.mozilla.org is to orient people and get them headed in the right direction. www.mozilla.org as historically organized had/has the problem of being a bit of something for everyone, but not enough for anyone. I think it is better to get people as soon as possible into a site or sub-site that is tightly targeted to a particular audience and attempts to totally address the information and other needs of that audience.

* I think projects like Camino, Seamonkey, Sunbird, etc., having their own independent domains is overall a good idea -- I think it gives those projects a sense of identity and of not just being part of the mozilla.org "grab bag". This is healthy IMO.

* I agree that mozilla.com is for finished products, and that information on releases in development belongs elsewhere.

One major issue of interest to me is what to do with information that relates to the operation of the Mozilla project itself, e.g., formal policies, module owner lists, etc. Should this stay on www.mozilla.org, or go somewhere else (wiki.mozilla.org? www.mozillafoundation.org? a new site directed at "internal" users, i.e., project participants?)? I don't have any final opinion on this yet.

(In reply to comment #6)
> I have an interest in this, because one of the things I'd like to see is a
> separate www.mozillafoundation.org site splitting off some of the content
> currently on www.mozilla.org.

Isn't Zak supposed to be working on a new www.mozillafoundation.org web site?

> One major issue of interest to me is what to do with information that relates
> to the operation of the Mozilla project itself, e.g., formal policies, module
> owner lists, etc. Should this stay on www.mozilla.org, or go somewhere else
> (wiki.mozilla.org? www.mozillafoundation.org? a new site directed at "internal"
> users, i.e., project participants?)? I don't have any final opinion on this
> yet.

mconnor mentioned this in our discussion on IRC and felt that things such as policy, drivers, module ownership, etc. should remain on www.mozilla.org. I agree with him, as I believe most of that is already located under http://www.mozilla.org/hacking/, so I don't see why that would be a problem just to leave it there (with some reorganization as needed).
(In reply to comment #4)

> > * Small/new/etc. projects should be moved to a new projects.mozilla.org site
> 
> Who decides what's small/new?

IMHO, the project owners/leaders should decide theirselves if they want to have their own domain for their project or not. All projects should have some default space though where they can place some basic information about their project, e.g. projects.mozilla.org/<projectname>/ - this can be used as long as the project itself thinks it's enough to stick their content there. If and when the project wants to move to using their own site/domain, we might even redirect this default space to their new site.


In my eyes, mozilla.org should be the place to go if one wants to know more about the Mozilla project and/or community. This includes getting involved, learning how the project itself is organized, how to get in touch with the community, what subprojects we have, maybe even what the Mozilla platform is and where it's headed - and linking all our various resources so that one can easily find them.
(In reply to comment #7)
> Isn't Zak supposed to be working on a new www.mozillafoundation.org web site?

Yes, he's currently working on that. (It's gone a bit slowly because he hasn't had much time to work on Mozilla stuff, but it is proceeding.)

> mconnor mentioned this in our discussion on IRC and felt that things such as
> policy, drivers, module ownership, etc. should remain on www.mozilla.org. I
> agree with him, as I believe most of that is already located under
> http://www.mozilla.org/hacking/, so I don't see why that would be a problem
> just to leave it there (with some reorganization as needed).

Leaving policy, etc., documents on www.mozilla.org is fine by me. Our current plan for www.mozillafoundation.org is that it would be a relatively minimal site focusing on the Foundation as an organization, and that stuff related to the Mozilla project itself would go elsewhere.
Alias: mozilla.org
To be honest, I think mozilla.org needs an owner before a proper plan can be formulated, since that owner will be responsible for implementing any plans that are developed.  

That aside, there's a lot of content in mozilla.org.  Paul Kim and I were discussing it a while back and I took some time and dug through the tree and took notes on the general site structure (as it currently exists).  I've put a copy of those notes on wiki.mo in case they might be helpful (feel free to edit the notes if there's inaccurate or incomplete info):

http://wiki.mozilla.org/User:Dria/Mozilla.org_Site_Structure

There's also a working list of content to be migrated from Mozilla.org to MDC here:

http://developer.mozilla.org/en/docs/MDC:Existing_Content

That list is in rough shape right now and needs to be cleaned up, but if there's anything obviously missing (or stuff that should be prioritized for faster migration) please let me know (or edit the list directly).  We have migrated a significant amount of developer documentation from MDC, but it's not finished yet, and migration of old content has fallen further down our priority list as something non-critical that we can work on as time allows.  As Bsmedberg says, someone needs to figure out where the non-developer documentation should live as well, since it cannot go into the MDC wiki.

I don't have a huge amount of time to spend on mozilla.org-related stuff right now, so I hope the process of fixing/reorganizing it won't be too rushed.  I think the first step might best be finding someone willing to take responsibility/ownership for the site and project who will be able to put together a comprehensive plan and drive this project through to completion.

(In reply to comment #10)

> As
> Bsmedberg says

And by "Bsmedberg" I obviously mean "Beltnzer".  Oops.
It seems to me that, whether we like it or not (and I think we should), www.mozilla.org is home to everything that doesn't have a more specific site dedicated to it. So, it will end up containing everything about the project - either directly on the site, or in the form of directions and links. As time progresses, more things may move off the site to be replaced by links.

So say we have:

mofo.org: Foundation activities, policies etc.
mozilla.com: Firefox/Thunderbird stable releases
spreadfirefox.com: Marketing
devmo: Developer docs
caminobrowser.org: Camino stable releases

Then mozilla.org becomes the home of what's left - development activity for all projects, including alpha and beta releases, and including projects too small to have their own "release" site.

[User documentation is a bit of an odd man out; it's something that seems like it should have its own site but doesn't yet.]

I don't like the idea of web pages on "archive.mozilla.org". If it's useful, keep it. If not, bin it - people can get it from CVS if they need it again. Let's not give ourselves a maintenance burden, and leave out-of-date info lying around.

Gerv
I don't see a big problem with having a lot of disparate pieces of content at URLs that start with http://www.mozilla.org/ .  We have a lot of projects and a lot of content -- there's nothing wrong with that as long as people can find what they're looking for and out-of-date information is corrected or at least marked as historical.

I think the big issues we need to address is (1) what we want to feature on the front page and the pages it links to and (2) how visitors find what they're looking for.

mozilla.org went through two major redesigns in 2003-2004 changing it from a developer-focused site to a user-focused site.  I think now that mozilla.com exists it should swing back towards developers.  The question is how far it should swing.  We already have www.mozilla.com for end users of the top-tier products and developer.mozilla.org for Web developers and developers using the Mozilla platform.  http://www.mozilla.org/hacking/ could be a central site for Mozilla core developers, although we probably want it to be migrated to a wiki since a lot of it is out of date.  Other projects that are making end-user software that's not Firefox and Thunderbird also already have sites for their users.  I tend to think that at a minimum mozilla.org should link prominently to all of these things -- though there's a question of how prominently it should link to each and how it should explain to the different audiences what those links are.
(In reply to comment #13)
> http://www.mozilla.org/hacking/ could be a central site for
> Mozilla core developers, although we probably want it to be migrated to a wiki
> since a lot of it is out of date.

In particular, to http://developer.mozilla.org/en/docs/Developing_Mozilla
I had started plans to migrate the Hacking Guide from mozilla.org to MDC, and that is on my list as a relatively major goal for Q3. If at all possible, I would like to have an initial migration of the existing content done by the end of the quarter, if not sooner.  I figure once the core of the Hacking Guide is migrated in, we can work on updating and reorganizing the content and sorting out what other bits we might want to include with it.

A while back (months) this was discussed on a thread...somewhere (I can't remember which group).  If I can find that thread again I'll link it here.  I had started a rough page for planning this migration here:

http://developer.mozilla.org/en/docs/User:Dria:hacking_guide_migration

Note that the "Licensing" and "Other projects" stuff at the bottom would not be included.  Please feel free to add new items or notes to that page.  

I'm hoping to get that project rolling again in the next week or so if possible.  Any help or suggestions would be much appreciated.
 

(In reply to comment #12)
> [User documentation is a bit of an odd man out; it's something that seems like
> it should have its own site but doesn't yet.]

If this means that you're considering something like support.mozilla.org, my vote would be against that. One thing I dislike about sites like kb.mozillazine.org is how users of different products are directed to same document. For example, a SeaMonkey user may be taken to a page written for Firefox users. It simply has a note at the top saying "this page also applies to blah, blah, and blah." Meanwhile that page may contain UI directions, that are different in SeaMonkey. The whole thing ends up confusing the user.

If there's going to be a support.mozilla.org, documentation should be separated by product, at the top level.
Could we at least get bug 341804 done as a first step, until we get a decision here? Reed has a patch there, we only need to get that in and get me checkin access to VARIABLES for future SeaMonkey version updates...
Blocks: 335376
Looking at years of efforts to clean up the mlp pages and the rdf pages, I myself happily participate in the "mozilla.org? run!" party that's going on.
Just that that's not a plan.

I'd like to echo what beltzner said in comment 4 in terms of content and fragmentation. We have enough separate sites already. More sites will just be less attractive. We're all part of the mozilla.org project, and we have a fuzzy, yet good-enough common understanding what that means.

What I would need in terms of a plan and direction is:

1) When do I put project pages on wiki.m.o, and when on www.m.o?
 I would think that this is something that can be decided depending on editing frequency and scale of cooperative editing. Maybe personal taste, too.

2) Where do I put project pages on wiki.m.o and on www.m.o?
 Looking at the QA and Project pages for Firefox2, those are at completely different hierarchies, some use / for separation, some use :. If you want to enter a URL, you need to know which, if you want to navigate to it, you need to know the right entry point.

3) How do I migrate project pages that are developer docs?
 Just for completeness, the migration docs for MDC are pretty good.

4) How do I migrate project pages that are user docs?
 Pretty academic question unless we manage to hire two more docs folks to run such a project, IMHO. Currently, kb.mz is likely the best place for en-US content.

5) How do I through old documentation in the bin?
 Looking at what we have in MLP and RDF, not all of that documentation is of historic value for the project, some of it is just deprecated and wrong now. If we could have project-wise 404 pages, throwing those away may be less painfull for broken bookmarks than anything. Setting up redirects for each and every page that doesn't speak the truth anymore is just going to keep us looking funny, and is may lead to confusing results in searches.

I don't think that a plan/direction including each and every page is going to be fruitful across the project, a top-level structure and some guidelines with sufficient freedom for project owners to fill that with the life they need sounds easier to accomplish and more valuable to me.
Hmm, just highlighting some stuff here:

Wrt Direction
-------------

Beltzner writes:
  IMO, the goal should be for mozilla.org to be the page where you go to
  learn more about getting involved in the Mozilla project which includes
  any Mozilla subproject.

I think this is a good mission statement.

KaiRo writes:

  In my eyes, mozilla.org should be the place to go if one wants to know
  more about the Mozilla project and/or community. This includes getting
  involved, learning how the project itself is organized, how to get in
  touch with the community, what subprojects we have, maybe even what the
  Mozilla platform is and where it's headed - and linking all our various
  resources so that one can easily find them.

A good restatement, with a list of subgoals for us. :)

Wrt Project Pages
-----------------

Reed writes:
  * Small/new/etc. projects should be moved to a new projects.mozilla.org site
  * More mature projects should be moved to separate domains
    (caminobrowser.org, for example); hosted by MoFo hopefully

Beltzner writes:
  Who decides what's small/new? And what value is obtained from this
  segmentation? I'd rather have a list of all projects, put the "big"
  (ie: famous in terms of queries or google searches) ones in a section
  at the top, but still make mozilla.org the home for all mozilla related
  projects. Heck, I'd even have pages for mozilla.org/songbird which talk
  about mozilla-derivative projects.

Hecker writes:
  I think projects like Camino, Seamonkey, Sunbird, etc., having their own
  independent domains is overall a good idea -- I think it gives those
  projects a sense of identity and of not just being part of the
  mozilla.org "grab bag". This is healthy IMO.

KaiRo writes:
  IMHO, the project owners/leaders should decide theirselves if they want
  to have their own domain for their project or not. All projects should
  have some default space though where they can place some basic
  information about their project, e.g. projects.mozilla.org/<projectname>/
  - this can be used as long as the project itself thinks it's enough to
  stick their content there. If and when the project wants to move to using
  their own site/domain, we might even redirect this default space to their
  new site.

I agree with Beltzner here. I think projects like Seamonkey and Camino
starting up their own domains is a good idea -- but I think those new
domains should be an end-user front, just like mozilla.com is for FF/TB.
Our projects aren't a "grab bag". mozilla.org is not SourceForge, we're
not cvs+bugzilla hosting. Our software are all interrelated: tied together
deep throughout the source code. You can't build any of them without Gecko.
This makes the source code, schedules, documentation, and communities all
overlap. Significantly. There's more overlap than not. The subprojects are
all part of the Mozilla Project, and should identify themselves as such.

The only thing that confuses the issue is the complications imposed by
MozillaCorp taking "Mozilla" as its trademark. (If you just pretend for
a moment that Mozilla Corporation is really named Dino Corporation, and
has a green-and-purple trade dress, this might become a little clearer.)
I don't think that should prevent us from identifying ourselves as the
Mozilla Project, however: I'm certain that wasn't the intent of the
trademark policy.

www vs wiki vs projects
-----------------------

Axel writes:
  1) When do I put project pages on wiki.m.o, and when on www.m.o?
  I would think that this is something that can be decided depending on
  editing frequency and scale of cooperative editing. Maybe personal taste,
  too.

  2) Where do I put project pages on wiki.m.o and on www.m.o?
   Looking at the QA and Project pages for Firefox2, those are at
   completely different hierarchies, some use / for separation, some use :.
   If you want to enter a URL, you need to know which, if you want to
   navigate to it, you need to know the right entry point.

I personally find this very confusing, but I don't really know what to
do about it...

I think we can start improving the situation by having all the projects
choose one (1) of either their wiki site Home_Page or their www site
index.html as their main entry page page. They should sort out their main
page content based on that decision, and we should update (revamp)
http://www.mozilla.org/projects/, have it point to the right main pages,
and link to it prominently from the front page.

Outdated Documentation
----------------------

Policy should be
  a) If it can be updated to be useful
       1. Migrate it to the right place (e.g. MDC)
       2. Set up a 301 Moved Permanently redirect
  b) If it's a historical document (e.g. press release, slideshow for a
     past developer conference, release notes, status notes, announcement)
       1. Move+redirect it to an archive, if it's not there already
       2. Get it indexed appropriately
  c) If it's completely useless
       1. cvs remove it
       2. Set up a 410 Gone

  And maybe we could customize the 410 message to point to a Web Archive
  copy of the missing document. (Epiphany does that automatically for
  failed domain lookups, iirc.)
(In reply to comment #19)
> I agree with Beltzner here. I think projects like Seamonkey and Camino
> starting up their own domains is a good idea -- but I think those new
> domains should be an end-user front, just like mozilla.com is for FF/TB.

I'm personally happy with this approach: List all projects under www.mozilla.org and provide for each the sorts of information appropriate for w.m.o (as discussed above), and then have optional separate domains containing end user information, for any projects that want to do that.

> The only thing that confuses the issue is the complications imposed by
> MozillaCorp taking "Mozilla" as its trademark. (If you just pretend for
> a moment that Mozilla Corporation is really named Dino Corporation, and
> has a green-and-purple trade dress, this might become a little clearer.)
> I don't think that should prevent us from identifying ourselves as the
> Mozilla Project, however: I'm certain that wasn't the intent of the
> trademark policy.

Correct. "Mozilla" is a trademark of the Foundation, not the Corporation, and it is intended to apply to the whole of what has traditionally been referred to as the Mozilla project. The Foundation *does* put limits on which products can include the term "Mozilla" as part of their formal product names. Thus we refer to "Mozilla Firefox" and "Mozilla Thunderbird", those being the official names of those products, but *not* to "Mozilla SeaMonkey", "Mozilla Camino", etc. However SeaMonkey, Camino, etc., are certainly part of the overall Mozilla project, and it's perfectly acceptable to refer to them as such.
(In reply to comment #19)

> Outdated Documentation
> ----------------------
> 
> Policy should be
>   a) If it can be updated to be useful

Who should determine if a document can be updated to be useful? 
Who else other than project manager should do such assessment and then updating?

>        1. Migrate it to the right place (e.g. MDC)

Who should do the migration?

>        2. Set up a 301 Moved Permanently redirect

Who should do such redirect?

>   b) If it's a historical document (e.g. press release, slideshow for a
>      past developer conference, release notes, status notes, announcement)
>        1. Move+redirect it to an archive, if it's not there already
>        2. Get it indexed appropriately


Who should do b1) and b2)?

>   c) If it's completely useless
>        1. cvs remove it
>        2. Set up a 410 Gone
> 
>   And maybe we could customize the 410 message to point to a Web Archive
>   copy of the missing document. (Epiphany does that automatically for
>   failed domain lookups, iirc.)


There are very good reasons to believe that outdated (updatable or not; worth keeping or not; worth archiving or not) documentation represents right now over 6,000 webpages. My reasoning is that no one other than project manager (or project webpages maintainer) should address its own webpages under his project, under his directory. You can not and you should not expect a single person to address/deal with 6,000+ webpages. A single person having to address 100 or 200 webpages is a manageable workload/task.

There are lots of other issues too. E.g.: new webpages and/or updated webpages should comply with m.o. guidelines (markup, validation, style, semantic).

My 2 cents.
Blocks: 350534
Voting for this bug. Deciding on what to do with outdated documents must be a priority in my opinion.
Here's what I"m planning to do with the developer documentation on the mozilla.org web site:

If there's already equivalent content on MDC, delete it.

If there's not already equivalent content on MDC, and the content is reasonably accurate and current, migrate it.

If there's not already equivalent content on MDC, and the content is obsolete or so far out of date that updating it is more work than rewriting from scratch, delete it.

It's time to fish or cut bait on this stuff.  We have too much material that's so badly obsolete that it's misleading floating around out there -- worse, much of it doesn't have replacement content available, so people assume it's accurate and don't bother to contribute updated documentation (or even complain about the lack of docs).
I forgot to mention that "delete" means "delete from the old site and redirect to MDC".
Go sheppy go!  (I'm assuming you have all of the needed access, right?)
All I need is the ability to read the web site, which I do have. :)

Shaver and I talked about this yesterday, and it looks like we're going to get an intern or contractor in to help with this migration, so my time can be spent primarily on new content.  I'm writing up a req for it now.
> If there's not already equivalent content on MDC, and the content is obsolete
> or so far out of date that updating it is more work than rewriting from
> scratch, delete it.

The following 2 documents meet the above description.

Cross-Browser DHTML TechNote:
Code Generator for Setting CSS1 Properties from JavaScript
http://www.mozilla.org/docs/web-developer/css1technote/css1tojs.html

The Ultimate JavaScript Client Sniffer, Version 3.03:
Determining Browser Vendor, Version, and Operating System With JavaScript
http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html

In the 2nd document, the guidelines and instructions are even contradictory to what *many* documents recommend, like:

Using Web Standards in Your Web Pages
http://developer.mozilla.org/en/docs/Using_Web_Standards_in_your_Web_Pages
and
Browser Detection and Cross Browser Support
http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support
and
Browser Feature Detection
http://developer.mozilla.org/en/docs/Browser_Feature_Detection
Fixing this bug would be nice.  Did we ever end up with an intern/contractor to work on it (see comment 26)?

http://www.mozilla.org/roadmap.html is pretty painful to look at right now, as is  http://www.mozilla.org/projects/ .  Both are linked from a lot of places.  :-P


David Bosworth is also looking into this from the Mozilla Foundation side.  I'm not sure what his bugzilla account  is, I'll ask him to add himself to this bug.

mitchell
Jason, you're right that www.mozilla.org is a mess in a lot of places. I posted a proposal on how to deal with www.mozilla.org/projects in mozilla.dev.mozilla-org a few months ago[1], but didn't complete it due to political issues and conflicting interests, which made it impossible to follow this through.

If you give me a free rein on this, I can certainly accomplish the cleanup of www.mozilla.org/projects itself and the related cleanup work (cvs removing all the obsolete or completely outdated project pages) in a few weeks.

But without backup from MoFo/MoCo I won't work on this.

[1]http://groups.google.com/group/mozilla.dev.mozilla-org/browse_frm/thread/6f57629383cab883
I think what we probably really need is
1) a real vision what www.m.o actually is for and what is actually should contain, and
2) a module owner for www.m.o who stands behind that vision and happily will review all changes that leads towards that vision.
I agree with comment 31.

But of course these important tasks need not block incremental improvement to the site, right?  I think Simon should be encouraged to proceed, not with "free rein" but with the understanding that we don't expect or require perfection.

Simon, no one can guarantee that editing the projects page won't make you a lightning rod for controversy.  Quite the contrary.  At the same time, I don't think anyone in that thread really intended to discourage you.  Whether you want to take baby steps and avoid controversy or "Wikipedia:Be Bold" and brush off complaints with "you're right, feel free to go fix that yourself", I am sure you can improve the site.  Without getting your access revoked or being torn to pieces by fierce animals.

I hope you will (and I hope I'm right).  But as I have no authority regarding mozilla.org, if you feel you must wait for a green light, this isn't it.

Simon, if you want I will review your changes. I was appointed to website-drivers when www.mozilla.org was our only website, so that gives me some justification for assuming this role. If I give r+ and someone objects to your changes, they'll have to take it up with me.

KaiRo - I'm willing to take on the role of reviewing changes (assuming staff@ or the MF Board or whoever's in charge here doesn't object) but I don't have time to do much actual work. I have website CVS access, including front page access, so I can check things in for people who don't.
I've read through all of the comments in this bug and it seems like there is general agreement about what needs to be done (although some of the specifics are up for debate).  If we are going to come up with a plan for www.mozilla.org, I think these are the high-level action items:

- Establish Identity
- Archive Obsolete Pages
- Migrate Content
- Reorganize Structure
- Select Owners

I'm happy to help move things forward and it sounds like there are some others who are also interested (Simon, Sheppy...).  It might make sense for a small group of interested people to set up an area on the wiki where we can work on a plan and then we can report back to this bug and then get started on updating the site.

I don't want to block any incremental improvement, but putting a basic high-level plan in place could help us make sure that we're all working toward the same goal.
My main interest here is in seeing the developer material properly migrated to MDC where it belongs.  It's been taking a long time to get that done, but needs to be.
I like the idea of pursuing both incremental improvements and updated content
as well as a big picture plan.  Either would be a big step forward; both would
be awesome.  Let me know if I can help (though I'm not volunteering to be part
of the working group; that would mostly serve to slow things down).

mitchell
From talking to documentation contributors on two projects (rdf and l10n), I find three competing lines of thought:

- that's old bitrotten cruft, let's remove it
- we need that documentation to unbitrot it or to resurrect the project
- please don't purge my contribution to the mozilla project from the world

I probably ignored a few others, but it seemed to boil down to this.

As an example, http://www.mozilla.org/projects/l10n/mlp_status.html links to builds such as 1.8alpha4 or 1.3, or even 0.9. Not that we want anybody to use those builds, yet, if someone would want to contribute a firefox localization in that language, he or she could still reuse quite a bit of that work.

I like David's proposal of archiving stuff, that might be a good idea, in particular once the identity is clear. We're using wikimo for most of what mozilla.org/projects used to be, including Firefox pre-release planning and documenation or l10n.
I could live with obsoleting projects/ completely, both for l10n and rdf. Other folks from mlp-staff may disagree on the l10n part. I'd rebrand the archive version just to get the least amount of work in moving it out.

As for the communication, I don't think that a thread in m.d.mozilla-org is sufficient, this should go through .planning to actually get buy-in from project owners.
I don't buy a "let's unbitrot some stuff and resurrect it"-strategy on 99% of all outdated content on www.mozilla.org

Most of the outdated stuff there has been rottening there for years and since nobody has taken any steps on resurrecting most of the outdated stuff, I don't think that people will suddenly step up and do it now that stuff is even more rotten than it was 2 years ago.

As for archival, that's why the cvs attic exists IMO. Anybody can resurrect stuff there if he wants to.

Last of all, my posting to md.mozilla-org wasn't meant as a project-wide communication to everyone involved. It was meant as a first step in that direction. Nothing more.
I agree; if something's bitrotted, it's pretty unlikely anyone is going to bother to fix it now.
Just because something hasn't been modified for a while doesn't mean it's not useful.

As a user, I hate it when a page that I have bookmarked and use occasionally disappears.

That pages are no longer useful is a judgment call that needs to be made by people who know something about their content, not something that you can presume from lack of recent modification.
Your definition of "bitrot" differs from mine.  To me, it means that a document has remained unchanged despite changes in the described technology, resulting in the document being wrong or obsolete.

If it's just old, there's certainly no reason to throw it away, as long as it's still factually correct.
comment 40 was a response primarily to comment 38, which seemed to imply that old == bitrotted.

That said, I also disagree that errors in a document due to underlying changes in the technology mean that the document is inherently obsolete.  For example, it's useful to have design documents explaining why parts of Mozilla were designed the way they were -- they explain the rationale for many of the old decisions, which is useful to know -- even if some parts of the design have since been changed.

I'm also not all that happy with the feeling that I'm going to need to expend a good bit of energy fighting for every document that I think is worth keeping around.
Well, that would be why we should keep a place where people can go to read archival documents.  But they need to be kept out of the main flow of information if they're not up-to-date, because it will only serve to confuse readers if they're looking for current, correct information.
I guess I fundamentally disagree there.  Understanding why something is designed the way it is is some of the most important documentation we have.  It's easy to get so caught up in the disadvantages of a current design that we forget about the advantages and redesign them away.  I don't think that should be out of the main flow of documentation.
This is where the audience has to be kept in mind.  Keeping old documents somewhere that regular users are going to find them doesn't strike me as a good idea. If the documents are helpful to developers and the like then maybe they should be in an archive section of MDC. Not something hidden that doesn't turn up in search, but something that denotes that the documents are old and should only be used for reference.

That said, I'm not sure how many people would read an old document and be able to determine the decision path from it.  Given, I don't know how the documents you're talking about are structured, but if they come right out and say "we made this decision because of x" then that's definitely something migratable.  If the explanations are relevant to developing those tools/sections today then some sort of history should be included in, or near, the current documents.
That sounds great on paper, but the problem with that notion is that 95% or more of our readers aren't looking for the history of Mozilla development.  Nor are they actively involved in the development of the project.  They're extension developers and web site developers looking for the quickest way to get their work done.  They don't care about the history of why things are the way they are, and we need to keep that in mind as we organize the material.
How is a design document for the style system or XPCOM relevant for users to begin with?  A lot of the content on www.mozilla.org is developer content; that doesn't mean it should be deleted.
I'm talking about actual documentation, rather than design documents. Design documents don't belong on MDC; it's only the MDC-targeted content I'm interested in.  MDC is for reference and conceptual documents.  Design documents belong somewhere else, and they're outside the scope of what I deal with.
Documents that now exist for historical reasons shouldn't be moved to MDC: things move to MDC so they can get updated. We could deal with historical documents by just adding "Historical Document, May Be Wildely Inaccurate, Use At Your Own Risk", not linking to them prominently, and leaving them alone. They do need to be accessible somehow, and that somehow can be a "List of Historical Documents" organized by project.

Eric, the scope of this bug, and thus this discussion, is all of www.mozilla.org. Much of it /is/ actual documentation, it just may not be MDC-worthy content. It therefore may be out of scope of /your/ interests, but it is not out-of-scope for this bug and this discussion.
Well, yes, obviously it's not out of the scope of this discussion; I was simply clarifying my previous comments -- trying to point out that my opinion on bitrot only applies to documents that are targeted toward the general developer population, since my comments were misinterpreted previously.  Obviously I did a bad job of making that clarification.
I agree that we don't want to end up debating about what to do with every page (keep it, update it, migrate it or archive it).  I think this question seems so difficult to resolve now though because there isn't a clear vision for the site.

If we decide that the function of www.mozilla.org is to serve as an entry point for the whole of the Mozilla community, that would lead to a different outcome for a given page than if we decide the site should exist to provide the context for the rest of the community.

To take an example, what should we do with a page like 'Mozilla Turns 1'?

http://www.mozilla.org/birthday.html

This page obviously provides a lot of useful background information about how Mozilla got where it is, but it doesn't do anything to help people find information that will help them deal with issues related to any of the current Mozilla projects.

If the site's role is to provide an entry point for the rest of the community, then I think it makes sense to archive that page.  Archiving the page wouldn't hurt anyone who wasn't interested in the history of the community and archiving would make this page much easier for people to find who are interested (by creating an archive section or archive site instead of keeping these pages buried on www.mozilla.org).
As I've said in previous discussions about www.mozilla.org (apparently not on this bug, though), I think it's important to separate the following two questions:

 1) What should http://www.mozilla.org/ and the pages prominently featured on it be focused on ?

 2) What should we do with all the content already at URLs that begin with http://www.mozilla.org/... ?

I think the two questions are largely independent.  Having a clear mission for what you get when you go to http://www.mozilla.org/ doesn't mean we need to change the URLs of all the other content that lives on the site.

I'm not sure what "archive a page" means -- but I'm ok with it as long as it means that:
 a) there are redirects so URLs don't break, and
 b) we can still edit the pages at least as easily (if not more)
 c) we can still redirect the archived URLs to pages on 
    developer.mozilla.org or wiki.mozilla.org if we choose to migrate
    them
That said, I'm not sure what the point of such archival would be.
> If we decide that the function of www.mozilla.org is to serve as an entry
> point for the whole of the Mozilla community, that would lead to a different
> outcome for a given page than if we decide the site should exist to provide
> the context for the rest of the community.

It should do both.

> To take an example, what should we do with a page like 'Mozilla Turns 1'?

https://bugzilla.mozilla.org/attachment.cgi?id=205396

> there isn't a clear vision for the site.

See comment 19. Is there anything there we need to further clarify?
I don't recall this bug being discussed in the newsgroups. Given the amount of comments lately, do you think we should start a thread in one of the newsgroups about this bug? mozilla.dev.mozilla-org and mozilla.dev.planning?
I think that would be a great idea, Chris. Would you post a summary of the discussion so far?
I don't think I have a good enough grasp of the entire discussion. Sorry. :-)
Those posts do a good job of summarizing the discussions about what www.mozilla.org should become and what to do with all the docs on www.mozilla.org that don't support that vision.  I think there's a third discussion happening though about who will own the tasks involved with implementing the vision.

I've set up a wiki page as a place to create a plan based on these discussions and to identify owners for each of the action items.  Feel free to add new items, edit existing ones, or suggest owners for each section.

http://wiki.mozilla.org/Mozilla.org:Planning
I've spun off bug 393447 for a specific discussion of http://www.mozilla.org/projects
Blocks: 393447
It looks like the discussion in mozilla.dev.mozilla-org about archiving has reached a consensus.  Two weeks ago an archiving plan was posted based on discussion in the thread and no one has objected to it.  To move things forward with this process, I've updated the Mozilla.org:Planning page on the wiki and opened a bug to set up a snapshot of the site.

http://wiki.mozilla.org/Mozilla.org:Planning

Create snapshot of www.mozilla.org to post as archive.mozilla.org
https://bugzilla.mozilla.org/show_bug.cgi?id=395669

If there are any comments or suggestions about this, feel free to post in

http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/2c2079dc764fa8e2/0fd4ff627edad777
> http://wiki.mozilla.org/Mozilla.org:Planning
Re: "Archive Obsolete Pages". Do we have to wait for the archive site to be created before starting with action #2 (create a list of pages and discuss whether they can be deleted)?

It's just not clear how long the wait for archive.moz.org will be and there are people who'd like to clean up the technical docs in the foreseeable future.

There's also no clear process defined which will be used to delete the pages. In fact, the only process we have for moz.org documentation is migrating it over to MDC, which sometimes leads to useless content getting migrated instead of deleted. A process we could follow to delete clearly useless pages would simplify things a lot.

You are right that we don't need to wait until an archive site is up before we start posting a list of candidate pages to archive.  However, we do need to wait until the vision discussion has reached a conclusion before figuring out what to archive.

As far as a process goes, the process for dealing with documentation that has been migrated will probably be different than the process for dealing with archived pages.  I can't speak to the migration process, but I think the archiving process is fairly straightforward (there will be a page on the wiki of candidate pages to archive, we'll have a period of discussion, after that time those files will be removed from CVS and a redirect set up to the archive site). 
I'm going to renew my suggestion that we should archive the entire mozilla.org site, nuke everything, and start over.  We can then either put stuff back where it was or migrate it to MDC.  It's clean, it's easier on everyone (IMHO), and is the most likely way to guarantee we do a proper job of it.
(In reply to comment #62)
> However, we do need to wait until the vision discussion has reached a
> conclusion before figuring out what to archive.
> 
That's right. Hasn't it reached a conclusion though? You said in comment 60 that it has, or did I misunderstand you?

> [..] but I think the
> archiving process is fairly straightforward (there will be a page on the wiki
> of candidate pages to archive, we'll have a period of discussion, after that
> time those files will be removed from CVS and a redirect set up to the archive
> site). 
> 
Well, OK, but 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.

> That's right. Hasn't it reached a conclusion though? You said in comment 60
> that it has, or did I misunderstand you?

I apologize for any confusion.  The archiving discussion had reached a conclusion, but AFAICT the separate discussion about the vision for mozilla.org has not reach a conclusion.  The links to both threads are in comment #57.

As for adding more detail to the archiving process, I'll update the planning page on the wiki to flesh things out some more.
Sorry, didn't realize you were talking about the other discussion. I don't think that one needs to be completed though, before we start killing/archiving old technical documents, since technical documentation should either be migrated to MDC or deleted.

> As for adding more detail to the archiving process, I'll update the planning
> page on the wiki to flesh things out some more.

Thanks a lot!

Re comment #63: I'm not opposed to adding relevant content back to an empty site versus removing irrelevant content from the existing site, but won't we still need to evaluate and deal with each page on the site with either process?

Re comment #66: If you (or anyone) would like to suggest some pages that you think should be archived, please add the link to the new Archiving Suggestions page on the wiki:

http://wiki.mozilla.org/Mozilla.org:Archiving_Suggestions

I don't think we should remove any of this content from www.mozilla.org until the vision discussion is over and the archive site is up, but we can start compiling a list of candidate pages now.

Also, I want to avoid any confusion between the migrating and archiving efforts, so if anyone sees any potential confusion between the two let me know and we'll figure out how to update our processes.
(In reply to comment #67)
> Re comment #63: I'm not opposed to adding relevant content back to an empty
> site versus removing irrelevant content from the existing site, but won't we
> still need to evaluate and deal with each page on the site with either process?
> 

There are going to be some pages that everyone will agree on where they should go, no matter what the specifics of the vision turn out to be, and by taking them all down and adding them back as you guys figure out more of what should be up you can also see what pages people are still looking for.  That could be useful to help shape the "vision."
Based on recent discussions among several people who have commented on this bug previously, we suggest that www.mozilla.org's new role should be as a community portal and as a place to host official content.  I understand that there are some concerns that the word 'official' is too vague, but we feel that it is clear enough to give us a direction to work with.  For more information about this, please feel free to review the meeting notes at

http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/43a9e855115c3bde#
http://groups.google.com/group/mozilla.dev.mozilla-org/browse_thread/thread/704b78dbf09fb0de/6415057949877fff#6415057949877fff

In the interest of moving things forward with the site, I'm closing this bug.  If there are any objections to this, feel free to comment.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Hello all,

IMO, the following webpages/documents are outdated, clearly obsolete, unreliable (in some cases, clearly incorrect) and should be document-graveyarded or archived:

Cross-Browser DHTML TechNote:
Code Generator for Setting CSS1 Properties from JavaScript
http://www.mozilla.org/docs/web-developer/css1technote/css1tojs.html

The Ultimate JavaScript Client Sniffer, Version 3.03:
Determining Browser Vendor, Version, and Operating System With JavaScript
http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html

All CodeStock'99 webpages:
http://www.mozilla.org/docs/codestock99/
This is bug 350534

Links leading to such webpages should be removed as well.

My 2 cents.
Gérard, thanks for the suggestions about outdated content.  I'd recommend that you add those links to the following wiki page:

http://wiki.mozilla.org/Mozilla.org:Archiving_Suggestions
David,

I followed your recommendation and added those links to the Archiving_Suggestions Mozilla wiki page. Thank you !
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
As I reopen this old thread. This is either not fixed, or it's broken again. 

The mozilla.org domain is still a terrible mess. 
At least in the area of login and pw. 

I have a username/pw that works for bugzilla.mozilla.org. 
I have a username/pw that works for forums.mozillazine.org
I should have the same username/pw for mozilla.org, but it doesn't work. 
I try the pw reset, but no email is ever received.  

The site says:
Password Reset

We've sent an email to any account using this address. Please follow the link in the email to reset your password.

It's not entirely clear whether the email I was using for that is actually in the database or not. There is no way to find out. 

It's not clear that registration on any other mozilla.org site constitutes registration at support.mozilla.org. 

This is a huge mess.  This should all be resolved in favor of usability.  Set up RADIUS so authentication can be integrated, something like that.
* forums.mozillazine.org is not owned by Mozilla. More info: <http://www.mozillazine.org/about/>.

* This bug is about WWW.mozilla.org, not BUGZILLA.mozilla.org

* The purpose of this bug was to redefine the purpose of www.mozilla.org - what content belongs on it and what content belongs on satellite sites.

* Mozilla has been working on a login system that can be used on many sites. For more info, visit <http://www.mozilla.org/en-US/persona/>
> * forums.mozillazine.org is not owned by Mozilla. More info: <http://www.mozillazine.org/about/>.
An important distinction.

>.* This bug is about WWW.mozilla.org, not BUGZILLA.mozilla.org
Not at all an important distinction today.  Sounds like the same domain to me. At least as far as login in concerned. 

I realize bugzilla likely has it's own login mechanism, but that is a side issue. Something steeped in the past.  Needs to be integrated now.  What happens when we have support.mozilla.org too? Oops, too late. 

>* The purpose of this bug was to redefine the purpose of www.mozilla.org - what content belongs on it and what content belongs on satellite sites.

If we are concerned with the purpose of the mozilla.org domain, regardless of what subdomains we are discussing, the ability to login is important.  

With as fragmented and illogical as it is right now, someone somehow has to fix something.  

Leaving it as is, with no ability to assign logins to mozilla.org, well, might as well take the domain down if no one can login.  

What possible good can there be having different logins for www.mozilla.org, bugzilla.mozilla.org, support.mozilla.org, and maybe others?  That is just insane. 

It's sure not fixed. Maybe the original purpose of this bug was resolved years ago (I dispute that), but we do have this problem to deal with today, and it's not going away.
You need to log in before you can comment on or make changes to this bug.