On Mon, 3 Sep 2001, Gervase Markham wrote:
>
> Proposed URI Structure:
Overall looks great!
> 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. The community/ section should
explain how to join mailing lists and IRC, and should cater for whatever
projects are being worked on (e.g. Bugzilla, Mozilla, Mozbot) whereas
about/ should, by its nature, be pretty static information about the
mozilla.org organisation itself.
IMHO.
> | |
> | |--history/ - a history of mozilla.org
> | |
> | |--mission/ - mission
> | | http://mozilla.org/mission.html
> | |
> | |--people/ - who we are
> | | http://mozilla.org/about.html
> | |
> | |--sponsors/ - sponsors
> | |
> | |--credits/ - http://mozilla.org/credits.html
Also colophon/, explaining how the site itself was created.
> |
> |--contribute/ - How to get involved/contribute to Mozilla
> | | http://mozilla.org/get-involved.html
> | |
> | |--advocacy/ - Mozilla advocacy guides
> | |
> | |--evang/ - Evangelism guides
Avoid unnecessary abbreviations in URIs, this should be evangelism/.
> | |
> | |--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.
> | | |
> | | |--checkin/ - Checkin rules/process
> | | | http://www.mozilla.org/hacking/rules.html
> | | | http://www.mozilla.org/hacking/bonsai.html
> | | |
> | | |--guidelines/ - coding guidelines
> | | | http://www.mozilla.org/hacking/best-coding-practices.html
> | | |
> | | |--write-access/ - getting CVS access
> | | | | http://mozilla.org/hacking/getting-cvs-write-access.html
> | | | |
> | | | |--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/).
> | | |
> | | |--review/ -
> | | | http://mozilla.org/hacking/reviewers.html
> | | |
> | | |--guide/ - Reviewer's Guide
> | |
> | |--qa/ - overall QA stuff
> | | | http://mozilla.org/quality/
> | | |
> | | |--bugs/ - bug writing guidelines and related resources
> | | | http://mozilla.org/quality/bug-writing-guidelines.html
> | | |
> | | |--_?_/ - much of http://mozilla.org/quality/help/ (maybe a
> | | triage/ directory?)
Should qa/ be under contribute/mozilla/ ? That depends on how much detail
we put in there.
> | |
> | |--tools/ - tools for contributing
> | | | http://mozilla.org/tools.html
> | | |
> | | |--bugzilla/ - for use of Bugzilla
> | | | http://mozilla.org/bugs/
> | | |
> | | |--bonsai/ - for use of Bonsai
> | | | http://mozilla.org/bonsai.html (top half)
> | | |
> | | |--cvs/ - for use of CVS
> | | | http://mozilla.org/cvs.html
> | | |
> | | |--tinderbox/ - for use of Tinderbox
> | | | http://mozilla.org/tinderbox.html
> | | |
> | | |--zope/ - for using Zope
> | |
> | |--writing/ - document writing/coding/uploading/style guidelines
> |
> |--dev/ - all development-related information
> | |
> | |--tech/ - Mozilla technologies
> | | |
> | | |--xul/
> | | |
> | | |--js/
> | | |
> | | |--xpcom/
> | |
> | |--ports/ - Platform homepages
> | | |
> | | |--beos/
> | | |
> | | |--macosx/
> | |
> | |--_?_/ - Mozilla developers' stuff
?
> | |
> | |--web/ - Web Developer info - articles on writing pages for
> | | Mozilla, FAQ, show-off section, etc.
> | |
> | |--embed/ - info for potential embedders of Mozilla tech.
> |
> |--events/
> | |
> | |--year/ - all events for year
> | |
> | |--event_name/ - all files associated with event
> |
> |--license/ - MPL, NPL, current licensing strategy
> |
> |--software/ - list of software released by mozilla.org w/ description
> | |
> | |--mozilla/ - intro & description for all of Mozilla
> | | |
> | | |--build/ - build instructions
> | | | | http://mozilla.org/build/
> | | | |--beos/
> | | | |
> | | | |--mac/
> | | | |
> | | | |--macosx/
> | | | |
> | | | |--os2/
> | | | |
> | | | |--unix/
> | | | |
> | | | |--win32/
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?)
> | | |
> | | |--distributors/ - link to Mozilla distributors
> | | | (e.g. Netscape, Beonex)
> | | |
> | | |--releases/ - Mozilla release info (one directory per
> | | | release)
> | | | http://mozilla.org/releases/
> | | |
> | | |--0.6/ - relnotes and stuff
> | |
> | |--bugzilla/ - for using Bugzilla on your own system
> | | (subdirectory structure similar to mozilla/,
> | | above)
Also, mozbot/ - basically what's in projects/mozbot/ now.
> | |--etc.,
> |
> |
> |--news/ - news items (may be links to other parts of the site)
> | |
> | |--year/ - all news items for year
> | | |
> | | |--month/ - all news items for month (numerical - e.g. 05)
> | | |
> | | |--article/ - all files associated with the article,
> | | directory named after article title
> | |
> | |--status/
> |
> |--support/ - links to product-specific info under /software/product
Redundant?
> 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. On my own sites I regularly
look through my logs and add redirects for almost any old 404, including
typos; existing files which have moved should IMHO _always_ be redirected.
HTH,
--
Ian Hickson )\ _. - ._.) fL
/. `- ' ( `--'
`- , ) - > ) \
irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
