Matthew Thomas wrote:
| fantasai wrote:
| >...
| > Ok. All this needs to be archived under some top-level directory;
| > the second level needs to be a date stamp (year should do). The
| > structure can go under that, as it might change from year to year.
|
| Yes. A typical URL might be
| <http://mozilla.org/news/2000/04/>, which would have links to all the
| news items for April 2000. Most (but not all) of these `news items'
| would be pointers to recently-updated documents elsewhere on the site,
| in sections that would have their own datestamp (e.g.
| <http://mozilla.org/events/mozilla.party/1999/>), but some would be
| articles in the News hierarchy itself (e.g.
| <http://mozilla.org/news/2006/07/fantasai.interview/>).
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/.
Is http://mozilla.org/news/1999/events/mozilla.party/ acceptable?
Also, is there a reason why you chose numbers as opposed to
names for the months?
Where would you put general articles--that is, informational
articles that aren't particularly dated? (Something like a
National Geographic article, which is not news yet relevant to
the time though not any particular date.) Under the release date?
| > Latest stuff can go without a date.
|
| No. URLs should be designed to be persistent, otherwise you will suffer
| linkrot <http://www.useit.com/alertbox/980614.html>. This means that if
| datestamps are ever going to be used for documents, then that includes
| the latest stuff.
Gotcha.
| > | * developer info
| > | - Mozilla development
| > | o code architecture overviews
| > | o ports
| > | o accessibility
| > | o usability
| > | o internationalization
| > | o localizations
| > | o good coding style
| >
| > Ports and code architecture overviews don't seem
| > to fit here. They're software-specific--everything
| > else seems to be overall guidelines.
|
| Not just guidelines, but all documents relating to these aspects of the
| development of Mozilla (what some people are referring to as
| `projects').
So, what do you refer to as 'projects'? It needs to be there,
as a coordinating point for each specific aspect of Mozilla.
And what, consequently, from the 'projects' directory, would
you put under general Mozilla development?
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.
| > | - application development
| > | o XP Toolkit
| > | o XUL reference
| > | o embedding
| >
| > Who are these documents aimed at?
| > - Mozilla developers
| > - outside developers using Mozilla code
| > - both
|
| Both. (Whereas the documents in the `Mozilla development' section are
| mainly of interest to Mozilla developers.)
|
| > | - Web development
| > | o supported standards
| > | o articles on cool ways to use the standards
| >
| > This should probably be top-level; it definately
| > doesn't go under Mozilla development.
|
| It's not under Mozilla development, it's under `Developer'. Something
| like a Mozilla standards compliance status update will be of interest to
| Mozilla developers, application developers, and Web developers alike, so
| it would be splashed at the second-level `Developer' section; whereas
| other items would be of interest only to one particular class of
| developers, and would appear in their third-level pages.
Ok, I see what you're doing here--misinterpreted your use of "developer".
|
| > /web?
| > It's very browser-centric. What about mail-news?
| > NNTP is an Internet Protocol--not a Web one, but
| > it's still supported--by mail-news, not by Bugzilla.
| > This needs to be worked out more.
|
| Well, if there are ways for developers to use NNTP, SMTP, IMAP, etc
| which are interesting enough to be written about on mozilla.org, then
| maybe so. But the only thing I can think of which falls into that
| category is telling mailing list maintainers how to use the
| `Unsubscribe-To:' header (which Mozilla doesn't even support yet).
Ok
| >...
| > | * software [I agree with Fantasai that this should be a separate
| > | area]
| >
| > /software or /releases?
|
| /software. Installation instructions, feature summaries, etc would go in
| this section, not just release notes (which is what /releases implies).
All right.
1 for /software
1 for /releases
Since that's a tie, and I prefer /software, it's been changed back (for now).
Any comments from the community at large?
| > | * support
| > | - Mozilla Update (detect Mozilla version, and offer upgrades)
| > | - language packs
| > | - FAQs
| > | - links to Usenet groups and IRC channels
| >
| > These are mostly app-specific and should not be in a general
| > directory.
|
| I think it would be easier for people looking for this stuff to find it
| starting from a single place, rather than having to go into separate
| areas for each application.
Logically or physically? IMO, the documents should physically go under
their respective release directories--that includes the web address.
But a general support page can tie these up with links.
| >...
| > | - advocacy guides
| >
| > ?
|
| <http://www.datasync.com/~rogerspl/Advocacy-HOWTO.html>
--> /advocacy. Objections?
| >...
| > These are /not/ hacking docs. I can build Mozilla without intending
| > to modify the source code (as, to test something that's been
| > #ifdef-ed out on official builds).
| > Downloading and building are related--and app-specific.
| > Getting CVS access is organizational.
|
| All of them are required if you are intending to `hack' Mozilla in the
| general sense (which doesn't necessarily involve modifying the code).
I think coding style and rules for changing builds are better classified
as "hacking".
| >...
| > Where do community-related things go?
| > - newsgroups/mailing lists
|
| Generally, under the Get Involved section. Specifically, under the
| relevant Developer (or Support) sections.
Developer > Mozilla > Get Involved > Community is a bit much, I think.
Would this do?
Devloper > Mozilla > Community
|
| > - links to other mozilla-related sites
|
| dmoz.org. Listing them on mozilla.org itself would be a slippery slope.
|
| >...
| > | * breadcrumb navigation
| > What's this? ^
|
| You are here: _mozilla.org_ > _Developer_ > _Application_development_ >
| _XP_Toolkit_ > _XUL_Reference_ > tabbox
|
| A breadcrumb trail of links leading from the front page to where you are
| now.
Ah, yes. Thanks.
