Table of Contents

Date

25 Apr 2017

Attendees

Actions items from previous meetings

• 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
• 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): let Aaron Williamson know if there are particular people at CS who should be explicitly invited to the Open Source Strategy Summit in June (note: this event has been rescheduled to November)
  
  • We encourage all ESCo members to let us know who in their firms would benefit from the event!

Agenda

Meeting notes

• Quorum not achieved
• Action item review:
  • Frank: getting CII certification of the symphony-java-client is my next priority after contribution of the ESCo vote bot
  • Peter: and I know Frank and I haven't worked any further on the project lifecycle proposal - that's as much in my court as his
  • Aaron: James did not reach out yet regarding Credit Suisse folks at the Open Source Strategy Summit
    • Peter: and the pressure is off a bit, given that it's been rescheduled
  • Aaron: Lawrence did kick off the policy template work in the BoD meeting - it's on the agenda for today
• Deutsche Bank / desktop interoperability plans:
  • Skipped as neither James or Lawrence were present
• CONTRIB-79 ESCo review:
  • Frank: thanks for your wonderful work with the community.  My apologies for starting an "international incident" around the contribution vote.    Background is that ESCo are looking for projects that can be combined over time, and we want to flag that early on.  The deeper the projects we create, the more focus we have internally within the community and externally.  We have a lot of projects in incubation but we're not yet seeing deeper projects coming out of it.  That's where this is coming from - it's not that what you're contributing doesn't have value, it's that we're trying to drive deeper value.  Can you describe your contribution?
  • Glenn: sure - I can show you what the app looks like via screen share:
    • 
  • Glenn: My desire is to have a consumer product, more than a back-end, back-office sort of thing.
    • 
  • Glenn: The whole thing is script based.  The key thing are the scripts down the bottom.  A script is a regular expression, and how to respond to it - that's the entire technology.  There's some subtleties, but it's intended to be simple.  Here's an example bot script:
    • 
  • Frank: so this is the editor for the bot?  Where you add commands, and their responses?
  • Glenn: exactly
  • Frank: what's the input for the bot?
  • Glenn: the config screen (screenshot #2 above)
  • Frank: so you're updating the bot in the background?
  • Glenn: the bot has two pieces - a back-end and a front-end.  The front-end sends bot management commands to the back-end.
  • Frank: so this is like a management interface to hubot, in a sense.  That's why it's very cool.  Do you see alignment with existing projects?  e.g. hubot-symphony could use this front end to update the back end hubot scripts.  symphony-java-client could absolutely use this front end too - be managed dynamically from this front end (once I add the interface to the SJC back end).  I see this becoming a universal or standard interface - the value of this is super useful, but to see the benefit come though I'd want to see this tied to the bot backends - commands / actions etc.  Having actions themselves administered through the Symphony front end is very exciting to me.
  • Glenn: a couple of things: the interface right now is very specific for my bot.  The way it communicates with the bot backend is via pub-sub with Redis.
  • Frank: but we could fix all that.  
  • Glenn: yes, though most of the UI code is around those things.  It could be adapted to a more generic way.  The genesis of this project was an internal bot hackathon about a year ago, and I promised I'd submit this then - that's how we got here.  I can see how taking the concepts of a front end that configured your bots running on the back end - I can see the value in that.  I think that is different than what I've created, but you might be able to converge it on something with those other projects.  Oh and everything is written in node.  
  • Frank: any other comments?  James?
  • James: conceptually I like that the UI is in Symphony
  • Glenn: yeah most of the stuff I do has an integration with the Symphony web client, because that's my job here.  
  • James: it's kind of a fun example, even if the code requires a bit of adaptation.  It's a great example of how to do some of this stuff.
  • Frank: anyone else have anything to add?  A demo is worth a million words.  
  • Nick: I agree with James - it's good to have this as an example of how you might implement a front end UI to configure a bot.  I don't think most people approach bots that way.
  • Glenn: I assumed as much.  
  • Frank: I'll ask Peter to put the vote back up so we can move this forward.  And just so you know, once a vote is in motion, we don't have a way to pause the vote - it wasn't intentionally voted down because of anything you've done.  I'm going to ask Peter to put the vote back up, but once contributed I'd like you to work with Jon Freedman on the hubot back end.
  • Glenn: yep he and I are speaking.
  • Frank: the API Working Group is also working on client bindings for the REST API.  Within the API WG a standard for defining and administering bots would be a great topic.
  • Glenn: another thing I recently configured contributed is a node-based API binding.
  • Frank: yep I'm aware of that.  Are you part of the API WG?
  • Glenn: no.
  • Frank: it's in its infancy, but the working group will likely reach out to you shortly regarding what a language binding looks like.
  • Nick: you're exactly who we need on the WG.  What we really need is an agreement on the API between the web client and whatever the container is.
  • James: I think Frank is talking about the API WG where they're talking about the back-end REST API bindings.
  • Frank: yeah.  We're creating language bindings and back-end bot solutions, and again I can see an interesting topic about administering bots.  What Nick's saying is another topic entirely, but might also apply to the work Glenn is doing.
  • Glenn: if you want me to have any involvement, talk through Thomas here [at the LLC], and we can see how much time I can devote to it.
  • Peter: is that Thomas Kiessling?
  • Glenn: yes - he owns my time.
  • Frank: and speaking of time, thanks for joining the call and giving us a demo.  We'll put the vote back up and review with the other ESCo members.
  • Peter: one seed I'd like to plant are the security implications - this is basically a script injection attack, and in some runtimes (e.g. the JVM, which has lots of low-level access to the running server) executing code that comes from a UI is a big security issue.  Something to think about as we go forward.
  • Glenn: yep I'm very security conscious and come from a game environment, which is a very hostile environment.
  • Frank: cool yeah - thanks again Glenn!
• Open source readiness:
  • Peter: do we have enough representation to discuss?
  • Aaron: Lawrence and Gab are driving this, so I feel like we can't continue until they're here.
  • <Lawrence joined - impeccable timing!  >
  • Aaron: Lawrence pitched to the BOD that there be a group convened to share open source policies and discuss avenues for collaboration and hopefully in the end come up with draft or reference policies for open source in financial services.  The board was generally supportive and there were several volunteers.  Lawrence laid out the ground rules:
    1. It should be the person who owns the open source policy
    2. The firm should, in principle, be open to adopt recommendations the group
    3. The firm should be willing to share their open source policy, if they have one
  • Aaron: we also talked about limiting the number to a workable number of participants, but in followup conversations that could be problematic for a couple of reasons:
    • we don't want to exclude members
    • we should expect some of those who expressed interest to drop off
  • Lawrence: my original thinking was that we might want to create artificial scarcity to create interest. but that didn't seem to be an issue at the board meeting.  This brings up some of the stuff you raised James re the consultancy.  If we have a large group the dynamic is going to be different and people will be a little less open.
  • Frank: yes that was my comment in the last ESCo meeting.  My concern is making this too large and not getting a good output.  I see starting with 5 or so and growing down the road, but if we have more than that, bringing in a consultancy may help.
  • James: there's difficulty in constraining it, especially via the Foundation - if we're running it via the Foundation then it should be open to anyone who's a Foundation member.  Outside of the manageability of it (which I believe is a real practical thing), I don't know how we'd say no to a 6th person.
  • Frank: the ground rules need to be clear that people will collaborate in well defined ways.  The proposal from eCo is interesting for that reason.
  • Lawrence: as a broader proposal that was not drafted for the Foundation.  Within the Foundation the work would be more open and would focus on the policy we'd propose.
  • James: what they're proposing is compatible.  It's a proposal for us, and I said I'd share it with you guys - it's not a proposal for the Foundation per se.  I believe they are speaking with the Foundation at some point, and we could go back to them and say we want them to work that way - asking them how they might work via the Foundation.  Also we'd be able to adjust it based on our feedback.  My understanding is that when I spoke with them about the proposal and said "how concrete is it going to be" their view is that a single draft / agreed reference policy seemed to them (given the conversations they've had) to have some level of optionality - they talked about a decision tree in the document.  People would pick & choose the parts of it that suits their particular firm.
  • Lawrence: yes it'd have to be a reference policy rather than a single policy.
  • James: I think it's broadly aligned.  I don't know how many firms they're speaking to, but clearly, given the Foundation membership, it would be some of the Foundation board.  It seems unlikely we'd want to do this twice.
  • Lawrence: and there's a cost question.  On one hand there's a question of "if we did this in the Foundation, let's look at what they're charging the firms for the consultancy work".  Presumably we're talking about their labour costs being in the range of 6 man months of work, possibly more.  So if we resourced this inside the Foundation we have a reference point.  Could the Foundation support 6 man months of work, or would this come from the Foundation members volunteering time?
  • James: Gab specifically said he wants to be in this conversation, and he's on vacation this week.
  • Lawrence: I think there's a question of what the commitment would be to do this inside the Foundation vs bringing in outside help.
  • James: there are multiple permutations.  What we're all interested in is an outcome, and finding the best way to get that outcome.
  • Aaron: looking at the way this proposal is structured, it cuts the Foundation out of the picture.  Obviously our members are welcome to work with each other however they want to, but the value of the Foundation to the members is that it's the place for this kind of collaboration.  My concern is that if the firms interact this way, rather than inside the Foundation (regardless of eCo or otherwise), the participants may decide they don't want to share the policies after all, since they've invested in them and the ground rules weren't set from the beginning that the final product would be public.
  • Frank: I'd recommend the Foundation manage and own it, and if there are requirements to bring in additional resources to support the activity we can have that conversation.  And James thanks for sharing this - it helps identify ways to organise this work.  I want to see a practical outcome - the goal is to create a reference policy for companies to apply and it's a very clear goal.  We need to be clear on those objectives.  I think this is going to be a collective thing - it's not going to be one person doing this.
  • James: one comment on the eCo proposal is that it's for banks.  The proposal doesn't include the Foundation because it's from a consultancy to a bank - we shouldn't read too much into that.  If the Foundation engaged the consultancy the proposal would be different.
  • Aaron: under participant terms, they reproduced what Lawrence presented, and it looked like it had been prepared afterwards with those conversations in mind.
  • James: or they're smart people who figured out what the requirements are.  Let's not assign motive to this beyond "they're a consultancy who want some work".  And I spoke with them prior to reinvigorating our own efforts on ESCo regarding this.
  • Lawrence: yeah my conclusion is they'd reached similar conclusions independently.
  • James: and my concern is that the collective nature effort of trying to get things done, particularly in the banks, can run afoul of people's time to do things.  Paying someone to do it, and everyone committing to that, means you're more likely to get something done rather than being beholden to volunteer time.
  • Frank: I appreciate that.  But we have capability within the Foundation to run point and to your point, how much personal time we, as an ESCo body, can devote is a big question
  • Lawrence: if firms wanted to hire eCo, then say 5 of the firms could hire eCo and the resulting common understanding could be input into the working group.  That might give us, say, 80% of the analysis, then we'd need to layer in the policy concerns of the other member organisations.  This could be complimentary and semi-independent, is my point.
  • Aaron: I think that's right.  Frank to answer your question, Gab considers this to be part of my job and I have time to devote to this.  The difficulty I've run into is gaining an audience with the stakeholders at the banks, but it seems like things have moved since our initial efforts.  So adding resources could help, but right now resource constraints haven't been the issue.  Regardless of how successful the working group is, each firm is going to need consulting from experienced people to operationalise the recommendation within their firms.
  • Lawrence: in terms of next steps, we seem to be at a point where we're in a position to call together the working group and start talking through these things collectively.  In terms of how ESCo fits in with this, a number of organisations have expressed interest, and I imagine there are a few more who are also interested but didn't speak up at the BoD meeting.  We should put a call out "if you're interested...".  There's general consensus in ESCo on criteria for joining the group.  Let's see who puts their organisation forward and get those meetings  moving.  Then we can talk about how to operate, what the mandate is.  We only have 3 banks in ESCo.
  • Aaron: I think that sounds like the right approach.  Any reason not to run this process the same as every other working group?  Draft a charter, have an initial meeting, and go from there?
  • James: probably not.
  • Aaron: and of course obtain ESCo approval.
  • Lawrence: I think you're going to find that there will be ESCo involvement in this WG.  The only different between this and a regular WG is that there may be elements of legality, so we may need rules about what gets said in the WG stays in the WG.
  • Aaron: yes communication rules.
  • James: that topic is worthy of a discussion around ESCo as well.  For instance, we've just talked about our approach for using or not using eCo.  These minutes get put up absolutely verbatim, and I'm not sure that's how we want to operate as ESCo.  I think summarised minutes might be better.  Some of the things we talk about, taken out of context, may not be great.
  • Lawrence: I thought the ESCo minutes were private to ESCo?
  • James: I believe they're public.
  • Lawrence: though I've always tried to act as though they're public.  Peter can you confirm?
  • Peter: yes they're public, all the way back to the first ESCo meeting.
  • James: I don't have a problem with them being public, I have a problem with them being verbatim public.  If we're going to have them verbatim, then if we're discussing commercial matters etc. we need to be careful.  Just a comment given that this working group may be discussing legal matters.
  • Lawrence: I'm generally inclined in that direction.  But it's valuable to have a complete, high-fidelity version - I use it quite a lot to refer back to previous conversations, but it adds a dynamic to the discussions since it's very public.  I'd be interested in what other ESCo members think.  I suspect Peter also has reasons for it.
  • Frank: I concur with the sentiment on the call - that putting verbatim minutes in a public forum.  The difficulty is how do you summarise the viewpoints efficiently.  Anything is probably better than verbatim, but we have to be careful with summaries.  I agree, I just don't know how we'd execute on it efficiently.
  • Lawrence: I think what we'd want to do is make a formal decision to change how the minutes are being captured, and what to do historically.  It would add this additional step, which I think is relatively small - 3 or 4 bullet points at a summary level of what the summarised minutes are.  Then the detailed ESCo minutes would be private to ESCo.
  • James: then the first  standing item in each meeting will be to approve the previous summary minutes.  While we quite often have detailed conversations about things, the summary notes wouldn't capture all of that, and would be easy to read.
  • Peter: as Gab's email a few weeks back discussed, transparency is a cornerstone for establishing trust in a community, so I'd want to at least see the full minutes being visible to the membership (which we can do, as we have those groups setup in Confluence).
  • James: but if ESCo needs to talk about a member (e.g. a member being disruptive) would we want that going to the membership?  Transparency has unintended consequences i.e. that we set ourselves up for sidebar conversations that we don't want minuted.  I understand this idea of transparency, but it has a consequence of restraining the sorts of conversations we have.
  • Lawrence: Peter do you have a sense of whether the members use the minutes that are currently published?
  • Peter: I don't, no.  As far as I know Confluence doesn't provide any kind of access log (though it provides good visibility into editing activity).
  • Lawrence: do you have evidence that members use these minutes?  Have you heard of their use in your conversations with members?
  • Peter: yes, though it's rare.  I think the bigger issue is that this body represents the membership, and should therefore be transparent to the membership.  ESCo's "customer", if you will, is the membership.
  • Lawrence: well technically John and I represent the board, and some of the non-voting members represent sub-sets of the membership.
  • Peter: Aaron is that correct?  As I understand it, appointment and representation are unrelated.
  • Aaron: technically all the by-laws talk to is appointment.
  • James: regardless, if a group of people vote for someone, then effectively they will consider that person their representative.  But I don't think we can come to a conclusion in this meeting, so let's add it to the agenda for a future meeting.
  • Lawrence: I think we've identified two actions:
    1. Aaron go ahead and put out a call for the WG, and share a draft of the email with ESCo first (ground rules etc.)
    2. Put this question of the minutes on the next ESCo agenda for discussion.  General consensus of those who are participating on this call, that some form of change should be made,.  So either we need to put forward a concrete proposal to discuss, or a general discussion to kick the idea around.
  • Aaron: perhaps there's an associated action to not publish these minutes?
  • Peter: I see the grandfathering problem as going back to the first ESCo meeting, and wouldn't want to special case today's minutes.
  • Lawrence: I agree with Peter - let's not change this time unless we need to.
  • James: maybe it would be a good idea to send these minutes out for review by ESCo before they go out to the public?
  • Peter: Happy to do that - I'll restrict permissions on the minutes to just ESCo, so you can review.  If I don't hear any objections by the end of the week, I'll then open them up to the public as per standard practice.
• Adjourn

Action items

• Former user (Deleted): reach out to Thomas Kiessling regarding Glenn's participation in the API WG (Lawrence Miller (Deactivated) to help facilitate)
• Peter Monks: rerun the CONTRIB-79 contribution approval vote
• Aaron Williamson: draft email for board, soliciting participation in the proposed open source readiness WG, and send to ESCo to review
• Former user (Deleted): add agenda item to future meeting to discuss format and visibility of meeting minutes
• Peter Monks: set permissions on these minutes to just ESCo - if I don't hear any objections by the end of the week, I'll then open them up to the public.