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
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
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
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
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)
Attendees 9 January
Heather, Ivan, Rainer, Scott, Roland, Einar, Ioannis, John, Johan,
Rainer, Leif, Benn
Action item:
- Heather to get links to the mailing lists for the different components
on the website
- Ivan to post a proposal to the idpy-discuss mailing list for
adding/removing projects from idpy
- Leif and Ioannis to work on slack channel ownership
- Heather to send Benn a list of people to add to the BlueJeans invitation
Agenda bash
1. Project introduction
- Policy stuff: How do we communicate? Where should issues be reported?
* idpy-discuss for general discussion; will send meeting information
to this list
* the other technical components also have their own lists (e.g.,
satosa-dev)
*
o pysaml
o pyoidc library is in a bit of a special place as Roland works
for Google on this library in the different languages. Roland
would like to retire the current pyoidc, which has implications
for other idpy projects like Satosa, that will need to be
updated to point to the newer libraries. Google will be at the
heart of maintaining the newer libraries going forward.
* Suggest consolidating slack spaces - Ioannis
- The community: Who is using our projects? How we communicate with
these entities? How can they get involved? What are their concerns?
- The competition: We offer a product, but there are other tools
that can satisfy one's requirements. What are we doing differently and why.
2. Project governance (Leif, Heather)
* Google has an opinion on governance. The problem is they want idpy
to handle all three libraries, not just the python library. This is
still under discussion. One suggestion is the OIF.
*
o Heather to talk to Adam Dawes @ Google to discuss what they
would like to see, what kind of stability do they need to find
an organization
* Everything will be in an open source license
* Who owns idpy? Who holds the copyright? What country is this based in?
* Currently looking at NLNet / Commons Conservancy and others as
possible hosts for the project, a neutral third party
* One possibility is to standardizing on the architecture (API spec),
but not the language
*
o Roland to discuss with OIF so we can have a cross-language API
for pyoidc
o This is independent of idpy governance
3. Project technical details
- Project goals and roadmap(s)
* the different projects have their own architects; there is no
overarching architect for idpy
*
o Discuss the dependencies in Vienna (1-2 hours)
o Are there missing parts/additions we could incorporate/develop?
This will come out of the discussion in Vienna as well
4. Review GitHub (does it have all the projects it's supposed to?) -
https://github.com/IdentityPython
* It does not have everything; will aim for moving things after Vienna
* What is the consensus process for accepting new work into idpy?
*
o Proposal: someone other than the project maintainer proposes a
project to the list; we collect +1s and aim for rough consensus
o
+ taking something in means we are responsible for maintaining it
+ removing things from idpy means that no components we use
are impacted (this will take longer than taking things in)
+ Ivan to draft a proposal for the process and post to to the list
5. TIIME planning (Rainer, Heather)
Proto agenda:
* any open pull requests (see Rainer’s PR)
* release policies (will we have a regular release cadence?)
* refactoring (e.g., logging in Satosa)
* coding guidelines
* other items to be added as we build agenda on site
* Note that each project may need dedicated time
6. Administrivia
- call schedule and platform for 2018- future call
7. AOB
Agenda for next call: Brainstorm on requirements or goals for
documentation, versioning and release cycles, common coding guidelines
The number of registration is zero, because I failed to define a ticket for the event :-^(.
I have seen registrations from Heather, Roland and Scott for other tracks, so there is no need for you to act. Everybody who plans to join else please register.
https://tiimeworkshop.eu/
Thanks,
Rainer
Hello all,
The process of setting up a call fell off the radar, but hopefully the
poll results for a decent time slot for a regular, biweekly call still
works for most.
The proposal is to have a a biweekly call starting Tuesday, December 5 @
15:00 GMT+1. This will give us four calls (five if we really want to
meet on January 2) between now and TIIME.
DRAFT AGENDA (Please add your topics to the thread)
* Introductions
* Planning for the TIIME workshop (what do you want to get out of it?)
* Project governance status
* Current coding priorities
Does anyone have a particular preference for video conference tools? We
could use Google Hangouts, Skype, or someone could volunteer something
(Lifecloud?)
Dear all,
I am pleased to announce that Heather Flanagan [1] has been funded by
the National Institute of Health's National Institute of Allergies and
Infectious Diseases (NIH NIAID) to act as the project manager for the
Identity Python project. This represents a major step for the project
and will enable us to move forward more quickly and will also help us
establish the Identity Python governance and organizational structure
needed for long-term sustainability of the project.
[1] https://www.linkedin.com/in/hlflanagan/
Cheers Leif
