Meeting minutes status: Approved

Date

11 Oct 2018

Attendees

Name	Organization
Nicholas Kolba	OpenFin
Riko Eksteen	JP Morgan
Frank Tarsillo (Deactivated)	IHS Markit
Espen Overbye	OpenFin
Zoltan Bourne	Citadel
Colin Eberhardt (He/Him)	Scott Logic
Former user (Deleted)	Refinitiv
Leslie Spiro	Tick42
Tosha Ellison	FINOS

Goals

come to agreement on initial spec

Discussion items

group

Time

Item

Who

Notes

5 min

role call - get started

group

Tosha Ellison agreed to minute the meeting.

45 min

open questions, comments on current spec

group

Comments/Discussion

Nick started by stating that the group has a good set of standards to start with, which can be further improved following feedback from implementations and opened to the group for questions/comments.

Kat provided feedback from Refinitiv that part of the value of the Eikon Side by Side Integration API is being able to launch applications with specific instances. The current state of the FDC3 API would not enable them to replace their existing API. They need the ability to keep communicating with the applications once they've launched.

The above prompted discussion around the value of being more or less specific in the API. Nick pointed out that the current API doesn't go into instances but does cover raising intents to various platforms. Raising an Intent returns an IntentResolution which has a source property (string). This is open-ended so could refer to an instance. Leslie questioned the value of being open-ended vs specific and stated that he thinks the current spec is to loose and that is why the Tick42 proposal defines types.

There was continued discussion/debate regarding whether the API should be more opinionated/specific or not and whether or not this was a good enough baseline to move forward with. Leslie pointed out that the Tick42 spec was additive; Zoltan noted that they had to make quite a few changes to use the current version and that not having namespaces was an issue; Frank pointed out that other WGs are also having back-and-forth on similar topics and agreeing to move forward with a base, which can be improved incrementally.

Nick suggested that the group vote to ratify. Leslie pointed out that they have an alternative and feedback from the group was that PRs should be made against the existing spec so that the group could best evaluate the changes individually. If it can not be represented through PRs to the existing spec then it should be raised to the PMC to clarify/understand why a new API is required.

Motion to ratify specifcation

Nick made a motion to vote to ratify the current version of the API Specification. Frank seconded the motion. A verbal vote was held with the following results:

Colin - In favour

Espen - In favour

Kat - In favour

Leslie - Opposed

Riko - In favour

Nick - In favour

Frank - Abstain

The group being quorate and the majority vote being in favour, the motion was passed.

The proposal will now be made available for wider comment before being presented to the PMC for ratification.

Next Steps

The current spec (labeled 1.0) will made available as is for comment and review by a wider group. If changes need to be made they can be made to a working draft for a new version (branch 1.1).

The spec will be labeled as 1.0 and there will be a branch for 1.1

Kat agreed to go through Side By Side to identify the gaps that need to be addressed before they can adopt the FDC3 API.

The group should analyse the FDC3 Use Cases to help identify specific proposals to extend the existing API.

10 min

AOB

group

Riko requested that the group establish a process around PRs addressing questions such as how long can they stay open, how many individuals need to review before merge.

Nick commented that for large PRs they should be discussed in this WG. Need to determine how to distinguish large from small and perhaps this is for the PMC. In general, for PRs, three seems like a good number but if there are negative comments it should be discussed.

Riko pointed out that the group should exercise basic discipline around PRs and it would be useful to establish some non-invasive protocols, such as using tags; using "approved" vs "requires work" buttons; having one person do the PR & two approve, etc.

Action items

Browser not supported