I promised myself I was going to stay out of the Mozilla discussion, but,
well, I can't. :^)
This thread about organization structures is pretty critical. When dealing
with a large corpus of documents, it's one of the only ways to stop the
madness and make content location logical and predictable.
However, organizing by containment is only one of the ways to get there.
Saying the everything related to "news" goes under "news" works...except
when it doesn't. For instance, what if something is about both "news" and
"gecko"?
One solution is an architecture (a la dmoz) that decouples the organization
from the location. This is done with metadata (ours is based on Dublin
Core). You then have virtual folder hierarchies that are actually metadata
queries. On the downside, this requires some buyin from authors to
participate in the system. Each of these folders can then optionally be RSS
channels for syndication.
Also, regarding the definition list...it's a fabulous idea and might be
workable.
--Paul
On 1/14/01 5:28 PM, in article [EMAIL PROTECTED], "Gervase
Markham" <[EMAIL PROTECTED]> wrote:
>> Overall Structure:
>> - about the organization
>> - news & events hierarchies
>> - software hierarchy for all software released by mozilla.org
>> - developer hierarchy subdivided into:
>> - Application development
>
> What is an application?
>
> /Checkin, /cvs-access and /review shouldn't be under /moz, because they
> apply to most/all mozilla-org hosted software.
>
> Same for instructions on use of the web tools, and the coding guidelines.
>
> "subdirectory structure mimics..." - /distributors has no meaning for any
> mozilla.org software other than Mozilla, and /ports has meaning for very
> few. Just a note :-)
>
> The news hierarchy will probably be de facto organised by whatever Zope
> add-on we use to deal with it.
>
> I reserve the right to make further comments as time goes on ;-)
>
> Remind me what goes in classic?
>
>> - Should press releases also be pulled out into /press/'year'?
>
> No. We make about one a year as it is.
>
>> Testing/Testcases:
>> - Where should testcases go?
>
> In the hacking area for the bit of software they relate to.
>
>> - Instructions for running automated tests?
>
> With the testcases.
>
> Gerv
