Table of Contents

Date

15 Nov 2016

Attendees

Actions items from previous meeting

• 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)
• Lawrence Miller (Deactivated) nudge LLC platform team to completed setup and testing of symphony-java-client
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Former user (Deleted) ping Matthew Gardner re Blackrock contributions to symphony-java-client, including Aaron Williamson in the conversation
• 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 to schedule additional session to complete the governance overview

Agenda

Meeting notes

• Roll call:
  
  • Quorum is reached.
• Vote: Contribution Lifecycle:
  • Peter: email vote failed after 72 hours due to insufficient responses.  Frank has requested that it be conducted as an in-person vote today.  We have quorum, so the vote can take place.  Frank - can you give a quick recap of what it is, then state your motion as a yes or no question?  Secretary will then take the votes.
  • Frank: We've discussed this in ESCo before, but we're talking about v0.3 of the contribution lifecycle which contains criteria for moving projects from incubation to active to long term maintenance and/or archival.  The goal is to agree on the states and the process - specific dates and durations etc. can be determined later, as well as responses to Peter's comments.  We also want to add a new "long term maintenance" state.  Each project would be expected to clearly communicate its current state in its README file, via a "badge".
  • VOTE: to adopt the contribution lifecycle.
    • Michael Harmon: +1
    • john.stecher@barclays.com: +1
    • Lawrence Miller (Deactivated): +1
    • Former user (Deleted): +1
    • Former user (Deleted): +1
    • RESULT: Unanimous +1, the motion is passed.
• Action item review:
  • Peter: The communication actions are awaiting socialisation of the governance refinements, before communicating with project leads and WG chairs
  • Peter: Alternative voting mechanisms are still being investigated
  • Peter: Some thought has been put into reporting requirements since last week's request.  We've looked at comparables (ASF, standards bodies, etc.) and many of them seem to use off-the-shelf project-level metrics systems (e.g. Bitergia).  This may not work for us given that Working Groups don't have code or projects - these systems can generally only measure code projects.  A primary guiding principle we've chosen is to have consistent reporting across both projects and WGs, in terms of "health".  The current thinking, and this is open to feedback, is to define "health" in terms of 3 dimensions:
    1. Activity - how active the project or WG is e.g. measured by # of commits or releases (projects) and/or or topics discussed and/or work products produced (WGs), etc.
    2. Maturity - how mature the project or WG is e.g. measured by lifecycle state, etc.
    3. Viability - how viable the project is e.g. how many contributors / participants the project or WG has, how active they are, etc.
       • Peter: For example the "2 contributors per project" guideline that has been discussed may be better supported via a viability metric, rather than as a gating factor.  The Foundation has a concern that placing gating factors on new contributions substantially reduces the momentum around contributions (we've already seen this with CCLAs, for example - they stifle contribution).
       • Frank: we want 2 contributors per project even if it's a Foundation staff member, so that if one of them disappears, we still have someone in charge of the project.
       • Peter: understood, and perhaps that should be a gating criteria for activation.  But we would prefer to have as few gating factors on new incubating contributions as possible, to encourage contributions to incubate within the Foundation.  Once in, it will be easier for those developers to find and engage like-minded developers on their projects anyway - it's harder to do that from the outside.  Also, right now the majority of the Foundation's projects only have a single contributor anyway.
       • Frank: if the outcome is the same I'm fine with it.
  • Testing of symphony-java-client by Symphony:
    • Lawrence / Frank - meeting later today or tomorrow with Symphony platform team to discuss
    • Peter / Frank - Frank and Maurizio scheduling a meeting and will discuss CI/CD
    • Frank - initiated the conversation between Blackrock & Aaron - looking forward to having more contributors on the project!
• Governance refinements (continued):
  • Aaron: complete slides are in the agenda - would encourage those who weren't present last week to review those.
  • Aaron: quick recap of why this was prepared (request from Board, and then ESCo).  Goal is not to change the bodies in any way, but rather to provide more definition about how they operate.
  • Slide 15:
    • Projects are not defined in the by-laws, so they have no formal authority, responsibilities and policies (but some de-facto ones that we're all familiar with)
  • Slide 16:
    • Peter: to the last bullet point, we found an interesting article that discussed the typical lifecycle of open source projects, from benevolent dictatorship early on to more democratic models as a project matures and stabilises.  We've based the "benevolent dictator by default" recommendation on those findings, given that we expect most contributed projects to initially join the Foundation early in their lifecycle (i.e. incubating).
  • Slide 17:
  • Slide 18:
  • Slide 19:
  • Slide 20:
  • Slide 21:
  • Aaron: Questions & thoughts?
    • Lawrence: we've provided some feedback during the previous review.  Will that feedback be put into a revised draft of this?  It seems like most of this stuff has broad alignment, but there's been specific feedback on specific points.
    • Aaron: what form would you prefer this proposal to take?  Are these slides, incorporating the feedback, sufficient or would you prefer a different or more fleshed out form?  The primary issue that I have is to work through the notes from these meetings - I know the quorum change was one proposal the ESCo didn't wish to change.  I'm sure there's additional colour on other items, but I think they were mostly minor.  How would you like to see them incorporated?
    • Lawrence: make some revisions to the deck then recirculate to ESCo.  Not sure we need to have more discussion.
    • John: yes that's the best course of action.
    • Aaron: ok great we'll do that today or tomorrow.
• Discussion on  Unable to locate Jira server for this macro. It may be due to Application Link configuration.  vote:
  • Peter: we may want to reschedule this conversation, given that James dropped from the call.
  • 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.
• LiveCurrent / Paragon recommendation for the Board:
  • Peter: background is that the Foundation has received the original LiveCurrent and Paragon code, as required by the founding documents.  The board has asked for a recommendation from ESCo about what to do with them.
  • Lawrence: my recommendation with the original LiveCurrent code is that it's far removed from the Symphony code base, and we're already working through open sourcing that.  Right now I think we should continue to execute on the open sourcing plan.  Keep the LiveCurrent code but not publish it, as it's not valuable for anyone and it would be confusing if we were to publish it.  With respect to the Paragon source code, my recommendation is that the original source code is more usable, but there are subsequent contributions from LLC and GS and the LLC contributions have been approved but are commingled with the GS contributions which are not.  If we could get approval for the GS contributions then it would be better to release that.  While the API WG is beginning to take a different track, 
  • Peter: just to clarify, did you mean the Desktop Wrapper WG?
  • Lawrence: yes - the Desktop Wrapper API WG.
  • John: from the GS perspective, I support that.  The LiveCurrent code in particular would be confusing.  I'd also like to see the latest Paragon code contributed, with the GS and LLC additions.  The LiveCurrent code is so old that it's just not worth open sourcing.
  • Frank: I agree with all the statements made. LiveCurrent just doesn't make sense, and the Paragon code would have to have the updated code or else we're going to create a fork.
  • Mike: Lawrence is echoing the LLC's position on this.
  • Lawrence: I can take point on drafting something, circulating on the ESCo private mailing list, then coordinating with Gab to communicate it to the board.
• AOB:
  • Reminder that we will not be meeting next week (November 22nd) due to the week of Thanksgiving.  Next meeting will be Tuesday November 29th.

Action items

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