From 5b1d0dc9cd5035c679ed2706aa24534b6c3ed5d0 Mon Sep 17 00:00:00 2001
From: Andy <andyaport@gmail.com>
Date: Tue, 18 Jul 2017 18:33:00 -0700
Subject: [PATCH] added CONTRIBUTION.md -- guidelines for contributors

---
 CONTRIBUTING.md | 64 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..815c3a1
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,64 @@
+# Contributing to svgpathtools
+
+The following is a few and guidelines regarding the current philosophy, style, 
+flaws, and the future directions of svgpathtools.  These guidelines are meant 
+to make it easy to contribute.
+
+## Being a Hero
+We need better automated testing coverage.  Please, submit unittests!  See the 
+Testing Style section below for info.
+
+Here's a list of things that need (more) unittests
+* OK, well... maybe you could help by filling out this list
+
+## Submitting Bugs
+If you find a bug, please submit an issue along with an **easily reproducible 
+example**.  Feel free to make a pull-request too (see relevant section below).
+
+
+## Submitting Pull-Requests 
+
+#### New features should come with unittests and docstrings.
+If you want to add a cool/useful feature to svgpathtools, that's great!  Just 
+make sure your pull-request includes both thorough unittests and well-written 
+docstrings.  See relevant sections below on "Testing Style" and 
+"Docstring Style" below.
+
+
+#### Modifications to old code may require additional unittests.
+Certain submodules of svgpathtools are poorly covered by the current set of 
+unittests.  That said, most functionality in svgpathtools has been tested quite 
+a bit through use.
+The point being, if you're working on functionality not currently covered by 
+unittests (and your changes replace more than a few lines), then please include 
+unittests designed to verify that any affected functionary still works.
+
+
+## Style 
+
+### Coding Style
+* Follow the PEP8 guidelines unless you have good reason to violate them (e.g. 
+you want your code's variable names to match some official documentation, or 
+PEP8 guidelines contradict those present in this document).
+* Include docstrings and in-line comments where appropriate.  See 
+"Docstring Style" section below for more info.
+* Use explicit, uncontracted names (e.g. "parse_transform" instead of 
+"parse_trafo").   The ideal names should be something a user can guess 
+* Use a capital 'T' denote a Path object's parameter, use a lower case 't' to 
+denote a Path segment's parameter.  See the methods `Path.t2T` and `Path.T2t` 
+if you're unsure what I mean.  In the ambiguous case, use either 't' or another 
+appropriate option (e.g. "tau"). 
+
+
+### Testing Style
+You want to submit unittests?!  Yes!  Please see the svgpathtools/test folder 
+for examples.
+
+
+### Docstring Style
+All docstrings in svgpathtools should (roughly) adhere to the Google Python 
+Style Guide.  Currently, this is not the case... but for the sake of 
+consistency, Google Style is the officially preferred docstring style of 
+svgpathtools.  
+[Some nice examples of Google Python Style docstrings](
+https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html)