Re: [gnome-love] It's all about the medals you're wearing.

[Telsa Gwynne <hobbit aloss ukuu org uk>]

Most of this is not about coding and how to do it. I trust Chema won't
mind my rambling. I hope it has some useful ideas though.

On Fri, May 25, 2001 at 11:17:45AM +0800 or thereabouts, Malcolm Tredinnick wrote:
> While coming dangerously close to a "me too" response (and I don't have
> Chema's credibility), I just wanted to add a couple of observations
> here...

Malcolm's too modest. See this for the number of bugs he and Alan
together fixed in one pass. I would call that credibility :)

http://news.gnome.org/970508127/ 

It's nearly five hundred bugs. Apparently a good half of them were
all _the same bug_ which had two distinct manifestations. One of
them involved hitting the preferences button and getting a crash.
Lots of people met it, therefore. It might have been just one bug, 
but fixing it made a _lot_ of people happy. 

> A lot of Chema's mail is about actual code writing. Let me add another
> job description here which is just as important: assisting the code
> writers.
>
> What does this mean? Let me use my small experience as an example: I got
> sucked into fixing gnorpm because Telsa was sitting on #gnome going
> through all the bugs[1] and asking if people could repeat things. A
...
> [1] Why this bug list was being compiled in the first place is another
> story.

The cynical answer: 
Because I wanted people to fix my bugs. And with all those -other-
bugs there, I wanted people to be able to see mine. And since I 
can't code my way out of a paper bag, if I make it easier for someone
else to fix bugs, my bugs will get fixed faster.

The other answer:
I just thought it would be useful. It was clearly unlikely that
anyone else had time to go through them (it took me about forty hours
over three or four days, and every day more were arriving). And I
thought it would help. Apparently it did :) 

In all honesty, the second answer is the real one. 

> So, if you don't think you want to code yet, but do want to help, find a
> package that seems to have a bazillion bugs against it that could do
> with some love and work out where the problem areas are. Compile a list
> and then tell us about it. Somebody will possibly pick it up and use
> your hard work to kickstart their own. Of course, this is another way to
> "get medals", too, because you will be build up the experience necessary
> to close a bunch of those bugs because they are fixed, or they don't
> contain enough information, or they are under the wrong category (don't
> close those ones -- refile them).

This list is largely dedicated to becoming a gnome hacker rather than
a um... I dunno. Supporting role? auxiliary? But if someone is looking
for things to fix, and needs help with bugzilla, I can try to give a hand. 
(I cannot solve the problem of "my proxy is correct, my cookie file is 
correct, but it won't let me login" though. I am awaiting a bugzilla
guru to fix that.) By the time you've done a little of this sorting, your
perspective changes somewhat. 

You start to see patterns everywhere: patterns in how people describe
things. The number of ways to describe "I hit this button, then this 
button, then there was a pause, then a message flashed up and foo-app 
crashed with the following information" is incredible. It helps when
you are faced with two different "I did this and...". You start to see
similarities in stack traces even if you can't code. After one bug was 
fixed in deskguide and tasklist, I found that anything with two 
consecutive lines referring to two particular functions could be 
closed with "Fixed in version whatever". 

Patterns in which OSes are affected: for example, gnorpm is available 
for Mandrake, but either they patched it heavily, or no-one used it there, 
because the number of crashes was tiny in comparison. What's going on? [1]

Patterns in what version of gnome people are using. We are up to 1.4
now. But bug reports still come in for October Gnome (the 1.0.5x release
following 1.0). Why are people still using that? [2]

Patterns in what people do when something goes wrong. I could have
wept for the number of people who reinstalled everything just in
case that would fix it. And reports of "I got this error message"
and then "so I did foo..." start you wondering whether anyone has 
considered fixing the damn error message to stop people thinking 
they needed to do whatever foo was.

Patterns in how people are associating these things. gnorpm got a
lot of bugs which were actually rpm, but people weren't using that.
They were using gnorpm and that's where they thought the bug was.
(Which meant that a mass-close of the now-fixed bugs had to include
emailed details to all valid addresses of gnorpm bug-reporters on 
how to install the new gnorpm for those who had broken ones which 
included how to download and install at the command line: worth 
thinking about when you fix something like that. I learned a lot
about shell scripts and how many emails you can send out at once
when I did that!)

Another great example of this is the bugs reported against gnome-core.
People aren't sure what crashed, but it must be pretty central, so
that must be the core of gnome, right? (Don't laugh. It's logical 
enough.)

Going through the gnome-applets reports teaches you a lot about which
applets people are using often enough to be annoyed when they crash.
gweather, for example, features heavily: it may crash, but -lots- of
people run it (don't you people have windows to look out of? :)). If
people are looking to trim down gnome-applets, I can safely offer the
advice of "don't remove gweather" as a result. 

Some of those patterns might be useful for when you get tired of
fixing bugs and want to create your own bug collection in the shape
of a new app :) 

I am sure some of the usability team will say that using bug reports
as a way to find out how people use programs is using a very skewed
sample and there should be proper user testing. I agree. Reading
too much into these patterns can be a bad thing. But it does help. 

I am having another fit of bug-sorting at the moment. If anyone is
interested, I can post such results here and people can do what 
Malcolm did :)

I am also trying to write a doc on how to use bugzilla, for reporters,
people going through trying to replicate things (gnome bugzilla
distinguishes between "unconfirmed" and "new"), and people going
through and fixing. 

Chema, are such lists of "lots of people meet this" and categories
of "this program crashes when... and when... and when..." likely to 
be useful on gnome-love? 

Telsa

[1] The answer, I suspect, is that Mandrake has a set of sysadmin facilities 
which include drakrpm or rpmdrak or something. And people were using that 
in preference to gnorpm. Then you start to wonder why. (Other than
"gnorpm crashes when I hit the preferences button", I mean.) Is gnorpm 
unintuitive in some way? What extra facilities does Mandrake's have 
that gnorpm lacks? Or are they already in gnorpm but not obvious so 
people don't use it? If so, could they go into it, once all the bugs 
are gone? How could that be done? 

[2] Why old versions? Several reasons:
        * It works. Why should I upgrade? 
        * It's a production box and I'm keeping to things I know.
        * I'm in an area of the world where net access is a problem, so..
          - ditto and our LUG had an installfest with old CDs.
          - ditto and I get my upgrades from CDs on magazine covers.