Re: Roozbeh's post..

[Claus Schwarm <c schwarm gmx net>]

On Tue, 15 Mar 2005 09:09:21 -0800
Sriram Ramkrishna <sri aracnet com> wrote:

> I was reading roozbeh's post:
>
> http://www.advogato.org/person/roozbeh/diary.html?start=0
>
> and the 3rd paragraph is of interest to me considering our recent 
> turmoil in d-d-l.  Do we really have a problem here?  We should be
> honest with ourselves about our weaknesses otherwise we'll never be
> able to fix it.

It really depends what the goal of GNOME2's rewrite was: A usability
showcase? Finding new users throught usability? Having more users?

I do think there's a general trade-off between making GNOME easy to
use and making it powerful. The easy-to-use argument doesn't translate
into 'market share' right now because Linux -- the whole system -- isn't
popular enought yet.

GNOME's not only a desktop and development enviroment, it's also an
organization. The goal of organizations is coordination of its member's
actions. If we have a problem, it's the coordination. Maybe it's fine
within sub-projects but it lacks when dealing within our broader
enviroment: powerusers, and third-party app developers.

I think, you even tried to address this before in your post 'How do we
make decisions?' on ddl.

> Taking it further...
>
> When I look around me for the past two years I do not
> see a lot of new people joining the ranks of developers working
> on projects.  Is my impression wrong?  Or perhaps I'm just not
> hanging out in the right lists.  I'd like someone to either correct
> my impression if they are wrong.

I'm only 1 year on GNOME's mailing lists. But I do have experience in
participating in other volonteer projects. From that perspective, I find
some things rather surprising.

I even have a half-finished paper about it somewhere on my disk. The
sort version:

  1.) I think, we should try to collect a sort of GNOME agenda: the
goals of the project. Think: Why should I contribute when I don't know
where GNOME is heading? What problem does GNOME solve?

This holds true for all projects, IMHO, but GNOME has a special
reputation about changing direction, unfortunatly.

The description should be as clear as possible, and it should be about
the 'why?' and not only about the 'what?' Remember the positive example
of a bug report on Jimmy Steiner's blog:

http://jimmac.musichall.cz/weblog.php/Design/Speccing.php

I also tried to address the issue in the post about GNOME 3.0 object
stuff.

  2.) In our project, we tried to never let a potential volonteer run
out of the door after he came in. We gave him tasks to do until he was
ready to contribute on his own. This seems to happen quite seldomly
here.

I found out I even adapted this sort of behaviour. For example, there
was a mail about an french artist who did a marketing poster here on the
list. Did somebody of us respond?

Similar situations occured on the web-list in the last year: Somebody
said 'hello, I'm a web dev and want to contribute' but nobody responded.

They come into 'our house', offering help, but we hardly look at them,
and thus they go away.


  3.) We should stop putting tasks into public, making them common. This
results in less people contributing because everybody thinks the task is
done by someone else.

I saw this for gstreamer (list of easy bugs), same holds to the bugzilla
gnome-love keyword list, and probably lots of other tasks. I also
remember a post by Murray on the GTKmm list along the lines: "Should I
do everything on my own here?" Sounded rather frustrated.

Compiling a list, and say: 'Help!' may work, but it works slowly.

I believe it's better to say 'Contact me'. Get in touch, assign tasks.
One needs to remember people and their abilities and interests for stuff
like that, though, and the one needs to be 'famous' (ie. influential) to
do that.

Oh, and it helps to ask people what they would like to reach. I still
remember my first post to a GNOME list, and that nobody asked me what I
wanted to to do, or if I would be willing to do something else instead
of what I suggested.

To use the gStreamer example: Why not doing a sort of seminar instead of
posting a list of bugs? First publish an article tutorial, and then do a
Live tutorial on IRC using the easy bugs as exerices -- a little bit
like the bugsquad day. This may include previous promotion of the
article, and a follow up about the IRC tutorial.

If there are no easy bugs, what about helping third party app
developers? Sort of 'Reimplementing XYZ in GTK2 using gStreamer'? It
might even include a sort of exercise CVS/SVN account.

Taking the idea even further: If we find someone with server space and
PHP experience, putting some cookbook style notes on a proper wiki
instead of an article might be more helpful: Doing similar events for
other parts of the development platform will then fill the cookbook
while everythink is available at a single place.

But that's nearly off-topic, sorry.

  4.) I already mailed about the 'missing community feeling' of GNOME -
maybe in a too emotional state. Sorry about it, but I still think it's
true. It got even more relevent since the ddl post about the low
signal-noise-ratio, I believe.

There's much we could do about it: I discovered typekey.com for
building a central identity. Looks cool. Advogato seems to use a user
homepage to build community feeling. 

  5.) Since bugzilla is (or seems to be) a major point of communication,
can we please ask a usability engineer to do a study? And then change
the interface to make it more simple? 

> We should spend some effort in trying to recruit more people.
> Stuff like what happened this past week makes it harder.  The problem
> occurs in the fact that the pool of people we draw from are the
> same people we tend to have conflicts with because they want a
> technical desktop.

Implementing the above points will help to recruite more people, I'm
sure.

Concerning last week: You can't prevent bad press. You can only react
properly.

GNOME (that is: the known names from the planet) just reacted too late,
and used the wrong channels -- wrong because it nearly proved the point
of the editorial. A sort of GNOME agenda to refer as to the project's
'definition' or 'constitution' would have helped, too.

Oh, and as a general note: Public actions now (including blog posts)
will be evaluated in the light of the editorial for the next time,
unfortunalty.


Cheers, 
Claus