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

[Malcolm Tredinnick <malcolm commsecure com au>]

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...

On Fri, May 25, 2001 at 03:37:58PM -0500, Chema Celorio wrote:
>      If you want to become a contributor, you need to start getting
> medals arround your neck. It does not matter how big the medals are, who
> cares. It only matters how many you've got. Get used to gaining medals,
> and the size of your contributions will start growing. If you have
> been spending time trying to get your first medal and you think
> that you have not acomplished the objective (code in CVS) then redesign
> your strategy and shoot for a smaller medal.
>
>      Yesterday i received this patch :

[...patch snipped...]

>       This is a 1 line patch, in fact is a remove 6 characters and add
> 13 characters. But this patch fixes an actual bug (see bugzilla if
> you are curious). So this guy got a medal yesterday, his code is in
> CVS and will be fixed on the next release, whenever that happens.

One of my contributions to Gnome is that I like dabbling in projects and
fixing little bugs. I've spent a reasonable amount of time over the past
siz months helping fix bugs in gnorpm, for example. And one thing stands
out:

        A large number of bug fixes can be done in a single line
        or two.

The patch Chema posted above is not unusual in this respect. I feel this
is worth mentioning because I've had at least two conversations with
people on #gnome who basically said they were afraid to start fiddling
with something because they didn't have the time to become familiar with
every byte of code. If you can identify the region where the bug occurs
(gdb is your friend!), it can often be fixed without needing to read the
other ten thousand lines of code.

It sometimes takes a fair bit of time to understand why a bug is
occurring, but the fix is often just a matter of inserting a single line
here or there.

Of course, there are exceptions. Every now and again you have to go in
and club some code to death to make the product work, but if you are
just fixing an app (rather than writing one from scratch), this is rare.
:-)
        
> lesson #2
> It's all about the medals that you're wearing
>
>       So to get involved, you don't need to get involved with a
> bleeding edge library or a huge application, start small, get the
> experience you need, get the ball rolling, learn a lot. Yes, I know
> you are a very, very smart hacker [*3] and there isn't anything
> that you can't tackle but it's like building a muscle. You need to
> get used to actually contributing, utill it becomes second nature.

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
couple of them I could repeat and I was thinking "that's dumb ... I can
almost guess what's going wrong there" and I fixed two things pretty
quickly. The next day an enormous list arrived in my email from Telsa (I
was framed, I tell you!) of a number of bugs filed against gnorpm sorted
by the general bug description. This list grew over the next couple of
months (I think there were about 1100 bugs initially and another 300 or
so got filed immediately when Red Hat 7.0 came out).

The point (yes, there is one): it was _incredibly_ useful to have
somebody else spending the time to go through the bugs reports and
classify them into categories. Looking at a single bug at a time gives
you something to play with. Looking at a list that says "27 people have
filed reports that your program crashes when they do XYZ" is motivating!
It also helps you prioritise the bits to fix first. Make most of the
people happy most of the time and they will forgive you the slightly
rough edges.

Lately, I've adopted the same strategy when working on gnome-terminal ..
first classify the bugs to see how the land lies. Except I got bored at
around 200 bugs, so I started fixing things instead of classifying for a
while.

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).

There are other "assisting the code writers" tasks, too. A couple that
spring to mind:
        - write documentation for projects that you find hard to use
          (talk to the GDP guys before doing this to avoid duplicating
          work).
        - help try and replicate bugs if asked. Harldly anybody has
          access to all distributions in all their versions, so it's
          often hard to repeat problems reliably.

Cheers,
Malcolm

[1] Why this bug list was being compiled in the first place is another
story.

-- 
Works better when plugged in.