Add "Contributing" page to docs

[deanishe]

Should cover:

• [ ] Code requirements (clear variable names, PEP8 etc.)
• [ ] Documentation requirements (write some, including docstrings)
• [ ] Dependencies for testing
• [ ] Dependencies for building documentation

[hardkrash]

Please add a section describing your desires for a python 3.7 pull request. e.g.

• Support for official package 3.7.x at python.org
• Desired path for compatibility
  1. Strict compatibility when possible.
  2. Use python-future for compatibility cases.
  3. Separate out functions at a module level for gross incompatibilities.
     • Avoid at all costs...

[deanishe]

http://www.deanishe.net/alfred-workflow/supported-versions.html#python-versions

[hardkrash]

Exactly, the sentence is “(But if you manage to add full Python 3 support without breaking 2.6, a pull request would be gratefully accepted.)”

There is an implicit term here “breaking” that I would like qualified before undertaking a porting project such as this.

I’ve made fully documented and tested changes to projects only to have “merge requests” be summarily rejected. So agreeing on what the acceptance requirements are is a good place to start.

For example, is from __future__ import print_function a dealbreaker. As it is in python 2.6.0a2 but may cause a major change in behavior that is not desired.

[deanishe]

For example, is from __future__ import print_function a dealbreaker

It's in almost every Python file in the project already…

There is an implicit term here “breaking” that I would like qualified before undertaking a porting project such as this.

Like Snow Leopard, 2.6 support is largely irrelevant at this point in time. The library is no longer tested against it (Travis dropped 2.6) and there are already several incompatibilities in the Alfred 3-only (i.e. Python 2.7-only) portions of the code.

I'd only reject a PR with Py3 support if it really fucked up the code with loads of 2/3 branches and/or there were external dependencies.

But to be very clear: I have zero interest in Py3 support until Py3 is part of macOS. I'm not interested in helping people write workflows with needless external dependencies like Py3. It's a crappy, user-hostile way of going about writing a workflow, and I don't want to encourage it.

As noted, I'll accept a PR, but not if it turns web.py (almost certainly the hardest bit to port) into an awful mess.

My personal preference would be for a Py3-only rewrite once it is included in macOS.

[NickSeagull]

Are there any kind of docs in order to understand how this library is implemented? It'd be cool to know a little bit of the implementation details (like where does the library read Alfred's data from) in order to write this contributing document