ContributorGuidelines

These are WIP contributor guidelines.

1. Golden rule: Please do "git log"/"git log -p" and follow the same approach with your changes. Some specifics:
2. One changed module/package per commit.
3. One logical change per commit. E.g., adding new method vs changing formatting should be 2 separate commits.
4. Every commit message starts with "<module>: "
5. Package version, dependencies, etc. info is tracked using metadata.txt file (from which setup.py is auto-generated). Changes to metadata.txt almost always should be a separate commit. (The idea is to keep code vs metadata changes separate, to minimize patch noise.) It's ok to omit metadata.txt changes for package version increase. But if you e.g. change dependencies, please include related changes in a separate commit.
6. Name something test_*.py only if it's a real unittest (which will checks results itself and will fail if there's error). Otherwise if a human should check test results, name it example_*.py.
7. We follow PEP8, except for over-tight line length limits. Lines up to 90 chars are OK. If there're good reasons, a line can be longer (consider 132 to be hard limit).
8. For new modules written, please use "" as string delimiters (double-quotes, not single-quotes '').
9. Beyond that, follow the style of the surrounding code. For example, if literal strings in a module/function use double-quotes "", use that. If single-quotes '', use that. (Double-quotes is the default style, per above.)

When porting a module from CPython or other 3rd-party source:

1. Do some research to find suitable source. CPython 3.3 stdlib should still be considered as a base version to take modules from, as more recent versions has some modules bloated, which isn't really good direction for MicroPython. (But still, try to look at different versions and sources beyond CPython (e.g. PyPy) to find the best.)
2. Start with committing 3rd-party source as-is, clearly stating in the commit message from where it was taken (exact version, preferrably with a URL to tarball, or VCS revision, preferrably with URL to it).
3. Follow up with your changes as a next commit.
4. When making your changes, the criteria should be minimizing size of a diff. Change as few lines as possible, within lines, don't change more chars than needed. Prefer commenting out to removal of lines. Don't fix typos, formatting, etc. - if you want them to be fixed, submit patches directly to upstream.
5. Prefer taking (and porting) tests from CPython rather than duplicating effort and making your own.