Table of Contents

Date

18 Oct 2016

Attendees

Actions items from previous meeting

• 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
• Lawrence Miller (Deactivated): follow up offline with Former user (Deleted) and Michael Harmon regarding limitations around rich content
• Lawrence Miller (Deactivated): locate internal LLC conversations (if any) around "messaging strategy and vision", and then work with john.stecher@barclays.com and Nathan Bricklin on potential new WG on this topic
• Peter Monks: push agenda items we didn't get to to subsequent meeting(s)
• Peter Monks to let the group know if his conference attendance will impact the weekly ESCo call
  • It won't - Peter is available on the 18th for his usual secretarial duties
• Michael Harmon to let the group know once his & Lawrence Miller (Deactivated)'s upcoming travel plans are finalised
  
  • Peter Monks to reschedule ESCo meetings, if necessary

Agenda

Meeting notes

• Quorum achieved
• Desktop Wrapper WG update - James:
  • Gave a status update on the WG's
  • Overwhelming response was lack of interest in Minuet - interesting thing for WG is standardisation
  • In the last meeting we then had a slightly wider attendance and rieterated that that had been the opinion of those in September.  Again having a focus on standardisation with the goal of being able to produce and put Symphony into any compatible desktop container was one that people wanted to focus on.
  • The action out of that was to look at the OpenFin API as a straw man.  As of Monday no one had looked at it, but as of today we've had contributions from Blackrock and Credit Suisse.
  • I am still a little wary that we say we're going to do things and people on the call nod and agree, but then nothing happens.  It's going to be hard to standardise on anything if we don't get input from anyone.
  • This week we have JC to give us the latest plans from Symphony LLC regarding desktop containers, which might invigorate some discussion.
  • Peter: James has been rallying the troops
• Lawrence: open sourcing update
  
  • Context around this: we went away after the last Foundation board meeting and assembled aa plan in terms of how the LLC is going to go about open sourcing the code.
  • This was presented to the LLC board and there was a dynamic discussion around that.
  • The outcome was a 3 stage plan:
    • Initial and 1.5 stages were approved by the board
    • 2.0 stage is pending further discussion and buy in from the LLC board, and once those questions are concluded, I don't see that being an impediment to the discussion being resolved.
  • I think this is a very good outcome, because we have authorisation to move ahead with the initial and 1.5 stages of the plan.
  • James: in practical terms, what does "1.0" and "1.5" mean?  My recollection is that "1.0" was Minuet, but 1.5...
    • Lawrence: 1.0 also had bot work.  1.5 involves some of the other components, in particular the horizontal integration API, and some front end code.  The front end code is particularly interesting as well ad the horizontal integration code, since they're parts where people are going to want to make contributions.  Initially contributions to the front end behaviours is likely, more than making the back-end routing 10% faster.  We're also in favour of that, but it's probably less interesting to the community than being able to contribute front-end behaviours of the system.  It's well aligned to making value available quickly, and the 1.5 phase has some significant "meat" in it.
  • James: is there anything concrete about when things are going to pop out of the process?
    • Lawrence: the plans we presented (both Foundation & LLC) had schedules related to APIs.  The front-end code needs to go through our internal process and in fact Mike is running our internal review process on the contribution.
    • James: so you're executing on it?  There are no blockers?
    • Lawrence: exactly.
• Frank: Symphony Foundation Contribution Lifecycle Proposal
  • Has anyone looked at it?  It's pretty straight forward.  It's about if/how ESCo gates initial releases after the contribution process.
  • Right now it builds on the project approval process ESCo has today - it's consistent with what we have in place.
  • Gate A: The difference is that post-approval, the project is in the incubation phase and we want to evolve it to be truly released to a public repository.  Be able to say "This really makes sense now and can be used in the broader community".
  • Drawing your attention to point #5 - after 6 months in incubation, the project goes to archived state.  We can discuss the timeframes but I think it's important to have time barriers
  • Gate B: first release of a project - we want ESCo to review that release, alongside the Foundation (Maurizio, Peter, etc.) and make sure the quality gates defined by the Foundation are "met".  But also ensuring ESCo visibility and allow us to promote the project.  Point people outside the Foundation to it.
  • Regarding approvals, I put a few things there.  I don't think we have to be pedantic about it yet, but capturing some minimum levels of quality is important.
  • As part of Gate B source branches should be tagged properly - this is an important part of development quality.
  • Once the first release is approved I'd expect standardised delivery to occur - the ESCo doesn't need to be involved.  Projects can release at will.  I'm not proposing to put any specific gates around that.
  • The last thing is inactivity - if a project has been sitting there quite a while with nothing happen, even post-release, then we should consider archiving it.  Perhaps the project has gone as far as it can go and it should be put into care & maintenance.
  • Monthly we (ESCo) should look at things that are not active, and make a call as to whether they should be archived or not.
  • Questions?
  • Peter: on the Foundation side it would be wonderful to have these requirements, as it gives us clear opportunities for automation
  • Lawrence: my comment is that this is very well thought through.  I like the process.  I'd defer to Mike whether he has any comments on how Github is used technically.  The one thought I would have is that we should think about inactivity / archived category that there may be projects that don't have contributions to them very frequently e.g. sample code, sample bots, etc.  I don't think this particular statement here around inactivity precludes those kinds of projects existing, but perhaps we should have an affirmative status for those.
  • James: perhaps "long term maintenance"?  Over time APIs may change and actually we want to affirmatively say we will maintain bots etc. using those APIs.  We want it to be clear to end users whether the bot has been updated for v2 or is only working on v1.
  • Lawrence: absolutely, and if we have a good story around API compatibility we won't need too many contributions.
  • James: yep it could easily be the case that there are only breaking API changes every 2 years or whatever.
  • Frank: perhaps project labeling - having a label for "long term maintenance".  To go back to Peter's point it's all about tooling.
  • Peter: we've been discussing labeling a bit internally.  Github makes it a bit tricky to support an Apache style model (different domains for each status of project), but we need to solve this issue - it's on us.
  • Frank: so in terms of next steps I think we need a vote or decision on this, then communicate it.  How do we ratify this?  Does it need board approval?
  • Aaron: the ESCo has pretty broad authority to determine how it makes decisions on technical matters.  My reading of the by-laws is that things like ESCo membership need board approval, but everything else (especially technical governance) is up to the ESCo itself.
  • Frank: thank goodness!  The logic feels sound, but perhaps I should update it for Long Term Maintenance.  I also need to move it over to the general wiki - it's in a personal page right now.
• Aaron: ESco Advisors & WG membership:
  • First order of business:
    • In the past I understand that the ESCo has ratified new members in WGs, and one idea is to delegate this to the WGs.  This isn't an enumerated authority of the ESCo in the by-laws or any of the other governing documents.
    • James: from my point of view, within the limits of who's allowed to participate in a WG at all, then I'd be very happy for the chair of the WG to approve that.  If it's an external (non-member) person, then I'd be unhappy to decide that.
    • Lawrence: if there's a disagreement, then maybe it can be escalated to us and we're informed of what's happening.  e.g. if a chair is disallowing WG membership to someone.  We want to be there for problematic situations.
    • Aaron: anything else beyond disagreements or problematic membership?
    • James: I think we'd like clarity on the rules.  When Colin @ ScottLogic wanted to join Desktop Wrapper WG, it became an issue as they weren't a member.
    • Action for Foundation: clearly communicate WG eligibility rules to WG chairs.
  • Second order of business:
    • The newly amended by-laws allows Platinum & Gold members to elect, as a class, ESCo Advisors.
    • We'd like to ask those classes whether they'd like to elect their advisors now, or wait until later.
    • <reconnected due to poor connection>
    • So we'll be notifying the Gold & Platinum members to elect their advisors.  There's no specific timeline in which they're required to do this, but given it's an outstanding governance issue that hasn't been addresses, we want to give them the oppportunity to set their own timeline.
    • Lawrence: have they passed their thresholds?
    • Aaron: Platinum & Gold don't have thrlesholds, only Silver & at-large.
    • Lawrence: are there any election cycle considerations we want to take into account?  How do these sits fit in and intereact with the 5 current ESCO memberS?
    • Aaron: the Advisors are advisory, they can't vote unless there's a deadlock in the ESCo on an issue.  They don't otherwise interact with the existing seats.  There are no ESCo advisors elected now, and there are a total of 7 seats available.  Each class (Platinum, Gold, Silver, and At-large) get one seat, but as you point out there are thresholds for Silver & at-large.  Right now there are 5 open seats, including three seats appointed (not necessarily elected) by the ESCo itself.
    • As for timing, it doesn't make sense to wait until the silver & at-large tiers meet their thrseholds, since we don't know when that'll be.  The ESCo has the option to appoint their advisors alongside the elected Platinum & Gold advisors, but they don't have to.
    • I'd be interested in your input on timing wrt current seats' ?  I 
    • Lawrence: I see some benefit to having a predictable election cycle.  I also see some benefit to some form of staggering, so not all seats turn over at the same time.
    • Aaron: the only problem with trying to stagger the Platinum & Gold advisors is that they only have 1 seat each.  The other considering  is that there aren't any term limits for ESCo advisors - new election would be when the existing advisor chooses to step down, or the membership turns over the member.  To put in term limits might require some governance changes.  This could result in staging by fiat, but also presents a risk of long terms.
    • Lawrence: ultimately I don't think this is too big of a deal, but I could imagein elections happening on a regular schedule, so tthat we're not having elections each month.  We could still stagger them and have them aligned, say, every 6 months, as a matter of practice.
    • Aaron: I just don't want the Platinum & Gold classes to have to hold off their initial votes because the Silver & At-large tiers haven't reached their threshold.
    • There's aboard meeting tentatively scheduled for January 11th, and right now we have enough lead time to have the membership tiers vote around the same time.  I don't know if that's necessary, but aligning it with the board meeting might at least allow us to place these things next to each so that we're not bugging the membership with lots of new actions.
    • In the nomination form ,we were thinking os asking the members to describe why the nominee is appropriate using the same criteria previously used for the project leads.  Would you agree that those qualifications are the same for advisors that we'd be want to be seeking?
    • James & Lawrence: yes
    • Aaron: I don't want to leave the staggering question unanswered.  Do you have any suggestions on how we might address that concern, given that right now it's only the P & G members how'd be choosing their advisors?
    • James: I think given what you've said, the staggering thing will resolve itself.  I'd like to get the two high end guys at the same time.
    • Lawrence: I'm in agreement with that.
    • Aaron: ok as far as the ESCo advisors (3 seats) you'd appoint - is that something you'd like to move forward with, or would you like to wait?  You could also deliberate on this and get back to me - you're not bound by the same 60 day nomination process the membership is, so you could act a bit quicker if you'd like.
    • Lawrence: I'd like to give people more time to demonstrate activity as this is a useful way to recognise individual and organisational participation.  My $0.02 is to look to the Foundation and if there's a point where you think there's appropriate individuals or theoretical thresholds in terms of how active folks are and they're qualified candidates...
    • James: or there are specific problems we think we need help with.
    • Lawrence: the concern I have about that is whether you've nominated someone will they follow through.
    • James: agreed, and I don't see a burning need to do it (appoint our seats) now.
    • Aaron: ok so the ESCo would then prefer to hold off on appointing any of the 3 seats until the Foundation or ESCo sees a need to fill those seats, or there's an individual who's been contributing to the community and who's input would be especially valuable.
    • Lawrence: yep that sounds like the consensus.
    • Aaron: thanks everyone.
• AOB:
  • Frank: going back to API WG discussions.  Have they ratified their charter?  I'm confused on what they're focusing on.
    • James: their meeting #4 started 56 minutes ago, so I'm not sure on the latest.
    • Frank: biggest concern I have is focus on building Symphony REST API roadmap.  I don't think we should be focusing on that.  I think we should be focusing on SDKs and client libraries.
    • Lawrence: I think we expressed those concerns to them on August 25th.  It doesn't sound like those issues were addressed.  I think it's on an upcoming agenda to review, so maybe we should wait and see.
    • Frank: I agree, I just want to give them an FYI.  What you're looking at and what I'm looking at from the minutes I'm thoroughly confused.
    • Lawrence: the concern you articulated was stated to the WG by the LLC's representative in the WG.  This is coming up on our agenda for the 1st, so the WG could decide between now and the 1st if they want to do something  I think they passed a motion that they want to send it to us for review.  Unless they do something else, it's going to be coming to us on the 1st and we can review it and formally respond to it.  They have the option to do something in the interim if they choose to.
    • Frank: I don't want to waste anyone's time
    • Peter: the meeting minutes aren't the best way to understand what the WG will present for ratification - to repeat an analogy from some time ago, they capture the process of making a sausage, not the sausage itself
    • Lawrence: the API WG clearly haven't heard the ESCo's prior feedback, and is at risk of not having their charter ratified
    • Frank: I'm concerned that this WG won't succeed, even if the charter is ratified
    • Peter: providing that feedback to the WG chair (Anthony) would be advisable - over-communication is better than under-communication, and I'm not sure feedback from a single ESCo meeting is sufficient
    • Lawrence: let's let the process run and see what happens

Action items

• Former user (Deleted) to update Symphony Foundation Contribution Lifecycle Proposal with feedback from today's meeting, and move it to a general wiki page
  
  • Former user (Deleted) once updated, redistribute the docs and call for an email vote to approve the lifecycle
• Peter Monks to communicate WG eligibility rules to WG chairs
• Former user (Deleted) to share his concerns regarding API WG directly with Former user (Deleted)