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:
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.
** 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.
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.
** 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.
** 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.