Re: initial structure ideas

[Ryan Muldoon <rpmuldoon students wisc edu>]

> 
> On Sun, 19 Nov 2000 18:47:00 Ross Golder wrote:
> > Steve Theodorou wrote:
> > > 
> > > I think we need to look at putting the initial structure outline in a
> > format that
> > > will allow all of us to contribute to it. It would be nice to have
> > something we
> > > could revise from one central location. :)
> > > 
> > 
> > Perhaps, if we represent it in some kind of pseudo high-level XML, then
> > we could use it as a basis for other artefacts (e.g. sitemap), break it
> > down further, and establish a common vocubulary for further discussion.
> >
> 
> why not use dia to model the structure? as it uses xml it would be easy to
> have a centeral file that could be checked out using cvs and improvements
> could be sent as patches.
> 
> also as dia has support for uml it would be easy to model the backend in
> uml and show how it interacts with the ui.
> 
> but before structure is considered don't we need clear aims and objectives?

I am thinking that we're taking this a little too far........I don't think that
we need to develop an XML DTD to just plan out some initial structure.  
UML doesn't really help us out more either. How is plain text not a common 
format that we can all contribute to?  Sure, it isn't buzzword compliant, but it
works. ;-)  No special tools needed to write it or read it either.  

I think that we should keep simple things simple, and not make sub-projects for
everything.  I proposed the structure to present a few ideas on how to organize
content into directories (and subdomains).  I think that discussion should focus
on the content, not the format.


As for clear aims and objectives, I think that they are reasonably implicit in
the project.

1. Improve structure for the gnome/gtk sites
2. Improve look/feel for these sites
3. Improve localization of the sites
4. Improve the sites' usability
5. Improve the content of the gnome/gtk sites
6. Keep the sites "fresher" with more regular maintenence

Maybe I'm simplifying things a bit, but that may be a good idea.  It is better
to solve small problems efficiently than to work on elaborate, lengthy solutions
to big problems.


    --Ryan