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 <[EMAIL PROTECTED]> 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... _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
