Maintenance and Contributing

_I am continuing our conversation from #128._

@3b1b, @cclauss has provided a great checklist (https://docs.python.org/3/howto/pyporting.html). One of the most important points is to add continuous integration to ensure you maintain compatibility when supporting both Python 2.7 and 3.x. @vors has begun these efforts with #162. There are no tests for this library, but running a script that exercises a significant portion of the codebase is better than nothing.

From the general maintenance standpoint, it may help contributors if you do the following:

1. Document how people can contribute. This can be as simple as a part of the README advising folks to file issues, open PRs, and mention you to get your attention. edX (my former employer) goes to a lot greater detail (https://github.com/edx/edx-platform/blob/master/CONTRIBUTING.rst), but don't be overwhelmed as you don't need to be that detailed.

2. Define an [SLA](https://en.wikipedia.org/wiki/Service-level_agreement) for responding to PRs. I try to respond to PRs for https://github.com/jsocol/django-waffle within 24 hours. This works for me because I'm pretty much always in front of an Internet-connected computer. If you want to do weekly reviews, that's fine. Just be cognizant of the fact that prolonged feedback loops may lead to frustration. Regardless of the SLA, _communicate_ it in the README/contributor's notes.

3. Consider giving others merge rights to share some of the maintenance burden. My offer to help remains; however, I don't use this library (I only stumbled across it due to a rant elsewhere). I would nominate folks like @vors or @cclauss, who have actually taken steps to improve the project in the form of pull requests, to help with maintenance.