Table of Contents

Date

11 Apr 2017

Attendees

Actions items from previous meetings

• Former user (Deleted): come back to Former user (Deleted) with feedback on third point of proposed revisions to Desktop Wrapper WG charter
• Former user (Deleted): work with Maurizio Pillitu on a gap analysis of what would be required to CII certify / badge the symphony-java-client
  • Present that gap analysis at a future ESCo meeting
• Gabriele Columbro: write up some points on trust in transparent communities, with a particular focus on why identity, archival / auditability, and addressability are important for the voting system
• Former user (Deleted): work with Peter Monks on a proposed refinement to the project lifecycle.
  • MVP: ensure that each project currently in the portfolio unambiguously fits into a single state
• Former user (Deleted): create CONTRIB JIRA for ESCo voting bot

Agenda

Meeting notes

• Quorum is achieved
• Action items:
  • Frank: I'm happy with the latest revisions to the desktop wrapper charter.
  • Frank: Peter and I haven't had time to sync up on the revised project lifecycle - not sure how urgent it is right now, but some projects may want to move status (e.g. LTM vs Archived).  For the java sample bots project we were discussing in previous ESCo meetings, we can make it long term maintenance for now, and if we have to change it later we can.  What do other ESCo members think?
  • <no objections>
  • Peter: ok let's vote!
    • VOTE: to approve the transition of the symphony-java-example-bots project to ☠️ Long Term Maintenance ☠️
      • Former user (Deleted): +1
      • Former user (Deleted): +1
      • Lawrence Miller (Deactivated): +1
      • Michael Harmon: +1
      • Former user (Deleted): 0, due to non-attendance
      • RESULT: The motion passed.
      • Next steps: Peter to coordinate with project team.
  • Frank: CONTRIB for the ESCo voting bot should appear later this week
• Review of 2017 corporate goals / Q1 KPIs:
  • Gab: a couple of things - first question: I'd like to understand who from ESCo will present to the board next week.  Any candidates at this point?
  • Frank: as an aside for ESCo, I'm happy to fill the gap if necessary
  • Lawrence: I'll be remote dialed in from Singapore, so I'm not an ideal candidate, though happy to present when I'm at a meeting
  • Gab: Ok I'd love to have someone who hasn't presented.  I pinged John in private as well.  Thanks Frank & Lawrence - if I don't hear from John by end of today I'll take you up on the offer.  Frank I know you've done it already but you'll be there in person so it makes sense.
  • Gab: 2nd topic I have is there's a couple of objectives in the H1 scorecard.  Obviously we'll give the standard update on projects and WGs - we're tracking nicely to objectives (in terms of volume of projects).  The one question I would have is specifically there's an objective around definition of project health.  I know you're also working with Aaron on Working Group health.  My specific question on project health is that the ESCo seems quite happy with the current set of metrics we're reporting on.  We've discussed multiple times to have a higher level "health score" that might aggregate different lower level metrics, and this was one of the objectives put on me by the board in January.  Does the ESCo think that moving forward it makes sense to have an aggregated "project health" metric, or are you guys for the time being happy to continue working with the current metrics (and the enhanced version of those that will be provided by Bitergia)?  I think you'll have a lot of weight in steering the projects, and I don't want a disconnect between ESCo and BoD around project health.  To repeat the question: does the ESCo feel that we should do research into aggregate qualitative indicators of project health, or for H1 would you prefer to continue reporting low level metrics (projects, commits, etc.)?
  • Lawrence: where did this objective originate from?
  • Gab: I added it to the plan and the BoD approved it.  It's not something that originated from the board.
  • Lawrence: so is your question whether we're willing to review something you're putting together?
  • Gab: the question is: do you want us to go off and do the work to aggregate those low level metrics into higher level unique indicators of health?  Is that an exercise that's useful moving forward, to support your reporting to the board?
  • Lawrence: since you put it on your objectives I guess you kind of have to do it right?
  • Gab: should the ESCo recommend that the current set of technical metrics are enough, then I'm happy to go back to the board and ask to remove this from the H1 objectives.
  • Frank: so we have a tool that can gather these metrics?
  • Peter: yes, but it's a little premature for us to discuss that in detail.
  • Frank: having a system that provides metrics to the community and the board is obviously a good thing.  My view is that the metrics we have today are pretty good indicators of activity.  I think a lot of those underlying metrics bubble up to key views of how the Foundation is doing.  I like the underlying metrics in terms of providing insight into how the community is growing.  It doesn't get into the WGs, but I think there are other ways of handling that.  The underlying metrics are fine right now, and I have no problem adding metrics that are clear to the board members (who are less technical).
  • Gab: I have no strong feeling here - I'm just asking for your recommendation.  The one comment I would raise regarding an overarching concept of "health" (based on low-level metrics) is driven by the feeling that looking at things like "number of projects", "number of commits" without a correlation between those might result in targets we don't really want.  For example Frank you were talking about "depth" of projects a few weeks ago, not "number of projects", and I concur with you on that.  In H2 I'd like to track objectives beyond simplistic "number of projects" but instead track to "depth" or "health" of projects.  And this objective was originally to research and figure out how that can be measured (with ESCo's assistance) into a more comprehensive measure that we can use in H2.  That's the background.  But if you feel the current metrics are fine, we can punt on this.
  • Frank: my opinion is that I don't think metrics need to be a scientific thing at this stage.   We should pick out 2 or 3 projects that are representative of a healthy, deep project, and encourage other projects to get to, then the metrics will come out once we're more stable and have more projects with depth to look at.  That's my opinion on that.  The current underlying metrics are fine.  We had discussions last week, and some of the stuff we want to focus on going forward is how to get others to participate in the community - the internal legal barriers etc. - helping to bring them into the Foundation, and that's the thing we want to discuss going forward, above and beyond health of current projects.
  • Gab: sounds good.  You're technically recommending to remove an objective for my H1, so I'm supportive of that!    But I'll definitely relay the feedback, and I agree with you that it's more important to bring in a more engaged community and ensure the ESCo can deliver on its charter.  Ok I think I have enough feedback on this.
  • Frank: does anyone disagree with my proposal?
  • Lawrence: I concur with the recommendation you just made.  As we get further through we'll have more recommendations, but right now I'm more interested in getting the engine running, than tuning that engine via metrics.
  • James: I'm not bothered about metrics - I think we should get qualitative reporting from the people involved.  Metrics can come in time.
  • Gab: thanks - I have what I came for.  We have dynamics & decision making improvements to be made, and there's a big missing element that there's no way of tracking tasks and the progress of those tasks, but I don't want to start a separate topic.
  • Peter: Mike?  Venkat?  Any comments?  Don't by shy.  
  • Mike: I have nothing to add, and don't worry - I'll speak up if I have something to say.  
  • Venkat: I might give you a call to better understand.
  • Peter: please do!
• Desktop Wrapper WG:
  • James: the last WG meeting was a little tense.  Members from OpenFin feel that the work is going in the wrong direction, and had been led to believe there was a problem with the commitment from the LLC to implement the API's the group is defining.  But in following up with JC and Lynn since then, it doesn't sound like there's any pushback.  Everyone seems to be in violent agreement.
  • Lawrence: I'm surprised by the origin of this in the first place.  I don't understand the reason for the concern.
  • James: yeah that's worth talking about a little bit.  I think the headline concern was there seemed to be a lack of focus on implementing an API that would be both used and implemented by the LLC, and ScotLogic were busy creating code that Lynn had apparently said he wouldn't be using (not that that was Colin's intention - he saw it as prototype code).  The more interesting thing was that OpenFin came out quite aggressively and said there was no value in providing a veneer / API that would allow applications in general to target any container - in fact all they're interested in is running the Symphony app in another container (i.e. OpenFin).  It was clear they were being a little protective, and if you recall we had concerns about them doing this before they joined.  It was interesting to see that happen - they started down one path, then become more aggressive about protecting lock-in for their container.  My gut feeling is that this can and should be resolved within the WG, and I've asked Lynn to reply to the WG (I'll chase him up about that).
  • Lawrence: it might be best to resolve this within the WG.  I don't know what's happening in the WG.  I don't know, but it's possible it came out of left field for Lynn.  From one perspective, if folks are making representations, characterisations, generalisations about others' strategies, then it should be taken with a grain of salt.
  • James: totally agree with you.  The whole thing was a little bizarre and uncomfortable, especially as I hadn't been in the meetings they were referring to.  Ideally if Lynn and/or JC could turn up to the next WG meeting that would help address the concerns.
  • Lawrence: I caught up with JC and recommended that we have an alternate so that if JC can't attend someone else from the product team can attend.
  • Mike: is JC the normal member of that WG?
  • Lawrence: yep
  • Mike: yeah that's a bad idea - he's pulled in a lot of directions.
  • Lawrence: I think he's been a positive member of the group, but he's only been there half the time.
  • James: yeah I think we're all agreeing - let's get the right attendance in the WG and I'll raise it with ESCo if OpenFin or anyone else is a problem.  Unfortunately the next WG meeting coincides with the board meeting, which is a pain in the butt.
  • Peter: Aaron is on the call and may have ideas to mitigate that.  Thoughts, Aaron?
  • James: I don't think we can shift either the WG meeting or the board meeting.
  • Aaron: we can try and hold a make-up meeting the next week, but I'd prefer not to leave a 4 week gap - it would be good to keep the momentum.  James do you think that moving the meeting would not be advisable?
  • James: my experience is that you're dealing with a lot of busy people across a lot of timezones, and trying to move it in the past has resulted in cancelation.
  • Lawrence: perhaps a poll via email on who would attend?
  • James: Aaron and I will take it offline.
  • Gab: question for you James - you mentioned you haven't attended the sub-group meetings, so you're unable to comment on the representations / claims made there.  I wonder if this calls for a more general solution - if there are no records of those sub-group meetings then we're always going to play telephone games and have to have backchannel conversations to clean it up.  At this stage it seems the sub-group is operating with complete independence - do they have any record of their meetings?  How do they report up to the WG?  I want to foster engagement, but I also don't want to have awkward situations like this one.
  • James: no formality asked of the sub-group, beyond periodic reporting at the WG meetings.  Nick from OpenFin was arranging the calls, though they haven't met for a few weeks - I don't know why not.  I wasn't keen to make it formal as that's a big turn off for people.  Let's see if we can resolve it within the WG, and if we can't then all of those things should be put on the table.
  • Gab: great - we're here to help - happy to strategise with you.
• AOB:
  • Frank: one of the things we want to schedule for subsequent discussions is on how we within the ESCO can engage with the community, especially those members who've yet to offer up developers or gotten through the legal barriers to contribution.  We discussed this a little last week and got to a view of what we as an ESCo body should be doing to encourage the community.  The team was very much in agreement that we should spend time in these weekly calls to discuss planning / engagement of those members.
  • Lawrence: a little more context: we had an executive session on Friday to align on how to make the ESCo more effective to meet the foundation's strategic sessions.  We discussed mechanics and processes and improvements to focus better on most impactful topics.  Out of that we came up with internal consensus that for the next ESCo meeting we set 55 minutes for a discussion on open source policies, which we think is a major impediment to our member base form contributing, and keep the procedural matters to 5 minutes.  We'd also like to, on a forward going basis, an agenda reviewer on a rotating basis - on the Monday before, do a quick once-over of the ESCo agenda so that someone from ESCo has reviewed it - we haven't spent as much time on that as we'd like.  The other point that came out of that is that we felt that we were really good advisors to the members on open source policy improvements, so we're willing to volunteer ourselves to participate in those member discussions.  At the upcoming board meeting I think there's going to be a higher level discussion around Foundation goals with some kind of working group being set up.  During that meeting we plan on proposing that ESCo are directly involved in that mandate discussion.
  • Gab: absolutely.  I love the fact that you guys got together.  If you have feedback I'd love to take it offline.
  • Lawrence: we'll take you up on that.
  • Gab: on the more general Foundation discussion - absolutely.  Obviously the board will determine if that discussion needs to proceed, and I want to leave that meeting with clear next steps - sub-committee or whatever, and obviously the ESCo has to have clear participation in that.  I'd love to have the ESCo more engaged in agenda building.  The more engaged you are, the more empowered you'll feel.  Finally, on open source policies we've finalised the dates for our "Open Source Strategy Summit" (final name of what was the "open source readiness event").  Aaron is taking point on that.  I'm also bringing in Jono Bacon, a well-known open source community leader, who also has depth in fin serv.  If you have any input on this, please sync up with Aaron - he's driving the bulk of the content for June, which is just one instance of a broader initiative we expect to carry on the remainder of the year.  So I'd love engagement, but would encourage alignment with Aaron.
  • Lawrence: sounds like Aaron should be involved in the upcoming conversation.
  • Venkat: is there anything we need to prepare ahead of time for next week's open source discussion?  Anything we should share ahead of time?  Existing policies / documents we could go through?
  • Lawrence: if we want to share among ESCo a couple of current policies, especially on the bank side, that would be helpful.  Perhaps Goldman or Citi or CS would be willing to do that confidentially with ESCo.  I have no problem with sharing Symphony's policy, but I don't think it's especially relevant because we're not a bank.  Some of that material would help ahead of time.
  • Aaron: I've been working on this myself and can give you a quick status update on what progress I've made.  I went to Goldman because John Madsen offered up their policy at the last board meeting.  I followed up with several people there,  but unfortunately the impression I've gotten is that Goldman's policy doesn't really encompass the most useful aspects of the open source policy - i.e. what they're doing to enable open source contribution.  I haven't seen the policy, but that part doesn't seem to be written down.  From what I've heard from Ali at Citi is that they don't really have anything either.  I'm working with Cit's patent counsel to talk through the issue and trying to figure out a way there, and I've had similar conversations with a couple of other banks - none of them have open source contribution policies at all - this seems to be a common them.  Morgan Stanley is the one exception - they have a sophisticated contribution policy.
  • Frank: has anyone looked at the Linux Foundation's contribution documentation set?  It provides a clear set of guidelines on how to implement open source contribution within a firm, and is what we based ours on.  I'm also happy to share our policy, though like Symphony it may not be that relevant.
  • Lawrence: I'd like to have visibility into Markit's policy to help facilitate the discussion around sharing policies.  There might be things we can do in a smaller group that can grease the wheels.
  • Aaron: I'm somewhat familiar with the Linux Foundation's work, and I'll look at it again to see if it can foster more engagement.
  • James: my view is that policies are one thing, but people need to understand them.  Our policy, for example, is incredibly vague and doesn't say much more than "you can contribute and you need approval to do so".  Practically, the "how do I implement" is where it gets difficult, and that's not policy - that's tool and process.  Currently our tools and process are "do the work, send it to the manager, manager is supposed to review it, you email it to your personal account which will trigger a DLP alert, then your manager remembers that months before he approved the contribution and resolves the DLP event".  We're clearly not remotely comfortable with any of that, but it's not a policy problem - it's a tools and process problem.
  • Gab: we've identified 2 main areas: technical management and legal management.  Typically the cases where we've seen this working (e.g. CapitalOne) there's always business ownership over both technical and legal - there's clear business value.  The way we're structuring the event in June is around 3 tracks: technical, legal, and culture.  The last one is important because the FinServ culture takes a toll too.  But it's not just technical and legal - there has to be real business ownership for developers to engage.  If there's a business case, technical and legal will follow along.
  • Aaron: the reason we're having this summit in June is to bring together the people who are stakeholders in these policies and processes at their firms, so that they can get information and also talk to one another about what their common problems are - hopefully we can be a meeting point for that.
  • James: when does that get advertised?
  • Aaron: landing page goes up today.  If there are people at CS who would benefit, let me know.
  • Gab: keep in mind the next day is the member's meeting.  The ESCo might like to have a session at the member's meeting that would fit nicely if we can get mindshare and buy-in the day before.  It'd be great to present the results at the member's meeting the next day.  You'll remember we tried with a WG last year but didn't get much traction, so I'm happy to see the ESCo bringing that discussion forward.
  • Frank: to be clear we're trying to solve this problem here within the ESCo meetings.
  • Gab: the working group failed last year - it didn't even start, so I welcome other ways to solve the problem.
  • Frank: I shared the link to the Linux Foundation docs on the Webex chat: https://www.linuxfoundation.org/offerings/open-source-compliance
  • Gab: yes we're familiar with that.  There's been a lot of work on tooling with some now de facto standards (CII, Fossology) - it doesn't make sense for us to reinvent the wheel.

Action items

• Peter Monks: communicate symphony-java-sample-bots transition with project team
• Gabriele Columbro: confirm with Former user (Deleted) if he'll be presenting to the board next week or not
• Former user (Deleted): give Peter Monks a call to discuss project health metrics
• Former user (Deleted): chase up Lynn Neir (Deactivated) regarding email to Desktop Wrapper WG
• Aaron Williamson: work with Former user (Deleted) regarding conflict between next Desktop Wrapper WG and the BoD meeting
• Lawrence Miller (Deactivated): add 55 minute item on next week's agenda to discuss open source policies
• Lawrence Miller (Deactivated): work with Aaron Williamson to align ESCo's efforts on fostering member engagement and clearing firms' legal hurdles
• Lawrence Miller (Deactivated): share LLC open source contribution policy with ESCo
• Former user (Deleted): share IHS Markit open source contribution policy with ESCo
• Former user (Deleted): let Aaron Williamson know if there are particular people at CS who should be explicitly invited to the Open Source Strategy Summit in June
  
  • We encourage all ESCo members to let us know who in their firms would benefit from the event!