1# Contributing
2
3This document outlines the ways to contribute to `python-dateutil`. This is a fairly small, low-traffic project, so most of the contribution norms (coding style, acceptance criteria) have been developed ad hoc and this document will not be exhaustive. If you are interested in contributing code or documentation, please take a moment to at least review the license section to understand how your code will be licensed.
4
5## Types of contribution
6
7### Bug reports
8Bug reports are an important type of contribution - it's important to get feedback about how the library is failing, and there's no better way to do that than to hear about real-life failure cases. A good bug report will include:
9
101. A minimal, reproducible example - a small, self-contained script that can reproduce the behavior is the best way to get your bug fixed. For more information and tips on how to structure these, read [StackOverflow's guide to creating a minimal, complete, verified example](https://stackoverflow.com/help/mcve).
11
122. The platform and versions of everything involved, at a minimum please include operating system, `python` version and `dateutil` version. Instructions on getting your versions:
13    - `dateutil`: `python -c 'import dateutil; print(dateutil.__version__)'`
14    - `Python`: `python --version`
15
163. A description of the problem - what *is* happening and what *should* happen.
17
18While pull requests fixing bugs are accepted, they are *not* required - the bug report in itself is a great contribution.
19
20### Feature requests
21
22If you would like to see a new feature in `dateutil`, it is probably best to start an issue for discussion rather than taking the time to implement a feature which may or may not be appropriate for `dateutil`'s API. For minor features (ones where you don't have to put a lot of effort into the PR), a pull request is fine but still not necessary.
23
24### Pull requests
25
26If you would like to fix something in `dateutil` -  improvements to documentation, bug fixes, feature implementations, fixes to the build system, etc - pull requests are welcome! Where possible, try to keep your coding to [PEP 8 style](https://www.python.org/dev/peps/pep-0008/), with the minor modification that the existing `dateutil` class naming style does not use the CapWords convention, or where the existing style does not follow PEP 8.
27
28The most important thing to include in your pull request are *tests* - please write one or more tests to cover the behavior you intend your patch to improve. Ideally, tests would use only the public interface - try to get 100% difference coverage using only supported behavior of the API.
29
30#### Changelog
31To keep users abreast of the changes to the module and to give proper credit, `dateutil` maintains a changelog, which is managed by [towncrier](https://github.com/hawkowl/towncrier). To add a changelog entry, make a new file called `<issue_no>.<type>.rst` in the `changelog.d` directory, where `<issue_no>` is the number of the PR you've just made (it's easiest to add the changelog *after* you've created the PR so you'll have this number), and `<type>` is one of the following types:
32
33- `feature`: A new feature, (e.g. a new function, method, attribute, etc)
34- `bugfix`: A fix to a bug
35- `doc`: A change to the documentation
36- `deprecation`: Used if deprecating a feature or dropping support for a Python version.
37- `misc`: A change that has no interesting effect for end users, such as fixes to the test suite or CI.
38
39PRs that include a feature or bugfix *and* a deprecation should create a separate entry for the deprecation.
40
41
42
43> {description of changes}. Reported by @{reporter} (gh issue #{issue\_no}). Fixed by @{patch submitter} (gh pr #{pr\_no})
44
45An example changelog entry might be:
46
47**581.bugfix.rst**
48```
49Fixed issue where the tz.tzstr constructor would erroneously succeed if passed
50an invalid value for tzstr. Reported by @pganssle (gh issue #259). Fixed by
51@pablogsal (gh pr #581)
52```
53
54For bugs reported and fixed by the same person use "Reported and fixed by @{patch submitter}". It is not necessary to create a github issue just for the purpose of mentioning it in the changelog, if the PR *is* the report, mentioning the PR is enough.
55
56## License
57
58Starting December 1, 2017, all contributions will be assumed to be released under a dual license - the [Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0) and the [3-Clause BSD License](https://opensource.org/licenses/BSD-3-Clause) unless otherwise specified in the pull request.
59
60All contributions before December 1, 2017 except those explicitly relicensed, are only under the 3-clause BSD license.
61
62
63## Development Setup
64
65### Using a virtual environment
66
67It is advisable to work in a virtual environment for development of `dateutil`. This can be done using [virtualenv](https://virtualenv.pypa.io):
68
69```bash
70python -m virtualenv .venv      # Create virtual environment in .venv directory
71source .venv/bin/activate       # Activate the virtual environment
72```
73
74Alternatively you can create a [conda environment](https://conda.io/docs/user-guide/tasks/manage-environments.html):
75
76```bash
77conda create -n dateutil                # Create a conda environment
78# conda create -n dateutil python=3.6   # Or specify a version
79source activate dateutil                # Activate the conda environment
80```
81
82Once your virtual environment is created, install the library in development mode:
83
84```bash
85pip install -e .
86```
87
88This will allow scripts run in your virtual environment to use the version of `dateutil` in your local directory. If you also want to run the tests in your local directory, install the test dependencies:
89
90```bash
91pip install -r requirements-dev.txt
92```
93
94## Testing
95
96The best way to test `dateutil` is to run `tox`. By default, `tox` will test against all supported versions of Python installed on your system. To limit the number of tests, run a specific subset of environments. For example, to run only on Python 2.7 and Python 3.6:
97
98```bash
99tox -e py27,py36
100```
101
102You can also pass arguments to `pytest` through `tox` by placing them after `--`:
103
104```bash
105tox -e py36 -- -m tzstr
106```
107
108This will pass the `-m tzstr` parameter to `pytest`, running only the tests with the `tzstr` mark.
109
110The tests can also be run directly by running `pytest` or `python -m pytest` in the root directory. This will be likely be less thorough but is often faster and is a good first pass to check your changes.
111
112All GitHub pull requests are automatically tested using [Travis](https://travis-ci.org/dateutil/dateutil/) and [Appveyor](https://ci.appveyor.com/project/dateutil/dateutil).
113