X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=CONTRIBUTING;h=76548624dd7882ca83cedf59ae25df6ba0ed57a5;hp=9d63d8abb67252974e5a1267b2e38b67c1ad0a06;hb=b1860d6c71733314417d053a72af66ae72e8268e;hpb=f89ee71bc81017e04ac50f570d8aed87f495bcf2

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 9d63d8abb6..76548624dd 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,38 +1,55 @@
 HOW TO CONTRIBUTE TO OpenSSL
 ----------------------------
 
-Development is coordinated on the openssl-dev mailing list (see
-http://www.openssl.org for information on subscribing). If you
-would like to submit a patch, send it to rt@openssl.org with
-the string "[PATCH]" in the subject. Please be sure to include a
-textual explanation of what your patch does.
-
-You can also make GitHub pull requests. If you do this, please also send
-mail to rt@openssl.org with a brief description and a link to the PR so
-that we can more easily keep track of it.
-
-If you are unsure as to whether a feature will be useful for the general
-OpenSSL community please discuss it on the openssl-dev mailing list first.
-Someone may be already working on the same thing or there may be a good
-reason as to why that feature isn't implemented.
-
-Patches should be as up to date as possible, preferably relative to the
-current Git or the last snapshot. They should follow our coding style
-(see https://www.openssl.org/policies/codingstyle.html) and compile without
-warnings using the --strict-warnings flag.  OpenSSL compiles on many varied
-platforms: try to ensure you only use portable features.
-
-Our preferred format for patch files is "git format-patch" output. For example
-to provide a patch file containing the last commit in your local git repository
-use the following command:
-
-# git format-patch --stdout HEAD^ >mydiffs.patch
-
-Another method of creating an acceptable patch file without using git is as
-follows:
-
-# cd openssl-work
-# [your changes]
-# ./Configure dist; make clean
-# cd ..
-# diff -ur openssl-orig openssl-work > mydiffs.patch
+(Please visit https://www.openssl.org/community/getting-started.html for
+other ideas about how to contribute.)
+
+Development is done on GitHub, https://github.com/openssl/openssl.
+
+To request new features or report bugs, please open an issue on GitHub
+
+To submit a patch, please open a pull request on GitHub.  If you are thinking
+of making a large contribution, open an issue for it before starting work,
+to get comments from the community.  Someone may be already working on
+the same thing or there may be reasons why that feature isn't implemented.
+
+To make it easier to review and accept your pull request, please follow these
+guidelines:
+
+    1. Anything other than a trivial contribution requires a Contributor
+    License Agreement (CLA), giving us permission to use your code. See
+    https://www.openssl.org/policies/cla.html for details.  If your
+    contribution is too small to require a CLA, put "CLA: trivial" on a
+    line by itself in your commit message body.
+
+    2.  All source files should start with the following text (with
+    appropriate comment characters at the start of each line and the
+    year(s) updated):
+
+        Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
+
+        Licensed under the OpenSSL license (the "License").  You may not use
+        this file except in compliance with the License.  You can obtain a copy
+        in the file LICENSE in the source distribution or at
+        https://www.openssl.org/source/license.html
+
+    3.  Patches should be as current as possible; expect to have to rebase
+    often. We do not accept merge commits, you will have to remove them
+    (usually by rebasing) before it will be acceptable.
+
+    4.  Patches should follow our coding style (see
+    https://www.openssl.org/policies/codingstyle.html) and compile
+    without warnings. Where gcc or clang is available you should use the
+    --strict-warnings Configure option.  OpenSSL compiles on many varied
+    platforms: try to ensure you only use portable features.  Clean builds
+    via Travis and AppVeyor are required, and they are started automatically
+    whenever a PR is created or updated.
+
+    5.  When at all possible, patches should include tests. These can
+    either be added to an existing test, or completely new.  Please see
+    test/README for information on the test framework.
+
+    6.  New features or changed functionality must include
+    documentation. Please look at the "pod" files in doc/man[1357] for
+    examples of our style. Run "make doc-nits" to make sure that your
+    documentation changes are clean.