Marc Paré wrote: > I have re-read all of the posts and thus far: ... > Have I missed any? Please add points to this list that have come to a > resolution of debate among the contributors of this thread.
I have re-read all of them too, not only your summary, and I still see we have strategic choices to make. 1) We shouldn't be discussing on a website, but on something more remarkable. Not in terms of features (I agree in keeping out mailing lists and stuff that is not web-related), but as seeing this as a huge opportunity for creating a nice, remarkable, network of websites. And, if the Document Fondation has a future, it will need this: it already does, just open http://extensions.libreoffice.org A proper discussion would not fit the deadlines and tools the Document Foundation has now: if a decision has to be taken now, it will miss the bigger scope. If the Document Foundation must choose a tool that will be flexible enough to rebuild all the current OpenOffice.org infrastructure on it (e.g.: OOo site; Extensions; TCM; QATrack), then Drupal is that tool; I can't imagine how to rebuild the Extensions site and all processing in Silverstripe, for one. So the whole idea of "choosing a tool just for the site" is short-sighted; build it on any technology, but it will come the time when a really powerful tool has to be chosen to give the community a unified user experience across all different sites, and Drupal can hardly have rivals here. 2) Moving to a database-based CMS can imply loss of traceability of changes. The current CVS infrastructure, as bad as it can be, allows to see a full log of changes very easily. Drupal has a killer feature here: site settings can be exported to PHP code, shared among a distributed development team through any revision control system (SVN, git, whatever) and applied in a safe way to the running site. It is very important that we are able to answer the question "Who enabled this permission, when and why?" easily and reliably, and the Drupal Features module does this: it automatically monitors site settings and exports them, so answering this question is just a matter of reading the changelog. I didn't see anything like this in Silverstripe; is it there? 3) How do you plan to implement translations? (from a visitor's point of view, not technically). I mean, the current http://www.openoffice.org site is in English only; you need to go to http://de.openoffice.org to see content in German, but that one is a totally different site. On the other hand, the Silverstripe demo (and of course Drupal too) seems to support translation of the single pages: but is that what you want? From what I could see (pumbaa has been down for me for the last two hours) you also foresee N-L subsites. A choice must be made between: - Having translatable pages - Having localized websites, with independent structure but same login - Having both (not acceptable from my point of view, too confusing) These kinds of decisions are much more important than a demo in my opinion: then, I understand that on this and other important matters the Steering Committee is in a hurry and it needs things done quickly rather than properly. I just fear, and my arguments are above, that choosing the "nice out of the box" Silverstripe will hinder further development... Unless there is the attitude to rediscuss this in a few months, like the "Codebase migration from CVS" discussion, that was resolved by temporarily migrating to SVN as a quick decision with the promise (then fulfilled) to migrate to a distributed SCM after one year. Best regards, Andrea Pescetti. -- E-mail to website+h...@libreoffice.org for instructions on how to unsubscribe List archives are available at http://www.libreoffice.org/lists/website/ All messages you send to this list will be publicly archived and cannot be deleted