X-Git-Url: https://code.delx.au/gnu-emacs/blobdiff_plain/5244bc019bf7376caff3bb198ff674e0ad9fb0e6..6950f15268f8d94199140be49d73043a79fdfae4:/etc/CONTRIBUTE

diff --git a/etc/CONTRIBUTE b/etc/CONTRIBUTE
index aff350f964..5d6b4238c9 100644
--- a/etc/CONTRIBUTE
+++ b/etc/CONTRIBUTE
@@ -1,4 +1,4 @@
-Copyright (C) 2006-2012 Free Software Foundation, Inc.
+Copyright (C) 2006-2013 Free Software Foundation, Inc.
 See end for license conditions.
 
 
@@ -22,7 +22,8 @@ inclusion in a future version of Emacs (see below).
 
 If you don't feel up to hacking Emacs, there are many other ways to
 help.  You can answer questions on the mailing lists, write
-documentation, find and report bugs, contribute to the Emacs web
+documentation, find and report bugs, check if existing bug reports
+are fixed in newer versions of Emacs, contribute to the Emacs web
 pages, or develop a package that works with Emacs.
 
 Here are some style and legal conventions for contributors to Emacs:
@@ -59,6 +60,11 @@ answer any questions you may have (or point you to the people with the
 answers), at the emacs-devel@gnu.org mailing list.
 
 A copyright disclaimer is also a possibility, but we prefer an assignment.
+Note that the disclaimer, like an assignment, involves you sending
+signed paperwork to the FSF (simply saying "this is in the public domain"
+is not enough).  Also, a disclaimer cannot be applied to future work, it
+has to be repeated each time you want to send something new.
+
 We can accept small changes (roughly, fewer than 15 lines) without
 an assignment.  This is a cumulative limit (e.g. three separate 5 line
 patches) over all your contributions.
@@ -93,8 +99,7 @@ revise your patch, send it as a followup to the initial topic.
 
 ** Description
 
-For bug fixes, a description of the bug and how your patch fixes this
-bug.
+For bug fixes, a description of the bug and how your patch fixes it.
 
 For new features, a description of the feature and your implementation.
 
@@ -102,7 +107,7 @@ For new features, a description of the feature and your implementation.
 
 A ChangeLog entry as plaintext (separate from the patch).
 
-See the various ChangeLog files for format and content.  Note that,
+See the existing ChangeLog files for format and content.  Note that,
 unlike some other projects, we do require ChangeLogs also for
 documentation, i.e. Texinfo files.
 
@@ -111,24 +116,16 @@ Manual, for how to write good log entries.
 
 ** The patch itself.
 
-Please use "Context Diff" format.
-
 If you are accessing the Bazaar repository, make sure your copy is
 up-to-date (e.g. with `bzr pull'), then use
         bzr diff --no-aliases --diff-options=-cp
 Else, use
 	diff -cp OLD NEW
 
-If your version of diff does not support these options, then get the
-latest version of GNU Diff.
-
 ** Mail format.
 
-We prefer to get the patches as inline plain text.
-
-Please be aware of line wrapping which will make the patch unreadable
-and useless for us.  To avoid that, you can use MIME attachments or,
-as a last resort, uuencoded gzipped text.
+We prefer to get the patches as plain text, either inline (be careful
+your mail client does not change line breaks) or as MIME attachments.
 
 ** Please reread your patch before submitting it.
 
@@ -178,18 +175,12 @@ by following links from http://savannah.gnu.org/mail/?group=emacs .
 
 ** Document your changes.
 
-Think carefully about whether your change requires updating the
-documentation.  If it does, you can either do this yourself or add an
-item to the NEWS file.
-
-If you document your change in NEWS, please mark the NEWS entry with
-the documentation status of the change: if you submit the changes for
-the manuals, mark it with "+++"; if it doesn't need to be documented,
-mark it with "---"; if it needs to be documented, but you didn't
-submit documentation changes, leave the NEWS entry unmarked.  (These
-marks are checked by the Emacs maintainers to make sure every change
-was reflected in the manuals.)
+Any change that matters to end-users should have a NEWS entry.
 
+Think about whether your change requires updating the documentation
+(both manuals and doc-strings).  If you know it does not, mark the NEWS
+entry with "---".  If you know that *all* the necessary documentation
+updates have been made, mark the entry with "+++". Otherwise do not mark it.
 
 ** Understanding Emacs Internals.