Table of Contents

Date

28 Mar 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  
  
  • 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): promote upcoming hackathon internally within IHS Markit
      (UPDATE) We are securing the "common area" space in our new building (we are in the process of moving).  This area should be able to accommodate over 40 people with AV available.  Hershal Shah will be coordinating efforts.  The event would have to start after 5:30 PM EST to accommodate working day in the office.   Now that IHS Markit staff are in the same office, I feel there will be broad participation from our side.  There could also be a few non-tech staff curious about the foundation and Symphony in general. 
• 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

             (Update) Proposed different language for Active state.  Under review.

• Former user (Deleted): setup ESCo advisors with ESCo Bot, once the code has stabilised to an appropriate point
• Former user (Deleted): enhance ESCo Bot with email integration, specifically for official vote recording, and to support Former user (Deleted)
     (Update), latest update support email notifications.  Email to chat is in the works
  
  

Agenda

Meeting notes

• Quorum is achieved
• "Hello World" repository
  • Mau: simple question - Aaron is working on improving legal requirements for the contribution process on the wiki.  He's proposed to build a "hello world" project to help contributors understand how to comply with the legal requirements - basically a worked example.  We'd like to build this project publicly in the open.  Question for ESCo is: would you like a CONTRIB for this project, so we can follow the contribution process?  Any other notes or suggestions?
  • Lawrence: my comment would be that if it's a demonstration project for the process, then the process should be followed.
  • Mike: what's the logic in not following the process?
  • John: agreed
  • Mau: I don't have a specific reason why not to follow the process - that's why we're asking you.  But the project is intended to show the legal requirements, more than the process.
  • Lawrence: if you want to contribute it, follow the process.  If not, don't follow the process.
  • Mau: ok great - I'll create a CONTRIB.
• DB / interoperability update:
  • Lawrence: we're working through the logistics for a follow-on meeting.  The conversation is ongoing, but no material progress.
  • Frank: what are the main blockers here that you foresee in the conversation?
  • Lawrence: setting aside logistics (which are harder than you might think - DB dev team is in Russia, LLC dev team in CA, DB management in London, and I'm coordinating from NYC).  Bumps I see are completion of technical evaluation - they've built a generic interoperability layer, and from the initial hour or so JC and I have spent with them it sounds like a very interesting technology very much worthy of follow up, and a valuable contribution.  But we haven't gotten past an initial pass because we've been trying to get the dev teams to meet together.  The more challenging aspect of this is the question of how the engagement process is working, and how they're tying into the conversation with Symphony and The Foundation.  DB's view of this is that they want a bilateral commitment from Symphony to use the technology before they contribute it, and before they socialise it with the community.  In my view this isn't an ideal way of contributing something, but I have to be respectful that they're a customer & investor.  It's also not unlike how some other contributions have been made (e.g. Minuet).  I don't think this is a good historical practice, but there's precedent in terms of this type of engagement mechanism.
  • Franks: thanks!
  • Lawrence: the key thing is that I'd really like them to come and talk to ESCo so we can have a broader discussion around the technology.  I'm trying to unblock that to move it ahead faster, but it's hard when there's this precondition of making a decision bilaterally.
  • John: this is my hangup into what they're trying to do - we've had zero visibility into it, and can't evaluate how we might exploit it etc.
  • Lawrence: yeah this is exactly why I'd like to see a greater degree of socialisation happening.
  • John: can we get them to come to ESCo and disclose what they want to get out of having this project in the Foundation?
  • Laurence: I tried that.  I don't want to come across as overly critical of their preferred contribution approach, given the history.  Where I've gotten to with it is that the most likely way ahead is to get far enough through the bilateral conversation to get them to the point of discussing with the community, or at least ESCo.  Ultimately it's their call.  I think talking to ESCo would be a faster way of moving ahead.
  • Gab: adding some colour from my conversations with Jim.  Originally this was presented with an aggressive timeline - in March we had a transitional update.  On April 19th I've asked Jim to come to the board with a clear yay or nay - not sure if that's achievable, but I've tried to timebox that as much as possbile.  We don't want another one year lingering type of thing.  So as an FYI I'm completely aligned that he should have come to the ESCo even before the board, but I also put forward our requirements as a Foundation with respect to a clear roadmap for the April 19th board meeting - engagement with or creation of working groups, contribution of code etc. - we don't want this floating around.
  • Lawrence: I'm trying to walk a fine line in encouraging them to make what will be a great contribution.  But I don't want to push too hard and upset them.
  • Gab: there's also a cultural element.  DB, like anyone engaged in the Foundation, have objectives in contributing to the Foundation.  The two key elements that Jim needed to move this forward - buy in from the board and buy in from Symphony.  He seems to have some buy in from the board, and is looking for buy in from Symphony.  The general comment I have is for ESCo, beyond just this contribution, is that there seems to be a lot of pre-commitment / analysis paralysis from the firms before anything is done.  As the ESCo we should try to revert this pattern - in open source you start with a contribution of code,.  You don't start with some 2 year commitment before you contribute.  I'm seeing this pattern reoccurring.
  • James: I'm seeing that too, but the problem the DB folks have is that they do have a particular agenda with the code they've developed.  The conversation I had with Jim is that he doesn't want to jump through the internal hoops unless he has that commitment from Symphony.  If he contributed and it doesn't end up in Symphony - it just lands in the Foundation - his personal credibility will take a hit.
  • Gab: we had similar conversations last year regarding the container discussion.  Certainly private 1:1 conversations helped, but I believe the work of the community has impacted the direction of Symphony in working on container APIs etc.  I completely understand Jim's position, and he's put a lot of political capital on the line.  But on the other hand we've already proven that when the community applies pressure in an orchestrated way, it turns into influence on Symphony.  It's a fine line.
  • Lawrence: I don't see it as the application of pressure - we've been trying to move this ahead.  Pressuring us (LLC) isn't going to move this forward.  I think that the issue is two fold:
    • Wanting to make sure there's a broad acceptance in the community that if we go in a particular path in introducing this technology that our own community of users is broadly supportive of that direction.
    • On the Foundation end, we have WGs for containers & API.  For LLC to make an agreement with one particular customer without engaging with the community - you may rightly turn around and say we're not engaging with the community appropriately.
  • James: agreed.
  • Gab: agreed.  When I said "pressure" I meant "value" really - the carrot not the stick.  Again, you (LLC), like any other firm, will see value in the Foundation and join forces with the community.  I think we're saying the same thing - I'm trying to unlock this seemingly deadlocked situation.
  • Lawrence: to close this topic off - we're going to continue working on this, but it's just not moving as quickly as it should be.
• Aligning common contributions to create project depth:
  
  • Frank: observation - I've been watching contributions flow through (which is super positive), but what I've been observing as contributions are proposed and committed is that there are a lot of contributions that could be aligned / merged to create what I'm calling "depth".  Bigger sets of source code that are more attractive to the community, resulting in more engagement.  Question for the group here: how do we maybe stop a bit during the voting process and bring up certain proposals as potential projects that can be combined with other existing project work.  That doesn't mean project work has to be form one company or user.  Does the group see value in "depth"?  How do we as ESCo look at these proposals coming in and combine them officially, and what is that mechanism to work with the contributor to make them see the light?
  • Lawrence: I'm in favour of having greater "mass" behind contributions.  I see two considerations to think about:
    • I would not want to discourage people from making contributions.  Saying "it's great that you've contributed this, but now we want you to combine it" would create headwind.  So we have to be careful about how we do this to avoid discouraging participation.
    • We would need to consider that our own metrics for the Foundation highlight new contributions as a metric.  Combining contributions may mean we don't get credit for contributions.  If we want to encourage contributions then we need to have the right metric.
  • Frank: I'd respond to that by saying I want both.  We don't want to discourage contribution.  But how do we help facilitate a community towards single repos are going to create a multitude of functionality that the community will rally around, so that we don't end up retiring projects?  I think it's more about the mechanics of doing it - do we invite the contributor to the ESCo and talk about the benefits of combining things.  What approach might we take here?
  • Gab: comment on second point Laurence made - we are working on a much more advanced way of measuring projects (though software called Bitergia).  Peter has done a lot of work to define affiliations for committers.  If I understand correctly, the second concern of Lawrence regarding attribution of work (i.e. multi-firm projects) is something we're very close to solving.
  • Lawrence: two factors to the concerns - 1 is attribution, the other is that we separately keep track of who's been making new contributions.
  • Gab: I see so measuring new contributions.
  • Lawrence: right, and ensuring Frank's objective isn't penalised by the current metrics.
  • Gab: for now we've always worked via metrics and "steering", rather than preventing things from happening.  I wonder if the "how" is going to be more around reporting and steering, and "when" you want to steer something like this?  But I definitely see value in this.  Example: my former company Alfresco proposed a project to the Apache Software Foundation for an open CMIS Java client, but ASF already had a project for CMIS clients.  The Apache incubator proposal (equivalent to our CONTRIB issue) was pushed back with a "you should merge with the existing project", and in the end we did that - merged the two projects creating a single, more collaborative project.  Question is: do you want to require it pre-contribution, or during incubation / activation time?
  • Lawrence: what would be the normal practice in the industry?
  • Gab: depends on the maturity of the foundation.  ASF has no problems due to the breadth of their project portfolio.  Do we think our portfolio is broad and credible enough to do this already?  My feeling is to start projects but steer / advise before activation.
  • Frank: I'd say that I think that if we see smaller utility code I would encourage us to invite the contributor to ESCo and have a simple conversation with them - "you have really great work, let us help you bring these things together as a deeper repo of functionality that we can sell in the community and get more uptake by the community."  It's just a conversation - in terms of forcing it we could do that too, but I don't see that being necessary until activation.  So simple conversations rather than enforcement - not discouraging, not enforcement, not shoving stuff down their throats - just a conversation.
  • Gab: FWIW it makes a lot of sense to me.  The direction is correct - I would expect ESCo to keep an eye on this, and we have examples of this already - the symphony-java-sample-bots - this is the kind of optimisation I'd like to see.
  • Frank: also recent Symphony contribution on the extensions API, which is great, but I think again we could bring those things together into a single extension API utility repo.  Let's have the conversation - invite those contributors in and have those conversations.  I think they'd appreciate that too.  The proposal I'm going to make on this call is that if I notice something on the proposal list that I think we should review before voting, then I'll put an agenda item on to discuss it.  We don't need to stop the approval process, but we also invite in the contributor (or contributors) to review the roadmap with us on that contribution.  
  • Lawrence: I would concur with what you just said.  The overall principle is that we're not going to put initial roadblocks, but we'll curate once the projects are under way.
  • Frank: yes except that the curation portion needs to be more active - "come to the ESCo and have a 10 minute conversation" - we don't wait until activation, for example.
  • Lawrence: got it, and agree.
  • Gab: if you guys think a discussion is needed, why wait until the project is contributed?  Maybe comments on the JIRA regarding duplication could trigger the in-person conversation prior to contribution?
  • Frank: we're saying no - contributions will flow through.  Regarding commenting on proposals in JIRA - that's absolutely positive, but as we saw with Glenn's contribution I asked the question in the JIRA and he said "no no I'm not doing it that way", so I stepped back and let it go through.  What I'm suggesting is that I would have then invited Glenn to ESCo to discuss with us his roadmap.  In terms of projects that move towards active status, I think that should become normal operating procedure - we review the entire portfolio and what's there, and look for conflict of work or potential to combine, then we'd raise it then.  Is that clear?
  • Gab: clear to me.
  • James: seems reasonable to me.
  • Mike: and to me as well.
  • Venkat: I'm good with this.
  • Peter: I think this is great.
• AOB:
  • Frank: lifecycle pieces: I sent out the proposal last week or this week - don't remember.  Peter responded offline and we're discussing that proposal and possibly changing what I presented . We're coming to the conclusion that we should simplify the states rather than increase the number of state definitions we put out there.  So we're potentially looking to propose to eliminate ☠️ Long Term Maintenance ☠️.  Before everyone screams out that that's a terrible idea, we need a little more time to define what and why, and we'll come back to ESCo next week with a definitive view of the necessary changes.  We've been spending a good amount of time on this, and I didn't intend my email to be the final email - more an opening for discussion and visibility into what the proposed changes would look like.  We have more work to do - Peter has been building a big matrix and it helps figuring out the individual use cases .  We also do not want to reinvent the wheel, so I've been spending time looking at the ASF model and we should be following best of breed in the communities that already exist.  We're not too far off  - just need some small adjustments.  So just be aware we'll be back next week with a real response regarding adjustments to the lifecycle.
    • Gab: we presented at FinDevr last week, and lifecycle really resonated with the idea of a Foundation that delivers high quality software.
  • Gab: provide ESCo with update from membership & governance committee which just met this morning - Frank and Laurence were there.  One of the elements we discussed was upcoming ESCo board leads election, and if you remember ESCo had recommended keeping the current makeup.  Membership & Governance committee has ratified that makeup, so we'll likely reappoint John and Laurence in the April board meeting.
    • Lawrence: quick question on a technical point: staggering of ESCo seats.  In discussing with Aaron that's something that ESCo could initiate of its own volition because the term limits are set by ESCo on itself.  So in terms of implementing the staggering structure, we're more informing & consulting the board, rather than having them formally ratify it.  To the end, there are two points:
      • We should formalise that resolution for implementing the staggering process - in ESCo we were all in agreement on my process.  We should put it in place formally at one of the upcoming meetings.  We might like to have this adopted in some way in advance of the board meeting.
      • If the board is going to be voting on the chairs - the votes the board will be making will be for particular members to be going in particular classes of seats.  If John & I are being put forward as leads, they'd be in seats that have different terms (according to the staggering proposal) - 1.5 years and 2 years.  When the board elects people, we'd need them to elect individuals into particular seats.  There's a question about which seats John & I go into, and I've proposed we flip a coin.
    • James: I think we'd need a notary and several witnesses, and conduct this in a bar!  
    • Gab: we discussed that at the committee today.  Personally I have some operational concerns (more elections), but absolutely supportive to move forward.  I've asked Aaron to reach out to you following the committee meeting, and what you're saying regarding going into implementation mode.  We can move quickly on this one.
    • Lawrence: I get what you're saying but also think that if the elections happen every 6 months they might be easier to run since we'll get so used to them.  There may be some operational advantage in making them a routine operation.
    • Gab: hard to get people's attention, given the large board we have.  But I see advantages from a membership standpoint - many of the members are thinking about ESCo and/or board seats, and having more regular availability has advantages.
    • Laurence: would also just add that classes of senators in US senate is decided by coin toss, to clarify the precedent.

Action items

• Maurizio Pillitu: create CONTRIB for legal requirements "hello world" example project