CONTRIBUTING

   1 HOW TO CONTRIBUTE PATCHES TO OpenSSL
   2 ------------------------------------
   3
   4 (Please visit https://www.openssl.org/community/getting-started.html for
   5 other ideas about how to contribute.)
   6
   7 Development is coordinated on the openssl-dev mailing list (see the
   8 above link or https://mta.openssl.org for information on subscribing).
   9 If you are unsure as to whether a feature will be useful for the general
  10 OpenSSL community you might want to discuss it on the openssl-dev mailing
  11 list first.  Someone may be already working on the same thing or there
  12 may be a good reason as to why that feature isn't implemented.
  13
  14 To submit a patch, make a pull request on GitHub.  If you think the patch
  15 could use feedback from the community, please start a thread on openssl-dev
  16 to discuss it.
  17
  18 Having addressed the following items before the PR will help make the
  19 acceptance 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 available 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/man[1357]
  54     for examples of our style.