Attending: Jonas, John, Scott, Heather, Einar, Ivan Notes: 1. Documentation, versioning and release cycles; coding styles 2. Coding styles and guidelines (e.g., https://spaces.internet2.edu/display/COmanage/COmanage+Coding+Style) Scott would like to see a convergence on these things. For some coding (e.g., pysaml) it’s hard to get through because of the personal undocumented conventions use. Having a consistent style would be help. Suggest starting with PEP 8 is good, but probably not sufficient. Downside is that some of the code will need to be rewritten. Perhaps a coding guide per project. It will also take time to review code against a coding guide. Code with multiple people committing (Satosa and pysaml initially) will require a style guide. For the other projects with one person developing, probably less time and effort available to make code fit the style, but probably less important.  Ivan is to work on a draft proposal for how to accept/reject projects. One of the things in there is how we evaluate projects, and part of that is the quality and documentation of code. How willing authors of code are to adapting their code is also. Alternatives to PEP 8  * the Google Python Style Guide (https://google.github.io/styleguide/pyguide.html) * flake8 * https://en.wikipedia.org/wiki/SOLID_(object-oriented_design <https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design>) Having a general structural guide is useful, but also having guidance on details (e.g., variable names) would be useful.  Need a collaboration editor so we can start drafting something; we can all write something about what we want to have and would like to see.  Action item: Heather to create a document to start on collaboration Versioning  Want to use semantic versioning. Not sure pysaml does; it has the same format, but not following the practices.  Action item: Heather to post to list to get a consensus vote on using semantic versioning Release Cycle Given that most of these projects don’t have full time people on it, can’t really enforce a standard release cycle. An example of concern is Satosa, which has had so many changes that production code often has to run against GitHub instead of an official release version. We don’t want a new release after every commit, but can we set a standard threshold? Ivan: Every new feature should be a separate release; no two new features together. It’s easier to test things. Everything that exposes a change in API, a bug fix, etc, should be a separate release. This could result in multiple releases a day. For this to work, the release process would need to be very streamlined.  Example: if you have three changes (two bug fixes and a new feature), the bug fixes are each released first in two releases, then the new feature is released incorporating the earlier releases Team is willing to try this. Combine this with semantic versioning, and it should work. Action item: Heather to take this proposal to the list to see if there’s consensus. 3. AOB Next call: January 23 (Heather to solicit agenda items on Friday)