Some thoughts about GNOME websites



Hi,

I just want to share some random thoughts. I have read some archives
and also some web page. I might repeat some points but I think some
things may not have been discussed yet or have not had enough focus.
This is a long email and I promise that future mails will be a lot
shorter...

1.) Channels:

1.1.) Too many channels
I think one problem we have is having many channels for users and
developers to communicate. This is only partially a web problem. I
think this has also a dependency to IRC and mailing lists. IRC and
lists are not considered to be part of the web discussion, are they?
This would be more the popular meaning of "Web" that many people are
using for what most of us would call the internet and usenet and
email. I would suggest to integrate these channels into a web strategy
because in fact people (users, developers,...) are using all kinds of
services to a) get their information out and b) get the information
they want.

And in fact people can get answers from WWW, IRC, ML, Jabber or
whatever channel/service they are using that is or is not GNOME
related. They might even get a good GNOME hint from reading about a
GNOME app in Wikipedia!

BUT- I think we have a problem in the sense that we communicate  too
many different channels for use but  a) the quality of one service is
not always good - this means that you might as  a question on IRC and
do not get any answerm although generally GNOME people would be able
to help you b) People have to choose what service to use and they
might stop on the first level like:

They go to http://www.gnome.org/contact/ and want to ask a question
but do not have a IRC client installed (see also
http://live.gnome.org/GnomeWeb/GoalChatClient for discussion) or even
know what this is.

In Germany I have watched our IRC  channel for about a week only to
find out that nothing is going on there. But we still communicate this
channel as one prefferred way to communicate with us. In the many
years maybe many people have tested the channel only to find out that
nobody is answering questions. This is no good PR (so this is an
aspect for GNOME Marketing)
[ On this point I like to make an excursion in discussing double
structures in having wiki pages and discussion lists with the same
topics. If we consider the number of channels to grow this will result
in a general information overload or at least trouble in having to
deal with all that channels. We should really think about if we should
not rather have an asynchronous and not a n:n relations. For instance
have a list that discusses many issues like web and marketing but then
have pages for each topic.]


1.2) The right channel
I had similar troubles discussing issues inside the Fedora project
where you often make the experience on beeing on the wrong channel.

I think communicating right in a project like GNOME is a task that
requires a realtively high knowledge of organisation structure and
long-year knowledge of "not-so-transparent" structures. So maybe the
most important problem is transparency - I think that pages like
http://live.gnome.org/GnomeWeb/GnomeSubsites in this relation are very
important because often knowing what does exist is more important than
having the cool brand-new solution - or if you look at it from a
different perspective: Something nobody knows of does not exist,
really. (BTW: good job Quim! ;-) )

I do not hesitate to admit that I could not say that I have a good
overview of that does exist, nor would I be able to recommend a german
speaking user a good starting point as a GNOME user (We are working on
it!)

2.) The live.gnome.org (LGO) and other wikis

I am a big fan of wikis, although they tend to get messy. I think Ward
Cunningham the wiki inventor has some good views on it. If you have
the time you could view an interview on
http://video.google.de/videoplay?docid=-7739076742312910146. As a
summary Ward says that maing errors in a wiki is sometimes better than
no content or perfect content, because people start to participate
when they see: Yes this is somehow right but needs correction. In
GNOME Germany we are switching from a MediaWiki only site to a split
of Drupal and Moin Wiki, because it was obvious that a wiki that gets
too much perfect structure will be dying or lose its
wikiness/sexyness. Thats one thing I fear might happen to LGO if we
start to clean up some messes. I personally tend to present a mix of
good structured pages (that might even be write protected) and pages
that have a relation to that structure. This is because it is
important that a wiki page has a relation and is no dead-end. Another
aspect is that we must encourage wiki users to be courageous and not
too respectful (better protect important content from unintentional
edits).

The other aspect are other websites and wikis. I think some redundancy
is good, but we also should consider beeing effective. So we also
should consider banning some content. But we must be careful not to
act with DisagreeByDeleting
(http://www.c2.com/cgi/wiki?DisagreeByDeleting) - meaning that if we
are deleting we should considering either archiving "bad" content or
take the time telling people why a page is empty ot what and why they
should not add.

And to a more general point I think wikis are very different because
they often allow anonymous users to start contributing. This is very
different to a given administrative structure with passwords and so
on. So I do not recommend wikis as a primary website or for
representational purposes. This is because they tned to be more
chaotic. But I would like to suggest the ability for anonymous users
to add content to some pages in LGO. I think there is no need to
protect every page to 100%. We could do this by adding an ACL line
like:
#acl All:read,write to a page.

----
I stop here although I could continue. But first like to here some
feedback/comments

One thing I practically would like to start with is some kind of
commented site map for the LGO wiki because it is hard to find many
contents.


Thilo



----
http://vinci.wordpress.com
Linked In: http://www.linkedin.com/in/tpfennig



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