...

Actions items from previous meetings

...

Meeting notes

Anthony Fabbricino: First, we’ll run through some action items and update them. There are a couple related to language bindings. Johan, Frank, I don’t see Jon Freedman, but we wanted to create some detailed use cases, API definitions, and YAML swagger.

Johan Sandersson: Yes, I know Jon has posted some items into the wiki on exactly the functionality he’s been doing. I’ve tried once to get ahold of him to discuss, but we haven’t made contact yet.

Anthony Fabbricino: That’s no problem. But it sounds like Jon’s done his part which is to add use cases to the wiki. Frank, can you comment on creating the YAML-Swagger spec?

Frank Tarsillo: I added a couple use cases to the wiki. As an aside, I think we need someone to own updating the subsection on chatroom bots, etc., to make it easier to read.

Paul Teyssier: What’s the ask specifically? To define more clearly who the author is of each section?

Frank Tarsillo: I think 1) who owns each subgroup, and 2) agreement on a template/format for defining these things.

Johan Sandersson: I feel slight ownership of the subgroup. My attempt was, as a non-technical person, to get some simple examples going – not technical, just what are we wanting to do on Symphony, e.g. “Bob wants to see if Alice is online.” The next step would be to put that use case into a category. Then hopefully those who are more technical could take ownership for specifying, say, the whole API piece using the use cases in the wiki.

Frank Tarsillo: I like your format, so happy to use that.

Leslie Spiro: What format are we talking about? Right now it looks like it’s just a sentence of text describing a high-level use case.

Frank Tarsillo: So for example “Chatrooms – bots”: Scope, Collaborators, Working Examples, etc. I’ll convert my use case to that format.

Leslie Spiro: If we don’t have all of that information, could we put in a simple text description of our use case and hash out the rest from there?

Paul Teyssier: Here’s a proposal. There’s a way to use Confluence such that the individual pages are easy to produce and you can generate overviews that are easy to understand. If we do it from the get-go, it’s easy to maintain. Doing it later means a lot of work. So maybe I’ll take one of these and make it explicitly a template so the subsection is easy to work with.

Johan Sandersson: Another good thing to clear up would be why one of the more technical examples exists – what are we trying to do? That way we can tick off – because we’ve done these technical things, this practical use case is accounted for.

Paul Teyssier: One necessary step to get there is to be aligned on, what is the pattern for use cases that we’re trying to establish? We need to be clear on the nomenclature we’re using, so the use case is clear and stable across different language bindings.

Peter Monks: We just had this same exercise with the click-to-dial projects, and I proposed that we use “job story format” for expressing requirements, and I’m happy to talk about that if the group is interested.

Paul Teyssier: The good thing about that format is that it’s relatively lightweight so everyone can participate without spending a lot of time to learn it.

Leslie Spiro: We have two OBO use cases, and I went to the site and was about to post one, and I couldn’t figure out where to write it and what to do with the templates. So I’ve got them and can write them out as text, but I don’t know enough to create the templates.

Anthony Fabbricino: How do we help with that?

Leslie Spiro: If it’s just about typing text into the examples page and we can talk about whether we agree about it, that’s fine. If I need to provide the more structured information required by the template, that’s more work and I need to bring more people in.

Paul Teyssier: I think the goal is to focus more on the functional aspects and being very business-centric with the examples.

Johan Sandersson: Yes, and that’s all I feel comfortable doing, to be honest.

Leslie Spiro: I’m happy to define my use cases in the functional format and maybe

Paul Teyssier: I can create the template by the endo f the week, how’s that sound?

Leslie Spiro: Yes, that would be helpful. I’ll put in my two cases and we can go from there.

Anthony Fabbricino: There’s another action here about providing feedback to Paul about high priority errors/exceptions.

Paul Teyssier: I think this is just a standing action. This is potentially the group that is most aware of the Symphony API and is using it most deeply. We know the exception handling isn’t great and we’re working to improve it. But having your input on what’s particularly bad would help us prioritize it.

Aaron Williamson: We can reformat that to make it clear it’s just a standing action item.

Anthony Fabbricino: There’s an action about guidelines and best practices. We started a conversation about API versioning, which would be part of an API guidelines. And we have put some information into the wiki about that, and BNY is looking into sharing our own guidelines on this.

Paul Teyssier: We also put out our change-management policy a couple of days ago. Peter have you had a chance to look into that?

Anthony Fabbricino: I tried to open that link on the developer portal and couldn’t get to it.

Peter Monks: I think you need to register.

Paul Teyssier: You have to login and click the link again.

Anthony Fabbricino: Ok, I’ll try again. I think we’ve gone through most of the action items. There’s an agenda item here about the approach to best practices. I’ll give a summary of how we’ve talked about this and propose a way to move forward more quickly. You can see I’ve created some subsections that cover the major items that we should discuss and agree on/formalize around design styles and best practices around REST APIs. One is around response-handling, another on naming conventions, then data representation. Not sure how the latter relates to the FOS working group, but we can sort that out. But I wanted to get some thoughts on whether this is a good way to approach a collaborative process for defining best practices, and for people to identify the areas they’d like to see addressed in a bottom-up manner. I’ll open that up for feedback.

Paul Teyssier: A question for the group: what are the areas of best practices that the group would be most interested in working through first.

Matt Joyce: I don’t know if this is relevant to best practices. In the next release, you can stop using PKCS authentication.

Peter Monks: To be clear, it will still work, it’s just redundant, right?

Matt Joyce: It will, but if you’re hosted in cloud it will be on a different endpoint so you’ll have to change the URI.

Anthony Fabbricino: Is that something we want to capture in terms of guidelines and best practices?

Aaron Williamson: Well, it relates to best practices in the sense that it has to do with API versioning and backward compatibility, right?

Matt Joyce: It also relates to how we use the PKCS certificates safely.

Anthony Fabbricino: On the versioning side, if what we’ve written so far can support what this change needs to do to maintain and communicate a version, that’s good, but I’m not sure how that product change comes back to a best practice or guideline.

Johan Sandersson: I was just thinking, Paul and Symphony folks, is there anything you’re looking for from the working group about how to get the next round of priorities cleared up. What would be beneficial for you?

Paul Teyssier: One question is how we’re thinking about our priorities. I’m happy to share how we’re thinking about those from a Symphony platform standpoint. Do you want to do that now, or hold it for the next meeting?

Anthony Fabbricino: I think maybe set it up for the next meeting so that people can have time to think about it first.

Paul Teyssier: Ok, here’s the short version. We’re trying to address two goals. First, our API is 1.5 years old, which means it still needs to mature around stability, exceptions, etc., so that’s a big priority. I’d like to hear the community’s input on a couple levels: from the more technical, like which parts are painful to deal with as a developer; to the more strategic, like how can we make certificate management easier; all the way to, is the design of the REST API consistent with what you wanted to see when you first approached it. On all of those levels, I’m interested in hearing what would make the API easier to use.

The second piece is, there’s lots of functionality customers want that’s not supported yet. So as we increase the functional scope, what do you need most and first? To a large extent, I see that the interest and energy in these conversations is typically correlated to the areas that your organizations are working on.

Frank Tarsillo: I would suggest that in the next session, it would be the community responding to that very clearly in a way that’s actionable for the LLC. Is that what you want?

Paul Teyssier: Yes, at both the functional level (which we hear a lot of) and the more strategic level, which we hear less about but this WG is well-equipped to provide. Maybe we’ll replay what we’ve heard and get your reactions to that.

Frank Tarsillo: And we just need to be prepared for that.

Paul Teyssier: What’s the level of preparation that would be helpful?

Frank Tarsillo: I’d like to have people write down what they’re going to ask, e.g. “I think we should remove the agency server on-prem and communicate directly with the pod.” “I want to see a full SDK for embedding Symphony chat into other applications outside the desktop.”

Paul Teyssier: I see value in having the group dynamic add to things, so we should pick one way of listing the questions that are of interest to WG members. Should we use Confluence or the mailing list?

Aaron Williamson: I’d suggest Confluence so things don’t get buried in inboxes.

Anthony Fabbricino: Another item on the agenda is, we’ve got these different work groups – I think we’ve talked about use cases, Johan, is there any update you want to give? And Paul, on language bindings?

Johan Sandersson: One of the action items I had was to send an email out to the group to explain what I was asking for in the example page. I haven’t had any responses, but what I’m most interested in is an extremely high level of interest from the various teams. FactSet is very interested in user presence, and showing it in other applications. So if you could get your organizations’ input on what’s interesting/important to them, that would be helpful. And maybe we could put names next to things so we can have a real debate about it. I’d like people to be shouting out, “I need this thing so I can build something exciting.” So please ping me over email or Symphony if you have use cases to discuss and don’t want to add it directly to Confluence, and I’ll put it up.

Anthony Fabbricino: Do you think there’s value in sitting around in these meetings and going through that part of the wiki and talking about the existing ones, adding new ones? Or is that duplicative of effort that’s already happening? 10-15 minutes each meeting?

Johan Sandersson: I think that’s a great idea.

Anthony Fabbricino: Yeah, since we’re all here and screensharing we can go through it in realtime. I’ll work with Aaron and Paul to come up with a format for doing that as a standing item. Paul, I don’t want to put you on the spot, but on the language bindings projects, do you have any update to share on those activities and how we want to identify actions and priorities?

Paul Teyssier: I’m not sure I’m the best person to answer that. There’s a lot of activity going on that we’ve

Frank Tarsillo: I think it’s very useful to walk through the language bindings, and it’s just a matter of time and energy. The idea of the subgroup would be to compare notes and align where we can to make the bindings consistent across languages. That’s the goal, it’s just a matter of getting started on it. We just haven’t had the time/energy yet. We’ve got the Members Meeting on the 21^st of June, and maybe we can get around the table specifically on that effort.

Aaron Williamson: And while we’re on the topic, I want to encourage everyone on the call to bring as many folks as possible to the Members Meeting. In addition to presentations in the morning and working sessions of working groups in the afternoon, we’re going to have an afternoon-long training session for developers new to the Symphony platform and the ODP, so it’s a great opportunity to bring in people from your organization who haven’t had a change to get started with Symphony development yet.

Peter Monks: We’re also currently hosting a global virtual hackathong, the Open Innovation Challenge, Global, which will culminate with an awards ceremony at IHS Markit’s new space the night before the Members Meeting. So we encourage you to get hacking on something interesting and join us there.

Action items

•  Former user (Deleted), Former user (Deleted), Aaron Williamson: create standing agenda item to go over existing use cases during biweekly calls.
•  Former user (Deleted): for the next meeting, prepare to go over Symphony's API priorities and customer/working group input, and lead a discussion of priorities.
•  Leslie Spiro: add your high-level use cases to the use cases page.
•  All: review the job story format and consider whether to use this format for use cases.
•  All: register yourself and your developers for the Foundation's June 21st Members Meeting (including the developer intro to Symphony training) and the Open Innovation Challenge, Global hackathon.
•  All: write down in Confluence your wish list for the Symphony API (at both a functional and a strategic level).