Table of Contents

Date

Nov 8, 2016

Attendees

Actions items from previous meeting

Agenda

Meeting notes

• Roll call: quorum not reached - no decisions will be made today

  • Note: the meeting dropped from some ESCo members' calendars.  At this time, the only day the ESCo meeting has been cancelled is Tuesday November 22nd.

• Action items:

  • WG eligibility rules and new project status:

    • Peter: Awaiting governance refinements (a topic for today's meeting) before communicating / updating wiki

  • LLC testing of symphony-java-client:

    • Lawrence: conversations were held last week.  The ball is in Frank's court.

    • Frank: I've seen those chats too, but not sure what's happening internally re testing - would appreciate Lawrence giving the platform team a nudge

  • CI/CD for symphony-java-client:

    • Peter: this work is underway

  • Blackrock contribution to symphony-java-client:

    • Frank: didn't get to it - will get to it this week

  • Alternative voting mechanism:

    • Peter: been investigating with James' help.  Nothing to report yet, but will schedule a session once I do.

• Governance refinements (slides here):

  • Gab: we've discussed over the year project team and working group governance.  We've looked at the bylaws, and what's been de facto operating procedure and want to present what we've come up with

  • Aaron: talked through slide 2 - work to date

  • Aaron: talked through slide 3 - in-scope vs out-of-scope for this exercise

    • Gab: approach was to focus first on responsibilities of the governing bodies.  Once we have general agreement from ESCo and/or board, we have a whole set of processes that need to be defined in detail.  Some of them being higher priority (e.g. reporting).  We intend to define those processes next, but we want general agreement and consensus first.

  • Aaron: talked through slide 4 - governance summary

  • Aaron: talked through slide 5 - governance status - Oct 2016

  • Aaron: talked through slide 6 - Board of Directors formal authority

    • This slide just shows the roles the BoD has in terms of governance.

    • This should not be contentious, given it's defined in the bylaws.

    • We're not recommending any clarifications to how the BoD participates in governance, because it's very well defined already.

  • Aaron: talked through slide 7 - ESCo formal authority

  • Aaron :talked through slide 8 - ESCo de facto authority

    • Gab: to clarify here, by "de facto" we mean something that is not defined in the bylaws, but which has been approved over time by the appropriate governing bodies e.g. code quality, voting rules, etc.

  • Aaron: talked through slide 9 - ESCo gaps / uncertainties

  • Aaron: talked through slide 10 - ESCo proposals

    • Gab: preliminary feedback or questions, before we move onto the other bodies?

    • Lawrence: with this particular slide a question I'd have generally - are these things that we feel that ESCo can't currently do?

    • Aaron: no it's not that ESCo can't currently do it, it's more that what ESCo should be doing with these things is not defined anywhere.  There's not definition on how this happens, and we'd like to put this on the wiki etc.

    • Gab: we'd like to formalise things that might be happening ad-hoc today.  Existing and prospective members are asking for details on governance, and while we wasn't to leave freedom of action ,we want to define some key things,.

    • Lawrence: so these are things we have power to do, but this is socialising / publicising / it

    • Frank: sounds like it's more structured.

    • Aaron: right - ESCo has power to do them, but we want to clarify that these are things that not only can happen, but will happen, and how, and how often.

    • Frank: IO don't want to make it too aggressive though.  We need a lightweight way to provide feedback to project teams, and funnel up associated status to the board.  Each WG can easily provide status statements that the board can have visibility into./  This is about mechanical elements rather than process

    • Gab: good observation and certainly our target is to have as much automated reporting as possible.  Requiring manual interaction only to steer and comment.  We look at it as a graph with the bodies the nodes and the interactions the edges.  We're just defining the flows, not the detailed reporting.  This should be as simple and frictionless to each of the bodies as possible, and that's where the Foundation can help.

    • Lawrence: I don't think we need to change the ESCo voting quorum.  If you look at the voting that we do, it's lots of email votes.  We're not having issues getting quorum when using that mechanism.  We often don't have quorum when we meet, and maybe we should clarify that we can still meet without quorum.  Quorum issues have tended to be at the board level.

    • Gab: fair point.

    • Lawrence: if it ain't broke, don't fix it.

    • Gab: the issue is the high percentage of absentees.

    • Lawrence: we don't have quorum on this call, but if we needed to vote we'd move to email and get it.

    • Gab: how does the ESCo feel about having incentivisation to be present in the meetings.  While it might not stop votes, throughout the year there's been a relatively high percentage of people not attending the meetings.  How does the ESCo feel in general about incentivisation mechanisms for ESCo.  e.g. in OASIS you only get voting rights if you attend 3 meetings in a row.  What's the feeling about having some mechanism like that?

    • Lawrence: I'm drawn to US Congress where members who don't show up for votes face issues when they're up for re-election.  We have attendance information then if the board wanted to track active participation they could.

    • Gab: so an after-the-fact reporting, rather than pre-emptive methods.

    • Lawrence: I don't think 100% participation should be required.

    • Aaron: if ESCo isn't in favour we're not going to push for it.

  • Aaron: talked through slide 11 - Working Groups' formal authority

  • Aaron: talked through slide 12 - Working Groups' de-facto authority

    • Lawrence: do the charters have to be approved by the board and ESCo?  Or is it ESCo only?

    • Aaron: bylaws say nothing about it, but de facto process is that ESCo alone approves

    • Lawrence: so slide 11 "by Board" is incorrect.

    • Aaron: yes - not sure how that slipped in there.

    • Gab: how does ESCo feel about this approval process?  First two WGs were approved before my appointment.

    • Lawrence: having ESCo do approvals allows more interaction with the WG and so is faster / more expedient than going to a board discussion.  Going to board would slow down these processes.

    • Frank: I concur.  It's obvious we're not going to send everything to the board for granular discussion.  I'd see the board having visibility into the charters, but the day-to-day work should be between the ESCo and the WGs.

    • Mike: I agree.  The Board is too far removed day-to-day to make those kinds of decisions.

  • Aaron: talked through slide 13 - Working Group gaps / uncertainties

    • Lawrence: regarding reporting I'm fine if you guys come up with a proposal.  But in terms of frequency I'm think every 2 months or quarterly at most.  It should align with ESCo → board reporting.

    • Gab: quarterly is pretty typical for other open source foundations (e.g. ASF).

    • Frank: I think that's fine.  We do want the WG's to involve ESCo when necessary, I don't know if that's happening today.  Looking at the API WG as an example - we had some involvement but they weren't listening.  I'd expect WGs to reach out when necessary.  I'd like the door to be open.

    • Gab: so you're saying that's an additional thing?

    • Frank: yes.  I'm not a fan of process per se.  I want it to be very fluid so people can communicate clearly, and creating structure obscures that.

    • Aaron: which is exactly why we're not recommending specific structures for things like this.  For WG reporting to ESCo, the period and general parameters of what gets reported might be defined, but it's going to vary between working groups based on their area of focus, and how much progress they've made each reporting period.

    • Frank: I'm fine with that.

    • Gab: and we're aligned with what Frank is saying too - we see a recurrent model where projects and WGs take a federalist model - they're highly independent, but define, to a workable extent, the interfaces & communication points with the other bodies.  Internal process we want to leave flexibility about how they operate independently, but the interface with other bodies is where we draw the line.

    • Aaron: to the third bullet point, to the extent that WG recommendations need to be ratified or adopted across the Foundation, there's some ambiguity.

  • Aaron: talked through slide 14 - Working Group proposals

    • Lawrence: I get that we need a voting mechanism underpinning things.  But some of the dynamics we've seen have voting mechanisms being used in lieu of consensus building.  Votes don't resolve conflict and I would caution against a focus on voting for decision making.  The primary model should be consensus building.

    • Aaron: we see a voting procedure as a necessary fallback if consensus can't be reached.  Votes on a contentious issue are better than a stalling out on something.  But I agree that the mandate of a working group should emphasise consensus as the goal.

    • Gab: I agree generally on this point, and think consensus / unanimity is important at the board level.  I don't see contention in other bodies as an issue however.  Votes force real feedback rather than stalling progress.  In certain cases having a vote helps to form that consensus.  While consensus is a good choice I don't see a huge problem with holding more votes.  In other Foundations, voting is a transparent and fundamental way of expressing opinions.  Let's separate the board and the other bodies.

    • Aaron: as we work to putting these things down, we'll take that feedback into account.

• Out of time - meeting adjourned

Action items