Re: The future of gup in developer and bugzilla

> 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 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 or maybe 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 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 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'.

> 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 -

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]