Attending: Johan, Ivan, Rainer, Heather, Christos, Scott Regrets: Roland https://bluejeans.com/163562895 <https://bluejeans.com/163562895?src=join_info> Notes: 1. Governance update a. Commons Conservancy - now officially under the care and feeding of the Commons Conservancy b. Note Well and licensing by repository and/or license in each file - this sounds like an overcomplication. Ivan’s take is that having a license per file is actually not a good practice, and the open source community is moving away from that. If you are using files someone else has developed, you usually import the whole project and not just individual files. Another problem - licensing a project is more than code files. It’s also documentation, HTML files, binary files, etc. You can’t always add headers to those types of files. Proposal: have a structure with a single file where you declare the licensing and copyright for the whole project. All of our projects already have this for the license, though the attribution/copyright may be different. There may also be different licenses (apache and 2-clause BSD), and while we prefer apache it is not required. Where we have the 2-clause BSD, those files should be updated to include that name. 2. Code releases - speed vs stability? Right now, Ivan has to do PR review, making sure the change fits the general strategy that Satosa (and other projects) have for the future, and also think about other things like code quality, etc. This is a very big job for one person. Proposal - flag something that works but that could use some improvement. Alternatively - allow for more breaking changes. Also worth noting that there has been a lot of code changes (many PRs accepted) but not an actual code release. Open question: would there be code releases with the ugly code in there? In eduTEAMS they do allow that - as long as it works, it can be released. But they note what needs to be cleaned up later. (The downside: accruing technical debt fairly quickly) Scott points out that the code has greatly improved since Ivan started. But he still has functionality that is needed, it exists in an older PR, how should he handle this? Also, it’s hard to work with clients when there aren’t regular releases (that just need “pip install” to get working code). Ivan has the concern about introducing breaking changes as PRs are accepted at one stage, but then have to be redone and introduce breaking changes later. Are we ok with that? a. Resources (do we have enough if we use them well? If not, what are we asking the idpy Board for?) Scott asks: Is there enough effort outside of eduTEAMS for Satosa? Right now, eduTEAMS both funds Ivan (as does SUNET) and eduTEAMS uses Satosa. If eduTEAMS dropped Satosa, Ivan would still need to dedicate time to Satosa and balance that work. eduTEAMS is also trying to train more developers to be good enough to push their code back upstream, though they are not quite there yet. Final answer: Ivan should not get hit by a bus, and we can not use additional resources effectively at this time. 3. GitHub review - discussed after note taker left a. pySAML2 - https://github.com/IdentityPython/pysaml2 <https://github.com/IdentityPython/pysaml2> b. Satosa - https://github.com/IdentityPython/SATOSA <https://github.com/IdentityPython/SATOSA> c. pyFF - https://github.com/IdentityPython/pyFF <https://github.com/IdentityPython/pyFF> d. ... 4. AOB Next call: 28 May 2019 (HF unavailable)

Great agenda covering key governance and release questions. Also, interesting discussion around project stability and GitHub reviews. Check this out too: <a href="https://vape4usa.com/blogs/news/how-to-identify-genuine-vs-fake-… target="_blank">how to identify genuine vs fake Lost Mary vapes</a>.