fantasai wrote:
>
> Matthew Thomas wrote:
>...
> | - newsgroup summaries
> | o modelled on `Kernel Cousins' <http://kt.linuxcare.com/>
> | o could eventually replace the status updates, encouraging
> | developers to post interesting status in the newsgroups for
> | discussion (rather than saying `here's what I did this week')
>
> Sort of like Newsbot..
Yes, except that it would work. (Notice how nobody uses Newsbot any
more.)
>...
> 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/>).
> 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.
> | * 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').
> | - 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.
> /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).
>...
> | * 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).
>...
> | * 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.
>...
> | - advocacy guides
>
> ?
<http://www.datasync.com/~rogerspl/Advocacy-HOWTO.html>
>...
> 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).
>...
> Where do community-related things go?
> - newsgroups/mailing lists
Generally, under the Get Involved section. Specifically, under the
relevant Developer (or Support) sections.
> - 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.
>...
> | - don't include meaningless stuff like `.html', `.php3', or
> | `www.' in links
>
> There shouldn't be any file extensions /at all/.
> Nice side effect: documents can become directories in the future.
Exactly right.
--
Matthew `mpt' Thomas, Mozilla user interface QA
