Table of Contents

Date

13 Sep 2016

Attendees

Actions items from previous meeting

<none>

Agenda

Meeting notes

• Roll call
• Peter: Not sure if we have quorum - 2/3 of 5 is 3.333 - does that mean we meet quorum with 3 or with 4?
  
  • Not that it matters for today, since there are no motions expected to be tabled - it's just discussion items
  • <Mike hadn't joined at this point, but joined later, achieving quorum>
• Frank: release approval:
  • <Peter read out section 6.2(b) of the by-laws to the group>
  • Lawrence: I would think that the ESCo should take the same role in all Foundation-hosted projects.  It seems like this is a legitimate issue and we should probably not be directly approving all project releases (though we should be approving new projects and working groups)
  • Gab: my $0.02 is that that's the way that I would read it as well.  There is a similar example at the board member, regarding new members.
  • Frank: I agree with Lawrence - I don't think there's a separation between Symphony-provided open source, and any other project in the Foundation.  I think they should be treated the same.
  • James: can we delegate that responsibility?
  • Peter: we've had guidance that this requires an amendment to the by-laws
  • Lawrence: is that part of the current round of amendments?
  • Peter: no
  • Lawrence: that's unfortunate
  • Peter: yep - the current round of amendments started some months ago (before I started), whereas these issues have only just surfaced in the last month or so
  • Gab: if we formulate a proposal (and Peter is working on that), then that's something we can bring to the board for approval & ratification at the next board meeting.  We can amend the by-laws by resolution.
  • Lawrence: the thing that you want as a resolution would simply be that the ESCo is authorised to delegate powers granted to it under the by-laws at its discretion
  • Gab: we don't have the concept of projects in the by-laws.  We might need something more than just "ESCo can delegate powers" i.e. add the concept of projects to the by-laws.
  • Lawrence: my $0.02 is that the deeper the changes, the longer and more complicated the discussions will be.  From my perspective it would be nice to get a specific amendment in front of the board.  Is the issue mostly ambiguity in the by-laws?
  • Peter: mostly yes, but there are also gaps (such as the missing concept of projects)
  • Lawrence: would recommend that we don't let perfect be the enemy of good
  • Peter: agreed, and the current proposal minimises changes to the by-laws as much as possible, but there is a minimum set of changes required for this to be viable
  • Gab: we've already approved releases, based on guidelines that the ESCo has identified.  I'm ok to continue operating in this mode until these ambiguities are resolved - what do you guys think?
  • Lawrence: have any projects produced a release?
  • Gab: yes there's been at least one release per language - 1 or 2 of Java client, for example, 1 C# REST client, some for Hubot integration
  • Lawrence: those are contributions, and they were approved
  • Gab: no - they've also had releases - we've deployed symphony-java-client binaries to Maven Central, C# client to Nuget, and Hubot integration to npm.js
  • Lawrence: is that a release though?  Couldn't we call that something else?
  • Frank: I hear what you're saying, I just don't know what else we'd call those things.
  • Lawrence: well we didn't approve them, so they can't be a release
  • Gab: perhaps we call them an "incubation release", rather than an "active release"?  Symphony Java Client is at v0.9.0, for example.
  • Lawrence: it seems like there are 2 things we could do:
    1. ESCo can approve the releases retroactively
    2. Delegate the power to approve release to the project leads of those projects, but right now we don't know if we have the power to delegate that approval
  • Frank: I think ESCo should approve the first release of a project, to help ensure quality, then after that we'd delegate release approval to the project team
  • Lawrence: didn't we do that when we accepted the projects?  Or wasn't there enough information at that time?
  • Frank: when we take in code, it's in incubating and quality metrics aren't looked at - once there's use of the project there should be a formal release process (which Mau is working on) that would check those quality metrics
  • Lawrence: can we get something in front of ESCo to review at the next meeting or so?  It doesn't have to be much.
  • Frank: I'm happy to do that
  • Peter: this is some of the process work I've been doing - would love the opportunity to test it rather than rush this through in an ad-hoc manner
  • Lawrence: but we're arguably not discharging our obligations properly, and need to address that
  • Frank: as far as the internal ESCo vote goes, it would be good to have the gates defined - I can work on that
  • Gab: other Foundations (such as Apache) have formal transitions between phases - incubating → active, for example - that typically require substantial involvement (i.e. board / PMC).  But releases themselves are at the project level.
• AOB:
  • Lawrence: I'm wondering if it might be helpful if we start a regular process of reviewing progress of WGs, WGs in the pipeline and projects, just so we have a regular cadence of supervisory oversight
    • Peter: glad you brought this up - this is part of the process work I've been doing, which is due for Foundation-internal approval this Friday (Sept 16th).  From there it will be socialised with the ESCo and the Board
    • Lawrence: I don't want to wait
    • Peter: with 27 projects I'm relucant to rush into ad-hoc, organic status reporting - it is likely to create avoidable headaches for the ESCo
    • Lawrence: it sounds like those reviews will take time
    • Peter: perhaps, I'm reluctant to rush into this in an organic fashion
    • Lawrence: I'm concerned about the time this will take
    • James: what are your specific concerns?
    • Lawrence I'm concerned about things like the working groups - e.g, are they running effectively?  I'm less worried about projects.  Perhaps my main concern is a lack of knowledge about how the WGs are operating.
    • James: we don't have many WGs (2 + 1 forming), so it may make sense to do that ad-hoc
    • Peter: I'm more comfortable about being ad-hoc with WGs - in fact Former user (Deleted) is already on the agenda for next week's ESCo to give an update on the API WG formation
    • Lawrence: I want to know if things are not on track 
    • James: we have one WG update on the list next week, why don't we add another in next week's ESCo, and the third the following week?
    • Lawrence: I'm happy with that.  It makes sure we're moving the ball in the interim.
    • Gab: can ESCo provide some bullet points on specific aspects on what these updates should include?  It would be useful for Peter's work on processes.
    • Lawrence: a couple of things I think are important:
      • What is the progress that they've made since the WG initiated?
      • What are the things they've accomplished since the last update?
      • What are the blockers, if any
      • What is holding them back, that can be addressed by ESCo or others?
      • What are their objectives & goals over the next couple of months?
    • Peter:
      • Based on Apache and OASIS, we're also proposing the presentation of detailed metrics such as:
        • new members / committers / contributors
        • members / committers / contributors who've left
        • code commits
        • code size
        • etc.
    • James:
      • Joiners are easy to track
      • Leavers are hard to track - how is this even counted?
    • Lawrence: but participation is an interesting metric.  Let's be selective about the metrics - let's pick ones that are particularly valuable.  The time spent talking to the project leads needs to be substantive.
    • Peter: the intent is that reports are sent in writing prior to the meeting, then the ESCo can drill into anything of interest / concern during the in-person session.  The intent is not to have WG chairs and project leads read out a laundry list of minutiae.  In fact the Foundation is looking to provide value here by automating much of the content of these reports.  The last thing we want is for WG chairs and project leads to spend a lot of time on home work.
  • Gab: update from last week's board meeting
    • General update
    • Marketing metrics trending positively
    • OpenFin membership
    • Upcoming month - developer pod, 
    • Amendment of by-laws in support of membership tiering and renaming (Founding → platinum, Community → gold, introduce silver and individual membership classes)
    • General consensus in the room, but formal vote did not happen due to a technicality (75% super majority was not present in the meeting).  Vote is rescheduled for next Tuesday.
    • Lawrence gave an update on the OSS plan which fostered a productive discussion.
    • Various technicalities: Foundation CFO, board chairman, substitution of Lawrence Miller for David Gurle on the Foundation board
    • Lawrence: waiting for the LLC board to review and approve the OSS plan (in this week's board meeting).  Some of the details on the modules and timing is relevant to the ESCo - we need to ensure the governance structures can accommodate the increasing amounts of code that's going to come into the Foundation.
    • Gab: can we get an update from you on the (hopefully!) approved plan?  Perhaps the week after?
    • Lawrence: if we time box things, it should all fit into next week's meeting

Action items

•  Former user (Deleted) - draft project release approval criteria
  
  • Proposal is that ESCo will approve the first release of each project, then delegate approval of subsequent releases to the project team
•  Peter Monks - schedule Former user (Deleted) and Former user (Deleted) to give WG updates next meeting and the following meeting
  
•  Peter Monks - schedule Lawrence Miller (Deactivated) to present on OSS plan in next week's ESCo meeting