Getting started with the GIMP project
If you want an image editor with word wrap, then don't bother, because there are five million other idiot features which the beardo developers find more important than something as simple as a "text box" (which even the idiots at Microsoft manage to almost not completely screw up). Just warez a copy of PhotoShop instead.
Eventually, this page will contain lots of information on how you can contribute to the GIMP project, and become part of the madness.
Do I have to be able to...
No. The GIMP has room for everyone, regardless of technical level, operating system, language, nationality or sex.
The remainder of this wiki page describes various jobs available.
Testing
By using the GIMP, and reporting what's wrong with it, you are helping. You can report a bug using bugzilla
![[WWW]](/wiki/modern/img/moin-www.png)
http://bugzilla.gnome.org, our bug reporting system. Good qualities for a bug report include any number of:
concise
explain the behaviour you saw, and the behaviour you expected.
instructions for reproducing the problem
stack trace (if a crash, and you know how to generate one)
example images or links to web pages describing problem
exact error messages if applicable
Web content
As a drawing/photo editing program, nice screenshots, tutorials on creating a particular effect, links to artwork community sites and other similar content are always welcome.
FIXME: needed - someone to coordinate this effort.
Documentation
The GIMP has a web site, application documentation, lots of tutorials, and more. Unfortunately, as the GIMP develops over time, much of this documentation needs to be re-written or freshened up, documentation needs to be added for new functionality, the web site needs to get a new lick of paint and so on. There are lots of people who need help for this kind of thing.
Please look at GimpDocs page for further information.
Understanding GIMP source code and API
- API reference on developer web site or look at the $prefix/share/gtk-doc/html/ where prefix is the path you give to gimp during installation, for a local copy of the API reference.
Look at devel-docs/ directory from source archive for other docs: file formats(xcf, brush, patterns), structure.xml for classification of sources directories.
Bug triage
Lots of bugs get reported against the GIMP in bugzilla. Unfortunately, the quality of the bug reports often requires some extra information to be given before the problem can be reproduced, or the subject isn't accurate, or the problem has been reported to the wrong place.
All of these bugs need to be looked at, and a decision made as to whether they are valid or not, whether they are reported in the right place. This is something which might require some technical skill some of the time, but for the most part is a simple task.
It is recommended that you read the
GNOME Bugsquad Triage Guide in order to produce high quality bug reports. For a quick overview, see Bugsquad FAQ.
Bug fixing
Important links:
- The full list of bugs open against the GIMP (warning: long list).
- The list of bugs against the development releases with the "easy-fix" keyword.
If you are a developer who wants to start contributing code to the GIMP, this is one way to get to know its structure. Pick a bug, perhaps ask the advice of another developer as to whether he/she thinks it will be an easy bug or not, and then fix it
Sounds easy. After 20 or 30 bugs fixed, people will start to recognize your immense talent, and you will be on your way to becoming a GIMP hacker. What is more likely, though, is that you will find that easy and/or serious bugs are fixed almost instantly by the core developers, while the remaining ones are either obscure, very difficult, or require specialized knowledge that you probably don't have. An alternative is to pick an enhancement request and have a go at implementing it. The downside of this is that many enhancement requests are misguided, but you might not be able to figure this out from the Bugzilla notes. If you start by describing your intended approach in the Bugzilla area, though, somebody is likely to let you know if you are going in the wrong direction. Have a look at
http://developer.gimp.org for developer resources. All in all, the most productive way to start is probably with plug-ins. Either develop a new one or improve an existing one. Plug-ins are relatively easy to work with, because they are separate executables that interact with the main Gimp application via a set of libraries, most importantly libgimp. Also, the API for plug-ins is much better documented than the API for the core. If you play around with Gimp and try out a few plug-ins at random (from the Filters menu), you will quickly see that many of them could be improved in terms of usability.
The GIMP is a portable application. That means that we expect it to behave in more or less the same way on Windows as it does on Linux. Particularly needed are Win32 programmers, since the vast majority of the GIMP's programmers are using Linux or some form of Unix. Detailed instructions on building the GIMP on Win32 would also be useful. [HowToCompileGimp/MicrosoftWindows]
Hopefully this is enough to get something started.
FIXME: the following are still needed:
WikiWords for bugzilla
WikiWords for web site
WikiWords for writing a tutorial
Any forgotten jobs?
Contacts for jobs, with examples