File: CONTRIBUTING.md

package info (click to toggle)
natsort 7.1.0-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 596 kB
  • sloc: python: 4,347; makefile: 19; sh: 4
file content (44 lines) | stat: -rw-r--r-- 2,154 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
# Contributing

If you have an idea for how to improve `natsort`, please contribute! It can
be as simple as a bug fix or documentation update, or as complicated as a more
robust algorithm. Contributions that change the public API of
`natsort` will have to ensure that the library does not become
less usable after the contribution and is backwards-compatible (unless there is
a good reason not to be).

I do not have strong opinions on how one should contribute, so
I have copy/pasted some text verbatim from the
[Contributor's Guide](http://docs.python-requests.org/en/latest/dev/contributing/) section of
[Kenneth Reitz's](http://docs.python-requests.org/en/latest/dev/contributing/)
excellent [requests](https://github.com/kennethreitz/requests) library in
lieu of coming up with my own.

> ### Steps for Submitting Code

> When contributing code, you'll want to follow this checklist:

> - Fork the repository on GitHub.
> -  Run the tests to confirm they all pass on your system.
     If they don't, you'll need to investigate why they fail.
     If you're unable to diagnose this yourself,
     raise it as a bug report.
> - Write tests that demonstrate your bug or feature. Ensure that they fail.
> - Make your change.
> - Run the entire test suite again, confirming that all tests pass including the
    ones you just added.
> - Send a GitHub Pull Request to the main repository's master branch.
    GitHub Pull Requests are the expected method of code collaboration on this project.

> ### Documentation Contributions
> Documentation improvements are always welcome! The documentation files live in the
  docs/ directory of the codebase. They're written in
  [reStructuredText](http://docutils.sourceforge.net/rst.html), and use
  [Sphinx](http://sphinx-doc.org/index.html)
  to generate the full suite of documentation.

> When contributing documentation, please do your best to follow the style of the
  documentation files. This means a soft-limit of 79 characters wide in your text
  files and a semi-formal, yet friendly and approachable, prose style.

> When presenting Python code, use single-quoted strings ('hello' instead of "hello").