Re: The future of gup in developer and bugzilla

[Shaun McCance <shaunm gnome org>]

On Sun, 2006-02-12 at 14:43 +0100, Thilo Pfennig wrote:
> 2006/2/10, Shaun McCance <shaunm gnome org>:
>         What I strongly oppose is using different systems for every
>         single subsite.  ...  Using a single system for as many of 
>         our subsites as possible makes it easier for people to work
>         on web stuff.  It also makes it easier for us to maintain
>         consistent navigation across all pages, which we really must
>         try to do.
> 
> Well on the opposite I would strngly oppose to only use a singe
> system. The problem with that is the same with the
> All-In-One-Printers: If one system gets broken, eberything is broken.
> And by choosing different systems that should interact, different
> parts can develope quicker than others. This is one reason why Xorg is
> not monolithic. Maybe what you really want are systems that can easily
> communicate and look similar? The new MoinMoin for example has
> redefined authentication, so that you can use logins from other
> systems and do not have to login again
> 
> 
> 
>         everywhere: All pages on all subsites should have the same
>         header, presenting unified global navigation.
> 
> oh, communism. ;-) I would rather say we have different locations with
> different uses. Good stuff can be copied. Like Drupal as a basis or
> MoinMoin wiki. I do not see the need for the "one for all".

You oppose having a unified look-and-feel and consistent
navigation?  Do I need to pull up studies on information
retrieval and hypertext learning to convince you that the
single crappiest thing you can do to your reader is induce
cognitive overload?

As for having a single system, it just makes it that much
simpler to have consistent sites.  We will almost certainly
need multiple systems in some places, but we should reduce
the number of different systems as much as possible.

A better analogy than all-in-one printers would be the tools
we use in developing Gnome.  We all have our stuff in CVS,
we all use autotools+make, and we all use intltool and po
files for translations.  For gnome-doc-utils, I put a lot
of work into making it translatable using intltool with po
files.  It would have been way easier for me to tell the
translators that they have to edit some XML.  But then I
wouldn't get any translations, because it'd be too much of
a hassle for them.

>         www: We need largely static pages that are rich in content,
>         attractive, well-organized, and easy to update.
> 
> Why static? We need to inform users about the newest things. People
> only visit interesting pages. intersting pages have something new to
> tell. I thin gnome.org is there to tell people what is going on in
> GNOME land. not about every bit, but the major developments.

I apologize, my phrasing wasn't quite clear here.  When
I say "static", I do not mean "never changing".  Rather,
I mean that the content doesn't need to be dynamically
generated from some live feed of external data.  By this
definition, wikis are static.  Blog aggregators are not.

>         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.
> 
> I would expect developer pages being able to support developers. That
> means: Inform newcomers how they can contribute, developers to log in
> and just work on things quickly, have the ability to quckly change
> pages without asking an admin, reflecting the current status of
> development. 

Sure, fine.  The point I was trying to make is that we
have two very distinct sets of developers for whom we
need to provide information.  We have the people who
are developing Gnome (or want to be developing Gnome),
and then we have the people who are developing other
stuff using our platform.

Virtually all of our current developer-oriented pages
do not recognize and cater to this distinction.  They
basically assume that "developer" means "person hacking
Gnome", making life very difficult for ISDs.  Right now,
the state of our developer-oriented web pages, as well
as our lack of good developer documentation, makes our
platform a rather uninviting choice.

--
Shaun