2016-09-13 - ESCo - Meeting agenda / minutes
Table of Contents
Date
Attendees
Name | Organisation | Present / Absent |
---|---|---|
Symphony LLC | Present (10 mins or so late) | |
Goldman Sachs | Absent | |
Symphony LLC | Present | |
Markit | Present | |
Credit Suisse | Present | |
Gabriele Columbro (observer) | Symphony Software Foundation | Present |
Peter Monks (observer) | Symphony Software Foundation | Present |
Maurizio Pillitu (observer) | Symphony Software Foundation | Absent |
Actions items from previous meeting
<none>
Agenda
Time | Item | Who | Notes |
---|---|---|---|
5 min | Roll call | ||
| |||
15 mins | ESCo approval of releases | This seems odd - let's review! | |
5 min | AOB |
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:
- ESCo can approve the releases retroactively
- 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.
- Based on Apache and OASIS, we're also proposing the presentation of detailed metrics such as:
- 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
- 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
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
Need help? Email help@finos.org
we'll get back to you.
Content on this page is licensed under the CC BY 4.0 license.
Code on this page is licensed under the Apache 2.0 license.