Table of Contents

Date

06 Dec 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 investigate alternative voting mechanisms and report back to the ESCo
• Peter Monks to coordinate development of a proposal around reporting requirements
  • Project reporting proposal is available here
  • Working Group reporting proposal in progress
• Peter Monks: schedule email vote to approve governance refinements.
• Maurizio Pillitu configure CI / CD of symphony-java-client against the ODP (highest priority target for his existing CI / CD work)
• Former user (Deleted): draft a quick page on WG "scope" and distribute to mailing list for group iteration
  
  • All: review the page and update as appropriate
• Peter Monks: send out email asking about upcoming holiday availability, and cancel meetings as appropriate

Agenda

Meeting notes

• Quorum not met - API WG ratification vote cannot be conducted today
• Action item review:
  
  • WG reporting is now 
• API WG ratification vote:
  • Cannot vote, as we do not have quorum.
  • Any questions for Anthony while we have him?
  • Lawrence: would love a 30 second summary from Anthony.
  • Anthony: the charter explicitly follows the feedback & proposals from ESCo.  It came to the last WG meeting and we asked how the group felt about resubmitting.  There were no objections, and 5 of the 8 companies in the WG were represented there, so I'm comfortable that we have broad agreement, and that there are no surprises in the charter.
  • Lawrence: ok.  I've read through it and I'm comfortable with it.  Frank, Mike - any comments?
  • Frank: perfectly fine with it.  Thank you for following through on that Anthony.
  • Lawrence: thanks - I know it was complicated.
  • Mike: I'm good with it too.
  • Peter: any objections to conducting an email vote, given we don't have quorum today?
  • Lawrence: I think that's appropriate, and given the previous dialog and the fact that we have 3 members present who will vote for it, I expect the vote to go smoothly.
  • Frank: agree.
  • Peter: 3 days ok?  Yes - I will schedule a 3 day vote-by-email.
• Guidance on voting mechanism
  • Peter: to date I've been scheduling "new" types of vote for in-person, and everything else via email.  I realised I was doing that de-facto and wanted to check in with you to make sure you felt that was appropriate?
  • Lawrence: Seems to be working for me.
  • Frank: me too
  • Peter: ok great - I'll continue doing that, but don't be shy about providing any feedback, at any time.
  • Lawrence: it would be great if we had a Symphony based tool for this
  • Peter: I think multi-party cross-pod would be a requirement for that?
  • Frank: it could be done by a bot, like how the helpdesk-bot does it.
  • Mike: I could lift multi-party cross-pod restrictions on the corporate pod. Though big banks didn't want to deal with multi-party cross-pod.
  • Peter: maybe the Foundation pod would be a good guinea pig?
  • Mike: yes it would.  You'd need to live on the preview network, which contains some bugs at times.
  • Peter: I'll check with Mau and Gab and see if we're willing to do that.  I can't see why not - we have regular needs for multi-party cross-pod.
  • Mike: be aware that the other party also has to have multi-party cross-pod enabled for it to work, and most of the big firms are adamant about not having it enabled, due to previous scandals.
  • <discussion about what / when / how multi-party cross-pod entitlements might be designed in a way that supports compliance needs in the big firms>
• Finalise holiday meeting schedule:
  • Peter: we will not have quorum on the 20th & 27th, so propose canceling those two meetings but leaving the others in place.  Sound reasonable?
  • <no objections>
  • Peter: we've had some Google Calendar issues recently with deleted meetings not being deleted from invitees calendars.  So if, after I delete these meetings, they're still in your calendars, please feel free to delete them manually.  We will definitely not be meeting those days!
• Wiki updates:
  • Peter: I realise we only shared the new content last night, but any questions at this point?  Feel free to ping me if you do have any.
  • <no questions yet>
  • Peter: one comment is that the 2 week warning / 1 month trigger for inactivity seems too short.
  • Frank agreed - it should be one month.  These numbers were just a first pass - they're not set in stone.
  • Lawrence: 1 month seems short too - what about 3 months?
  • Peter: that would also dovetail better with project status reporting (which we had discussed being quarterly)
  • Frank: I'm ok with that.
  • Frank: and what about 6 months for automatically moving to archived?  I feel pretty strongly that we should automate that.
  • Peter: one possible complication is that we may want to move incubating projects with 6 months of inactivity to long term maintenance, rather than archived, and there's no way for automation to "know" which state to transition the project to (knowing whether a given project is "critical to the community" is a subjective measure).
  • Frank: ok - so ESCo will have to be automatically warned about inactivity, and then decide which way to go (e.g. after reviewing with the project team).
• AOB:
  • Frank: update on symphony-java-client activation vote
    • I'm preparing a wiki page with the activation information.  Hopefully finished by the end of the weekend, then hoping to put out an activation email vote early next week.
    • Lawrence: one question: we've been looking at the endpoints the client has been using, and one of the Symphony endpoints the client uses is not fully supported.  Paul (Teyssier) is supposed to talk to you about it, and his recommendation was to pull that endpoint out of the library.  Did that conversation happen?
      • Frank: yes.  It's the presence poll every 30 seconds - he mentioned it's no longer a published endpoint.
      • Lawrence: I don't believe it was ever a published endpoint.
      • Frank: one of the earlier YAML files had that endpoint published in it - I've always used the Symphony-published YAML files and that endpoint never left the Swagger generated code.  My concern is that people are using this API already.  I can either deprecate the API with warnings galore, or I can pull it out entirely because Symphony don't want it advertised.  I want to leave it up to ESCo to make that decision.  To be super clear, this presence call is a heavy call - I completely agree with Nathan (LLC engineer) talking about potential issues customers might have in using that service (PresenceService).  By default when you instantiate the symphony client library the presence service is disabled until you add a listener, at which point the polling infrastructure is enabled.  As I say, I can leave it in with warning language around it, or pull it out of the client with potential impact.  Are you comfortable for ESCo to vote on this?
      • Lawrence: at the end of the day I'm ok to vote.  Two arguments to consider pulling it: if users use this binding, in addition to the performance & stability implications, we plan on proving this capability in the future, and there's a risk the new functionality may work differently, and if a developer was using one particular pattern to use it, then Symphony changes it 6 or 9 months from now (I'm hoping it's not too far in the future), and if it works differently when we release it we run into compatibility issues with downstream code.  That's an issue that you as the language binding owner should consider, because it could put you in a difficult position regarding breaking changes.  The other comment is that it might be that the path here would be to propose it to the community without that feature in it because of these types of reasons, then see what the community reaction is - if there's a big reaction to that from the community then we could have a discussion around it.  These are reasons why you, as owner, might decide rather than putting it to a vote.
      • Frank: the client is implemented to abstract away the underlying bindings.  So the users using the PresenceService wouldn't see any difference, most likely.  The biggest concern I have is around stability.  I'll put a note out to the community saying there are concerns around potential stability when polling this no-longer-published endpoint, but I want to make sure that anyone who's leveraging that service is not going to be impacted.  If nothing comes back within a week or so then I'll pull it in, in a way that's not going to break too much.  I'll limit the use of the service so we're protecting the head end.  Are you comfortable with that?
      • Mike: I'm comfortable
      • Lawrence: if a bunch of people come back saying it's important, that's important for us to know.
      • Frank: it's important to us!  
      • Peter: it will also be harder to change once the project is Released.
      • Frank: though we're pretty damn active already!
      • Lawrence: when you communicate with the community, it would be good to make it clear that this capability will be there in a supported fashion - in a year from now there should be a solution.
      • Frank: and there's still a way to get presence, it's just bulk presence that the team wants me to shut down.

Action items

• Peter Monks to schedule email vote for ratification of API WG
• Peter Monks to cancel meetings on Dec 20th and 27th
  
  • Even if those cancellations don't come through properly, please delete them manually!
• Peter Monks to check with Gabriele Columbro and Maurizio Pillitu regarding the possibilities of enabling multi-party cross-pod chat in the Foundation pod
• Peter Monks to update wiki content (specifically thresholds for inactivity) based on today's conversation
• Former user (Deleted) to send email to community (dev mailing list?) regarding bulk presence API in symphony-java-client