Table of Contents

Date

01 Nov 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
• 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)

Agenda

Meeting notes

• Roll call - quorum is reached
• Action item review
  • All but one action items completed
  • Remaining action item (communicate WG eligibility rules to WG chairs) will be done as part of upcoming communication regarding governance refinements
• Review of CONTRIB-24 / ODP-3 - Former user (Deleted)
• This is a patch for the Symphony client extensions API (JS). Question: is the Foundation there to support patching of LLC projects / offerings? Should this be going through the Foundation, or to the LLC, or ...?
• Lawrence Miller (Deactivated) my $0.02 worth is that that code is not open sourced so I would suggest that the customer should follow up directly with the LLC support team.
• Peter Monks the background is that this was raised by a non-customer / non-partner who doesn't have any formal path to engage with the LLC support team (they were an NWS participant).  At the event, the Foundation and Former user (Deleted), agreed to capture this request temporarily as a CONTRIB, but pass it on to the LLC's product team soon after.  This is also a good example of a general class of feedback the Foundation expects to receive, and intends to handle via the ODP JIRA project.  Some Open Developer Platform (ODP) issues will be addressed by Foundation staff (e.g. account provisioning requests), and some will be "proxied" over to the LLC product team (e.g. API bugs & enhancement requests).  We do not intend to make that distinction in triage approach publicly visible.
• • Lawrence Miller (Deactivated) this informal procedure sounds good to me.
  • Peter Monks to clarify, this is not an informal procedure - it was developed collaboratively with Former user (Deleted) and the LLC product team, and has dedicated infrastructure in place (ODP JIRA project) to support it
  • Former user (Deleted) sounds good to me.
• Active vote for symphony-java-client - Former user (Deleted)
  • We should have a guinea pig to take a project to full release (v1.0).  v1.0 will be a special place ("gate B") and it would be good to release the symphony-java-client in the coming weeks.  After we've reviewed the criteria, I'd like to go through an official vote.  If everyone agrees for a vote, then I'd like to move forward with this.
  • Peter Monks terminology clarification - what we're talking about is here is the "Active" state of a project, not a release.  A project team may make any number of releases at any time, including while in "Incubation" state.  What needs ESCo approval is moving from "Incubating"  state to "Active" state.
  • Lawrence Miller (Deactivated) we (Symphony LLC) want to hook the client up to our API test suites.  Has that discussion come to a conclusion yet?  We might want to hold off on activating the project until we've heard back from the LLC platform team.
  • Former user (Deleted) they'd mentioned adding it to their test rig and I'm happy for that.  But I'm waiting on them to respond to my comments, while also working on the documentation side.  If they're proposing testing it, then I'm all for them pulling it down and testing it.  If you can nudge them, I'd appreciate it.
  • Lawrence Miller (Deactivated) there was a note on Friday saying they were doing that this week.  We should have some closure to this process this week, and this would make a baseline for v1.0.
  • Gabriele Columbro is the client being tested against the ODP?  Or is it just unit tests?
  • Former user (Deleted) there are very light unit tests in the build process.  Lots of people are using the symphony-java-client in code that connects to the ODP - sample code, etc.  I do think it's being test but not to the level the LLC might expect.
  • Gabriele Columbro one of the Q4'16 objectives for Maurizio Pillitu is to get continuous integration and continuous deployment set up against the ODP.  It sounds like that's not setup yet for the symphony-java-client
  • Former user (Deleted) that's correct
  • Lawrence Miller (Deactivated) the reason we're proposing testing this is that we expect it to be heavily used. As people start using it in a v1.0 form we want it to be formally tested and QAed.
  • Former user (Deleted) what I'd like are additional contributors from the community.  Some additional things we're planning (e.g. command frameworks) could do with help.
  • Gabriele Columbro an LLC engineer wants to contribute more docs / samples - I'll connect you with him.
  • Peter Monks did the Blackrock folks ever get back to you regarding their planned contributions?
  • Former user (Deleted) no - I'll ping Matthew Gardner again.
  • Peter Monks great - please include Aaron Williamson on those communications, so he can continue the CCLA conversation.
  • Former user (Deleted) have you opened up the GH pages in the symphonyOSS Github organisation, so I can publish the project's Javadocs there instead of my own personal GH site?  It was blocked last time I checked.
  • Peter Monks not sure we're tracking that, but if you raise an INFRA JIRA we can get right on it.  Please raise it as a high priority, so we can get ahead of it before the activation vote.
• AOB:
  • Peter Monks Thanks for responding so quickly to the avalanche of votes yesterday.
  • Lawrence Miller (Deactivated) on that note, I think there's a risk of missing votes if they're sent out in batches like that.
  • Former user (Deleted) if we have a mass vote, I'd propose having it on a web page.  A deluge of emails is a bit of a pain.
  • Peter Monks the current ESCo voting procedures are individual votes, conducted either in-person or via email.  Email votes are preferred since they're transparent and auditable (they're also how virtually every other open source initiative and Foundation conducts votes).
  • john.stecher@barclays.com I'd prefer live votes in a meeting too.  From an efficiency perspective, it's easier than having a set of vote emails scattered throughout my inbox.
  • Lawrence Miller (Deactivated) we should consider conducting a single vote on a package of CONTRIBs.
  • Peter Monks there is currently no procedure for conducting a single vote on multiple unrelated CONTRIBs.
  • Former user (Deleted) we're all busy people and we need to optimise these procedures to make best use of our time!
  • Peter Monks I understand the concern - I'm merely pointing out the current voting procedures.  I'll investigate alternatives and report back.

Action items

• Peter Monks add "Long Term Maintenance" as a new project state in the project lifecycle, and update all relevant documentation
• Lawrence Miller (Deactivated) ensure LLC platform team has completed setup and testing of symphony-java-client - DUE 2016-01-04
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Gabriele Columbro introduce LLC engineer (Kinkoi Lo) to Former user (Deleted), regarding symphony-java-client contributions
  • Completed 2016-11-01, via Symphony chat
• Former user (Deleted) ping Matthew Gardner re Blackrock contributions to symphony-java-client, including Aaron Williamson in the conversation
• Former user (Deleted) raise a high priority INFRA JIRA requesting that the symphonyOSS Github Pages ("web site") be opened up to publishing from project teams 
• Peter Monks investigate alternative voting mechanisms and report back to the ESCo