Table of Contents
Date
Agenda
Time | Item | Who | Notes |
---|---|---|---|
5 min | Convene & roll call | ||
10 min | Review action items from previous meetings | See below | |
10 min | Members Meeting: call for participation and discussion of agenda | Aaron Williamson and Former user (Deleted) | Proposed agenda items for Members Meeting: 1) working session to define API standards/best practice; 2) working session to define use cases; 3) informal meet & greet; 4) combination of 1-3. |
20 min | Discussion & feedback on new 1.46 release and priorities for future API development | Former user (Deleted) | |
10 min | Review use cases; discuss job story format for capturing use cases | Johan Sandersson & Peter Monks | |
5 min | AOB & adjourn |
New action items
- Matt Joyce (Deactivated) and Former user (Deleted): schedule a call to discuss API binding consistency. Coordinate with Former user (Deleted) and Dan Nathanson (Deactivated).
- Peter Monks: introduce Former user (Deleted) to the member with the OBO use case re: connection request reminders.
- Former user (Deleted): review API use cases with LLC team before the next meeting to determine/document whether they're supported by the existing API.
- Former user (Deleted): email the mailing list about Members Meeting agenda/attendance
Standing action items
- Capture API use cases relevant to your organization
- Identify high-priority use cases in Confluence or to Former user (Deleted)
- Tell Former user (Deleted) about API errors & exceptions that need work
Actions items from previous meetings
Language Bindings
- Former user (Deleted): create API definitions based on SJC abstracted binding layer and generate a YAML Swagger specification from it
- Former user (Deleted): Look into how to enable limited cross-pod capabilities on the Foundation's test pod and others to make integration testing possible.
- Former user (Deleted), Former user (Deleted), Matt Joyce (Deactivated):
- Start a list of the basic functionality bindings should have test for before being considered active. (Possibly Former user (Deleted) too.)
- Draft list of API endpoints that should be supported by active language bindings.
REST API Guidelines and Best Practices
- Former user (Deleted): clear BNY REST API guidelines for external publication.
Use Cases
- Leslie Spiro: add high-level description of Tick42's use cases into the wiki
- Former user (Deleted): work with Johan Sandersson to create detailed use cases to define the capabilities that bots should have access to
- All: review the job story format and consider whether to use this format for use cases.
Consuming the Symphony API
- All: If you are aware of an open source project that provides a good API for creating bots, tell Former user (Deleted).
- Former user (Deleted): Talk to Former user (Deleted) about bot deployment work, possibly contributing to Foundation.
Miscellaneous
- 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.
Attendees
Name | Organisation | Present? |
---|---|---|
Former user (Deleted) (Chair) | BNY Mellon | Y |
Former user (Deleted) (Co-chair) | Symphony LLC | Y |
Dhilip Buddha | BlackRock | |
Kashik Chaubal | BlackRock | |
Symphony LLC | ||
David Deng | Citi | |
At-Large Member | Y | |
BlackRock | ||
Symphony LLC | Y | |
Morgan Stanley | ||
Anton Kozyr | BlackRock | |
BNY Mellon | ||
JP Morgan | ||
Symphony LLC | ||
Barun Patnayak | Citi | |
JP Morgan | ||
FactSet | Y | |
FactSet | ||
Tick42 | Y | |
IHS Markit | Y | |
Symphony Software Foundation | Y | |
Symphony Software Foundation | Y |
Meeting notes
Paul Teyssier: We said we’d do a quick round-up of the latest activities. The attendants are primarily interested in use cases, I think. We also wanted to talk about the agenda for the Members Meeting. Johan, want to start with a recap of use cases?
Johan Sandersson: I spoke to Leslie and we went through a bit of the process and thinking and he had some good ideas. As you may have seen, I sent an email. We’ve restructured some of the one-liners, realizing that a sentence is maybe not enough. So now we have the possibility of adding more complete use cases if you have them. Jon and Leslie have both added some. In the table next to each use case we’ve allowed you to reference which more detailed API pieces you may need to use. If there’s need for something that’s not documented, you can add a new item to the wiki page. Then there’s a status column: is this something you’re ready to talk about? Is everything working for this? Then we’ve made another group that delves into the API functionality supporting the use cases in more detail. I saw Jon made some revisions, haven’t seen other activity, but hopefully we can start to go through and assign people to look into whether the use cases provided are supported by the existing API. And maybe we could start with OBO and presence since that’s what Jon’s interested in. My main concern is that people may want to add use cases but not know what to do, so I’d like feedback on that.
Paul Teyssier: What I’d propose, since we have some thinking on that on the LLC front, I can take a first cut at it with our team before the next meeting and we can go from there. Please check in with us and keep us honest.
Johan Sandersson: The other piece, Jon, you’ve been working on some of the other use cases with your chatroom bots. Would you like to speak more on what you’re doing, if there’s anything you need from the APIs, or if you want to get someone else from the WG that does something similar to speak to you in more detail… How are the APIs working for you?
Jon Freedman: We’ve got the hubot adapter written in JS running in production. I think the only oddities in the API are around permissioning – methods you need to be an admin user in order to use, but I think that’s been covered in the past. We’re not doing anything too complicated, so it just sort of works.
Paul Teyssier: Could you say more about the permissioning issue?
Jon Freedman: I’d need to dig out the specific issue, and I think Vinay at Symphony knows more than I do about it, because he’s the one who’s been asking for the functionality. We don’t use it. Some bit of functionality that wasn’t accessible, but I don’t remember.
Paul Teyssier: Ok, I think I know what you mean.
Jon Freedman: I think the speed at which 1.46 is being released is bit of a surprise. I guess it’s going in a week early? Aren’t you doing an emergency release this weekend?
Paul Teyssier: No, we have two release calendars. For enterprise, we released test last week and will release production next week, and for business users, we’re releasing production this weekend.
Jon Freedman: For a lot of people involved in API development, this might be an issue. We don’t have an enterprise pod, so I need to spend this weekend checking if this stuff works. Does the ODP have the new release?
Paul Teyssier: Yeah, the test pod is 1.46.
Jon Freedman: Will the API continue to work if you keep providing the auth?
Matt Joyce: It will, but you do have to change the endpoint.
Jon Freedman: That should be fine since that’s all configurable. I think on the examples I put onto the wiki, hopefully it’s clear. The format is slightly different. I don’t know if you want me to rewrite it…
Johan Sandersson: I haven’t really delved into it. I guess it’s more for the other people who want to use a bot or hubot in particular, if it has all the information that they need and if there’s more functionality that needs to be added in as people have other use cases, maybe it will need some revision. But I think for now it shows people how to work with bots.
Jon Freedman: There was another use case about setting avatars – that’s a use case that the API definitely doesn’t support right now, because you need to be an admin user type. I don’t know if OBO will fix that.
Paul Teyssier: What’s the gap?
Jon Freedman: Setting the icon or avatar. It doesn’t work unless the account doing it is an admin.
Paul Teyssier: Basically, we haven’t created a permission for avatar changes for OBO yet. We may consider it, but we don’t have it now.
Jon Freedman: Yeah, it’s not a big deal, but some of the stuff that people might want to do with hackathons, or IFTTT – keep your twitter pic in sync. To get developers interested in getting started on Symphony, it’s good for people to be able to stuff like that.
Johan Sandersson: Even if you don’t use OBO but are connecting as yourself, can you change it?
Paul Teyssier: Yes, you could mimic your user as a bot and do that. From an audit trail perspective, you can’t tell the difference, which we aren’t entirely comfortable with.
Jon Freedman: I tried this previously, and the only way I could do it was to make the user connecting an admin.
Peter Monks: Someone else told me that they wanted OBO to deal with outstanding connection requests: look at the whole userbase, find all unanswered connection requests, and notify users weekly till the connection request is answered. I told them OBO doesn’t cover this. Maybe Jon what you’re talking about is part of the same general pattern that there’s a lot more bots should be able to do on behalf of users.
Paul Teyssier: There’s specific functionality that has to behave slightly differently if you’re a regular user versus OBO. You don’t want to give OBO read capabilities to just any bot. So you want to grant only for specific rooms, or those created by that user, etc. I’m not sure there’s that complexity for connection requests, but I’ll look into that. Could you introduce me to that customer?
Peter Monks: Yeah. But my point more holistically is that there’s a whole slew of things people want to do with OBO and I wonder if there’s a more general-purpose approach to addressing them.
Paul Teyssier: Our view on this has been that the use cases can’t really be addressed wholesale. Most of them have very different functional behavior for normal, non-OBO use cases. This notion of scoping is a big deal and isn’t part of the existing functionality.
Peter Monks: Could you publish that analysis in the wiki so I could start directing users to that page, and people could collaborate on it?
Paul Teyssier: That’s a good suggestion. I was thinking the WG should look at the use cases first, but I’ll put that on my list and think about when we can do that. It would help us to know what the high-priority OBO use cases are for people, because till now we’ve mostly heard that people just want to post.
Johan Sandersson: There’s some information on the wiki page that Leslie has written specifically about Outlook presence and OBO, and he was interested in other OBO functionality, related to the old desktop API – can he see whether there’s a logged-in user on this PC?
Paul Teyssier: Yeah, that’s the kind of highlight we’re looking for. Anthony, we spoke primarily about the use cases. Want to take it over from here?
Anthony Fabbricino: Another thing we wanted to talk about was the next meeting, which would ordinarily be on the 22nd, but we have the Members Meeting on the 21st.
Me: We talked about a few ideas: 1) filling in some of the API guidelines/best practices; 2) fleshing out some use cases; 3) an informal meet & greet, or some combination of all three.
Anthony Fabbricino: My thought would be to maximize the value of the people there by working in the wiki on best practices, use cases, etc. It might give people who aren’t active on the calls the chance to participate another way.
Aaron Williamson: Anyone else have thoughts on that?
Paul Teyssier: Who will be there? [Yes: Aaron, Peter, Johan, Frank, Paul] [No: Anthony, Matt, Jon]
Anthony Fabbricino: And that sounds consistent with what Aaron told me about who’d be there.
Paul Teyssier: Should we maybe play it by ear?
Anthony Fabbricino: Let’s agree to formalize the agenda at our planning meeting this week. Then I’ll send a note to the mailing list to see who’s interested to attend and participate.
Frank Tarsillo: What was the proposal for the agenda?
Anthony Fabbricino: I think the most useful thing would be to do work on the wiki pages we’ve been working on: use cases, best practices, etc.
Frank Tarsillo: Ok, I have one other thing, which would be to go through the language bindings to see what matches up and see how we can do better.
Matt Joyce: I think that problem has changed a lot with the release of the YAML files and the swagger code gen we can do from that.
Paul Teyssier: Does that work if Frank you’ll be the only binding developer there? Is there anything going on on the .Net bindings?
Johan Sandersson: Unfortunately, not really.
Aaron Williamson: Maybe an off-cycle in person meeting for that between Frank and Matt?
Matt Joyce: I’d do that.
Frank Tarsillo: Yeah, that’s great.
[Discussion between MJ and PM regarding the difficulties of using swagger-generated Clojure and Python code.]
Anthony Fabbricino: So it’s not likely that this will be an agenda item for the 21st.
Frank Tarsillo: I’d like to meet with Matt in person another time since we’re both in New York.
Paul Teyssier: I’d love to have at least one member of the engineering team to be part of that meeting. We can fly Dan out for that. Let me chat with Dan. Why don’t you start with Matt and we’ll use the working group in the meantime. Maybe at the end of your meeting we can loop in someone while things are still fresh in your mind.
Anthony Fabbricino: The other item on the agenda is discussion & feedback on early impressions of the 1.46 release.
Matt Joyce: I’ve been using it and everything still seems to work, except for the endpoint change. I haven’t used any of the new features, including MessageML 2.0.
Frank Tarsillo: I’ve walked through some of the new services and they look cool. It’ll take time to engineer them into our existing work. I’ve started working on a new Symphony Java API project, so you can go and look at that. SJC needs to be updated for the new API version. The MessageML parser was contributed to the Foundation and I’d like to use that within the SJC as an optional tool. How robust is that?
Paul Teyssier: It’s the one we’re using in the agent. You should talk to Dan about versioning but everything should be aligned.
Frank Tarsillo: What’s the best way to report issues we find in the API? Confluence? Jira?
Peter Monks: We do have a Jira project set up for this, ODP, and there’s an issue type for API issues.
Frank Tarsillo: Could you send that to the mailing list?
Paul Teyssier: Peter, let’s connect offline so this is part of the Symphony SOP when an issue is relevant to the work going on in the community and we can give a quick summary to the group.