Update CONTRIBUTING

Fix typos and clarify a few things in the CONTRIBUTING file.

Reviewed-by: Rich Salz <rsalz@openssl.org>

1 files changed, 16 insertions, 9 deletions

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 1bfbc1b835..07115e5a75 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -1,11 +1,11 @@
 HOW TO CONTRIBUTE TO PATCHES OpenSSL
 ------------------------------------
 
-(Please visit https://openssl.org/community/getting-started.html for
+(Please visit https://www.openssl.org/community/getting-started.html for
 other ideas about how to contribute.)
 
 Development is coordinated on the openssl-dev mailing list (see the
-above link or http://mta.openssl.org for information on subscribing).
+above link or https://mta.openssl.org for information on subscribing).
 If you are unsure as to whether a feature will be useful for the general
 OpenSSL community you might want to discuss it on the openssl-dev mailing
 list first.  Someone may be already working on the same thing or there
@@ -16,7 +16,7 @@ The best way to submit a patch is to make a pull request on GitHub.
 If you think the patch could use feedback from the community, please
 start a thread on openssl-dev.
 
-You can also submit patches by sending it as mail to rt@opensslorg.
+You can also submit patches by sending it as mail to rt@openssl.org.
 Please include the word "PATCH" and an explanation of what the patch
 does in the subject line.  If you do this, our preferred format is "git
 format-patch" output. For example to provide a patch file containing the
@@ -42,7 +42,7 @@ the acceptance and review process faster:
 
     1. Anything other than trivial contributions will require a contributor
     licensing agreement, giving us permission to use your code. See
-    https://openssl.org/policies/cla.html for details.
+    https://www.openssl.org/policies/cla.html for details.
 
     2.  All source files should start with the following text (with
     appropriate comment characters at the start of each line and the
@@ -56,13 +56,20 @@ the acceptance and review process faster:
         https://www.openssl.org/source/license.html
 
     3.  Patches should be as current as possible.  When using GitHub, please
-    expect to have to rebase and update often.
+    expect to have to rebase and update often. Note that we do not accept merge
+    commits. You will be asked to remove them before a patch is considered
+    acceptable.
 
-    3.  Patches should follow our coding style (see
+    4.  Patches 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.
+    warnings. Where gcc or clang is availble you should use the
+    --strict-warnings Configure option.  OpenSSL compiles on many varied
+    platforms: try to ensure you only use portable features.
 
-    4.  When at all possible, patches should include tests. These can either be
+    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/apps, doc/crypto and doc/ssl for examples of
+    our style.