blob: b4c72ba4e1b640878fa1b45b42b7ca560d5a830e [file] [log] [blame]
Alex Gaynorc72e63f2013-09-09 21:44:26 -07001Contributing
2============
3
4Process
5-------
6
7As an open source project, ``cryptography`` welcomes contributions of all
8forms. These can include:
9
10* Bug reports and feature requests
11* Pull requests for both code and documentation
12* Patch reviews
13
Alex Gaynor2c67c822013-09-09 23:44:13 -070014You can file bugs and submit pull requests on `GitHub`_. To discuss larger
Alex Gaynorc72e63f2013-09-09 21:44:26 -070015changes you can start a conversation on `our mailing list`_.
16
17Because cryptography is so complex, and the implications of getting it wrong so
18devastating, ``cryptography`` has a strict code review policy:
19
20* Patches must *never* be pushed directly to ``master``, all changes (even the
21 most trivial typo fixes!) must be submitted as a pull request.
22* A committer may *never* merge their own pull request, a second party must
23 merge their changes. If multiple people work on a pull request, the merger
24 may not be any of them.
25* A patch which breaks tests, or introduces regressions by changing or removing
26 existing tests should not be merged. Tests must always be passing on
27 ``master``.
28* If somehow the tests get into a failing state on ``master`` (such as by a
29 backwards incompatible release of a dependency) no pull requests may be
30 merged until this is rectified.
31
32The purpose of these policies is to minimize the chances we merge a change
33which jeopardizes our users' security.
34
35We do not yet have a formal security contact. To report security issues in
36``cryptography`` you should email ``alex.gaynor@gmail.com``, messages may be
37encrypted with PGP to key fingerprint
38``E27D 4AA0 1651 72CB C5D2 AF2B 125F 5C67 DFE9 4084`` (this public key is
39available from most commonly-used keyservers).
40
41Code
42----
43
44When in doubt, refer to `PEP 8`_ for Python code.
45
46Every code file must start with the boilerplate notice of the Apache License.
47Additionally, every Python code file must contain
48
49.. code-block:: python
50
51 from __future__ import absolute_import, division, print_function
52
53Documentation
54-------------
55
56All features should be documented with prose.
57
58Docstrings should be written like this:
59
60.. code-block:: python
61
62 def some_function(some_arg):
63 """
64 Does some things.
65
66 :param some_arg: Some argument.
67 """
68
69So, specifically:
70
71- Always use three double quotes.
72- Put the three double quotes on their own line.
73- No blank line at the end.
74- Use Sphinx parameter/attribute documentation `syntax`_.
75
76
Alex Gaynor2c67c822013-09-09 23:44:13 -070077.. _`GitHub`: https://github.com/alex/cryptography
Alex Gaynorc72e63f2013-09-09 21:44:26 -070078.. _`our mailing list`: https://mail.python.org/mailman/listinfo/cryptography-dev
79.. _`PEP 8`: http://www.peps.io/8/
80.. _`syntax`: http://sphinx-doc.org/domains.html#info-field-lists