Page tree
Skip to end of metadata
Go to start of metadata

Table of Contents

Date

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 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

TimeItemWhoNotes
5 minRoll call
5 minReview action items from last meeting
  • See above
10 minVOTE: approve the governance refinements

Peter Monks (coordinating the vote on behalf of Aaron Williamson)

ESCo's feedback on the governance refinements has been incorporated into the slides. The Foundation is requesting a vote to approve these refinements.

Aaron Williamson will be present in case there are any last minute questions or clarifications.

10 minVOTE: activate hubot-symphony project

Peter Monks (coordinating the vote on behalf of Jon Freedman)

The hubot-symphony project has released several v1.0+ versions (active state releases), but is not yet officially an "active" Foundation project. This vote is to retrospectively activate it.

Note that some of the infrastructure implied by the new activation criteria (e.g. JIRAs for activation votes) is not yet in place, so the project leader (Jon Freedman) has provided the requested information via email as a temporary workaround. He has also been invited to attend the meeting, to answer any last minute questions.

Please review the activation ("Gate B") criteria ahead of the vote.

15 minKickoff WG ontology discussion

James Turck to introduce the topic, then all

Action item from the 2016-09-20 meeting. From that conversation (summarised, and with emphasis added):

  • Frank: Perhaps the focus on the container is too narrow?
    - - - - - - - - 8< - - - - - - - -
    Have you considered the implementation of a UI component?  Or is it focused on API interactions with the Symphony back end?  I see this WG as being about more than just the container
  • James: in fact one of the problems was calling it the "Desktop Wrapper WG" from the get go, while not defining either term.  When I first started I couldn't tell if it was about the container or the APIs.
  • Frank: my recommendation would be to revisit the charter of this group.  And change the "desktop" and "APIs" - I'm not saying we merge it with the API WG that Anthony is working on, but more the "extensions API".
  • Lawrence: it's an interesting question around how you decompose this.  How do you integrate the UI elements and speak to the UI elements.  They're all rendered in HTML, so when you talk about the user visible constructs, are they components of the API or are they aspects of which HTML widget libraries do you use in the HTML front end code, whether it's API related or not?  Are you talking about an API or an HTML coding standard?  I don't mean to complicate it, but I think it's a really good idea to try to figure out where these things should live.
  • James: it's an ontology question, and would also help with Anthony's WG.  If we're going to have WGs around Symphony, perhaps ESCo needs to define an ontology of WGs, both of the current ones and future ones.

Proposed objective for this agenda it (comments welcome!): decide whether the ESCo should define a WG ontology, and if so, when and how.

10 min

CONTRIB-17 - Getting issue details... STATUS vote discussion

Lawrence Miller

From ESCo mailing list:

"Is there any follow-up discussion we should have to address the -1 concerns?"

From the previous ESCo meeting:

"Lawrence: I think we should have James participate, but the comment I have is that we've approved a contribution where the contributing party voted against it. That's odd. And we should move it to the next agenda so we can discuss with James. I think the other ESCo members agree that it's odd.
Frank: Agreed. And I had a question about how far the CONTRIB was going to go - API access etc. - that we need James for. It was odd that James voted down his own contribution."


5 minAOB

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:
  • 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.
  • CONTRIB-17 - Getting issue details... STATUS  (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.
  • James Turck: 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