1 files changed, 76 insertions, 0 deletions
diff --git a/share/doc/libc-rand/contributing b/share/doc/libc-rand/contributing
new file mode 100644
index 0000000..c1ea401
--- /dev/null
+++ b/share/doc/libc-rand/contributing
@@ -0,0 +1,76 @@
+Name
+       Contributing - instructions for contributing to the project
+
+Synopsis
+       Email, patches, lint, style guide, and bug reports.
+
+Description
+   Email
+       There's no mailing list.  You can send an email to the maintainer:
+
+           To: Alejandro Colomar <alx@kernel.org>
+
+   Patches
+       If you know how to fix a problem in a file, send a patch in an email
+       (see above).
+
+       -  The subject of the email should contain "[patch]" in the subject line.
+
+       -  Write a suitable subject line.  Make sure to mention the name(s) of
+          the file(s) being patched.  Example:
+
+              [patch] stpecpy.c: stpecpy(): Accept NULL
+
+       -  Sign your patch with "Signed-off-by:".  Read about the "Developer's
+          Certificate of Origin" at
+          <https://www.kernel.org/doc/Documentation/process/submitting-patches.rst>.
+          When appropriate, other tags documented in that file, such as
+          "Reported-by:", "Reviewed-by:", "Acked-by:", and "Suggested-by:" can
+          be added to the patch.
+
+       -  Send patches in diff -u format, inline inside the email message.  If
+          you're worried about your mailer breaking the patch, then send it
+          both inline and as an attachment.  You may find it useful to employ
+          git-send-email(1) and git-format-patch(1).
+
+       -  Send logically separate patches.  For unrelated files, or for
+          logically-separate issues in the same page, send separate emails.
+
+       -  Make patches against the latest version of the project.  Use git(1)
+          for getting the latest version.
+
+   Lint
+       If you plan to patch a file, consider running the linters configured in
+       the build system, to make sure your change doesn't add new warnings.
+       However, you might still get warnings that are not your fault.  To
+       minimize that, do the following steps:
+
+       (1)  Lint first the entire project, so that make(1) knows that it only
+            needs to lint again files that you will touch.
+
+                $ make -ij lint >/dev/null 2>&1
+
+       (2)  Touch the file that you'll edit, and run make(1) again, to see
+            which warnings you'll still see from that file that are not your
+            fault.
+
+                $ touch src/c/rand/rand.c  # replace by the file you'll modify
+                $ make -k lint
+
+       (3)  Apply your changes, and then run make(1) again.  You can ignore
+            warnings that you saw in step (2), but if you see any new ones,
+            please fix them if you know how, or at least note them in your
+            patch email.
+
+                $ vi src/c/rand/rand.c  # do your work
+                $ make -k lint
+
+       See <INSTALL> for a list of dependencies that this feature requires.
+       If you can't meet them all, you can selectively run certain linters.
+
+   Style guide
+       There's no style guide.  I follow a mix of the coding styles for Linux,
+       Git, Google, Nginx, and a bit of my own.  Just look at surrounding style.
+
+Reporting bugs
+       Report bugs in email, as patches.