Table of Contents

Date

03 Jan 2017

Attendees

Actions items from previous meeting

• Peter Monks to communicate WG eligibility rules to WG chairs (as part of governance refinements comms)
• Peter Monks investigate alternative voting mechanisms and report back to the ESCo
• Peter Monks to coordinate development of a proposal around reporting requirements
  • Project reporting proposal is available here
  • Working Group reporting proposal in progress
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Former user (Deleted): draft a quick page on WG "scope" and distribute to mailing list for group iteration - superceded by the following item:
• Former user (Deleted) to send one-liner on "WG scopes" to Peter Monks for addition to the next agenda
  
  • All: review the agenda notes prior to this meeting

Agenda

Time	Item	Who	Notes
5 min	Roll call	Peter Monks
5 min	Review action items from last meeting	Peter Monks	See above
15 min	Review feedback on the WG scope one-liner	Former user (Deleted)	Proposed content: WG Charters should primarily look to influence and produce artefacts that are within the scope of the Foundation (standards for use within the Symphony Foundation) or are of primary interest to the Foundation. While influencing and providing input to LLC is expected to form part of work of the WG, WG Charters should try to avoid relying entirely on influencing the LLC to deliver the goals of the charter.
15 min	Define board reporting	All	During the governance refinements review the ESCo indicated it will be preparing the quarterly status reports to the board. This raises two questions: how would ESCo like to handle the upcoming Jan 18th BoD meeting? Here's an example of the status reporting we've been doing to date - we don't expect to change this for the January BoD meeting. more generally going forward, how will ESCo prepare and present status to the board?
15 min	Update on LLC's integration contributions - TENTATIVE	Lawrence Miller (Deactivated)	The LLC's integration contributions ( Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration. & Unable to locate Jira server for this macro. It may be due to Application Link configuration. ) had been delayed, and Lawrence Miller (Deactivated) had some ideas on possible ways to help expedite them. However just before new year they were contributed (see ), so the discussion may take a different tack.
5 min	AOB

Meeting notes

• Quorum is reached
• Action items:
  • Peter's tasks - no progress since last meeting
  • Frank: CI/CD of symphony-java-client: mostly done, just need to integrate Mau's work
    • Peter: CI & CD of clj-symphony has been configured and it was smooth sailing - should make symphony-java-client straight forward
• WG scope one-liner:
  • James: came out of API WG work.  Interestingly, this potentially conflicts with what we're talking about for DW WG.
  • Lawrence: directionally aligned with the statement, but I didn't see technical coordination and code contribution.  One of the objectives of WGs is that once code is in the Foundation there's participation in building technical artifacts.  These are primary things we expect WGs to focus on i.e coordinating code contributions and developing technical standards.
  • James: it might potentially be aligned with the difference between projects and WGs.
  • Lawrence: philosophical question - there is a difference between project and WGs, but is a WG just a more formalised structure when there's a more complex problem than just project governance?  Or is it that code contribution is the responsibility of the project teams, and WGs are different - technical standards etc.?
  • James: I thought it was the latter.  Code would be owned by the project.  It's an interesting question, given the level of maturity we're at.  I thought that what had been said before is that projects look after code, and WGs look after standards stuff.
  • Peter: yep that's spot on.
  • Lawrence: then directionally we should make that more explicit in the statement.  It seems focused on influencing topic vs focusing on developing technical standards.
  • James: my thinking is that this statement would be folded into the wiki where we describe what Working Groups do.
  • Lawrence: that helps crystalise the distinction we're making.  I appreciate that.
  • James: I'm purely thinking about it this in terms of what the DW WG is going to do.  In the DW WG we're talking about redoing our charter, and interestingly it may mean we have a WG and a project - in fact there's already a project.
  • Lawrence: it's a good example.  Brings to the forefront the question of there being a project building something, and the WG being responsible for standards, but how does it tie in or fit in with the project.
  • James: and no one on the WG was interested in having a separate meeting to work with the project.  They're likely to be the same meeting with the same people in them.
  • Lawrence: the project doesn't have to have a meeting - it could be a mailing list that coordinates pull requests.
  • James: Peter, specifically on this - do you know where this statement (or a version of it), could be easily merged in?
  • Peter: yep - Working Groups page on SSF space.  Happy to merge it in there then distribute for review.
  • James: can you merge it in, and clarify what WG deliverable are?
  • Peter: sure. I'll take the action.
  • Lawrence: how does this tie in with discussions about DW WG, and specifically would the technical work the project team be doing be segregated away from the standards group?  How do we see it operating?
  • Peter: seems to me that there's an opportunity to discuss JC's 3 use cases in the WG (and in fact I think a 4th one came up too, around Symphony running in other containers), while the project team cranks out code on the Symphony container.
  • Lawrence: so higher level use case discussions.
  • James: yes, though I'm cynical in practice that we can make that work.  Some people on the group are keen to cut code, and JC is keen to have us contribute to the code.  It's hard to see how the WG would ever generate requirements that the project would use.
  • Lawrence: if the WG is focusing on a standard, then they'd focus on what is that standard and how is it used.
  • James: the DW WG has been discussing a standard for the Symphony app, so that it can work on multiple containers.  Theoretically there's a natural break between the WG produced standards vs the project team producing an implementation, but I'm a little cynical of that happening.
  • Lawrence: I think you'd need more than just Symphony implementing the standard for this to work.
  • James: yep.
  • Peter: we have OpenFin engaged in this work, and IIRC Deutsche Bank have their own container too.
  • James: also Morgan Stanley.  Having spent a year chairing this group, having a break between the project team and the WG makes things better.  Having said that, it may not really be a meaningful break - a break in name more than anything else.
  • Peter: I see a fairly natural split between the WG focusing on higher level topics that SymphonyElectron may never get to (e.g. support for non-Symphony apps by a container, interoperability on the desktop between different apps, etc.).  These are topics the project team is unlikely to ever get to, but the WG could investigate and feed into the project team's roadmap where appropriate.
  • James: just not optimistic that it'll work.
  • Lawrence: if we're concerned about the degree of engagement in the DW WG, then this provides a good segue to propose a mandate that can be launched into in the new year.  If there's no interest in contributing or using the standard in their own wrapper, then there's a question about the viability of the group.
  • James: it's a chicken & egg problem: say DW WG says "we want to define the standard that sits between the Symphony app and the wrapper", then everyone has to be really certain that Symphony will commit to that standard, and that it'll work in their container just as well as the new Electron wrapper.
  • Lawrence: no one can guarantee anything until someone puts something together.
  • James: that's part of the problem - the group has repeatedly said things like "if it's there, then I'll implement it", but historically nothing has been there.
  • Lawrence: JC is now in the group, so the group is eminently able to gauge the level of engagement from Symphony.  But without a standard in place, no one is going to follow it.
  • James: it's a chicken and egg.
  • Lawrence: interesting question - is anyone else interested in using the standard?
  • James: in general, sort of.
  • Lawrence: the selling point to Symphony to use a standard API is that other organisations that have their own containers deployed will be able to deploy Symphony more easily.
  • James: action on me to put together new charter, and as part of that to talk about the relationship between the WG and the projects that might arise from it.
• BoD status reporting:
  • Tactical question for January 18th BoD meeting status update - is the ESCo interested in presenting the status update?
    • Peter: we had planned on using the existing (legacy) status reporting metrics (here's an example), and I've updated those metrics as of January 1st to reflect the entirety of 2017.
    • Frank: I think we can do that.
    • Lawrence: question is - what's the qualitative narrative?
    • Frank: I see it as one slide that covers what we're seeing as the Foundation & Community evolves, and where we're asking for help.  Good / Bad / Ugly on one slide, coming from us (ESCo).
    • Peter: I'll share the metrics for 2016 to help build that narrative.
    • Frank: let's collaborate on a Confluence page.
  • Going forward, how would the ESCo like to handle BoD status reporting, taking into account the project and WG status reporting that will start flowing in?
    • Not urgent (a quarter until the next BoD meeting), so let's table this discussion so we can get to the last agenda item.
• Integrations discussion:
  • Lawrence: when we were going through the process of completing the contribution of the horizontal integration APIs, we ran into an interesting topic within the LLC regarding the contributions: when we looked at it we were uncomfortable making the repositories public from the very beginning, because it's code we have in production but haven't had a full opportunity to do the level of security vetting that we'd want to do with code that's publicised.  Are we, as an ESCo group, comfortable in having some form of "legging in" process for fresh code contributions, where contributions are brought in under Apache, but we start out by having more restricted access to the repository (not "world readable"), but providing access to literally anyone who asked for it, perhaps for a period of 6 weeks at the beginning, then we open them up?  This allows community input, but also allows the LLC to dot the I's and cross the T's.  It would be an advantage for Symphony in that it allows us to do a contribution and get it out there, but also do a bit more after-the-fact due diligence before we expose ourself.  We thought this might speed up the contribution process if this option were available - this is not about changing the license or keeping contributions in that state for long periods, but we're slowing the process of consumption for the purely anonymous consumer.
  • Mike: I'm thinking that it'll be easier to get these things open if we support this.  In this case we hadn't completed the security reviews before they were pushed it out.  That's fine, provided the code isn't in production, but in this case we had POCs in production and didn't want to push it out without completing our security due diligence.  We wanted to push it out in a controlled way without allowing the whole world to have access to the code.
  • Frank: so the intention is to expedite that contribution to the open, and allow external partners to vet the code and make it ready for true public consumption?
  • Lawrence: you inevitably end up in the final phase of the discussion, which is "maybe we should do one more review".
  • Mike: that's exactly what happened.
  • Frank: I like the idea, but I think there'll be a point in time where there's someone who's skeptical during the review cycle.  We need a way to say when something is "good enough".
  • Lawrence: we say "you have 6 weeks" to respond internally.
  • Mike: putting a timeframe around it forces us to get a certain amount of work done.
  • Lawrence: the code is fully contributed, so theoretically anyone who has access to the code could legally republish it to the public anyway.  The question is whether there's a security agency sifting through the code.
  • James: those folks are already in your network!  But perhaps there's a majority rule, or a fixed grace period, then it becomes open after that.
  • Lawrence: we want to propose a grace period to avoid hold ups.
  • James: yeah it starts a bomb ticking.
  • Peter: and it wouldn't be a mandated grace period for every project?  The contributor would choose whether they wanted this grace period or not?
  • Mike: agreed.  I also think we need a process to allow the contribution to be opened more quickly.
  • James: yeah and the contributor should be able to make that decision.
  • Mike: agreed.
  • James: and is there an emergency "oh shit" thing that can happen?  e.g. something disastrous is found?
  • Mike: yeah I think we'd have to rip it out of production.
  • Lawrence: we do this in a community-based decision making process, where the ESCo is driving the decisions.  If ESCo decided it needed to do something for the safety of the community, then we'd have to figure out what to do in that situation.  It's hard to pre-plan all the scenarios while this is still theoretical.
  • James: having ESCo being able to override the release in extreme circumstances seems like a reasonable thing.
  • Peter: Lawrence / Mike: perhaps one of you could write this up, and I'll schedule an email vote?
  • Mike: I'll take point on that.
  • Lawrence: and let's apply the new process to the integration projects.
  • Peter: just a note that we don't currently have the ability to provision private Github repositories (we're on the free tier of Github).  We plan to add this in 2017, but the 2017 budget hasn't been approved yet (one of the tropics for the Jan 18th BoD meeting).  Because of Github's pricing model, even creating a single, small private repository is expensive, so there might be a delay on that end if we were to agree to make the integrations private.  If this group agrees we need this in the immediate term for the integrations, I'll work with Gab to make it happen.
• AOB:
  • None

Action items

• All: review project reporting proposal
• Former user (Deleted): work with Maurizio Pillitu to finalise CI / CD of symphony-java-client against the ODP
• Peter Monks: merge in Former user (Deleted)'s clarification of WG scope, and notify ESCo via ML once complete so they can review & refine
• All: prepare status update for Jan 18th BoD meeting - DUE 2017-01-11
  • Peter Monks: create Confluence page for collaboration
  • Peter Monks: upload 2016 project metrics to that page
  • Important Note: Gabriele Columbro will require these slide(s) the previous week (Jan 11th), so that he can incorporate it into the master deck that gets distributed to the BoD, prior to the meeting
• Michael Harmon: draft the proposal for the new "grace period" lifecycle state
  
  • Peter Monks: schedule an email vote to approve the new state