Versions Compared

Old Version 8

changes.mady.by.user Peter Monks

Saved on

compared with

New Version 9

changes.mady.by.user Peter Monks

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

...

  • No quorum - only 2 project leads 
  • Action item review
    • Investigation of improvements to ESCo email voting:
      • Laurence: I'd suggest spacing votes out, so they don't stack up 
      • Peter: what's a reasonable spacing?
      • James: one at a time
      • Peter: that caps throughput to 1 vote every 3 business days, due to "timeout period", and we typically need the full 3 days due to abstentions by non-response.
      • Laurence: have we spoken with those who aren't voting? 
      • Peter: I had done in the past - given gentle nudges via email that a vote was in progress.  That didn't seem effective so I've stopped doing it.
      • Laurence: have we thought about automatically spamming them every 12 hours until they respond?  It's unlikely any of us will be offline for much longer than that.
      • Peter: as I say I've tried that manually and it didn't work.  I don't think automated nagging will be any more effective than manual nagging.
      • James: I'm astonished we don't have a system that can do this.
      • Peter: keep in mind that email voting is the standard in most open source Foundations (Apache etc.).  We have 3 key requirements:
        1. firm employees must be able to access the voting system (and the lowest common denominator here is email - everyone has access to that)
        2. it must support our voting mechanic
        3. process and results must be transparent to the community
      • James: the current model is not a problem until another bomb load of votes is dropped
      • Nick: I find it confusing not to have a page where the current votes are listed.  But it seems that what you're saying is that there's one person who's a problem.  I know I've probably missed some votes because they get buried in email, but no one's chased me, but I assume there are people who don't respond to being chased.
      • Laurence: we need a certain number of votes from voting members (advisers don't need to be chased as their votes are advisory), so there are certain folks who need to be chased in order for votes to work mechanically.
      • James: when the 8 votes came out at once, it was an issue.  Having 8 on the run, finding them, and working out which ones had and hadn't been replied to was a pain in the arse.  I've also heard that that particular tranche was a pain for others.  But it hasn't occurred again, so we may be over-engineering the problem if there isn't enthusiasm to fix it.
      • Laurence: possibly tell us who the abstention was, in the vote result?  I don't know historically if I responded to a vote or not.  It might help create some social drivers to encourage everyone to vote and respond to things.  And it's not like the votes are private anyway.
      • Decisions:
        • We'll space votes so that at most one vote is initiated per day.
        • We'll include name on non-responses to create some incentive to participate in votes.
    • Jim Adams / interoperability:
      • James: Further conversation needed to form a new WG, and I see in the Foundation BoD materials that there'll be some level of discussion tomorrow.
      • Laurence: I've talked to Jim offline - we had a meeting earlier this week - and we got into more technical depth over what they're proposing and more follow on conversations to be had.  Exciting possibilities to be had in terms of development of this into a Foundation initiative - lots of initial interest.  They've been pushing to make sure that they've had bilateral conversation before they come and propose something at ESCo level.  I'm going to be encouraging them to present back to DW WG or some other forum (ESCo or whatever) because I'd like to convert this into a multilateral conversation.  They're open to that, but want to get some preliminaries sorted out first.  In terms of WG structure, the key question in my mind is: "is this a new WG or a sub-group of the existing one"?  In my last conversation, it seems there's a decent chance that what they want to do will fall into existing desktop wrapper and API WGs.  They happen to have an implementation of an API design pattern.  I'm not opposed to having a new WG, but I'd like to concentrate things in the existing WGs so they have critical mass.
      • James: I'd agree with you, and that was the outcome of my conversation with him too.  More iteration required regarding what they want to get out of this.  With your LLC hat on, they want to see the possibility of some of their technology making it into Symphony in some form, and that conversation needed to be had as well.
      • Laurence: yeah, they want to see some commitment from us to use their contribution.  There should be a way for this to be picked up by the industry.
      • James: what they wanted was some commitment, whatever level that might mean, that the tech would end up in Symphony and would end up in people's desktops or whatever.  That's how I left it with them, as that's a commercial conversation.
      • Laurence: elements of commercial conversation and big element of product roadmap too.  Also an element of chicken & egg - our view about adopting it is that we'd want to know it's something the industry wants.  But we can get to a point of sounding out the industry and finding out their response to it.  In terms of how it fits into the other WGs, even if we created a new WG for this the existing API WG might be mooted by this.  This technical implementation of this API would have a pattern to it, so if we adopted this API, that's how it would work.
      • James: for some of the API WG charter, but not all.
      • Laurence: if there's interest in having theoretical conversations, perhaps.
      • James: it might be the practical answer to a lot of what we're talking about.
      • Laurence: I want to make sure we're encouraging focus on active WGs, rather than spreading things out.  One of the BoD proposals is to kill off the security WG, and as we're managing what's happening with the WGs we need to be aware there's a fixed population to pull from.
      • James: completely agree.
  • FOS WG:
    • Laurence: I've talked with Paul Teyssier and Mike about this; if Paul were to be swapped in instead of Bruce.  Now that it's moving along on a product roadmap, having a product manager would make sense, and it would be a good way for Paul to have 1 meeting with 8 people instead of 8 meetings with 1.  He was pretty receptive to that, with some reservations due to his experience with the API WG - he was concerned about the overhead and logistics time.  I pointed out that there are some significant differences in terms of how this is aligned to something he's working on, rather than being a side project.  It also depends on who the co-chair is - if we could identify a good co-chair candidate, I think I could encourage a Symphony product manager to become the chair, as this is mutually beneficial - it helps that PM do their job.  We just have to get the process moving.  That's my background update on it.
    • Peter: I spoke with Mike last week, after he spoke with Bruce, and he was saying that the custom object capabilities are not production ready yet -they shouldn't be used, shouldn't be touched, and that that limits with the WG could do?
    • Laurence: there's an element here of talking to an engineer.  They're tasked with doing whatever the PM team prioritises, and therefore putting a PM who's tasked with giving customers these mechanisms is ultimately going to help.  I'm familiar with the technical readiness of the underlying mechanisms, and there's work that needs to be done to make them production ready.  But that's why we need the WG - to facilitate customers talking to PMs to tell them why these platform things need to be done.  I think the feedback you're getting is engineering feedback, rather than dynamics feedback about how to make things happen.
    • Peter: makes sense, and aligns with my sense of pent up demand for these capabilities. I was chatting with Goldman this morning about their ideas around an inter-firm "Task" object, for example - they're keen to participate in the WG to define this.
    • Laurence: any thoughts on co-chair?
    • Peter: I think Johan Sandersson at FactSet would be ideal - he's in effect the co-chair already.
    • Laurence: can you ping Gab to solidify a list of volunteers?  I'd like to have a plan of who the two chairs should be, then go from there.
    • Peter: perhaps we should also ping the FOS WG's mailing list, asking for volunteers?
    • Laurence: yeah 
    • James: speaking to Johan and going out to the WG is a good idea.
    • Peter: whose action item is this?
    • Laurence: I'd previously asked Gab to do it. Can you follow up with Gab on that topic?
    • Peter: sure - I'll take that action
  • AOB:
    • Peter: thanks James for getting the BoD slides out on time - really appreciate it
      • James: given the overlap between ESCo, WG and BoD members, there shouldn't be too much discussion
    • Peter: head's up on an upcoming email vote to archive , at the request of Paul Pollock (one of the project's leads) - that should appear via email later today

Action items

  •  Peter Monks: to discuss with Gabriele Columbro the potential for including the "ESCo seat vote staggering" proposal in March 1st BoD call - perhaps in AOB, given the slides have been distributed?
  •  Peter Monks: add ESCo agenda item regarding DB conversation
  •  Peter Monks: get an update from Gabriele Columbro regarding his action to identify co-chair candidates for FOS WG