+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.
+
+** Please reread your patch before submitting it.
+
+** Do not mix changes.
+
+If you send several unrelated changes together, we will ask you to
+separate them so we can consider each of the changes by itself.
+
+
+* Coding style and conventions.
+
+** Mandatory reading:
+
+The "Tips and Conventions" Appendix of the Emacs Lisp Reference.
+
+** Avoid using `defadvice' or `eval-after-load' for Lisp code to be
+included in Emacs.
+
+** Remove all trailing whitespace in all source and text files.
+
+** Use ?\s instead of ? in Lisp code for a space character.
+
+
+* Supplemental information for Emacs Developers.
+
+** Write access to Emacs' CVS repository.
+
+Once you become a frequent contributor to Emacs, we can consider
+giving you write access to the CVS repository.
+
+
+** Emacs Mailing lists.
+
+Discussion about Emacs development takes place on emacs-devel@gnu.org.
+
+Bug reports for released versions are sent to bug-gnu-emacs@gnu.org.
+
+Bug reports for development versions are sent to emacs-pretest-bug@gnu.org.
+
+You can subscribe to the mailing lists at savannah.gnu.org/projects/emacs.
+
+You can find the mailing lists archives at lists.gnu.org or gmane.org.
+
+
+** 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.)
+
+
+** Understanding Emacs Internals.
+
+The best way to understand Emacs Internals is to read the code,
+but the nodes "Tips" and "GNU Emacs Internals" in the Appendix
+of the Emacs Lisp Reference Manual may also help.
+
+The file etc/DEBUG describes how to debug Emacs bugs.
+
+
+
+* How to Maintain Copyright Years for GNU Emacs
+
+** Our lawyer says it is ok if we add, to each file that has been in Emacs
+since Emacs 21 came out in 2001, all the subsequent years. We don't
+need to check whether *that file* was changed in those years.
+It's sufficient that *Emacs* was changed in those years (and it was!).
+
+** For those files that have been added since then, we should add
+the year it was added to Emacs, and all subsequent years.
+
+** For the refcards under etc/, it's ok to simply use the latest year
+(typically in a `\def\year{YEAR}' expression) for the rendered copyright
+notice, while maintaining the full list of years in the copyright notice
+in the comments.
+
+\f
+Local variables:
+mode: outline
+paragraph-separate: "[ \f]*$"
+end: