GNU Info

Info Node: (


Next: Old Versions Prev: Platforms Up: Top
Enter node , (file) or (file)node

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
`', 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, <>, 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 <> 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 <> to add you to the bug-reporting
list for your program.  To set up a new list, contact
<>.  You can subscribe to a list managed by
Mailman by sending mail to the corresponding `-request' address.

   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

   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

   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.

automatically generated by info2www version