7 Dealing With Mail

Once a program is in use, you will get bug reports for it. Most GNU programs have their own special lists for sending bug reports. The advertised bug-reporting email address should always be `bug-program@gnu.org', to help show users that the program is a GNU package, but it is ok to set up that list to forward to another site for further forwarding. The package distribution should state the name of the bug-reporting list in a prominent place, and ask users to help us by reporting bugs there.

We also have a catch-all list, bug-gnu-utils@gnu.org, which is used for all GNU programs that don't have their own specific lists. But nowadays we want to give each program its own bug-reporting list and move away from using bug-gnu-utils.

If you are the maintainer of a GNU package, you should have an account on the GNU servers; contact accounts@gnu.org if you don't have one. (You can also ask for accounts for people who help you a large amount in working on the package.) With this account, you can edit /com/mailer/aliases to create a new unmanaged list or add yourself to an existing unmanaged list. A comment near the beginning of that file explains how to create a Mailman-managed mailing list.

But if you don't want to learn how to do those things, you can alternatively ask alias-file@gnu.org to add you to the bug-reporting list for your program. To set up a new list, contact new-mailing-list@gnu.org. You can subscribe to a list managed by Mailman by sending mail to the corresponding `-request' address.

You should moderate postings from non-subscribed addresses on your mailing lists, to prevent propagation of unwanted messages (“spam”) to subscribers and to the list archives. For lists controlled by Mailman, you can do this by setting Privacy Options - Sender Filter - generic_nonmember_action to Hold, and then periodically (daily is best) reviewing the held messages, accepting the real ones and discarding the junk.

When you receive bug reports, keep in mind that bug reports are crucial for your work. If you don't know about problems, you cannot fix them. So always thank each person who sends a bug report.

You don't have an obligation to give more response than that, though. The main purpose of bug reports is to help you contribute to the community by improving the next version of the program. Many of the people who report bugs don't realize this—they think that the point is for you to help them individually. Some will ask you to focus on that instead of on making the program better. If you comply with their wishes, you will have been distracted from the job of maintaining the program.

For example, people sometimes report a bug in a vague (and therefore useless) way, and when you ask for more information, they say, “I just wanted to see if you already knew the solution” (in which case the bug report would do nothing to help improve the program). When this happens, you should explain to them the real purpose of bug reports. (A canned explanation will make this more efficient.)

When people ask you to put your time into helping them use the program, it may seem “helpful” to do what they ask. But it is much less helpful than improving the program, which is the maintainer's real job.

By all means help individual users when you feel like it, if you feel you have the time available. But be careful to limit the amount of time you spend doing this—don't let it eat away the time you need to maintain the program! Know how to say no; when you are pressed for time, just “thanks for the bug report—I will fix it” is enough response.

Some GNU packages, such as Emacs and GCC, come with advice about how to make bug reports useful. If you want to copy and adapt that, it could be a very useful thing to do.