Table of Contents

Date

08 Sep 2016

Attendees

Actions items from previous meetings

• Review LLC API guidelines and existing API list - ALL
• Coordinate an exercise to identify 1 to 3 top API-related objectives that each participant thinks needs to be worked on in the next 3-9 months - Former user (Deleted), Peter Monks (with consultation from Former user (Deleted) &Former user (Deleted))
  
  • In progress - survey sent to members list 2016-08-18
• Check mailing list for JP Morgan Chase folks - Peter Monks
  
  • Done - Adeel, Jhonalyn and Ian are not members, so I've invited them.
• Iterate the charter and send it back out for comments - Former user (Deleted), Peter Monks, Former user (Deleted)
• Schedule next meeting / call for Thursday September 8th, in the afternoon UTC.  Include a location where people who will be at the Symphony BOD meeting can physically as well - Former user (Deleted), Peter Monks

Agenda

Meeting notes

• Roll call
• New introductions
  • Former user (Deleted) (Citi) - member on desktop wrapper WG, responsibility within Citi is integration of Symphony product within Citi - based in NY
  • JT Dupuy (Wells Fargo) - manage the technology for investment bank capital banks, sales & research - Symphony is one of the products I'm bringing in - based in California
  • Former user (Deleted) (Morgan Stanley) - not present
  • Borre Wessel (ICAT) - not present
• Anthony: Survey results:
  • 
  • Reviewed Survey Objectives: Sent to both general member list and WG members to offer prioritization on different activities
  • Activities could be ranked with equal priority
  • 14 responses in total
  • Scoring system involved assigning a weighting to each priority, then summing across the responses
  • Clear primary / significant top priority was to the activity to define API patterns and guidelines
  • Next priority was looking at the APIs from a requirements PoV - what functionality does this group say is required - not intended to be a dictate.  It's a pointer for what the expectations of the members are wrt APIs.
  • Third priority (almost equal) - looking at other means of implementation (SDKs, language bindings)
  • The other 2 activities didn't seem to resonate - not much priority assigned by the group
  • Next steps:
  1. 1. I'd like to hear people's opinions
     2. Take the charter and update it, send it around and agree as a group that it's good, then get the Foundation board to ratify it
  • Opens the floor:
    • Bruce: the survey is an information gathering exercise.  Is that how this working group is going to make decisions?  What is the process for making a decision on behalf of the WG?  Does everyone get a vote?  Does every organisation get a vote?  If it gets to the point where we're going to do the first priority on this list, are we going to rely on reaching consensus to perform work in this group?
    • Anthony: as we get into the construction / development of these guidelines I'd see this working group having a fixed list of participants / contributors and a process for agreeing on what we want to do. Depending whether it's majority rules or unanimous - I don't know yet.
    • Michael: is there a model for the working groups?  It seems like the groups should adopt whatever the Foundation decides, or should decide for themselves?
    • Amit: survey is an indication, it's not binding
    • JT: the survey is a good start - it gives us something to focus on
    • Anthony: we had a draft charter that spurred some conversations, the survey was intended to focus that conversation.  Before we have a ratified charter, we're working without a mandate.  Once we have an approved charter, and can start the activities (i.e. on API patterns), we'll have another process to put in place.  BNY has some proposals that they'd love to share with the group, but until we have a ratified charter
    • Michael: I think Bruce's point is that unless we have a decision model in place we can't approve the draft charter.
    • Bruce: it is not a secret that I don't think the top of the list is what this WG should work on.  I'm happy to go with what the group says, but I'd like to understand the decision making process.
    • Amit: it looks to me like a lot of people participated.  If only 2 or 3 participated I'd be concerned, but in this case it looks like virtually everyone in the group participated in the survey.
    • Paul: I'd like to chime in on this one.  We are in a very interesting point in time whereby the code base of Symphony is not fully open and therefore the only thing a WG can do is either create standalone code components independent of the Symphony code base, or advise what should be built by Symphony.  Items 1 & 3 on the list are inputs to the Symphony roadmap.  It's not a surprise that I've been talking to everyone on this call to flesh out the roadmap.  We'd like to continue building what you guys need.  I take the survey results as being important for the business - I'm not surprised these items rose high.  I want to caution about duplicating efforts.  What is the problem we're trying to solve.  I would therefore not be supportive of going to the ESCo at this time.  The problem statement is not clear enough or urgent enough to justify the involvement of every one on this call.  Many themes are interesting.
    • Peter: the survey had a "fill in the blank" option, and despite this the signal was strong - was the "full in the blank" option used at all, Anthony?
    • Anthony: no additional activities were proposed.
    • Paul: at this stage I haven't heard that API standardization is burning issue.
    • JT: the real questions here is when is Symphony's code going to be open?  When can we contribute to it?  We can talk about decision making, but does anyone on this call think that open sourcing the code is the highest priority.
    • James: I think we can agree that this WG isn't focused on that.  Though we all agree and should push it via other channels.  it's just not a topic for this WG.
    • Amit: we're also working on the assumption that there will be open source and that we'll be contributing to it.
    • Michael: I'm not describing a scenario that I would like, but with the current architecture, we could still create open source artifacts & functionality that works on top of the closed source pods.  It wouldn't allow a community, since it excludes folks without pods, but there is a limited spectrum of software that could be created even if the LLC never open sources their code.
    • Bruce: and their are C# and Java language bindings that have been contributed on the Foundation Github repository.
    • Paul: it's clear that there is interest on two topics.  I think we should be more precise on whether there is enough interest from the members of this group to build (for example) an API pattern is blocking us from doing something.  If the community is saying it's willing to support this as a community-developed shim, it's a sign for the Symphony product that this should be fixed in the product.  Right now the definition is a bit too broad.  It feels like it will be duplicative of work that will be done in the LLC.
    • Michael: let's get specific.  We would like to show two example BNY document that relate to our NEXEN initiative.  These could be very easily generalised to be non-BNY specific.  The first is our REST guidelines that are a generalised coding standard for how to do a REST API - best practices REST.  The second document that shows a Symphony API on the right hand side, and an equivalent REST API on the left hand side.  As a possible thing for this working group to work on would be a shim API, and might this be a good.  If we want to talk concretely about what a shim API would look like, this is a good example.
    • Bruce: we've gone past the question I asked.  We've got some survey results - we need to decide are they priorities we're going to work on.  Are we saying the decision is based on a set of anonymous survey results?
    • Michael: personally I don't think it should be the survey, but I think it should be a vote.  I think we need to vote now or later.
    • Bruce: I agree with that.  I would like to agree that we're going to use a voting method and then a show of hands.
    • Peter: propose that we use a simple majority of those present.
    • Amit: propose we use an email vote.
    • Bruce: email vote would be fine; who do we allow a vote? one per company, one per member?
    • Anthony: ...agreeing on a voting mechanic is a reasonable next step.
    • Bruce: it's a different question than what you're asking in the survey.  I don't understand why this is complicated - the survey says one thing, and all I'm asking is whether that's the priority of the WG.
    • Michael: to be clear Bruce, you're proposing that we take a vote right now the question being - does the survey reflect the interest of the WG or what the WG wants to work on?
    • Bruce: the survey indicates that the API patterns & guidelines is the priority.  I'd like the WG to formally make the decision that that's what we're going to do.  Is that complicated?
    • Amit: how does that differ from the survey?
    • Bruce: we've discussed what the decision making process should be.  The consensus seems to be that each Foundation member gets one vote, and the survey doesn't represent that.  There are 5 LLC people on the attendee list of this call.  There's no obvious reason to assume the survey reflects the answer from a voting procedure.  I don't care what the 
    • Michael: ...we need to get at the Foundation level the protocol squared away.  It's an existential question that we didn't close that out.  We need to make sure that at least is covered.
    • Peter: Foundation would prefer not to mandate, but we can if that's the recommendation.
    • Michael: lets summarize; we've made 2 decisions:
      • Decision model for the group
      • We're going to proceed with an email vote on the proposed charter
    • Michael: Anthony you'll work with Peter on that?
    • Gab: just wanted to comment on this.  This is similar to what we've done with the earlier working groups, despite not having voting procedures in place / set in stone.  We have used an email voting mechanic in the past.  We can create the appropriate mailing list, then bring an approved charter to the ESCo.

Action items

• Former user (Deleted) work with Peter Monks on updating the charter based on survey results
• Former user (Deleted) work with Peter Monks to organise the vote by email to submit for ratification by ESCo (or reject that charter for further development)