X-Git-Url: https://git.openssl.org/?a=blobdiff_plain;f=CONTRIBUTING;h=b65463c030c0cb4c9dfdd8e2550d73e38eabec3a;hb=5235ef44b93306a14d0b6c695b13c64b16e1fdec;hp=76548624dd7882ca83cedf59ae25df6ba0ed57a5;hpb=2876872ffe5dd53ec1c446656e924ff463e5d4bf;p=openssl.git

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 76548624dd..b65463c030 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -19,8 +19,16 @@ 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.
+    contribution is too small to require a CLA (e.g. fixing a spelling
+    mistake), place the text "CLA: trivial" on a line by itself separated by
+    an empty line from the rest of the commit message. It is not sufficient to
+    only place the text in the GitHub pull request description.
+
+    To amend a missing "CLA: trivial" line after submission, do the following:
+
+        git commit --amend
+        [add the line, save and quit the editor]
+        git push -f
 
     2.  All source files should start with the following text (with
     appropriate comment characters at the start of each line and the
@@ -28,7 +36,7 @@ guidelines:
 
         Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
 
-        Licensed under the OpenSSL license (the "License").  You may not use
+        Licensed under the Apache License 2.0 (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
@@ -53,3 +61,20 @@ guidelines:
     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.
+
+    7.  For user visible changes (API changes, behaviour changes, ...),
+    consider adding a note in CHANGES.  This could be a summarising
+    description of the change, and could explain the grander details.
+    Have a look through existing entries for inspiration.
+    Please note that this is NOT simply a copy of git-log oneliners.
+    Also note that security fixes get an entry in CHANGES.
+    This file helps users get more in depth information of what comes
+    with a specific release without having to sift through the higher
+    noise ratio in git-log.
+
+    8.  For larger or more important user visible changes, as well as
+    security fixes, please add a line in NEWS.  On exception, it might be
+    worth adding a multi-line entry (such as the entry that announces all
+    the types that became opaque with OpenSSL 1.1.0).
+    This file helps users get a very quick summary of what comes with a
+    specific release, to see if an upgrade is worth the effort.