Table of Contents

Date

07 Mar 2017

Attendees

Actions items from previous meetings

• Former user (Deleted): work with Maurizio Pillitu to finalise CI / CD of symphony-java-client against the ODP
• Former user (Deleted): come back to Former user (Deleted) with feedback on third point of proposed revisions to Desktop Wrapper WG charter

Agenda

Meeting notes

• No quorum (3/5 project leads)
• Peter: Mau has a hard stop at half past the hour, so we'll start with him
  
  • Mau: I was looking at the activation criteria on the wiki and noticed there aren't any quality criteria listed there.  "Quality" can vary by project, so it might be challenging to come up with some constant criteria.  The Foundation has started looking at the Core Infrastructure Initiative, which is an interesting project for these needs.  They aim to take a "collaborative, pre-emptive approach to strengthening cyber-security", and their offering includes not only security, but also quality and legal compliance.  They have a sub-program called the "CII Best Practices Badge Program".  If ESCo is interested to move ahead with this, our recommendation would be to move on two parallel tracks:
    • Facilitate a conversation with the CII team and invite someone from their team to speak here at a future ESCo and give an overview of CII and the badge program.  I think the CII team is in touch with Gab and Peter already (they met at the recent Linux Foundation Open Source Leadership Summit), and they're keen to hear feedback from us on the open source challenges in financial services.
    • I can work with project leaders, starting from active projects, to apply for a CII badge, so that we can see how it works.  I can then feedback to ESCo (gap analysis etc.).
  • Lawrence: my $0.02 from taking a quick look is that it seems to me like a good idea.  A lot of this is motherhood and apple pie points, but I think it's very much aligned to what I would expect best practices to look like, and it's nice to have it all bundled together.  Being able to tell LLC customers & Foundation participants that we have a program that's aligned with and certified with industry best practices is a good idea.  I would suggest the first step is a check of our processes against this list to see if we have a view of what the gap analysis is, so that we have an idea of what we're undertaking to implement this.  I would do this before we have them pitch ESCo.  I suspect my colleagues on ESCo are going to agree that it's a good idea, so there probably won't need to be much "selling".  The other thought I'd have is that any procedural practice modifications we have to do be socialised with the most active projects - the LLC projects, the IHS Markit projects, etc. - so that some of the procedural steps around release notes etc. can be followed.  Short answer is that I think it's pretty compelling, and is something of a no-brainer.
  • Mau: This is also a good way to scale out and reach out to all of our projects to go through the badging process.
  • Frank: just looking at it, but I think it's an accomplishment if you can get the badge.  I'm worried about the overhead about the requirements to move forward.  I want to make sure the barrier to entry, especially to incubation, is low.  And if we can focus on helping incubating projects attain the badge before they go for activation, the better.  I want the activation criteria to also be low, while achieving best practices.  But how can we (ESCo) help the community get to these levels?  How much of this do we set in stone?
  • Peter: and to confirm, we're looking at CII for activation, not incubation - our general philosophy is to make incubation as pre-requisite free as possible.
  • Lawrence: a good example might be: would the symphony-java-client meet the criteria, or is there a gap?  If we go for the badge, what would it look like for a project we have today?
  • Frank: I'm happy with using symphony-java-client as a guinea pig to get it to that level.
  • Lawrence: I'd like to do that with some of the LLC projects too.  We need to be prepared to follow open source development practices - we just need to go through the due diligence.
  • Peter: Mike I'd be keen to hear your thoughts on the compatibility of this to the LLC's development model?
  • Mike: the devil is in the details, but nothing is immediately obvious that's incompatible.  We're also going through a major shift in our development model - introducing CI / CD process with higher unit & integration testing thresholds.  I agree in general, but don't want to put any additional load on our development model right now.  As long as it's not required for incubation stage, there's no problem.  In general this is the right approach, but there's quite a lot of detail on this website that I need to review.  In general we should move forward on a trial basis and see how it goes.  If Frank is willing to sign up as a guinea pig then let's do it!
  • Mau: Thanks Mike.  Frank I guess we'll follow up on this? 
  • Peter: just to clarify, we're not going to hold up symphony-java-client activation for this though?
  • Mike: nope
  • Frank: nope
  • Mike: Mau do you have examples of other open source projects that have this badge already?
  • Mau: I see several Linux Foundation projects with the badge, but this is one of the things I've been working on.  I'll get back to you with more info on that.
  • Mike: this would lend credibility (or not) to this program.
  • Frank: in looking at this wrt symphony-java-client I think we have a good portion of this, but we'll fall short in some areas.  The core of the criteria seems to be here: 
  • Mau: the list of badged projects is here 
  • Mike: GitLab, OpenSSL, ... - well OpenSSL is not a shining star for security compliance!  
  • Lawrence: though OpenSSL was only certified last year, so hard to blame CII for what happened before that!     This is a lot of stuff - there are a lot of good projects here.
• Action item review:
  • Frank: CI/CD is in place for symphony-java-client.  We're using Maven integration plugin and doing simulated testing between two bots that communicate with each other on the ODP.  There's communications going on between those two bots that test the feature set of symphony-java-client.  We've successfully implemented that and it runs on commit.  Primary use cases have been added to these integration tests.
  • Frank: don't have an update on the Desktop Wrapper WG charter action.  I think this was related to impacts to the LLC?  I'll follow up with James.
• Failed votes due to lack of quorum
  
  • Peter: last week we had two votes fail, both due to lack of quorum.  No specific request or recommendation here, beyond raising this with ESCo and seeing if it deserves further discussion.
  • Frank: well emails are emails.  I personally haven't had an issue with responding to them.  I don't know if others have issues with email responses.4
  • Laurence: you're at 97% response rate, and I'm at 89%.  The thing I'm taking away from it is that it's not statistically surprising we don't have quorum all the time.  If we were all at 97% then we'd always have quorum.  But if you combine everyone's participation together you'd expect that not everyone is going to vote, and with a double miss we fail the vote.  I'm not sure if the issue is procedural (do we try to get the percentages up?) or whether we do something else.  In looking at this it exposes the statistical underpinnings of the challenge.
  • Peter: one thing the data does make clear is that the concern about lots of simultaneous email votes is not borne out.  There have been three periods when votes failed due to lack of quorum (June 2016, November 2016 and March 2017 to date), each of which had 2 failed votes.  Only one of these periods had a high rate of email votes (November 2016, with 14 email votes).  June 2016 was all in-person votes, so these failures don't appear to be in-person vs email related either.
  • Laurence: I don't see that in the data - March 2017 is an outlier.
  • Frank: can we focus on solving the issue?  The problem is that we're not passing a lot of the vote requests that come through.  We've all agreed that email is our way to manage votes, and we should be able to execute on them within a 72 hr period.  What can we do to alleviate some of these problems?  Is there a better way of communicating within the team?
  • Mike: for me personally it would help to get notifications in Symphony.  It's a multi-company chatroom we'd have to create, and I think I can build a bot to do this.  Or we set up the Foundation pod with a couple of chatrooms and blast to all of them.  We don't have to conduct the vote on Symphony, but notification is key.  I don't mind switching back to email to vote.
  • Frank: good point, and a few months ago I said I'd start on a vote bot, which I did.  But it turned out to be more complex than I'd expected.    But if it's only notification you're looking at, I could whip that up pretty quickly, and the ESCo etc. could be notified.
  • Mike: that would certainly help in my case - if I had Symphony notifications I'd hit 100% of votes.  David has us well trained not to use email, so they get buried.  
  • Frank: I'm happy to take that action - I'll whip up a bot.
  • Laurence: if we wrote a notification bot, how would we respond to the vote?
  • Frank: via email.
  • Mike: via email.  Peter notified me a few times on Symphony but it was too late.
  • Peter: how would this work for John, who doesn't have cross-pod?
  • Mike: I believe John has (or used to have) cross-pod enabled?
  • Frank: yeah that would be a problem.
  • Mike: yeah John is not cross-pod enabled.  We should ask for permission to get that enabled for him.
  • Laurence: We should ask for permission from Darren or John Madsen.  I'm sure we could get that done.  But first let's ask John himself.
  • Peter: I'll take that action
  • Mike: first we should ask John whether he still uses Symphony.  If not, notifying him via Symphony won't help.
  • Frank: so at IHS Markit we already have a generic notification bot that should be able to do this.
  • Peter: would IHS Markit be willing to open source it?
  • Frank: yep
  • Mike: great - this is exactly how this should be done.
  • Peter: bonus thought: should we be presenting this data (or something like it) to the BoD, as part of the "health of the Foundation" updates?  We're increasingly using data to present project and working group health, and it seems like applying the same idea to ESCo is worthwhile.
  • Frank: I think if we were not performing it would be obvious.  But if we want to be fair and transparent, then these are some of the metrics we could present.
• AOB:
  • Frank: yes - my vote failed!
    • Mike: can we vote now?
    • Frank: no - we don't have quorum.  I'm going to send it out again via email.
    • Laurence: did anyone vote on it?
    • Frank: yes - 2 folks.  So I'll send it out again, and send manual Symphony notifications.    One important thing to be aware of is that I'm getting questions from the community - that's where the urgency is coming from.
    • Laurence: one more thought about the notification bot - if we got pinged every 24 hours we wouldn't miss a vote.
  • Peter: related: the bot-jira archival vote failed too - any objection to me resending that vote via email again?
    • <no objections>
  • Mike: scheduling conflict problem - week of the next Foundation board meeting Laurence and I are in Singapore, so we're going to miss the next board meeting.
    • Laurence: I would prefer not to do a meeting at some crazy hour of the morning.
    • Mike: moving it 24 hours might work.
    • Peter: is this the Foundation board meeting or the ESCo meeting that same week?
    • Mike: Foundation board meeting.  The ESCo meeting is at something like midnight so it should be fine.
    • Peter: yeah and if you don't attend that it's less of a big deal.  I'll also let him know, but can you inform Gab?
    • Laurence: I have a 1:1 with him tomorrow - I'll let him know then.

Action items

• Former user (Deleted): work with Maurizio Pillitu on a gap analysis of what would be required to CII certify / badge the 
  
  • Present that gap analysis at a future ESCo meeting
• Maurizio Pillitu: provide list of CII badged projects (completed during meeting)
• Peter Monks: reach out to Former user (Deleted) regarding enabling cross-pod, and whether Symphony notifications for voting deadlines would be helpful
• Former user (Deleted): resubmit activation vote for symphony-java-client
• Peter Monks: resubmit archival vote for bot-jira
• Lawrence Miller (Deactivated): let Gabriele Columbro know about scheduling conflict for himself and Michael Harmon at the next Foundation BoD meeting