...

...

Meeting notes

• Roll call
• Not sure if we have quorum - 2/3 of 5 is 3.333 - does that mean we meet it with 3, or meet it with 4?
  
  • Doesn't matter for today, since there are no motions expected to be tabled
• Release approval:
  • Peter read out section 6.2(b) of the by-laws to the group, which is relevant here
  • 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 thaty's the way that I would read it as well.  There is a similar example at the board member, regarding new members.
  • Frank: 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, or
  • Peter: requires an amendment to the by-laws
  • Lawrence: is it part of the current round of amendments?
  • Peter: no
  • Lawrence: that's unfortunate
  • Peter: yep - the current round of amendments first started months ago, whereas these issues have only just surfaced
  • 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.
  • 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 it mostly ambiguity?
  • Peter: mostly yes, but there are also gaps (such as 
  • 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: there's been at least one release per language - 1 or 2 of Java client, for example, 1 C# REST client, some for Hubot
  • Lawrence: those are contributions
  • Gab: no - they're released - we've deployed binaries to Maven Central for public availability, or Nuget for the C# client, and Hubot releases to npm.js
  • Lawrence: is that a release?
  • Frank: I hear what you're saying, I just don't know what we'd call those things
  • Lawrence: well we didn't approve it, so it can't be a release
  • Gab: perhaps we call them an "incubation release", rather than an "active release"?
  • LawrenceP it seems like there a re 2 things we can 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 
  • Lawrence: didn't we do that when we accepted the projects, or wasn't there enough information to approve it?
  • Frank: when we take in code, it's incubating - once there's use there should be a formal release process (which Mau is working on)
  • 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 
  • Gab: it sounds 

Action items

•  Former user (Deleted) - prepare criteria for ESCo release approval
  
  • Proposal is that ESCo will approve the first release of each project, then delegate approval of subsequent releases to the project lead of that project
•