Table of Contents

Date

01 Dec 2016

Attendees

Actions items from previous meetings

• @Anthony to share the ESCo result by email, following the ratification meeting. If approved by the ESCo, then create a formal kickoff meeting.

Agenda

Meeting notes

• Anthony: Update on current charter, incl. ESCo feedback & recommendations:
  
  • Charter, as submitted to ESCo had two objectives:
    1. Creating guidelines & best practices
    2. Gap analysis and input on what functionalities could be included in the APIs as a matter of input from the community & Foundation
  • Response from ESCo:
    1. First charter objective accepted
    2. Second charter objective was not accepted on the basis that there's no contribution at the moment nor definitive time when it will be, so the feeling is that it's not an actionable objective.
    • Feedback was to resubmit the charter with only the first objective (best practices around APIs), and that could be helpful for a number of projects (e.g. creating and working on client libraries), and then we can always refine the charter going forward.  The expectation is that the ESCo would approve this revised charter.
  • Are there any objections to resubmitting the charter in that way?
    • Amit: quick question - you mentioned that gaps in the API is not to be part of the charter, is that right?
    • Anthony: not initially.  We were asked to take that off the charter and at some future point in time when there are contributions to the Foundation, then we could update the charter accordingly and look at that.
    • Amit: so right now, the main focus would be on best practices around APIs.
    • Anthony: agreed.  Some context is that the LLC itself has some documentation around how it publishes its REST standards.  We've mentioned in previous calls that BNY have made some efforts around REST API guidlines and we'd like to share that with the group too.  But yes really that's the one thing the group has been given some approval to proceed with.
    • Paul: some additional colour representing the LLC - we'd like to phase that second point.  Right now I'm working with each and every member of the WG and you know we're working as hard as we can to add API capabilities.  In that world it would be just premature to go into gaps, beyond what's already being worked on.  When the codebase is in a state where everyone can help, rather than having more people piling on the limited engineering resources who are already working on APIs, then it could be looked at.  I'm keen to have you all have visibility into the API roadmap, but I think you all already have visibility.
• Anthony: Next steps:
  • Revise and edit the charter and submit to the ESCo for a ratification vote, (which they've said they would approve), and then we'd start some actual WG meetings.  That's the plan I have going forward.  If that's fine with everyone then the next thing I'd like to do is set an expectation around when we meet again.
  • Paul: on the first element of the legacy charter has two subcomponents:
    1. Best practices across the board - compatibility, naming, structuring etc. 
    2. What does that mean to the extent that the working group can help guide the various project teams working on language bindings.  I want to make this distinction because the community is waiting for language bindings, and there are a Java client (Markit), .NET client (FactSet), Python client (LLC), two nascent node.js clients, etc.  These groups need a place to connect on these topics, but I want to make sure that that's clearly identified.
    • Consistency between different languages is completely irrelevant due to the structure of the languages themselves (functional vs streaming vs OO). But for example the Java SDK abstracts some of the streams management for the raw Symphony API (that I'm not super proud of yet - there are many best practices we're aspiring to), but the client, if done properly, can make that management significantly easier (as in the Java SDK).  As a group we should be able to say that's a very good thing to do, and all client builders should consider it.  Helping decode what's being tested in the various projects so that there's cross-pollination of best practices.  At some point it's very likely that organisations will start using these client libraries to build against Symphony, instead of the raw APIs.  There will be an expectation around SLAs etc. that those clients have.  Being able to articulate that and discuss it openly will make life easier.
  • Peter M: to be clear, the ESCo and board have asked for the charter to be resubmitted with the second objective stripped and no other changes.  While we could in theory ignore their advice and go back to the drawing board, I think that would be problematic.  I would suggest to the group that they stick to that guidance, get ratified, then refine the focus once we're an officially established working group.
  • Paul: agreed, I just want to ensure we focus on this client side issue.
  • Peter M: yep and the first charter objective has language for that, so I think that's a good potential first activity, after the WG is ratified.
  • Anthony: so we'll edit the charter as discussed (remove second charter objective), then submit revised charter for ratification vote ASAP.  On the assumption that the WG gets ratified, I'll then schedule a first official WG meeting for the 15th of December, as an early Xmas present.  
• AOB:
  • Peter M: if you haven't already, please sign up for the Working Groups mailing list.  If you're not sure how to do that, or have issues, please contact Peter Monks on Symphony, or at peter@symphony.foundation and he can get you setup.

Action items

• Former user (Deleted): revise charter to remove second objective (no other changes to be made)
• Former user (Deleted): resubmit charter to ESCo and ask for ratification vote
• Former user (Deleted): on the assumption that the charter will be ratified, schedule a kickoff call for December 15th