Anthony: I'd like to focus today on identifying who might like to work on each itemIdentify the timeline and deliverables for each item. Malay, Johan - did you have specific work items you felt you'd like to work on?
Johan: #3 - use cases. Proposals for functionality for use cases we see, and trying to come up with possibilities for the API set today.
Anthony: ok great! Malay?
Malay: I think it makes sense for us to start with what Johan mentioned - it'll force the conversation down to terminology - it will be helpful to have use cases that unify everyone's mental models.
Anthony: from the BNY perspective, I'd like to put myself forward for REST standard and guidlines. We'd like to share what we've done at BNY Mellon and merge it with what's been provided by the LLC. Former user (Deleted) may also have a separate interest. Form the LLC perspective, do you want your name on any particular work items?
Paul: interested in all of them, but practically I or someone from my team should work on terminology and domain model with the FactSet team. We have some drafts on that, but would like alignment as a group.
Anthony: so we have a good overlay of names for these work items.
Paul: I'll find someone in the engineering team to help out with the REST API guidelines, perhaps Dan.
Anthony: let's assume that we'll take lead on those work items to kick things off. Let's now talk about how we'll come to deriving milestones and deliverables, how we'll report that back - Confluence wiki, mailing list, readouts at the bi-weekly meetings. I'd like to lay out what the next couple of things that we should agree to do. Peter, what does the Foundation recommend here?
Peter: there's one hard constraint around firm access to some of these systems - some banks can't access Github, or Google, for example. But ignoring those constraints I'd recommend we use Confluence for developing artifacts, and the mailing list for coordination. I'd also suggest that the "sub teams" cc the mailing list on everything, as that makes progress visible, encouraging participation.
Anthony: yes let's cc the mailing list on all comms. So I'll start with a sub-page for the REST API guidlines work, describing scope, deliverables, milestones, etc.
Paul: Malay, Johan - is your primary interest use cases or terminology & domain model?
Johan: I'm primarily interested in use cases (#3 on the list)
Peter: so you'll take point on creating a sub-page for that, a bit like Anthony is doing with REST API standards?
Johan: sure
Anthony: and Paul you'll do domain model?
Paul: I think we should focus on one or the other. I'd rather focus on fewer work items than spread ourselves too thin, so I'll join Johan on the use cases.
Anthony: ok so two initial work items - REST API guidelines and use cases.
Peter: should we put a status update in the next meeting?
Anthony: yes let's make that a standing item on the agenda, for those who don't follow the wiki etc. It becomes a forcing function for progress.
Peter: I'll take the action to add "status update" standing items to the agenda.
AOB:
Paul: comment for chairs - I'm kind of surprised by the attendance we had before the break vs now. Perhaps we need to be more flexible about attendance, and validate that? The scope of the work items we identified assumed a higher attendance.
Peter: I think that's partly technological - this invite was sent to the list vs the December one which (IIRC) was sent individually. Although it's a pain, I can revert to individual invites if need be.
Action items
Peter Monks: check that everyone received the meeting invitation