> The broken navigation is due to people not caring about the wiki. > This is due to happen with a CMS too when more people take part in > the CMS. The reason is GNOMEs size. With Drupal you can limit the ability of creating new books to certain users (i.e. editors) and then any new page needs to sit as taughter of a current page. This way you keep always a consistent breadcrumb navigation. You can define different weights between pages at the same level to decide their sort in the automatic indexes generated. You can move the "location" (relationship) of a page in a couple of clicks without needing to rename it, so even if a user succeeds doing some mess is very easy to fix it without change of URLs. See http://drupal.org/handbooks for an example. Each entry is a book. > lgo will always be exposed to the public; if not by us then by others This is not a problem if it's clear that lgo is for internal scketching and planning. ViewCVS is also exposed to the public, its function is clear, no problem. > The only problem is developer.gnome.org or maybe library.gnome.org: I > think they should be living sites, and hence on some kind of wiki. We shouldn't mix concepts. One thing is the "life" of the tools that power a site and another thing is the user interface we offer in the different parts of a site. Moin, Drupal and many other tools can power living sites with pages editable with a single click, easy to update, etc. It's a matter of interface design and layout making these pages look like solid documents written on stone or dynamic sketches in progress. > Of course, if someone feels like "Oh, ok. I'll do the lgo planning > and a few layout mockups in our wiki, then" -- that would rock! What lgo needs to start with is a list of requirements written in plain text in lgo. Can someone create this list and then everybody drops ideas there? It will be easier to discuss the development based on an agreed list of requirements. > A few links to live.go from the main page won't hurt. This can be useful to improve the current site while the revamp goes on, like other actions Claus suggests. Which are the specific links you propose and where would you place them? > (And if they would finally agree on a common mark-up standard, these > bloody /&%$§$=()/ ). With Drupal you can create content using plain text with a WYSIWYG editor, limited HTML, full HTML and PHP. XML DocBook is planned to be offered as native input format as well, but this feature is not ready yet. There is an extra module to offer wiki format à la phpWiki if you really need it. > The wiki technology MoinMoin presents is hardly used (categories for > example). To me this is part of The Wiki Freedom. You are free to use the functionality you know how to use, which is unique to wikis. Precisely categories are living a high momentum thanks to the tag fever promoted by brilliant categorized projects such as Flickr or del.icio.us. With Drupal you can categorise your content either by selecting terms from a drop down menu of already created categories, you can create categories on the fly, you can even get those nice tag clouds... > The good thing about wikis is, that they do not limit you in any way, > but a CMS does. A CMS is good if you want to do 2-3 things. A wiki is > better if you do not know what future will bring. Interesting but could you provide examples of extra freedom Moin offers and Drupal not? On the other side, Drupal has modules for functionality that might be relevant to gnome.org such as news aggregation, CRM, donations & eCommerce, image galleries, banners, frontpage with different design, specifc CSS/theme for one/some pages... and the i18n features commented in previous threads. It also have a lot of features related to users management and communication 'admins -> users' and 'users <-> users'. More: http://drupal.org/project/Modules > I see the GNOME LIve! Wiki as a good site for organising things and > develop ideas. Agreed. But I don't see lgo for mothing else than this, though. The projects' websites wanting to go out from the static CVS can also be handled by Drupal. Anything aimed primarly to users' consumption and interaction could be handled by Drupal. Then we would have the needed web tools for internal use. > But we > should evaluate our X's based on how many of our subsites > they can handle. Agreed. Most subsites you name can be Drupal based (FootNotes is Drupal already). The integration can be eased though by working on a common set of templates based on includes, so Drupal and non-Drupal subsites could share the same general layout and navigation automatically - having each subsite their own customised layout and navigation bar. Investing some time in a common search engine able to look through all the content would be also very useful. And if a subsite i.e. status needs new development we can alays consider the possibility to develop on the Drupal API and contribute the results. This way we need some extra effort by learning and following some guidelines. On the other hand, we will save time and effort finding/solving bugs since other sites will be using our tools and improving them. > developer: We need the same as for www. Remember, we need > pages that cater to ISDs, as well as the sort of scratch > pages we need for internal development. With Drupal, use different taxonomy (categories) for finished/stable pages and drafts, and use different themes/CSS for any of them. This way you offer the 'written on stone' look&feel on final pages and the 'Improve this page' living-site behaviour to the scratches. Clearly differentiated, although internally they are just the same. -- Quim Gil - http://desdeamericaconamor.org
Attachment:
signature.asc
Description: OpenPGP digital signature