Ok, let's go for Plone. I think we could reach our wgo goals with Midgard as well but there are some reasons that probably make Plone a better choice here and now. These reasons, detailed above, are based more on human factors than the tools themselves. To me this is the end of the CMS selection process. If you have anything to discuss, let's discuss it. But Ramon can already start the work, to be coordinated via gnome-web-list - http://mail.gnome.org/mailman/listinfo/gnome-web-list ------ IN DETAIL One aspect that has pushed the Midgard option since the very beginning is their use of GNOME libraries - http://bergie.iki.fi/blog/project_gnomegard.html . From a technical point of view this might open ways of integration between the GNOME website and desktop. I'm sure that a dinner with Henrius or Tuomas would throw thousand interesting ideas. Also, from an "institutional" point of view makes sense betting in projects that have bet in GNOME to support each other mutually. My conclusion about this is that it would be still interesting to experiment with the Midgard-GNOMEdesktop integration, but wgo is probably not the best place to do so. I think this essay would make more sense in something like a my.gnome.org - which is a slightly different battle than wgo 2.18. Let's compare Plone and Midgard. - Localization: We could probably fulfill the whole i18n requirements with both tools and some hacking. I can even imagine the Midgard developers willing to make an investment on this since the working solution could be pretty interesting to potential clients with intensive L10n needs. That would be a best case scenario. However, this humble wgo revamp coordinator needs to think in worst case scenarios: the Midgard developers busy in other projects, Henrius lost in the Antarctica with a moped... and our PHP guys around saying it is complex to get into the Midgard thing and "we told you Quim it was better to go for [your favorite PHP CMS here]". As a result, the i18n team, upset, decides it's not worth to waste the time with us. With Plone technically we could reach the same features than with Midgard (and viceversa), but the human context is very different. Perhaps Ramon & co don't want to invest the time needed to fulfill all the i18n requirements, but the already existing Plone tools can offer the minimum requirements to deliver to the i18n the minimum they need to work: XML, versioning, diffs (same as Midgard). From that point if the i18n team says "we got A, B, C which is fine but ideally we would want to have E, F, G as well" our answer can be "no problem, go hack yourself". Why this answer with Plone and not with Midgard? Well, Danilo knows Python, he is developing http://live.gnome.org/TranslationProject/NewStatusPages (Python based) and as far as I know is working in https://launchpad.net/rosetta (Plone based). Same for Jordi Mallach of GNOME i18n fame and even Carlos Perelló (former GNOME i18n tools maintainer). No idea if there is more Python knowledge in the i18n team, could be. In this context the worst case scenario wouldn't be assumed alone by the wgo team, we would share responsibilities with the i18n team who would have more skills than us to develop their own solution at their own will. A perfect integration can be achieved if someone within the GNOME community is willing to code it. - Look&feel: no problem with Plone or Midgard. - Learning curve: let's have a look to the three levels of users needing to learn how the wgo CMS works. Editors and translators would need to deal with forms and little more, a simple 2 pages tutorial would probably do. Web admins would have probably a similar learning curve with both tools, that allow the administration of most tasks via web interface (although it might be possible that Midgard relies more on the command line). About CMS hackers, the ones implementing new features, customizing stuff... in a typical PHP savvy web development environment Midgard could have an advantage here, but due to the special context of GNOME I think we have more good & intermediate Python hackers around. About documentation, both tools have the basic that is needed, but the Plone environment has a lot more, including a whole free book and screencasts for several levels. People like these things when they have to learn something. - Security and upgrades: both tools are solid and seem to be careful about the upgrade process. - User management: apparently both provide what we need. - Contributors around: as said, even if normally in web projects based on volunteers it is easier to find PHP hackers, I think in our context there is more Python knowledge. If the use of Drupal in guadec.org and gnomedesktop.org has brought some Drupal supporters on board, I think the use of Plone will have the same effect with this CMS. We have already some names of people interested in having wgo based in Plone - http://live.gnome.org/GnomeWeb/CmsRequirements/PloneEval?action=info - and we will probably find more through the Planet and other channels. In any case I trust the capability of Ramon leading the implementation of the wgo CMS within the 2.18 timeline (same as I do with Henrius, no differences here). This has been an important element in the decision as well. COLOPHON Thanks to all the people that invested time willing to find the most appropriate CMS for www.gnome.org. Even if the process wasn't as good as it was planned, I hope the result will be as good as expected. And now, let's build a great www.gnome.org -- Quim Gil /// http://desdeamericaconamor.org
Attachment:
signature.asc
Description: This is a digitally signed message part