[gnome-love] 10 ideas on where to start ....

[Chema Celorio <chema celorio com>]

The gnome-love activity has slowed down recently, the good news is that
some hackers that started with gnome-love are now important contributors
to GNOME, they "graduated" gnome-love.

So I was thinking about how could we generate the second wave of hackers
started. I wrote down ten small projects that could help someone to get
started. Now, more important than this particular ideas, is to show the
type of stuff that can be done to get started. Just as i was able to
come up with a couple of ideas, you can pick your own, maybe something
that you really want to get fixed or fix a crash or two for a module.

Rember that free software hackers need to develop the ability to be self
starters, it is important that you become a self starter (if you are not
one already). 

For those who have joined the list recently, you might want to read :
http://pobox.com/~hp/hacking.html
and
http://mail.gnome.org/archives/gnome-love/2001-May/msg00105.html

If you need any type of help, or have any question regarding how to do
any of this taks, please send your question to this list. From getting
source from the CVS, compiling, a coding question or anything else. We
would love to help you out, that is the whole idea behind gnome-love.

Ok, so here are ten ideas i was able to come up with in the last week,
as you can imagine most of this items are related to projects I am
involved in, simply because these are the projects i deal frequently.

1. Find a small bug in bugzilla and kill the little sucka !

The best way to get started in GNOME hacking, is probably by doing bug
fixing. I think this is how most of the hackers got started.  Go to
bugzilla, run a query for a particular module and find an easy to fix
bug. Unmaitained modules or modules with lots of bugs are a good place
to start since they usualy have lots of bugs to fix, so you can choose
and pick the right one for you. While fixing this bug you will learn
more about the way GNOME programs work and organized than the actual
code. The first tasks are more about getting familiar with a GNOME app,
the GNOME cvs, compiling, how to make a patch etc, than the actual bug
fixing.

2. Translations

If you are not yet ready to hack and english is not your first languaje
contributing to the translation effort is a good way to get involved in
the community. Making GNOME speak different languajes is a very
important task. Get in touch with the translations teams and start
helping them out.

3. screensavers .xml files

We have a graphical configurator for screensavers, we use some .xml
files to "map" the scrensaver arguments to a widget. A good project
would be to finish the .xml files so that the important parameters of
each of the screensavers can be edited. This requires very little
coding. Look at :
cvs/gnome-control-center/capplets/screensaver/screensavers/spiral.xml
for an example.

it contains arguments to the screensaver that map to a widget that will
be show in the user interface.

4. Grab your favorite (maintained) app and do a round of quality
assurance

A quality assurance guy is worth its weight in gold when working on a
project. If you are still learning to hack, or have limited time on your
hands, this taks might be for you. I for example, would love to hack on
gnumeric and improve it but i don't have the time for it, so my role in
the gnumeric team has been doing some quality assurance every once in a
while. This task is nice for me because a) I love gnumeric and want it
to succeed as a project and b) This is a task with "low compromise", i
can sit down 5 minutes or 2 hours to do it whenevery i have time and the
project does not stall when i don't do it. For example, this are the
bugs that i've reported for gnumeric in the last months :
http://www.gnome.org/~chema/gnumeric_bugs.html

(it might also be a good source on who to make recipies for bugs, in
particular the last 20 of them)

People don't value this type of jobs for GNOME as much as they should, I
feel like my small contribution to gnumeric is really helping the
developers and making gnumeric better, go ask jody about it and he'll
tell you how much help a quality assurance dude can be for a project.

5. gturing

gturing is a nice little toy, but it was never finished by arturo.
Specialy the tape editor. If you know what a turing machine is (very
interesting) and you like it, this might be the right project for you.
This project is unmaintained and it is a small one, so maintaining it
should not be too hard. It will teach you the basics of gtk+ if you are
not too familiar with gtk+ yet.

6. gnumeric HTML export merged cells

The HTML export code in gnumeric is not honoring merged cells. This is a
simple bug fix that should be easy to implement, this task if for you if
you are looking for something small, this type of small taks teach you a
lot of non-code writing abilitites, and it is an important feature for
generating HTML from a spreadsheet. Bug # 62032 in bugzilla. You will
also have to learn a lot about the internals of gnumeric, one of the
best written apps for GNOME.

7. glade2, recent opened files list

glade2 is far from usable and it needs lots of features. Get glade2 from
cvs, build the gnome 2.0 platform with the vicious-build-scripts and
implement the recent file opened list. There is code in several gnome
1.4 projects that already do this that can be used as a guide. Once this
taks is done, you can continue hacking on glade2, it needs a lot of
hacking to be usable. This might be a good task for you if you plan to
contribute a lot to GNOME since there is so much that can be done for
glade2, but if you don't you can start with this little task.

8. Fix and maintain the gnome-print pdf driver

Gnome-print powered apps can generate pdf files right from the print
menu. There is a pdf driver in gnome-print that generates pdf files.
This is an important feature of gnome-print. However, the gnome-print
driver has been unmaintained for some time. This task involves, first
getting the drive in shape again by testing it, generating a couple of
pdfs and test them in gv and acrobat reader (both for linux and for
windows).

Once a fair amount of testing and bugfixing has been done, the task
involves adding new features to the driver. Hacking on this driver was
one of the most fun GNOME task i've done, so I expect this task to be as
fun as writing the driver was. New features include font subseting. The
code needs to be cleaned to, see
cvs/gnome-print/libgnomeprint/gnome-print-pdf.c
for more info (there is a message at the top that describes the
rewriting needed). Writing of a test suite for the driver is also a
great idea, there might be a test suite for pdf's out there which we can
borrow, or it can be automaticly done by invoking gv and trying to see
if gv was able to read the pdf or not.

9. Write a cvs commit script for gedit

When comiting to cvs, cvs opens up a text editor so that we can add a
message that corresponds to the comit beeing done. The message is
usually composed of ChangeLog enries. When the text editor is opened it
is called with a temp file as a parameter, the content of the temp file
looks like this :

CVS:----------------------------------------------------------------------
CVS: Enter Log. Lines beginning with `CVS:\' are removed automatically
CVS:
CVS: Committing in . 
CVS:
CVS: Modified Files:
CVS: gnobots2/ChangeLog gnobots2/gnobots.c gnome-stones/ChangeLog
CVS: gnome-stones/help/Makefile.am gnomine/ChangeLog 
CVS: gnomine/gnomine.c gnomine/minefield.c gnotravex/ChangeLog
CVS: gnotravex/gnotravex.c iagno/ChangeLog iagno/gnothello.c
CVS:--------------------------------------------------------------------- 

What this plugin would do in its first implementation is open all the
files named ChangeLog. In this case it would open iago/ChangeLog
gnotravex/Changelog etc... so that the author can go and copy the
ChangeLog entries for his commit by hand. After the first implementation
is written, we can make it do more inteligent stuff, but for now
focus on the first step.

10. Port/Test the Ximian Setup Tools on your platform.

If you are a perl hacker or simply would like to test XST in your distro
this is the right task for you. The ximian setup tools (cvs module
ximian-setup-tools) are a set of cross platform gui configruation
utilities. Each tool is divided in a front end, writen in C and a
backend, written in perl. The front end knows nothing about the
underlying system, the perl backend knows how to read/write the
configruation files specific to each distro or type of Unix. Some
distros/versions are marked as unsuported simply because nobody has
tested them, there might already be code inside the tools that can
handle the system configration. For example, if we wrote some code for
Red Hat, it will most likely work on Mandrake. This task is also good
for people familiar with sysadmin tasks, since it puts a pretty face to
system administration.
==================

As you can see, there are a lot of tasks in which you can contribute to
GNOME, it is just a matter of getting off your butt ;-). Grab your task
and don't let go till you acomplish your objective.

love,
Chema