Ian Hickson wrote:
>
> > | |--evang/ - Evangelism guides
>
> Avoid unnecessary abbreviations in URIs, this should be evangelism/.
ok. Should /dev also be expanded?
> > /about/community
>
> 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.
The community page describes the mozilla community and
where to find it. The page /is/ not the community nor
it's meeting place--it only describes it. So, it is
fairly static.
My argument goes like this:
Assuming the community is part of the mozilla organization,
by describing the community it describes the mozilla
organization. It is -about- the mozilla organization and
thus belongs under /about.
Pages catering to individual projects will go in their
respective development directories, and links to specific
groups can appear anywhere.
> > | |--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.
Contributing to mozilla doesn't necessarily mean hacking,
so perhaps it should be /hacking/mozilla?
> > | | |--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/).
It's called write-access because the text applies whether
or not we're using CVS. It's not under contribute/ because
it does not apply to QA, writing, or anything besides
hacking. Even if it did, the requirements for write access
would be different for each one.
> Should qa/ be under contribute/mozilla/ ? That depends
> on how much detail we put in there.
I think it's fine under /contribute. If some docs go into
too much detail, they can split off under qa/. Most of the
stuff in Quality Assurance is not mozilla-specific, but
does apply to Mozilla--so Mozilla-specific qa documentation
should go under /contribute/qa to pick that info up.
The hierarchy should look like this:
Least specific
|
|--more specific, but least-specific stuff still applies
> > |--dev/ - all development-related information
> > | |
> > | |--_?_/ - Mozilla developers' stuff
>
> ?
Mozilla development project directories go under /dev
somewhere. (That would be most of the stuff linked from
http://mozilla.org/projects right now.) Exactly where and
under what categorization remains to be determined.
(Bugzilla development docs also go here, etc.)
> > |--software/ - list of software released by mozilla.org
> > w/ description
>
> 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?)
Project documentation--developers' documentation--go under
the appropriate directory in /dev.
/software is for all the software released by mozilla.org
It provides one place for the visitor to see everything we
offer.
This is where you get download and installation instructions
(including build instructions). This is where we put all the
advertising hype--developers know the software's features well
enough and don't need filter through that. This is where we
archive releases and their relnotes--developers are working on
the bleeding edge and don't need that info.
Everything in /software is targeted at people who come here to
get the software. They don't have to filter through developers'
news, technical notes, freeze dates, or any information on how
it works or what the lead team is prioritizing right now.
Mozilla distributions are linked from /software/mozilla; so
are skins. Langpack releases also appear here, and any other
paraphernalia that goes with the software. Everything's in one
place, and because developers' docs are in /dev, content can
be written around the "customer"--and potential contributor--
"don't forget to report any bugs", "Help us port Mozilla to
BeOS!" etc.
Here's a response to Gervase I wrote back in December:
| > But why do you think the distinction between software-in-development and
| > software-that's-released is so big as to split the two parts apart? Why
| > can't they live together?
|
| - They are aimed at different audiences.
| - Their purposes are completely different.
| - They don't follow the same time-table.
| - Releases don't always correspond with major changes in code that
| require documentation changes or additions; they come out after
| many minor changes, also.
| - Major changes to the code don't immediately trigger new releases;
| the code must be tested and stabilized first.
| - Software-that's-released is static. Software-in-development is dynamic.
|
| As I see it, if you were to create a table of all the project-related docs,
| you would get something like this:
|
| || Development Docs || Use Docs (not "User") |
| ||overview|documentation|project-org||overview|relnotes|build-instruc|
| -------||----------------------------------||-------------------------------|
| project||what is |how does it |community/ ||what's |(self- |how to get it|
| name || it? | work? |involvment || it do? |explain)| |
|
| You want the split along each row, then by columns
| I want it along the column groups, then by rows, then by columns.
-- http://groups.google.com/groups?selm=3A4289DD.9928B082%40escape.com
