January 2018 - Idpy-discuss

Proposal policy to add/remove projects on idpy.org

by ivan.kanak＠gmail.com

Hi everyone, The problem we are trying to address is «the process to decide whether to add or remove a project on idpy.org.» The following is a draft I put together based on the discussion we had on the call at 09 Jan 2017. Feel free to change it and enchant it in any way that you think will make the process smoother. # Project addition Accepting the project means accepting the responsibility to maintain it, and push to fulfil its short and long term goals. How do we make sure it can do this, and we can help? This is what I'll try to outline bellow. So, a project is proposed to be added: ## Proposal format The first thing we need to define is the format of the proposal. Ideally, I would like to see: + Introduction of the maintainer(s): Introduction could be just a hello from the person in charge. and a minimal message on that person's availability in relation to the project development. We do not collect projects, we want the people that develop those to keep doing that and have them become part of the organisation and their project part of the ecosystem. + Project goals & future: Project goals are in direct relation to the project's future. Their relation with idpy.org goals are the first thing to make sure is aligned. + How it relates to idpy.org: Is there another project that is using the new one as a dependency or enhancement? Is there a relation to a more generic AAI concept? We want to know! + Current project state: - How far is the project from its goals? - What are the problems it is facing (technical / community / dedication-time)? + Project metadata: - URL to project website - URL to project source code - URL to project ticketing-system (issue tracker) - URL to project license - Communication channels (mailing-list, slack, irc, etc) While all these might seem like too much bureaucracy, each of these sections could be a couple of lines or even mangled together in a couple of paragraphs. Once we have such a proposal we should evaluate the project and come to a conclusion. Bellow are some of the aspects I propose we must take into account. ## Technical quality Is there an architecture document? How much work is needed to be incorporated with our coding standards and practices? Does it have (updated) documentation? Does it have tests? Does it have a CI setup? What other projects does it depend on? What is going on in the ticketing system (number of bugs and general activity)? ## People quality This is a lot harder to judge, but very important. The community is vital to the organisation's lifecycle. Growing the organisation means growing the community and accepting more people in its core. While we cannot prevent people from fighting over (many times even non-)technical aspects, we can make a priority to make the community feel safe. Thus we must take notice of how communicative the new project's maintainers are, what the project's culture is, and whether this fits to the form of the environment we want to create - an environment where people are polite and try to understand rather than dominate. This is of course twofold - it is the same thing the other way around. We are dealing with work done by other people. We must respect that and be grateful that they put time in this. In simpler terms, it is better to not reply to an issue/question/email, if one is irritated, in hurry or stressed. None should feel forced to answer or pressured to keep with others' pace. ## Organisation stability While a project may fit perfectly, we should always keep in mind what the organisation's pace is, and how many things it can process at the same time. Growing should come in a steady fashion to avoid people getting overwhelmed. Enthusiasm is great and needed but should be kept in reason with pragmatism. There is always a right time to do more. We should not be afraid to reject even good looking matches, as doing so does not mean that there is no way of even having that chance again. The same way we require a project to be in a certain form to be accepted, the same requirement is on us to be in a state to accept that project. To put it in another way, the organisation should help its project move forward, and give tools and services to the community. If it is in a state that is struggling, then accepting a new project does not help neither party. ## Discussion and consensus Everyone should do their homework, go through this list and then decide whether they think it is a good idea and timing to accept the project. While a message outlining their basic reasoning is wanted, a simple +1 or -1 should suffice. Keep in mind that a "-1" is *important to express*. It is very common to only see +1 replies, accept the new thing, and then being into a situation where many people do not like the new state but never expressed it. In the long run, this will lead to problems within the organisation. My view on this is that it is many times harder to express rejection as it seems to place people in a position where they have to explain themselves. I reject this as a belief, and consider both +1 and -1 equally important and available with no justification. I cannot understand how a +1 should be self explanatory, while -1 should not. So I urge people to freely chose what they think is best for the organisation at the time of the proposal and do express themselves. ## Process duration We should put a limit on the overall process duration and at some point come to a final conclusion. I do not have a good estimate, I'd guess 4 weeks should be enough, even for people who may want to have a say but are away on vacation etc. Needless to say, that the community members must trust the decisions of other members, and as such should not demand that they are present in every process. As pragmatists (are we?), rough consensus is what we are striving for - unanimity is pretty hard to achieve. ## Aftermath - Set a member responsible for the overall supervision of the project (the existing maintainer(s) most probably). - Announce the conclusion to our communication channels (announce-mailing-list, slack, website, blog, twitter, etc) whatever the conclusion is. Transparency is important for the community as it builds trust and portrays a certain level of maturity. - Incorporate the code: Add project under the github organisation - Incorporate the people: Add members to the appropriate lists and other tools (github policies, travis, slack channels etc) - Open appropriate issues to integrate the new project with existing projects. - Add to the projects roadmap anything related to the organisation or things that come up in the proposal discussion. # Project removal Removing an existing project should follow the same process. The difference is that if decided, the actual process needs planning. The project might be a dependency or part of another project, and as such it should either be replaced (no functionality lost) or removed in way that users and services are not affected. The same way we want a steady removal of that project, the same thing will be wanted by other people that could be using this. We should reach out to project we know that they are using that component and ask them to either adopt it, or replace it. A good experiment for this will be the replacement of pyoidc/oic from satosa (if we decide this) and the integration with the new libs by Roland and Google. That's all for now. Do tell me what you think and as said before, feel free to alter and enhance this. Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 2 months

6
6
0 0

Coding style. Was: Re: Notes: idpy dev meeting, 16 January 2018

by ivan.kanak＠gmail.com

Hi all, > 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) flake8[0] is a wrapper that is enforcing a coding style using PEP8, and additionally does code analysis using pyflakes to catch bugs (eg undeclared variables) or leftovers (eg unused variables). It integrates well with different IDEs and also with the Syntastic vim plugin[1]. This article[2] goes into some details about flake8, PEP8 and pyflakes. I would strongly recommend to start using flake8 and progressively make style-changes to the code. SOLID is not related to coding style directly, but more to the principles which form a program structure - how interfaces are built, how components are separated, etc PS: I haven't looked into google's styleguide yet. [0]: http://flake8.pycqa.org/en/latest/manpage.html [1]: https://github.com/vim-syntastic/syntastic [2]: https://blog.sideci.com/about-style-guide-of-python-and-linter-tool-pep8-py… Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 2 months

3
9
0 0

Notes, idpy dev meeting, 23 January 2018

by hlflanagan＠sphericalcowgroup.com

Attendees: Scott, John, John, Ivan, Roland, Heather Notes: Coding style 1. flake8 and SOLID not mutually exclusive? 2. Any objections we should consider against PEP8/flake8? PEP8 is a start, but need some higher level constraints on things like variable names. Google’s style guide builds on top of PEP8. Perhaps use both? Homework for people to study before TIIME - if you’re not familiar with any of the above, please look them over and be prepared to offer an opinion as to whether using PEP*+flake8 and the Google coding guide should be adopted for idpy projects. Do we want to rely on autogenerated documentation on the code? Any guidance we want to apply? Roland is using Sphinx for some of his projects. Add to discussion at TIIME Incubator program - Ivan’s proposal vs following the model of one of the existing incubators Discuss at TIIME TIIME agenda * separate email AOB Google would like OIDF to host the libraries Roland is working on. Not sure what that means with regards to using GitHub to maintain (since OIDF doesn’t have a GitHub space). Roland would still like the python libraries in idpy. Not sure what Google would think about that (though they probably want everything in one space). What if they were offered a spot on the idpy board? There are many dependencies between them, which means hosting across different orgs would be unreasonably complicated. Next meeting @ TIIME (Cancel next week’s call)

6 years, 3 months

2
1
0 0

UPDATED: Agenda for idpy dev meeting @ TIIME

by hlflanagan＠sphericalcowgroup.com

Logistics: Monday, 5 February 2018, Room E, 13:00-17:30 Tuesday, 6 February 2018, Room E, 09:00-12:30, 13:30-16:00 (if needed) Topics to cover: * Policy to add/remove projects on idpy.org <http://idpy.org> (see email 17 January 2018) * Technical harmonization: project may need dedicated time, and we need to decide which projects fall under the idpy umbrella, including discussions on who is the tech lead for each, what the project maturity levels are, where we need to target refactoring of code * o pyOP o pyOIDC o OICcli o OICmsg o pyJWKEST o Satosa* o pySAML o pyff* * Consensus call on coding style: PEP8 enforced by flake8, with Google’s guide offering the additional detail guidance * Autogenerating documentation - Sphinx <https://pythonhosted.org/an_example_pypi_project/sphinx.html>? Other? * Governance and timetable * Any open pull requests 5 February 2018 13:00-14:00 - Introduction, agenda building 14:00-17:00 - open 17:00-17:30 - review action items from the day 6 February 2018 09:00-10:00 - Governance 10:00-10:30 - agenda building 10:30-12:30 - open 13:30-15:30 - open 15:30-16:00 - review action items from the day * Satosa and pyff to be covered on day 2

6 years, 3 months

1
0
0 0

unconference proposal for idpy @ TIIME

by hlflanagan＠sphericalcowgroup.com

Hi all, An FYI that I've submitted an unconference proposal to discuss the idpy project (governance, what projects make up idpy) at TIIME. I suspect we may want one or two more proposals to specifically discuss Satosa, pyff, and/or the other projects that (probably) make up idpy. -Heather (P.S. I also submitted proposals on RA21 and the REFEDS 2018 workplan.)

6 years, 3 months

1
0
0 0

DRAFT: agenda for idpy dev meeting @ TIIME

by hlflanagan＠sphericalcowgroup.com

Hi all, Obviously we'll do a fair bit of agenda building on site, but this list should give us a sense of what we need to cover and how much time we have. Does anyone have topics they would like to add, or want to propose a more precisely defined schedule in advance? ----- Logistics: Monday, 5 February 2018, Room E, 13:00-17:30 Tuesday, 6 February 2018, Room E, 09:00-12:30, 13:30-16:00 (if needed) Topics to cover: * Technical harmonization: project may need dedicated time, and we need to decide which projects fall under the idpy umbrella, including discussions on who is the tech lead for each, what the project maturity levels are, where we need to target refactoring of code * o pyOP o pyOIDC o OICcli o OICmsg o pyJWKEST o Satosa o pySAML o pyff * governance * any open pull requests 5 February 2018 13:00-14:00 - Introduction, agenda building 14:00-17:00 - open 17:00-17:30 - review action items from the day 6 February 2018 (maybe have the open time be split between each project?) 09:00-10:00 - Governance 10:00-10:30 - agenda building 10:30-12:30 - open 13:30-15:30 - open 15:30-16:00 - review action items from the day

6 years, 3 months

2
2
0 0

nominate pyFF, pyXMLSecurity, and pyeleven for IdentityPython

by skoranda＠gmail.com

Hi, I would like to nominate pyFF, pyXMLSecurity, and pyeleven to be included under the IdentityPython umbrella and in particular move to the IdentityPython GitHub account. The pyFF + SATOSA combination has become critical infrastructure for a number of research projects that I am working with to leverage federated identity. I have dialogued with Leif and he is willing to move the projects under the IdentityPython umbrella. Please +1 if you support the motion. Thanks, Scott K

6 years, 3 months

5
4
0 0

Proposal: idpy versioning

by hlflanagan＠sphericalcowgroup.com

There were two ideas related to versioning and release cycles coming out of today's call: 1. Use semantic versioning for all projects. 2. Every new change (e.g., bug fix, feature enhancement) should be a separate release. We can discuss further at the TIIME workshop, but if folks have strong opinions one way or the other, it would be good to start discussion on the list. Thoughts? Feel free to [+|-]1 -Heather

6 years, 3 months

3
2
0 0

Communication channels. Was: Re: Notes: idpy dev meeting, 9 January 2018

by ivan.kanak＠gmail.com

Hey everyone, On 16 January 2018 at 16:00, Ioannis Kakavas <ikakavas at protonmail.com> wrote: > We touched upon adding more people (Leif) as owners for the pysaml2-dev and > satosa-dev channels on Slack too > That's what we discussed, iirc. > pysaml2-dev.slack.com > > > satosa-dev.slack.com > > Since Leif wasn't a member in either of those, I made Ivan an owner for now. > Thanks for that. I've been on those channels for some time now, and they are both quiet enough. I would propose to have a single slack channel (idpy.slack.com maybe?) and have separate channels for each project (that want to have a channel) - plus the "random" channel for slacking :) , one for github integration (broadcasting code changes, commits, testing results), and another for announcements (new releases). I would also propose to have an idpy-announcements mailing-list, with only announcements of new project releases, or changes in the organisation (additions or removals of projects and people) -- that is strictly announcements, not discussions -- ideally replies should be ignored by the list. This would make management and coordination easier across the different projects and project-communities. It will give an easier overview of what's happening and will allow external people to subscribe to only the vital parts that they may care for (project announcement). Usually announcements can be posted on a blog or twitter as yet-another communication channel. This is a process that should be automated and a trigger will post to all those channels at the same time. To close this, this is definitely not a high-priority thing. If we agree on that, I think we can steadily start moving to that direction. But, lets discuss it first. Are people comfortable using a single slack channel? How do project maintainers feel about that? And if we go forward, can we merge message histories? Should we contact slack for help with something like that? Cheers, -- Ivan c00kiemon5ter Kanakarakis >:3

6 years, 3 months

3
2
0 0

Notes: idpy dev meeting, 16 January 2018

by hlflanagan＠sphericalcowgroup.com

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)

6 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Idpy-discuss January 2018