Matthew Thomas wrote:
|
| fantasai wrote:
| >
| > Matthew Thomas wrote:
| > |
| > | fantasai wrote:
| > | >...
| > | > I think the structure before the date (at least before the year)
| > | > should be minimal, which isn't the case with
| > | > http://mozilla.org/events/mozilla.party/1999/.
| >...
| > Because that structure might change over the course of, say, five
| > years. For instance, one might decide to further subdivide it by
| > location:
| > http://mozilla.org/events/mozilla.party/jp/2004/
| > which doesn't follow the pattern from 1999.
|
| Or we could get really really paranoid about future compatibility, and
| have <http://mozilla.org/event?type=party&date=1999&area=jp>, so that
| the order of the arguments didn't matter ...
#_#
Events are highly date-oriented. Now, explain to me what,
specifically, is wrong with
http://mozilla.org/events/1999/mozilla.party/
|
| >...
| > | If the article was a useful part of a larger knowledge base, then
| > | it would go in its relevant section (e.g.
| > | <http://mozilla.org/developer/web/style/alternate.stylesheets/>).
| > | As I said, most items in the `News & Events' section would actually
| > | be links to new/updated documents in other sections.
| > | Otherwise, an article would go in the news/ hierarchy under its
| > | year and month hierarchies.
| >
| > Ok, but where would you put such articles that are outdated? Like,
| > an article on Russia today would be of historical, but not current,
| > significance ten years from now. So, an article on writing web pages
| > for Mozilla today--which would go under Web Developer--where can I
| > find it ten years from now?
|
| Ok, make the URL <http://mozilla.org/developer/web/style/user.choice/>,
| so it's not implementation-specific. That URL would be understood to
| mean `discussion of the state of the art in allowing users to choose
| different styles in which to present Web documents'. Meanwhile,
| <http://mozilla.org/developer/web/style/user.choice/2000/> would mean
| `discussion of how allowing users to choose different styles in which to
| present Web documents could be achieved in 2000'. Right now these two
| URLs would have the same content, but over the next few months/years
| they would gradually diverge. (This is the sort of scheme used in the
| <http://www.w3.org/TR/> hierarchy, albeit that the W3C needs to use more
| specific dates for its recommendations and drafts thereof.)
So, to put it shortly, the generic location of the article would
contain dated subdirectories to hold previous versions. ?
| >...
| > | > So, what do you refer to as 'projects'?
| > |
| > | I don't. Like I said, given enough hype, anything within Mozilla
| > | could be referred to as a `project'.
| >
| > What is your objection to that?
|
| That it's a more or less meaningless categorization.
All right. I'm sorry, I read more into your use of "thing",
limiting it with the definition of project rather than taking
the word by its own literal definition.
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?"
|
| > | It's a more or less meaningless categorization.
| >
| > I disagree. I think it's currently a meaningless categorization,
| > but that it can be a useful one in reorganization.
|
| Sure. We can use it somewhere on the site where we can't think of a
| better name for something. :-)
The word /has/ a definition, you know.
| > | >...
| > | > Also, would you post a short description of each of the Mozilla
| > | > development categories? I'm having trouble imagining what sorts
| > | > of things would go in each.
| > |
| > | 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.
|
| > http://www.mozilla.org/projects/xbl/xbl.html
|
| Developer > Application Developer > XP Toolkit > XBL > Specification > 1.0
|
| > http://www.mozilla.org/projects/xpcom/nsCOMPtr/
|
| Developer > Mozilla Developer > Technology > XPCOM > nsCOMPtr
No objections. I like "Technology".
| > http://www.mozilla.org/hacking/portable-cpp.html
|
| Developer > Mozilla Developer > Qualities > Portability > C++
| portability guide
I'm thinking, either "Qualities" includes stuff like
localizability and i18n, or Portability moves up to
their level, eliminating the category.
|
| > http://www.mozilla.org/newlayout/
|
| Developer > Mozilla Developer > Technology > NGLayout
See below.
|
| >...
| > I still think Get Involved is an awkward and ambiguous
| > categorization. Where do you draw the line between
| > "Getting Involved" and /being/ involved?
|
| Probably a good rule of thumb would be that items in the `Getting
| involved' section would be ones that you would only need to visit once,
| whereas those in the `Developer' section would be useful references to
| return to again and again.
|
| >...
| > For example, I can be involved in Mozilla layout by using
| > my bugzilla account, even if I'm not subscribed to
| > n.p.m.layout. If I later decide to subscribe to the layout
| > newsgroup, must I go to Get Involved, when I'm already
| > involved?
|
| No, because there is also a link to it from the NGLayout main page.
|
| > Or does "Get Involved" mean involved with the
| > newsgroup specifically, not the layout project?
|
| It means with the project generally.
|
| > 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.
| > Why are the instructions for building Mozilla under "Get
| > Involved" and not the guidelines for writing C++?
|
| 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.
I'd like to suggest coherence as a quality of good categorization.
| > If you're going to get -CVS access-, you must demonstrate
| > -good coding practices-.
|
| I guess the non-coders who want to fix up the Web site are doomed, then?
No, they just have to get their docs checked in by someone who
will ensure the quality of the markup.
| > I don't see why pages should be split up like this. IMO, the
| > topic and the audience are more important in categorization.
| > Pull out "Get Involved" and your hierarchies are no longer as
| > self-contained, but cross-linked far more than necessary.
|
| Alternatively, lump them all together like we do now, and you have half
| as many volunteer contributors as you would otherwise -- because those
| who are half-interested in helping out the project are wading through a
| mountain of documents about nsCOMPtrs and jar packaging.
Or, alternatively, you can split documents into project
(organization) pages and product (tech) documentation pages.
Making an example of NGLayout: http://www.mozilla.org/newlayout/
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.
