In general, tell people to send bug-fixes to gnats, not -hackers.

--
dannyman: Hey!  The handbook says to send submissions to &a.hackers;
jkh: Hmm...  It shouldn't.  Where's it say that?
dannyman: Oh, don't worry!  Tim Vanderhoek said he'd fix it!
hoek: What-huh!?  I never said that out loud, did I?

Zut!  ;-)

handbook/submitters.sgml

@@ -1,4 +1,4 @@
-<!-- $Id: submitters.sgml,v 1.145 1998-02-04 12:21:28 tg Exp $ -->
+<!-- $Id: submitters.sgml,v 1.146 1998-02-11 09:28:33 hoek Exp $ -->
 <!-- The FreeBSD Documentation Project -->
 
 <chapt><heading>Contributing to FreeBSD<label id="contrib"></heading>
@@ -291,49 +291,43 @@ the next version)
 <p>Contributions to the system generally fall into one or more of
 the following 6 categories:
 
-<sect1><heading>Bug reports and general commentary</heading>
+<sect1><heading>Bug reports and general commentary
-<p>If you have a bug to report or a suggestion to make:
+<label id="contrib:general"></heading>
 
-<itemize>
+<p>An idea or suggestion of <em>general</em> technical interest
-	<item>An idea or suggestion of general technical interest should be
+should be mailed to the &a.hackers;.  Likewise, people with an
-	  mailed to the &a.hackers;.
+interest in such things (and a tolerance for a <em>high</em>
-          Likewise, people with an interest
+volume of mail!) may subscribe to the hackers mailing list by
-	  in such things (and a tolerance for a <em>high</em>
+sending mail to &a.majordomo;.  See
-	  volume of mail!) may
+<ref id="eresources:mail" name="mailing lists">
-	  subscribe to the hackers mailing list by sending mail to 
+for more information about this and other mailing lists.
-          &a.majordomo;.
-          See <ref id="eresources:mail" name="mailing lists">
-	  for more information about this and other mailing lists.
 
-	<item>An actual bug report should be filed by using the send-pr(1)
+If you find a bug or are submitting a specific change, please report
-          program or its <url url="http://www.freebsd.org/send-pr.html"
+it using the <tt>send-pr(1)</tt> program or its
-	  name="WEB based equivalent">. This will prompt you for various
+<url url="http://www.freebsd.org/send-pr.html" name="WEB-based equivalent">.
-	  fields to fill in.  In the send-pr(1) case, simply go to the
+Try to fill-in each field in the bug report.  Unless they exceed
-	  fields surrounded by <tt>&lt;&gt;</tt>'s and fill in your own
+65KB, include any patches directly in the report.
-	  information in place of what is suggested there.  With the
-	  WEB based interface, you simply select the appropriate items from
-	  various option menus and fill in the various fields shown there.
 
-	  <p>You should receive confirmation of your bug report along with
+After filing a report, you should receive confirmation along with
-	  a tracking number.  Please keep this tracking number and refer to
+a tracking number.  Keep this tracking number so that you can
-	  it in any subsequent correspondence so that people can find the
+update us with details about the problem by sending mail to
-	  details of your problem quickly.  You may also send mail to
+<url url="mailto:bug-followup@FreeBSD.ORG"
-	  <url url="mailto:bug-followup@freebsd.org"
+name="bug-followup@FreeBSD.ORG">.  Use the number as the
-	  name="bug-followup@freebsd.org"> with your PR# in the subject
+message subject, e.g. <tt>"Re: kern/3377"</tt>.  Additional
-	  line to append further information to an existing bug report.
+information for any bug report should be submitted this way.
 
-          If you do not receive confirmation in a timely fashion (3 days to
+If you do not receive confirmation in a timely fashion (3 days to
-          a week, depending on your email connection) or are, for some
+a week, depending on your email connection) or are, for some
-          reason, unable to use the <tt>send-pr(1)</tt> command,
+reason, unable to use the <tt>send-pr(1)</tt> command,
-	  then you may also file a bug report by sending mail to the &a.bugs;.
+then you may ask someone to file it for you by sending mail
-</itemize>
+to the &a.bugs;.
 
 <sect1><heading>Changes to the documentation</heading>
 
 <p>Changes to the documentation are overseen by the &a.doc;.
-This does not generally include
+Send submissions and changes (even small ones are welcome!)
-changes to manual pages, which should be considered under the category
+using send-pr as described in
-of "changes to existing source code."
+<ref id="contrib:general" name="Bug Reports and General Commentary">.
 
 <sect1><heading>Changes to existing source code</heading>
 
@@ -368,31 +362,28 @@ diff -c -r olddir newdir
    details.
 
    Once you have a set of diffs (which you may test with the
-   <tt>patch(1)</tt> command), you should bundle them up in an
+   <tt>patch(1)</tt> command), you should submit them for inclusion
-   email message and send it, along with a brief description of
+   with FreeBSD.  Use the <tt>send-pr(1)</tt> program as described in
-   what the diffs are for, to the &a.hackers;.
+   <ref id="contrib:general" name="Bug Reports and General Commentary">.
-   Someone will very
+   <em>Do not</em> just send the diffs to the &a.hackers; or they will get
-   likely get back in touch with you in 24 hours or less,
+   lost!  We greatly appreciate your submission (this is a volunteer
-   assuming of course that your diffs are interesting! :-)
+   project!); because we are busy, we may not be able to address it
+   immediately, but it will remain in the pr database until we do.
 
-   If your changes do not express themselves well as diffs alone
+   If you feel it appropriate (e.g. you have added, deleted, or
-   (e.g. you have perhaps added, deleted or renamed files as well)
+   renamed files), bundle your changes into a <tt>tar</tt> file
-   then you may be better off bundling any new files, diffs and
+   and run the <tt>uuencode(1)</tt> program on it.  Shar archives are
-   instructions for deleting/renaming others into a <tt>tar</tt>
+   also welcome.
-   file and running the <tt>uuencode(1)</tt> program on it before
-   sending the output of that to the &a.hackers;.
-   See the man pages on <tt>tar(1)</tt> and <tt>uuencode(1)</tt> for more
-   information on bundling files this way.
 
    If your change is of a potentially sensitive nature, e.g.
    you are unsure of copyright issues governing its further distribution
    or you are simply not ready to release it without a tighter review first,
-   then you should send it to &a.core; rather than the &a.hackers
+   then you should send it to &a.core; directly rather than submitting
-   The core mailing list
+   it with <tt>send-pr(1)</tt>.  The core mailing list
    reaches a much smaller group of people who do much of the
    day-to-day work on FreeBSD.  Note that this group is also
    <em>very busy</em> and so you should only send mail to them
-   in cases where mailing to hackers is truly impractical.
+   where it is truly necessary.
 
    Please refer to <tt>man 9 intro</tt> and <tt>man 9 style</tt>
    for some information on coding style.  We would appreciate
@@ -401,7 +392,7 @@ diff -c -r olddir newdir
 
 <sect1><heading>New code or major value-added packages</heading>
 
-<p>In the case of a significant contribution of a large body
+<p>In the rare case of a significant contribution of a large body
    work, or the addition of an important new feature to FreeBSD,
    it becomes almost always necessary to either send changes as
    uuencode'd tar files or upload them to our ftp site <url