Re: some thoughts about contributing to gnome

[Elijah Newren <newren gmail com>]

Hi,

I'm not sure if this is the right place for this (some could go to
gnome-bugsquad, other parts to gnome-love, others to who-knows
where...so I'm sure someone will redirect us if need be), but I
thought I'd chip in and include some ideas for ways to fix things
(warning: I'm highly verbose here)...

On 5/10/05, Christian Krause <chkr plauener de> wrote:
> Dear GNOME developers,
> 
> Motivated by the current discussion about "why it's not fun to hack on
> gnome" I want to explain you some of my thoughts (a user's view) about
> the problem:
> 
> Yes, it's (mostly) fun to use gnome.
> 
> Yes, it _was_ fun to help (testing, writing bug reports, fixing small
> bugs, ...).
> 
> But no, contributing is not fun anymore.

You state this and give a whole bunch of reasons, but those reasons
seem to be examples of things have not really changed, at least as far
as I know.  So, did you change yourself and just decide you didn't
like it anymore, or did you actually find things to be different in
the past?  (It could be the latter since I'm relatively new, but I
don't think things have changed much during the time I have been
around)

> You ask why?
> 
> a) Bug reports are sometimes completely ignored, not even set from
> UNCONFIRMED to NEW for several weeks. No reaction. No questions to the
> reporter. Nothing.

<snip>

Hehe, when I joined the bugsquad I often thought "what is wrong with
all these developers who never respond to all these bug reports?"  I
really didn't have any clue the amount of time it took the developers
to handle bugs vs. the 15-30 seconds I spent triaging it.[1]

As someone now responsible for a number of bugs (and doing a crappy
job at keeping on top of them) as well as being an active bugsquad
member, I think our major problem is a matter of *managing user
expectations*.  Free and open source software users can upgrade to get
new goodies nearly constantly, and furthermore the close interaction
with developers is often touted as an advantage.  Unfortunately, that
doesn't scale.  At all.  To make matters worse, our presentation gives
users the expectation of thinking that they'll get notified early and
often about progress of reports.  Here's perhaps what causes that
perception--they are pointed out exactly where the bug report can be
viewed AND they are emailed with each and every change to any of their
bug reports whether it's relevant or understandable to them or not
(and it usually isn't, unless we're asking for more information).

I don't think that scales well.  Without sufficiently many developers
per bug report, the usefulness of reports is primarily to determine
where the biggest fires (or the easiest ones to put out) are so that
they can be tackled.  Since we are sometimes forced to use bugzilla in
that manner, I think we may need to a way to make it require a little
more effort for them to check up on the progress of their bugs as well
as somehow making it known that bugzilla may need to be used in that
way.  (Think of filing complaints with companies or trying to report
bugs with various proprietary software; I am usually made to feel
important when I do so but I know full well that my effort will only
have results if others make the exact same complaints...but it's okay
since I tend to know that in advance)

> b) Writing bug reports to evolution seems to be quite useless. Either
> these bugs are completly ignored or you'll get quite rude answers. Just
> read some of evolutions's bug reports. Sure, the evolution people are
> not the same as the other gnome desktop hackers, but evolution is part
> of gnome and so this falls back to the gnome developers as well.
> 
> One example: I've filed a security related bug report. In short: If you
> configure SSL for IMAP and than fetch email your password will not be
> encrypted (only after you restart evolution). The reaction was: it
> worked always in this way -> NOTABUG.

Is this a representative sampling?  I don't know, but my triaging and
reading of evo bugs in the last month didn't ring any alarms for me
(though that's a small biased sampling that may not pick as much of
this stuff up).  I did notice that Evo people tend to be very brief in
their responses, and perhaps that induces a user perception problem
(people can think brief means rude, regardless of the phrasing)--one
that could be solved by using stock responses (both those at
http://developer.gnome.org/projects/bugsquad/triage/stock-responses.html
and similar ones that they could write up for themselves).  That
doesn't seem to explain your specific example, but I don't know enough
to follow that one anyway...
 
> c) The users have no or only very little possibilities to stear the
> direction of gnome: e.g. features vs. easy-to-use desktop, ...

That's definitely a user perception problem.  Users aren't supposed to
steer the direction of Gnome.  They can provide suggestions, but
design by committee sucks.  People are probably going to twist my
words like they do with everyone else on this subject, so let me state
this a different way:  *Neither users nor developers are supposed to
steer the direction of Gnome.*  Developers can steer the direction of
their project, but only their project.  Although I'm a Gnome
developer, I do not and should not try to steer the direction of
nautilus development because that is not one of the projects I'm a
maintainer for.  Honestly, I don't even steer Metacity (that's Havoc's
job), though I have sometimes succeeded in persuading a change of
direction to be taken.  While I happen to provide a lot of patches to
improve things in Metacity (and a few random patches here and there
for a dozen or so other modules), the simple fact of the matter is
that some of my patches and/or ideas are rejected outright.  And
that's a GOOD thing.

> As an example metacity would be very cool if it would have only some more
> features.

Hehe, I thought that way too.  I was planning a fork.  I had a name
picked out for it, laid out a whole bunch of plans on what I would
change, and decided to first start working on bugs in Metacity so that
I could get the needed experience.  I came to find out that most of my
annoyances were genuine bugs and not design decisions.  So, I kept
working and fixing stuff, getting dozens and dozens of bugfixes into
Metacity.  I've been so busy with that, that I never had time to get
to my fork.  There are still a couple things that I'd like in a
different window manager that don't belong in Metacity, but that
doesn't mean I should take over Metacity and steer it in a different
direction.  It means that I (or someone else) should take the time to
fork if it's important enough.  And, judging by how hard a time I have
trying to help with Metacity maintenance (which still has bugs that I
want fixed for it as well as for any hypothetical fork), I just don't
have the time for it right now.  In fact, having learned the
difficulty of maintaining software (where effort is proportional to
2^n, with n being the number of features or "toggles" in behavior),
I've lost my interest in putting forth the effort for any fork.

> d) There is only very few documentation about debugging gnome:
> 
> How do I strace/gdb/ltrace/valgrind an application/an applet/a bonobo
> component/a plugin?

I cover strace, gdb, and valgrind at
http://www.gnome.org/~newren/tutorials/developing-with-gnome/html/ch03.html
for normal processes.  For applets, you can combine the information in
that chapter with the HACKING file in gnome-applets (see
http://cvs.gnome.org/viewcvs/gnome-applets/HACKING?view=markup,
especially the link in that file to
http://www.davyd.id.au/articles/debugging-gnome-applets.shtml).  I
don't know about bonobo components or plugins...

But, in general, documentation is lacking, yes.  And when we have it,
it is sometimes so outdated that it does more damage than good
(developer.gnome.org is more harmful than helpful to beginners, in my
opinion)  Help would be very appreciated.  Some day I'll get back to
my Developing with Gnome guide
(http://www.gnome.org/~newren/tutorials/developing-with-gnome/); I'd
also like to do a debugging/profiling guide similar to it--feel free
to beat me to the punch or even make some other new guide or tutorial.
 
> e) Contributing code seems to be hard, too.

Yes, it definitely is.  Part of that is somewhat inherent--large
projects take lots of effort to get involved.  (I have suggested
before and still suggest that alpha-quality software or small
projects, if not writing your own toy code even if it will be thrown
away later, is a much better starting point for many people; see
http://mail.gnome.org/archives/gnome-love/2004-August/msg00009.html). 
But I'm sure there are other things we can do to reduce
barrier-to-entry.  One thing I tried was a getting-started-guide
specific for a module (see
http://bugzilla.gnome.org/show_bug.cgi?id=162646, I did something
similar though of smaller scope for libwnck); another way that I tried
was the Developing with Gnome guide itself.  I'd be interested in
other ideas for how to make this easier.


Hope that helps,
Elijah


[1]   Granted, I knew it would be a lot more time, but I didn't
appreciate the difference between a project like Gnome and my own
programs and so I still vastly underestimated the time.  I also didn't
understand how few Gnome developers there are in comparison to the
numbers of bug reports.  For example, the nautilus developers could
spend all day giving progress updates to bug reports, not get through
very many of the reports, and then not actually get anything fixed
either--or they can concentrate on fixing problems and updating a
smaller number of bugs but actually make some real progress.  Of
course, it doesn't help that they have several other modules to look
after as well...