On Mon, 2006-10-23 at 09:34 +1000, Jeff Waugh wrote:
I have to send the "fighting subdomain disease" email in response to this.
We have several diseases to fight. One is the mess of subdomains and domains. Another one is the lack of consistency and general structure across subsites. We try to fight this diseases by mapping everything at http://live.gnome.org/GnomeWeb/GnomeSubsites and providing a sensible structure through the General navigation shared by all the official subsites. The suggested subdomains are intended to be a first cure to be implemented in 2.18. They are directly related to the new wgo scope, use cases and site structure. You say this will create more mess. I don't think so. In order to fix the mess we need a solid anchor and this is the revamped wgo. We can't go through the rest of messy subsites, if we ever do that it will take us years. The General nav bar and these new microsites provide the bindings to sanitize the whole structure. If you have better suggestions go ahead.
What is all this stuff?
All this stuff was suggested at http://live.gnome.org/GnomeWeb/Navigation and this list at the end of August, approved in September following our timeline and included in the 2.16.1 GnomeWeb planning document released few weeks ago. This is now the plan, since nobody objected before. Of course we can discuss the plan and implement improvements. I will answer here your general comments and I will open threads for each subsite / item in the General nav bar in order to find those improvements better.
Why does it need a subdomain?
What are the alternatives? A wgo page doesn't work: you carry the wgo look'n'feel and primary nav bar to interconnect i.e. several community subsites that are out of wgo. This is inconsistent. A good example of a nav bar full of inconsistencies is the current wgo top bar. The result is that all the subsites make their own interpretation of that bar - this is one of the factors of the current mess. A domain might provide consistency. However, at least from my point of view the domain disease is more acute than the subdomain disease. Aliasing and redirects avoid technical breakage. But we can be more flexible here, specially for 2.18. One more thing, the GnomeWeb process won't (and can't) impose any implementation not discussed with and accepted by the affected webmasters. We need to ask the projects webmasters what they think about a move to projects.gnome.org. We need to ask Luke & co about the future of gnomesupport.org vs support.gnome.org. We did ask Luke about news.gnome.org vs gnomedesktop.org. I thought (and think) that it would be better to integrate gnomedesktop.org but he thought it would be better to leave it as it is and use news.gnome.org for the planet news. He gave his reasons and we accepted. The whole GnomeWeb process is slow enough to plan it properly. But the steps done are the steps done. All we make mistakes that show up later. We can go backwards if we find new showstoppers. From the last emails we can take some improvements, but I still haven't found any reason to stop the current plan. And now let's discuss the subdomains. -- Quim Gil /// http://desdeamericaconamor.org | http://pinguino.tv
Attachment:
signature.asc
Description: This is a digitally signed message part