Matthew Thomas wrote:
|
| fantasai wrote:
| >...
| > Events are highly date-oriented. Now, explain to me what,
| > specifically, is wrong with
| > http://mozilla.org/events/1999/mozilla.party/
|
| Nothing.
....
| >...
| > As for my question, it was intended to ask "What is so
| > objectionable about allowing any mozilla-sanctioned concerted
| > effort to obtain its own directory to facilitate coordination
| > of its members?"
|
| Nothing. But calling such directories `projects' should be avoided, if
| there is a term to describe them which is more meaningful to a visitor
| to the site than `projects' is.
I can't think of any replacements, and the only synonyms I found
were worse, not better.
"project" has a nice definition itself, though, and I think it
carries all the necessary connotations. Denotations for the noun
include "An undertaking requiring concerted effort" and "A plan
or proposal", exact definitions varying by dictionary.
I think it adequately describes the category. Have you other
suggestions?
| >...
| > | > | The ones I posted were just examples. Most of the documents
| > | > | currently linked to from <http://mozilla.org/docs/> (from the
| > | > | `Core Mozilla architecture' section onwards) would end up in
| > | > | the `Developer' > `Mozilla Developer' section.
| > | >
| > | > These all go at that level?
| > |
| > | No.
| >
| > Then why didn't you say so? I can't read your mind, Matthew.
|
| I did say so. See the sentence beginning `Most of the documents ...',
| paying particular attention to the word `most' at the start of that sentence.
Almost none. /Mostly/, they're in subsections of Mozilla Developer.
But, anyway..
| If you want a full list of where *every* document linked from that page
| would go, just ask. (Otherwise I'll assume that spending the time to
| post such a list now would just bore everyone to tears.)
I just wanted an idea of how Mozilla Developer is organized; you
gave me the impression that everything would be at the same level
until I read those examples.
We will have to get up a complete list at some point, and
quite frankly, I think you'd do a better job than I would.
Although I'll still /try/.
| >...
| > | > Which specific pages under QA would go under Get Involved?
| > | > Those asking for help? Those aimed at beginners? Those aimed
| > | > at people beginning to become advanced?
| > |
| > | All of the above.
| >
| > The Verification guidelines are aimed both at advanced and
| > beginning-to-become-advanced.
|
| The only `verification guidelines' I can find on mozilla.org are
| <http://mozilla.org/quality/mailnews/mail-bug-verification.html> (which
| is in a mailnews/ hierarchy despite having nothing in particular to do
| with mail/news). Is this the document you are referring to? It seems
| mainly aimed at beginner-to-intermediate QA volunteers, and is not a
| document you would need to return to again and again.
Sorry; should've posted a link.
http://www.mozilla.org/quality/bug-verification-guidelines.html
I hope you didn't spend too much time looking for it.
| >...
| > | Because the former is a one-time thing (once you have built Mozilla
| > | once, any problems you have building it later are likely to be too
| > | esoteric to be in the build instructions), but the latter is a
| > | reference which you may need to refresh yourself on every few
| > | months (or when you break the tree).
| >
| > Thus the new contributor is sent scampering across top-level
| > hierarchies to read up on contributing docs and general
| > contribution guidelines.
|
| Better that than that they can't find what they want at all.
|
| > I'd like to suggest coherence as a quality of good categorization.
|
| Although they are nominally organised into a hierarchical
| management structure,this does not constrain the way people will
| communicate, and share information, equipment and software
| across groups ... The actual observed working structure of the
| organisation is a multiply connected "web" whose
| interconnections evolve with time.
|
| -- <http://www.w3.org/History/1989/proposal.html>
|
| In other words, Don't Panic. This isn't a gopher site we're designing
| here, it's a Web site. Links between sections *are* allowed.
Sure. But related information should be under the same directory;
if you're minimizing cross-top-level links, you've probably got a
better organization.
| >...
| > If you look at the pages linked from the main NGLayout index,
| > you can split them up into those documenting the layout engine--
| > those detailing how it does what it does--and those explaining
| > about the NGLayout project--e.g. its purpose, the people involved,
| > how to get involved, what needs to be done, how to access the
| > discussion areas, what is currently being done on the layout
| > engine, frequently asked questions, etc.
|
| Nothing wrong with that. The NGLayout section is probably one of the
| best-organized sections on the mozilla.org site at the moment.
One of the reasons I picked it. My point is, though, that
instead of splitting into Getting Involved and Everything Else,
we should split the documents into technical info and project
organization info. That serves the purpose of separating
technical docs from the "Getting Involved" stuff without
dictating which documents you read in what order and whether
you're supposed to read a document once or not.
