plan B - a process to accept pull requests and do proper releases * No development on the master. * Unit tests must pass before merged into Master. A test may need to be written to validate; a test is always required. * o Measure test coverage with Coverall (?). If the new code (bug fix or RFE) comes in on a place with few tests, then need test needs to be written. If there are a lot of tests, then committer should at least look at the test to see if it is likely to be valid. * Each version has to be tagged with dependencies * Peer review - someone posts to the list, describes how/why and points to a pull request; at least one approver (and the approver has to be someone who is approved to commit code and who isn’t a member of the same organization) * Stable releases should be posted to PyPI