Tips for new GNU maintainers

If you are new to maintaining a GNU package, whether one that you have offered to GNU or an existing one that you have adopted, it can be overwhelming to know where to start. The official email notice you received when you became a GNU maintainer has lots of details; this document is not a replacement for that email, but rather a complement, aiming to provide some tips on getting started.

Of course, what's listed here just skims the surface of GNU maintainership. Please be sure to read the GNU Maintainers Guide and the GNU Coding Standards. Indeed, you should have read them already, but they are densely enough written that careful re-readings are useful. In addition, a few experienced GNU contributors have volunteered to answer questions about GNU maintenance via mentors@gnu.org as well as maintainers@gnu.org.

First steps for new maintainers

Update project information on Savannah. Check under "Update Public Info" in the "Main" menu. Here, you should set the project's full name and, if needed, write both a short and a long description for it (please also send those descriptions to maintainers@gnu.org for use in the lists of all GNU packages). You should also set its development status to reflect the maturity of the code. It is essential to do this if you have adopted a package, since it will be marked as "Orphan". (About Savannah.)
Turn to the mailing lists. If you have a new GNU package, you should set up at least one mailing list for the package via Savannah. It is strongly recommended to have one called bug-PROJECT@gnu.org; others can wait until traffic warrants. If you have adopted an existing package, send an email introducing yourself. Finally, whether lists are newly created or already existing, don't forget to subscribe yourself, as this is not automatically done. (About dealing with mail.)
Check for existing bug reports. If you have adopted an existing package, be sure to look for existing bug reports. These may be on any or all of a Savannah bug tracker, a mailing list (mbox archives are available via ftp and rsync), or at the GNU debbugs server. (About replying to bug reports.)
Contact distro packagers. If you have adopted an existing package and it is available in downstream distros, get in contact with the packagers. It is likely that they have unresolved bug reports to be addressed, and perhaps even patches that should be applied. You may also like to get involved with the GNU Guix package manager. (About distros.)
Use the software. It should go without saying that if you have adopted a GNU package, you should use it to get a feel for its current status and to discover what might need to be fixed.
Pick some tasks and start hacking! There's no substitute for spending time doing the actual work.

General tips on maintaining GNU software

Aim for a quick first release. Whether your package is new or you've adopted an older one, your number one priority should be making a first release as soon as possible. If you've adopted a package, it's sufficient to fix a few bugs and push that out. In fact, just updating the infrastructure files (e.g., Autoconf/Automake, gnulib modules, etc.) is enough to justify a new release when you've first taken over a package. If your package is new, don't be afraid to put out an early version that is not yet feature complete. In any case, a release (with proper announcements) will draw attention to your package in the form of potential users or even other developers. It is the best way to let people know that an old package has been revived or that a new package exists at all. (About making releases.)
Focus on fixing outstanding bugs first. An excellent way to begin to learn a new codebase is to fix some outstanding bugs to get a feel for how the system works. Besides, new features shouldn't be given much focus if notable problems already exist. (About resources for GNU developers.)
Don't try to rewrite the entire thing. If you've adopted a package, we strongly recommend that you not set out to rewrite the whole program from scratch. While always tempting, and an easy thing to start, completing it successfully requires a colossal effort, and experience has shown that it is an almost sure-fire way to become demotivated and lead to eventual (re-)stagnation of the project. Instead, focus on incremental improvements. Once you've become intimately familiar with the package, you will be in a better position to consider more radical changes.
You're in charge! As a maintainer, you look after a package as part of the overall GNU project. GNU depends on you to take care of legal matters, make new releases, keep the web pages updated, reply to bug reports and otherwise communicate with users, handle patches appropriately, and all else. This is your privilege and your responsibility. Please help us maintain an active and stable collection of software. If you have questions or run into problems, do not hesitate to get in touch via maintainers@gnu.org. (About recruiting developers.)
Get involved. GNU consists entirely of volunteers and your participation in the organization is what you make of it! As a maintainer, the communication received from us (read: pestering) will be low-volume. Being active within GNU is a great way to increase your contact and exposure to other like-minded volunteers. If you find an aspect of GNU in which you would like to be involved, there is almost certainly room for contribution. (About helping GNU and free software.)

To conclude this list with one final reiteration: the information and links above are just a sampling. Please refer to and (re)read the full GNU Maintainer Information and GNU Coding Standards documents for plenty more.

GNU Philosophy

This also seems like an appropriate page on which to give some links to the basic ideas of GNU and free software: