CONTRIBUTING revision 312826 
1HOW TO CONTRIBUTE PATCHES TO OpenSSL
2------------------------------------
3
4(Please visit https://www.openssl.org/community/getting-started.html for
5other ideas about how to contribute.)
6
7Development is coordinated on the openssl-dev mailing list (see the
8above link or https://mta.openssl.org for information on subscribing).
9If you are unsure as to whether a feature will be useful for the general
10OpenSSL community you might want to discuss it on the openssl-dev mailing
11list first.  Someone may be already working on the same thing or there
12may be a good reason as to why that feature isn't implemented.
13
14To submit a patch, make a pull request on GitHub.  If you think the patch
15could use feedback from the community, please start a thread on openssl-dev
16to discuss it.
17
18Having addressed the following items before the PR will help make the
19acceptance and review process faster:
20
21    1. Anything other than trivial contributions will require a contributor
22    licensing agreement, giving us permission to use your code. See
23    https://www.openssl.org/policies/cla.html for details.
24
25    2.  All source files should start with the following text (with
26    appropriate comment characters at the start of each line and the
27    year(s) updated):
28
29        Copyright 20xx-20yy The OpenSSL Project Authors. All Rights Reserved.
30
31        Licensed under the OpenSSL license (the "License").  You may not use
32        this file except in compliance with the License.  You can obtain a copy
33        in the file LICENSE in the source distribution or at
34        https://www.openssl.org/source/license.html
35
36    3.  Patches should be as current as possible; expect to have to rebase
37    often. We do not accept merge commits; You will be asked to remove
38    them before a patch is considered acceptable.
39
40    4.  Patches should follow our coding style (see
41    https://www.openssl.org/policies/codingstyle.html) and compile without
42    warnings. Where gcc or clang is availble you should use the
43    --strict-warnings Configure option.  OpenSSL compiles on many varied
44    platforms: try to ensure you only use portable features.
45    Clean builds via Travis and AppVeyor are expected, and done whenever
46    a PR is created or updated.
47
48    5.  When at all possible, patches should include tests. These can
49    either be added to an existing test, or completely new.  Please see
50    test/README for information on the test framework.
51
52    6.  New features or changed functionality must include
53    documentation. Please look at the "pod" files in doc/apps, doc/crypto
54    and doc/ssl for examples of our style.
55