On Wed, 2006-07-26 at 02:39 +0200, Quim Gil wrote: > El dt 25 de 07 del 2006 a les 11:27 +0100, en/na Thomas Wood va > escriure: > As Greg requests, can the people in favor of keeping the current system > make an evaluation of the requirements, as we are doing with the new CMS > candidates? http://live.gnome.org/GnomeWeb/CmsRequirements
Actually, I'd prefer somebody who _knows_ the current system, even if he hates it :) > ... > Perhaps we could have all the news related stuff under news.gnome.org, > manage them through a CMS fully equipped with feeds features, tags and > all the marvel dynamic pages can offer to news related sites (i18n here > wouldn't be a problem since news are a one-shot work easy to track, with > no further editing/updating) > > My last but not least concern is the homepage, that shouldn't be static. > Au contraire, it should reflect everyday all the activity and life > generated in the GNOME project. But static PHP (or something) managed > with the current system could provide a vivid homepage operating with > the dynamic data spread through the GNOME subsites, isn't it. I would like to stress that the goal is not to select the content based on the CMS, but the CMS based on the content. Spinning off a news.gnome.org _just_ because it may be served by a different CMS is IMHO not the way to go. Spinning it off because it would crowd "regular" wgo content would be a valid argument. Also, static vs. dynamic serving is purely an implementation detail. The only relevant factor here is whether a dynamically served page can be churned out fast enough. Though note, many CMSs have a caching mechanism. A static page can be regenerated every few minutes (or better, on content change) just fine, and yes, a dynamic .php script can serve content that doesn't change for a year. CMSs don't make pages vivid. Authors do. > Perhaps the core reason why I think the current system is not enough is > the possibility of having a 'myGNOME' alike experience being a > registered user and getting the information and services tailored to my > interests. Olav, Anne, Journalist A, user B, ISD C etc would get > different homepages and perhaps also different wgo structure. But well, > none of this belongs to the current release goals and they are not even > agreed goals at all. I don't want to introduce red herrings, nor I want > to stop thinking in the big picture. Content personalization (dynamically deciding what to serve best for a given visitor) is not in the scope of this revamp. Content focusing (writing content targeted at a specific audience) is. This can be achieved with the current system just fine. > I hope my obsession for migrating to a good CMS is more understandable > now. However, I realize the current system evolved could be a reasonably > good choice for the strict wgo if we solve the content edition problem. > IMO this is more important than the i18n problem, since there is no > point having a good solution for translating if you don't have a good > solution for publishing first. Our goal is not to change the CMS. Our goal is to make wgo better. If that means changing the CMS, we'll do it. Let's not be obsessed with the CMS, because if it's done right, it really doesn't matter what CMS we use. That's why i wrote the platform issues document [1], to capture web content management issues independent from any CMS implementation. The CMS selection process is coming along nicely, I'm extremely happy with all the efforts coming in here. Nevertheless, we are not ready to make a decision just yet. I've seen good progress in the partitioning area too, pages appeared in the wiki like mushrooms. Yet, something is still missing, and I think i just found it: * Define the content and scope of www.gnome.org (needs coordinator) [2] IMHO this is the single most important task in the whole process. Until this is sorted out, a CMS should not be decided for. [1] http://live.gnome.org/GnomeWeb/PlatformIssues [2] http://live.gnome.org/GnomeWeb/GnomeOrgPartitioning Having said that, I also feel that a new CMS would serve wgo content better. The questions are: * what do we need it to do? * can we find something that does it? * can we extend that if it doesn't? * can we manage in time? In the end, I would recommend to stick with the current system only if we cannot have all its essential functions in the current CMS (like .po files for translators--although I contest this, see rosetta) AND if we cannot manage in time for this release (which I fear might be the case). I'm convinced that releasing a half-baked CMS solution worse than no change at all. Who said we cannot try again for the next release? I bet a lot of people would, if we come out with something that stinks :) Greg -- marketing-list mailing list marketing-list@gnome.org http://mail.gnome.org/mailman/listinfo/marketing-list