Patches for man-pages

If you know how to fix a problem in a manual page (if not, look here), then send a patch, and make sure that you:

Put linux-man@vger.kernel.org into "To:" or "CC:" (no HTML mail please),
Include the string "[patch]" in the subject line
Include either or both comaintainers (Alejandro Colomar <alx.manpages@gmail.com> and Michael Kerrisk <mtk.manpages@gmail.com>) in "To:" or "CC:". (Please do not CC mtk's @man7.org email address.)

The above is the minimum needed so that someone might respond to your patch. (If you did that, and someone does not respond within a few days, then ping the mail thread, "replying to all".)

To make your patch even more useful, please note the following points:

Make sure that the mail has a suitable Subject line (i.e., one that mentions the name(s) of the page(s) being patched). A suitable subject line might be something like:
```
    [patch] shmop.2: Add "(void *)" cast to RETURN VALUE 
```
For nontrivial patches, it is helpful if you add a Signed-off-by: tag to certify that you wrote the patch or otherwise have the right to pass it on as an open-source patch. Such a tag is added near the end of the commit message, and has the form:

Signed-off-by: Firstname Lastname <your-email-address>

For details, see the section on the "Developer's Certificate of Origin" in the file Documentation/process/submitting-patches.rst in the Linux kernel source tree. Where appropriate, other tags documented in that file, such as Reported-by:, Reviewed-by:, Acked-by:, and Suggested-by: can be added to the patch. The man-pages project also uses a Cowritten-by: tag with the obvious meaning.
PLEASE NOTE: for nontrivial patches, you can save the maintainers a lot of time by attending to the following:

Describe how you obtained the information in your patch. For example, was it:
- by reading (or writing) the relevant kernel or (g)libc source code? (please provide a pointer to the relevant code)
- from a commit message in the kernel or (g)libc source code repository? (please provide a commit ID)
- by writing a test program? (send it with the patch, but please make sure it is as simple as possible, and provide instructions on how to use and/or a demo run)
- from a standards document? (please name the standard and quote the relevant text)
- from other documentation? (please provide a pointer to that documentation)
- from a mailing list or online forum? (please provide a URL if possible)
The more information that you can provide, the easier you make it for the maintainers and others to review your patch.
Where relevant, include source code comments that cite commit hashes for relevant kernel or glibc changes:
```
      .\" commit <40-character-git-hash>
```
Doing so can be useful to help verify details of the patch, or for later historical reference.
Please CC relevant developers. If your patch documents a substantial feature or change, and you know which developers added the feature or made the change that your patch documents, please CC them on the patch; with luck they may review and fix your patch. If you don't know who the developers are, you may be able to discover that information from mailing list archives or from Git logs or logs in other version control systems. Obviously, if you are the developer of the feature being documented in a man-pages patch, please identify yourself as such.
Please CC relevant mailing lists. If your patch documents a substantial feature or change, please consider CCing relevant mailing lists on your patch. With luck, subscribers on the mailing list might review your patch. Relevant mailing lists may include:
- linux-kernel@vger.kernel.org for patches to system call pages
- netdev@vger.kernel.org for patches to pages relating to networking and sockets
The GNU C library developers don't consider man-pages to be official documentation for the library. However, if you have a new page for Section 3 or a substantial addition to one of those pages, you might consider CCing libc-alpha@sourceware.org; there are some friendly folk there who may review or comment.

For trivial patches, the project uses a number of keywords that are processed by scripts that automatically build the release changelogs. Please employ the following in the patch subject line, where appropriate:
- ffix: Formatting fix.
- wfix: Minor wording fix.
- tfix: Typo fix.
- srcfix: Change to manual page source that doesn't affect formatted output.
Obviously, there's some overlap between the above cases; just choose the one that you think fits best. Using this scheme, a patch's subject line might look like:
```
    [patch] tcp.7: tfix
```
Some general tips on how to make life easier for the maintainers:

Send logically separate patches (e.g., for unrelated pages, or for logically separate issues in the same page) as separate mails.
Patches that contain correctly formatted groff are preferred. The basics of groff are pretty simple, and you can probably learn as much as you need by just looking at the source of the page to be patched; for more information, take a look at the groff_man(7), groff_man_style(7), and man-pages(7) manual pages. If you are uncertain of groff, then send a patch that uses some plain text.
Make patches against the latest version of the manual page. For information on downloading the latest tarball, or pulling from the man-pages Git repository, see the download page.
If the manual page that you want to patch is not in the tarball or Git repository, that's because it comes from a package other than man-pages; in that case, you should look here.
Send patches in diff -u format; inline inside the mail message is usually best. If you're worried about your mailer breaking the patch, then send it both inline and as an attachment. Since the man-pages project uses Git, you may find it useful to employ git-send-email or git-format-patch.

Some things that you don't need to do:

Don't try to patch the COLOPHON section of a page in one of the release tarballs. That text is autogenerated as part of the release process.
You don't need to update the page timestamp (".TH" line); the project release scripts do that automatically.