Table of Contents

Date

29 Nov 2016

Attendees

Actions items from previous meetings

• Peter Monks to communicate WG eligibility rules to WG chairs (as part of governance refinements comms)
• Peter Monks add "Long Term Maintenance" as a new project state in the project lifecycle, and update all relevant documentation (as part of governance refinements docs updates)
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Peter Monks investigate alternative voting mechanisms and report back to the ESCo
• Peter Monks to coordinate development of a proposal around reporting requirements
• Peter Monks reschedule CONTRIB-17 discussion for next ESCo meeting
• Lawrence Miller (Deactivated) draft a recommendation re LiveCurrent & Paragon, review with ESCo, then coordinate with Gabriele Columbro regarding communication to the board - ideally before 2016-11-17 (board call)

Agenda

Meeting notes

• Quorum is achieved (4 of 5 ESCo Project Leads in attendance), so the votes can take place.
• Mike has a hard stop, so votes moved forward.
• Peter: as background, I've been scheduled in-person votes for things that are new or unique, and punting everything else to email votes.  Keen to hear if this is ok with the ESCo project leads.
• Vote: to approve the governance refinements:
  • Peter: background is that Aaron Williamson has incorporated the ESCo's feedback on the governance refinements into the slides, and we'd like to formally vote to approve these refinements.  Any objections to conducting this vote?
  • Mike: I would prefer to wait until Lawrence is present.
  • Aaron: Lawrence did reply to my email, and was supportive.
  • Mike: even then, I'd prefer to wait.  I'd also like more time to review the material.  I'd suggest we move this vote to email.
  • Peter: makes sense.  Any objections to moving this vote to email?
  • <no reply>
  • Peter: ok I'll send out an email vote after this meeting.
• Vote: to activate the hubot-symphony project:
  • Peter: background is that the hubot-symphony project is essentially already active, but hasn't been formally activated.  This vote is to retrospectively activate it.  Any objections to conducting this vote?
  • <no objections>
  • VOTE: to activate hubot-symphony:
    • Michael Harmon: +1
    • john.stecher@barclays.com: +1
    • Former user (Deleted): +1
    • Former user (Deleted): +1
    • Lawrence Miller (Deactivated): 0 (not present)
    • RESULT:
      • +1:    4
      • 0:      1
      • -1:     0
      • The motion is passed.
  • Former user (Deleted) to follow up with Peter Monks & Maurizio Pillitu as needed on what this means tactically.
• WG ontologies:
  • James: it's been a while, but I seem to recall a discussion about giving guidance as to how we would see WGs being set up in terms of different areas to be discussed in a particular WG.  This potentially bleeds over into the discussions about API WG, but intended to give general guidance on what we want WGs around and how we might communicate those.  There's been some tension between what is it that a WG can do and what it can't, with reference to influencing the LLC.
  • Peter: question is - should the ESCo work on this, and if so when and how?
  • James: best thing would be to when we're talking about WG setups we have to be quite clear about definitions.  Not necessarily a lot of work up front.  But given recent discussions in the Desktop Wrapper WG when new people join, and regarding the charter for the API WG, we need to be very careful about being good & tight about the intention of the WG and the charter as its developed.  Perhaps creating an ontology would be more work than we need.
  • John: my concern is we don't have enough data to make an ontology valuable.  Let's wait and see what comes in and refine our approach.
  • James: agreed.  We don't have a million people clamouring to create WGs.
  • John: no, and that would be a great time to discuss ontologies.
  • Peter: perhaps we can iterate on a wiki page to capture some of the finer points etc.?
  • Frank: that sounds good to me.
  • James: recent sticking point has been ability to influence LLC, and trying to stick WGs to being. The new difference between a WG and a project team has come out, so that's now clearer, and I think what we're saying de-facto is that WGs can only influence what's happening in the Foundation and so they shouldn't have charters that seek to rely on influencing LLC.
  • Frank: the last point about rely on is an important one.  Influencing the LLC is always going to be there, but relying on it is a problem.
  • Peter: any volunteers to write something up, and send around for iteration by the group?
  • James: I'll do something.
• Unable to locate Jira server for this macro. It may be due to Application Link configuration.  (CSFetchBot) - any concerns around -1 vote?
  
  • James: the background is that I had a conversation internally with people and there was a difference of opinion of the people who had been at the hackathon and originally put together the contrib and management regarding whether to contribute it or not.  This wasn't a CS policy problem - we'd have been happy to contribute it - it was more about whether the team was still happy to contribute it.  I voted against it to give CS people time to get aligned - there was no point in having a contribution that was dead in the water from the get go.  An interesting question is whether that was an appropriate thing to have done as an ESCo member, or whether we should have rescinded the contribution.
  • Peter: it is an interesting question, and what the Foundation's understands is that ESCo members are expected to represent the broader Foundation membership rather than their own organisations.  In this case that would mean voting on whether the contribution was suitable for Foundation hosting, regardless of whether it was going to be rescinded.  Abstention may also have been appropriate, if you felt there was a conflict of interest or whatever.
  • James: I should have internally asked the contributors to rescind the contribution.  I tend to agree with you on reflection.  Voting against it with my ESCo hat on was probably the wrong thing.
  • Peter: no big deal.  This stuff is poorly documented right now anyway, though we're in the process of updating the wiki to try to make this clear (both for ESCo and for contributors).  It's also one of the benefits of the Foundation's contribution model that any contributor can always rescind their contribution at any time, after the ESCo approval vote, or even after they've contributed the code.  Around half of the NWS hackathon contributions have ended up going this way, and we expect this to be "business as usual" and nothing to be especially concerned about.  If CS do intend to rescind it, let us know, otherwise we'll continue to pester the team for the code.
• Action item review - Peter:
  • First action is awaiting governance refinement vote.
  • Alternative voting mechanisms started, but has since stopped.  Hopefully lower volume of voting has taken the pressure off this one a bit, though it's still on my list.
  • Reporting requirements are being investigated.  We're looking at a vendor called Bitergia right now - they have done work with the Linux Foundation and Eclipse Foundation, amongst others.  Right now this looks promising for project team → ESCo reporting, but less so for working group → ESCo and ESCo → board reporting.  Early days in our investigation, but if you're interested definitely worth a look.
  • CI/CD is under heavy development by Maurizio Pillitu - security is proving to be quite involved.  He's been working with Frank on getting CI/CD setup for the symphony-java-client.
• AOB:
  • Peter: will send out an email asking for upcoming holiday availability
  • James: I'll be out next week due to a conflict

Action items

• Peter Monks: schedule email vote to approve governance refinements.
• Former user (Deleted): draft a quick page on WG "scope" and distribute to mailing list for group iteration
  
  • All: review the page and update as appropriate
• Peter Monks: send out email asking about upcoming holiday availability, and cancel meetings as appropriate