Ian Hickson wrote:
>...
> > mozilla.org/
> > |
> > |--about/ - about mozilla.org
> > | | http://mozilla.org/mozorg.html
> > | |
> > | |--community/ - newsgroups, IRC, mailing lists
> > | | http://mozilla.org/community.html
>
> I think community/ should be its own top level directory, emphasising
> its importance. Encouraging community involvement is one of the main
> things missing on www.mozilla.org right now.
That's what /contribute/ is for.
> The community/ section
> should explain how to join mailing lists and IRC,
/contribute/discuss/
IMO each group should have its own page, with a description of the
group, links for subscribing/unsubscribing from the newsgroup and from
the mailing list, and links to archives at Google Groups and Geocrawler.
Then those pages can be linked to from /contribute/discuss/, and from
the relevant sections (e.g. /develop/web/ can link to
/contribute/discuss/mozilla.web-developer/).
>...
> Also colophon/, explaining how the site itself was created.
/about/site/ would perhaps be more obvious than /about/colophon/. (There
could be some interesting links between /about/site/ and
/develop/web/, if the mozilla.org site itself is used to show off things
such as alternate style sheets.)
>...
> > | |--evang/ - Evangelism guides
>
> Avoid unnecessary abbreviations in URIs, this should be evangelism/.
Same goes for /develop/.
> > | |--hacking/ - general rules and guidelines for hacking
> > | | | Mozilla code
> > | | | http://mozilla.org/hacking/nutshell.html
>
> That should be mozilla/ instead of hacking/, since it is specific to
> one of mozilla.org's many projects. Bugzilla, for instance, has
> different checkin guidlines, different coding standards, different
> reviewers guides.
Then /contribute/hacking/ can link to the specific instructions for
those products which have different rules, products which make up a
small minority of the total hacking that is overseen by the Mozilla Organization.
>...
> > | | |--write-access/ - getting CVS access
>...
> > | | | |--cvs-form/ - CVS access form
>
> write-access/ should probably be called cvs/ and be one level higher
> (i.e., under contribute/ instead of contribute/mozilla/).
I agree about the renaming, but (and I hesitate to ask a rhetorical
question, for fear of getting an answer) why would you want to use CVS
if not to hack on the code? (Remember that the Web site will no longer
be using CVS.:-)
/contribute/hacking/cvs/
/contribute/hacking/cvs/diffs/
/contribute/hacking/cvs/write/
/contribute/hacking/cvs/write/application/
/contribute/hacking/cvs/mac/
/contribute/hacking/cvs/win32/
>...
> Should qa/ be under contribute/mozilla/ ? That depends on how much
> detail we put in there.
I think most information about filing bugs, finding duplicates, etc is
relevant no matter whether it's Mozilla, Bugzilla, or whatever else
you're doing QA for.
>...
> > |--dev/ - all development-related information
>...
> > |--software/ - list of software released by mozilla.org w/
>...
> > | |--mozilla/ - intro & description for all of Mozilla
> > | | |
> > | | |--build/ - build instructions
> > | | | | http://mozilla.org/build/
> > | | | |--beos/
> > | | | |
> > | | | |--mac/
>...
> Is this redundant with contrinute/mozilla/ ? Or are they subtly
> different? (The hacking guidelines for each project should probably
> point to any relevant documents in the project documentation, which is
> basically what this is, right?)
The build instructions for compiling Mozilla 0.8
(/software/mozilla/0.8/build/) will never change. The build instructions
for compiling from current CVS (/contribute/hacking/mozilla/build/ or
whatever) may not change very often, but they will change more often
than never. As each release is branched, a snapshot of the build
instructions as they are at that time should be placed in the /software/
directory for that version.
>...
> > |--support/ - links to product-specific info under
> > /software/product
>
> Redundant?
This is for directing those who come to mozilla.org looking for a
spell-checker for Mozilla, or wanting to know how to install Mozilla and
Netscape 6.1 in peaceful coexistence, or trying to get help with a
Bugzilla configuration problem, or whatever, to the appropriate
newsgroups (i.e. not developer groups), IRC channels, and distributors.
> > Key URLs from the old site, such as /MPL and /releases, will
> > be handled by redirects.
>
> Why only key redirects? Think about search engines, bookmarks, URIs in
> random documents on the web, etc. I think it would not be that hard to
> redirect the overwhelming majority of links.
>...
I agree. Even where there isn't a direct or even a close equivalent in
the new site to a particular page on the old site, we should really be
returning a 410 error instead of a 404. :-)
--
Matthew `mpt' Thomas, Mozilla UI Design component default assignee thing
<http://mozilla.org/>
