10:52 p.m.
My apologies as well. I'd thought the call was tomorrow and just saw the e-mail about
it being today.
FYI, I asked for legal review of the board agreement after our last call. I don't
have that back yet.
-- Mike
-----Original Message-----
From: Idpy-board <idpy-board-bounces at lists.sunet.se> On Behalf Of Ivan
Kanakarakis
Sent: Wednesday, December 12, 2018 12:36 PM
To: Heather Flanagan <hlflanagan at sphericalcowgroup.com>
Cc: board at idpy.org
Subject: Re: [Idpy-board] Very Informal Notes: idpy Board call, 12 December 2018
Hello everyone,
On Wed, 12 Dec 2018 at 21:15, Heather Flanagan <hlflanagan at sphericalcowgroup.com>
wrote:
Attending:
Heather, Chris, Leif
Regrets:
Christos, Roland, Mike, Ivan
I am truly sorry for not participating today. I knew the meeting was today, and I
anticipated having a final word on how we'll handle CLAs, but I was certain that the
meeting would take place at 22:00 (local time); which is exactly one hour after the
meeting actually took place.. This has happened to me before with an idpy-call and at this
point I am sure I need to find a way to cater for these timezone differences.
0. Agenda bash
Given the level of attendance, we’ll likely reuse this agenda for our next call. Heather
to send out a doodle poll to find a time in January.
Again, I'm sorry we have to do this.
1. IPR
- GÉANT and IPR (What is the relationship between IPR and the
GEANT project? The default clause in the consortium agreement is that
GEANT holds the IPR on behalf of the consortium. Need to see how that
would play out if that means handing the IPR over to a third party.
Action item for Christos to follow up on.)
From Christos: Regarding the IPR, I have discussed this in GÉANT. Unfortunately I cannot
provide a final response yet. The topic is in the hands of the GÉANT Execs at the moment.
I am nagging them to get it resolved as soon as possible.
- Draft Note Well (see email sent 11 December 2018) From Christos:
Regarding the draft note, it looks fine to me. Point 3 looks like a very high level code
of conduct. [It] is good that we something like this.
I think the draft should be added to the governance docs (or another repo to collect these
common parts shared between the projects) on github and iterate over it to make it better.
I would suggest to also ask a lawyer about the language used and wether it should be more
generic or specific. I am making some very generic comments bellow without strong feelings
about any:
Identity Python governance pages and in the GitHub
Terms of Service
Add the relevant links
in the GitHub Terms of Service
Should we
emphasise on the exact paragraph that relates to CLA?
you must disclose that fact,
change to: you are
obliged to disclose that fact
or not participate in the discussion
change to:
or restrain from participating in any discussion or process
about this.
This can be omitted.
- Next steps?
2. Review the criteria for bring in new projects to idpy (Practical
use case: evolution of pyFF)
-
https://github.com/IdentityPython/IdentityPython.github.io/wiki/Adding
-and-Removing-Software-Projects-to-idpy
From Christos: Regarding the criteria for bringing new project to idpy, I do not see
mentioning anywhere that the software has to be open source. Are all open source licenses
OK? and what about the topic of IPR?
This is a good point. It is an implicit assumption. I had written the original form of
this document, and obviously didn't feel the need to have it stated clearly at the
time. I agree we should add it.
There is a relevant section on the Governance docs:
https://github.com/IdentityPython/Governance/blob/master/DRAFT-idpy-statute…
This document could also be part of the governance (or that other-new
repo) on github.
3. TIIME?
- idpy Developers meeting @ TIIME, Monday, 11 February 2018
4. AOB
Offering a junior developer- Chris has a junior developer who will start on January 15
assigned to work exclusively on idpy project.
This is great news. Thanks.
Discuss tagging releases to make this more acceptable
for people who
are looking for mature products
Yes; this is something that is standard practice for the majority of open source projects.
A tagged commit can also be automatically converted to a github-release. For pysaml2 there
is a release guide[0] which includes how to tag a commit when making a new release. Note,
that git has two types of tags; lightweight tags are only labels on commits while
annotated tags[1] (which is what we want) are actual git objects.
[0]: https://github.com/IdentityPython/pysaml2/blob/master/release-howto.rst
[1]: https://git-scm.com/book/en/v2/Git-Basics-Tagging#_annotated_tags
Kind regards,
--
Ivan c00kiemon5ter Kanakarakis >:3
_______________________________________________
Idpy-board mailing list
Idpy-board at lists.sunet.se
https://lists.sunet.se/listinfo/idpy-board