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

These tasks are listed in order of priority. The labels ([All], [New], and [Adopted]) indicate the category of packages each task mostly applies to.

[All] Update project information on Savannah. Go to your project page (https://sv.gnu.org/projects/PKG, where PKG is the name of your package), log in with your Savannah ID, and 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”.
[All] Turn to the mailing lists. If you have a new GNU package, you should set up at least one mailing list for the package (“Select features” in the Main menu). It is strongly recommended to have one called <bug-PKG@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.)
[New] Set up a repository for your source code (“Select features” in the Main menu), and import whatever is available (look up the procedures under “Source Code Manager” in the Development Tools section). Experience has shown that self-hosting is unreliable. (About back-up files.)
[New] Upload your package to the GNU FTP site if it is ready for public release. (About the upload procedure.)
[New] Create a GNU home page, to replace the PKG.html file that webmasters have placed in your web repo (keep the same name). If you want to make this quick and easy, use our standard template. Comment out the irrelevant parts, such as Downloading and Documentation if the project has barely started; you'll complete them later on. Also put any documentation you already have in a subdirectory called “manual”. (About web pages.)
[Adopted] Check for existing bug reports if you have adopted an existing package. These may be on any or all of a Savannah bug tracker, a mailing list (mbox archives can be downloaded by HTTPS), or the GNU debbugs server. (About replying to bug reports.)
[Adopted] 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.)
[Adopted] 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.
[All] 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. This is an excellent way to start learning a new codebase, and 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: