Table of Contents

Date

20 Sep 2016

Attendees

Actions items from previous meeting

• Former user (Deleted) - draft project release approval criteria  (Please see Symphony Foundation Contribution Lifecycle Proposal)
  
  • Proposal is that ESCo will approve the first release of each project, then delegate approval of subsequent releases to the project team
• Peter Monks - schedule Former user (Deleted) and Former user (Deleted) to give WG updates next meeting and the following meeting
• Peter Monks - schedule Lawrence Miller (Deactivated) to present on OSS plan in next week's ESCo meeting

Agenda

Meeting notes

• Roll call
• Action item review:
  • Frank: gave overview of a draft of some project releaser approval criteria (available here)
  • • ESCo to review offline, prepare comments / feedback and discuss in a future meeting
  • Peter scheduled Anthony (today), James (today), and Bruce (next week) to give updates on their respective WGs
  • Peter did not schedule Lawrence to give an OSS plan update - will move that action forward
• API WG status update (Anthony)
  • Introduction to Anthony - new at BNY Mellon, previously at AT&T as a product manager / marketer on the developer platform team.  5+ years of experience with APIs and developer platforms.
  • Chairing the API WG on behalf of BNY Mellon.  Michael Gardner remains the executive sponsor.
  • Anthony: narrative update on the activities of the WG, and where we are:
    • This WG is still in the formation stages - we haven't submitted a charter for ratification yet, but that's our main objective.
    • We have membership from 8 different Foundation member companies, 17 or so individuals from those companies.  So reasonably good representation.
    • So far we've had 3 meetings, with 10-15 participants, including members of the LLC (Bruce, Paul).  So reasonably broad and committed representation, based on meeting attendance.
    • Our main purpose and focus of discussion in those meetings has to come to some consensus on the charter that we can submit for approval.  And also to look at it beyond the charter and think about the key activities of thew WG, and prioritise them, so that when the charter is approved we can get started quickly.
    • In those meetings we've used agenda / discussions / feedback to iterate on the charter.  We've conducted a survey, across the Foundation membership at large (not just those participating in the WG) to help identify priorities.
    • The plan going forward is to take the latest version of the charter, submit it to the membership and vote, on a member firm basis, to submit the charter to the ESCo.  We expect to conduct that vote by the end of the month (September).
    • We then expect to submit the charter to the ESCo for ratification sometime in October.
    • High level activities / prioritisation exercise identified these top priorities:
      1. Put in place a framework or set of best practices / guidelines around APIs that will be exposed going forward around code contributions to the Foundation.  We've used Bruce's document, BNY Mellon's own standards, and standards from comparable open source communities to build this.
      2. Key functional requirements that would be exposed as APIs.  Another voice of input into the Foundation on what we'd like to see in terms of building out and adding to the Symphony platform.
  • Q&A:
    • Lawrence: do you see the WG having both of those mandates ultimately, in the charter put forward to ESCo, or are you trying to pick between the two?
    • Anthony: the vote will determine that, but the intent is to include both of those mandates in the charter, and it's more about sequencing specific deliverables than it is about trying to say what's included vs not included.
    • Lawrence: 2 pieces of feedback:
      • The composition of the WG depends on what it spends its time focusing on.  The questions around standardisation and architectural design of "what does a RESTful API look like from an an architecture perspective" is a very different audience than people who are either consumers of the API or authors of the API code.
      • If I was looking at a dual mandate, I would be looking at how you'd operate under that mandate.  Are you biting off more than you can chew with this type of a WG?
      • Second question I would ask: as you're looking at the second topic (functionally what gets built), at least when I've looked at this through a Foundation lens, the governing processes are around accepting contributions of code.  Would you be looking therefore at this group as the group that approves contributions?  How are you positioning how the WG operates vs how the Foundation operates?
    • Anthony: 2nd question first.  We don't see the WG as being involved in approval activity.  The LLC is already doing market research and has a plan of deliverables.  This is more another set of requirements from Foundation members - another set of inputs.  It's not about approvals.
    • Lawrence: is this code contributions or how do you envisage this working?
    • Anthony: I envisage it as some code contributions to the Foundation.
    • Lawrence: so the WG members procedurally would come up with things they'd like to construct, then propose that code for contribution?
    • Anthony: the mechanism is more along the lines of how are some of the services / experiences we feel are necessary for clients to be able to implement Symphony as a platform product.  Not to build up teams to build that code, but to build up teams who can...
    • James: I'm a little confused by that.  If we think there are holes in the Symphony API offering, then things can either be delivered by Symphony LLC or 3rd parties.  Compatibility layers / client bindings are being delivered outside Symphony, but core things like directory lookup are developed by Symphony LLC.  I think it would be clearer to differentiate between things that must be developed by Symphony LLC vs things that can be contributed by 3rd parties.  I don't understand the idea of influencing Symphony LLC.
    • Lawrence: I think if someone sees a gap, they should contribute code to plug that gap.
    • Frank: I think if the gap is in core Symphony, is the recommendation to plug the gap or request that it be plugged by Symphony LLC?  I'm also a bit confused by the proposed charter.  I thought the API group was going to help evolve the APIs to be more consistent, perhaps with client bindings, capabilities that add on to the core API capabilities, and then if things come out of that that there's a requirement that the community is looking for that's missing, we would feed that back to Symphony (either individually or from a community perspective).
    • Anthony: yes that's exactly what I was trying to express - I think you've said that more eloquently.  
    • Frank: Lawrence is that how you see this charter going?  Do you see this as a value to the community?  I do by the way - I've always wanted to see this kind of WG.
    • Lawrence: I think that things like language bindings, and given where we are right now in terms of getting code contributed, we're either rooting things in creating and contributing code, or we're rooting things in standardising things that define what kind of contributions the Foundation will take on.  I'm trying to fit it into one of these two pillars.  As long as it's constructed around something functional, it's a code contribution - that's viable as a mandate.
    • Frank: I like your two columns.  I thought this body would play both roles.  One being that there should be functional software developed out of the WG (or the community in that space), or in lieu of that we get to your first column - let's try to create some standardisation so that the core software that underpins the APIs supports the kinds of things we're trying to build.  Whether this is two groups or one, this will help inform the participants in those groups.  This is a critical group for us to establish, and if we can isolate into those two buckets I think it would be very helpful.
    • Anthony: this is good feedback.
    • Frank: side note to all of this,  I'm sure we will find product-related issues with what is existing from a Symphony product perspective, and we'll figure out how to feed that back to product managemrn int Symphony.  That's going to be a natural outcome of the progress of this group.
    • Frank: question: do you need help?
    • Anthony: quite frankly I think we're reasonably close in articulating the mandate of the WG.  Happily I hear that there's a desire to have this WG in place, it's a matter of being specific on the mandate, and what I've heard on this call is tips on how to stay sharp on the mandate.  Obviously the charter is going to come to the ESCo for approval, so we're going to incorporate your feedback and reflect it back into the charter.
    • Peter: question: I'd appreciate feedback on the meta process of creating a WG - how was that, what could be improved?  This is our first time through this, so I'm sure there's lots of opportunities.
    • James: we need to provide better guidance to the WGs about what we're doing. The pillars of what's expected.  I was on the last fabulous API WG where 55 minutes was spent talking about voting process - we need to stop that.  It was just awful.  It wouldn't shock me if your attendees dropped as a result.
    • Peter: absolutely, and we already have changes in review within the Foundation to address this (and other things).
    • Lawrence: we need the procedures to be well documented.
    • Peter: agreed, and that's what's in review right now.
    • Lawrence: the second part of it is that a voting procedure itself won't help the WG come to consensus.  So while I think voting procedures are important at one level, they shouldn't be a crutch to come to consensus.  Going to a contested vote before a mandate has been agreed is inadvisable.  ESCo, for example, hasn't agreed on a voting procedure because we haven't had to - we come to consensus before any votes take place.
    • James: agreed.  I felt there was a case on the last call of people saying "if we don't have a voting procedure, then you don't have moral authority".
    • Peter: note that the ESCo does have a formal voting procedure - if you're unfamiliar with it Lawrence you might like to check the wiki.  Also, the group dynamics between ESCo (5 participants) and API WG (more than a dozen participants) are markedly different, so it's comparing apples and oranges.
• Desktop Wrapper WG status update (James)
  • As a reminder, this is the dual charter we originally put together:

• • Attendance stats:

• • I wasn't particularly diligent about tracking members joining initially, but apparently Markit never turn up.    OpenFin also joined later (indicated by the star in the above diagram).  I don't think we can complain about the level of attendance, but I have observations about quality of attendance.

• • Stewardship of an open source project that hasn't been open sourced is a bit of an oxymoron.
  • We've had a lot of conversations about the second objective - about the API between Minuet and Symphony.  In terms of actual analysis of how close to W3C standards we might seek to nominate as the interfaces, progress has been slow.  Some months ago Gareth at GS and myself proposed a POC of Symphony on alternative containers (Electron and OpenFin).  A  month ago we put out a call for participants in the POC, and got zero responses.  We (Credit Suisse) can contributes some resources, and are working through legal.  Gareth at GS was in an accident, so he's out.  OpenFin have indicated they'll participate, but they're unable to access Symphony which hinders things.

• • What we were going to do with Minuet wasn't very clear from the beginning . There were different view points.  Some of the GS folks thought that it was to promote Minuet as a competitor to Electron or any of the open source containers - they were quite vocal about that in the beginning.  Some of the other participants however were a lot more interested in the standardisation.  As the year wore on, it's become clearer that the LLC isn't particularly interested in Minuet per se as a topic.  Without the open source contribution and with a difficult situation regarding people with different views, the enthusiasm for teams to do real work is low - people are happy to turn up and talk at the meetings, but when it comes to real work nothing happens.  For example some time back I asked people to share their existing analyses of containers, and there was lot of "yeah we've got that and would be happy share", but then nothing was shared.
  • On a red / amber / green scale, I'd say Minuet stewardship is red.
  • Q&A:
    
    • Lawrence: I agree on the colour status.  When I think about Minuet from an LLC perspective, when we entered into using Minuet we were looking at it as a solid basic container that would be open sourced and we'd build a community around it and get things up and running.  Looking back there are questions technically around Minuet, like how to provide it on a Mac desktop, and I think there's an issue with the level of contribution to Minuet, especially given the delay in contribution.  Of course we don't have a community around it since we don't have the code.  Looking forward, to reset or re-baseline it is a good idea because where we were art the beginning the year vs where we are now I wonder how far we're going to get even if we do get Minuet eventually.
    • James: I completely concur.  In fact as I was writing this, I was thinking this needs a reboot.
    • Lawrence: the LLC is very interested in the topic of containers, but our level of confidence around what we'll be able to do with Minuet... ...well it hasn't been a good year.  It's not that it isn't important, but the idea of bootstrapping a new container and standards around it is a good direction to go.  The other question I have is that the point of these WGs is focused around code contributions.  Can we get the participants to contribute?  It's been a bit moot given the lack of Minuet contribution, but...
    • James: my honest answer is "no".  The initial answer was "yeah great idea to get Symphony running on Electron", but no one's stood up to do the work. My experience in these kinds of WGs elsewhere is that the banks are happy to rock up and give an opinion, but they're not happy to do work.  It ends up being the vendors who do the work.
    • Frank: it's funny that Markit are not participating in it.  We put Tim Burcham on the group and his focus was on the adaptability of applications & modules on the container, and how we'd open source it in the end.  Perhaps the focus on the container is too narrow?  Perhaps focusing on how applications can adapt to different containers is more...
    • Lawrence: is that a container thing or an API thing?
    • Frank: it's more on the API but there's some visual components. Have you considered the implementation of a UI component?  Or is it focused on API interactions with the Symphony back end?  I see this WG as being about more than just the container - it's how applications can get...
    • James: in fact one of the problems was calling it the "Desktop Wrapper WG" from the get go, while not defining either term.  When I first started I couldn't tell if it was about the container or the APIs.
    • Lawrence: it's interesting that the desktop API was different early on.  We've renamed them twice.
    • Frank: my recommendation would be to revisit the charter of this group.  And change the "desktop" and "APIs" - I'm not saying we merge it with the API WG that Anthony is working on, but more the "extensions API".
    • Lawrence: it's an interesting question around how you decompose this.  How do you integrate the UI elements and speak to the UI elements.  They're all rendered in HTML, so when you talk about the user visible constructs, are they components of the API or are they aspects of which HTML widget libraries do you use in the HTML front end code, whether it's API related or not?  Are you talking about an API or an HTML coding standard?  I don't mean to complicate it, but I think it's a really good idea to try to figure out where these things should live.
    • James: it's an ontology question, and would also help with Anthony's WG.  If we're going to have WGs around Symphony, perhaps ESCo needs to define an ontology of WGs, both of the current ones and future ones.
    • Frank: Markit sponsors our own API/UI module framework and we want to layer it onto Symphony APIs.  That project involves some of the Symphony APIs and some of the F2 framework.  We've written a shim between the F2 framework and the extension API that Symphony provides.  That code that we've created, Javascript code, is something we'd want to contribute to the Foundation, and it relates to interoperability between an existing framework (F2) and Symphony.
    • Lawrence: sounds like an API binding.  Apologies I have to drop off.  Happy to sync up offline.
    • James: with respect to the Desktop Wrapper WG, or whatever we call it, we should table this to next WG meeting.  I'll bring up in tomorrow's meeting and see what the WG members have to say.
    • Peter: this might also relate to the existing agenda item regarding Minuet stewardship as a project, rather than a WG.

Action items

• Michael Harmon, john.stecher@barclays.com, Lawrence Miller (Deactivated), Former user (Deleted): review Symphony Foundation Contribution Lifecycle Proposal and prepare comments / feedback for discussion in a future ESCo meeting
  • Peter Monks: schedule that discussion into future ESCo meeting agenda
• Peter Monks: schedule "WG ontology" discussion into future ESCo meeting agenda