...
- Roll call
- Action item review:
- Frank: gave overview of a draft of some project releaser approval criteria (available here)
- ESCo to review offline, prepare comments / feedback and discuss in a future meeting
- Peter scheduled Anthony (today), James (today), and Bruce (next week) to give updates on their respective WGs
- Peter did not schedule Lawrence to give an OSS plan update - will move that action forward
- API WG status update (Anthony)
- Introduction to Anthony - new at BNY Mellon, previously at AT&T as a product manager / marketer on the developer platform team. 5+ years of experience with APIs and developer platforms.
- Chairing the API WG on behalf of BNY Mellon. Michael Gardner remains the executive sponsor.
- Anthony: narrative update on the activities of the WG, and where we are:
- This WG is still in the formation stages - we haven't submitted a charter for ratification yet, but that's our main objective.
- We have membership from 8 different Foundation member companies, 17 or so individuals from those companies. So reasonably good representation.
- So far we've had 3 meetings, with 10-15 participants, including members of the LLC (Bruce, Paul). So reasonably broad and committed representation, based on meeting attendance.
- Our main purpose and focus of discussion in those meetings has to come to some consensus on the charter that we can submit for approval. And also to look at it beyond the charter and think about the key activities of thew WG, and prioritise them, so that when the charter is approved we can get started quickly.
- In those meetings we've used agenda / discussions / feedback to iterate on the charter. We've conducted a survey, across the Foundation membership at large (not just those participating in the WG) to help identify priorities.
- The plan going forward is to take the latest version of the charter, submit it to the membership and vote, on a member firm basis, to submit the charter to the ESCo. We expect to conduct that vote by the end of the month (September).
- We then expect to submit the charter to the ESCo for ratification sometime in October.
- High level activities / prioritisation exercise identified these top priorities:
- Put in place a framework or set of best practices / guidelines around APIs that will be exposed going forward around code contributions to the Foundation. We've used Bruce's document, BNY Mellon's own standards, and standards from comparable open source communities to build this.
- Key functional requirements that would be exposed as APIs. Another voice of input into the Foundation on what we'd like to see in terms of building out and adding to the Symphony platform.
- Q&A:
- Lawrence: do you see the WG having both of those mandates ultimately, in the charter put forward to ESCo, or are you trying to pick between the two?
- Anthony: the vote will determine that, but the intent is to include both of those mandates in the charter, and it's more about sequencing specific deliverables than it is about trying to say what's included vs not included.
- Lawrence: 2 pieces of feedback:
- The composition of the WG depends on what it spends its time focusing on. The questions around standardisation and architectural design of "what does a RESTful API look like from an an architecture perspective" is a very different audience than people who are either consumers of the API or authors of the API code.
- If I was looking at a dual mandate, I would be looking at how you'd operate under that mandate. Are you biting off more than you can chew with this type of a WG?
- Second question I would ask: as you're looking at the second topic (functionally what gets built), at least when I've looked at this through a Foundation lens, the governing processes are around accepting contributions of code. Would you be looking therefore at this group as the group that approves contributions? How are you positioning how the WG operates vs how the Foundation operates?
- Anthony: 2nd question first. We don't see the WG as being involved in approval activity. The LLC is already doing market research and has a plan of deliverables. This is more another set of requirements from Foundation members - another set of inputs. It's not about approvals.
- Lawrence: is this code contributions or how do you envisage this working?
- Anthony: I envisage it as some code contributions to the Foundation.
- Lawrence: so the WG members procedurally would come up with things they'd like to construct, then propose that code for contribution?
- Anthony: the mechanism is more along the lines of how are some of the services / experiences we feel are necessary for clients to be able to implement Symphony as a platform product. Not to build up teams to build that code, but to build up teams who can...
- James: I'm a little confused by that. If we think there are holes in the Symphony API offering, then things can either be delivered by Symphony LLC or 3rd parties. Compatibility layers / client bindings are being delivered outside Symphony, but core things like directory lookup are developed by Symphony LLC. I think it would be clearer to differentiate between things that must be developed by Symphony LLC vs things that can be contributed by 3rd parties. I didn't understand the idea of influencing Symphony LLC.
- Lawrence: I think if someone sees a gap, they should contribute code to plug that gap.
- Frank: I think if the gap is in core Symphony, is the recommendation to plug the gap or request that it be plugged by Symphony LLC? I'm also a bit confused by the proposed charter. I thought the API group was going to help evolve the APIs to be more consistent, perhaps with client bindings, capabilities that add on to the core API capabilities, and then if things come out of that that there's a requirement that the community is looking for that's missing, we would feed that back to Symphony (either individually or from a community perspective).
- Anthony: yes that's exactly what I was trying to express - I think you've said that more eloquently.
- Frank: Lawrence is that how you see this charter going? Do you see this as a value to the community? I do by the way - I've always wanted to see this kind of WG.
- Lawrence: I think that things like language bindings, and given where we are right now in terms of getting code contributed, we're either rooting things in creating and contributing code, or we're rooting things in standardising things that define what kind of contributions the Foundation will take on. I'm trying to fit it into one of these two pillars. As long as it's constructed around something functional, it's a code contribution - that's viable as a mandate.
- Frank: I like your two columns. I thought this body would play both roles. One being that there should be functional software developed out of the WG (or the community in that space), or in lieu of that we get to your first column - let's try to create some standardisation so that the core software that underpins the APIs supports the kinds of things we're trying to build. Whether this is two groups or one, this will help inform the participants in those groups. This is a critical group for us to establish, and if we can isolate into those two buckets I think it would be very helpful.
- Anthony: this is good feedback.
- Frank: side note to all of this, I'm sure we will find product-related issues with what is existing from a Symphony product perspective, and we'll figure out how to feed that back to product managemrn int Symphony. That's going to be a natural outcome of the progress of this group.
- Frank: question: do you need help?
- Anthony: quite frankly I think we're reasonably close in articulating the mandate of the WG. Happily I hear that there's a desire to have this WG in place, it's a matter of being specific on the mandate, and what I've heard on this call is tips on how to stay sharp on the mandate. Obviously the charter is going to come to the ESCo for approval, so we're going to incorporate your feedback and reflect it back into the charter.
- Peter: question: I'd appreciate feedback on the meta process of creating a WG - how was that, what could be improved? This is our first time through this, so I'm sure there's lots of opportunities.
- James: we need to provide better guidance to the WGs about what we're doing. The pillars of what's expected. I was on the last fabulous API WG where 55 minutes was spent talking about voting process - we need to stop that. It was just awful. It wouldn't shock me if your attendees dropped as a result.
- Peter: absolutely, and we already have changes in review within the Foundation to address this (and other things).
- Lawrence: we need the procedures to be well documented.
- Peter: agreed, and that's what's in review right now.
- Lawrence: the second part of it is that a voting procedure itself won't help the WG come to consensus. So while I think voting procedures are important at one level, they shouldn't be a crutch to come to consensus. Going to a contested vote before a mandate has been agreed is inadvisable. ESCo, for example, hasn't agreed on a voting procedure because we haven't had to - we come to consensus before any votes take place.
- James: agreed. I felt there was a case on the last call of people saying "if we don't have a voting procedure, then you don't have moral authority".
- Peter: note that the ESCo does have a formal voting procedure - if you're unfamiliar with it Lawrence you might like to check the wiki. Also, the group dynamics between ESCo (5 participants) and API WG (more than a dozen participants) are markedly different, so it's comparing apples and oranges.
- Desktop Wrapper WG status update (James)
- As a reminder, this is the dual charter we originally put together:
...