2018-07-13 Meeting notes

Draft:  

• visit the FDC3 Confluence site and Github Organization
• Document and share your use cases
• Participate in a Working Group
• Implement the standards in your organization
• Contribute to reference implementations
• Provide feedback on proposals, drafts, and specifications
• Contribute to the steering meeting

Nick: Originally FINOS has all of the ownership; this model seemed suboptimal for working together; we changed that now such that the PMC has ownership. If you don't have admin access, talk to Mau. The key thing is do not delete projects w/o FINOS permission; and definitely do not delete the org. 

Nick: Also of note is that FINOS has provided the program its own webex account now. We should move off of our existing meetings. 

Saori: Who do I ask for account / meeting access?

Nick: me.

Nick: A lot of good discussion. Lot of excitement about FDC3

Nick: Discussion of Plexus / FDC3. One of the things that was discussed was the outstanding pull request. Some of this might be semantics and us just sitting together; we also discussed putting FDC3 under an umbrella - there are lots of different ways to approach this. Curious to get feedback from the PMC about the PMC perception of overall – what has been productive? not productive. One thing raised has been that it's perceived as hard to raise questions in this organization – we want to be inclusive

Frank: Re programs themselves, those are two different programs. One is a platform play (Plexus); FDC3 is a specification of interoperability on the desktop. Have not seen bias; we do need to think about voting and voting capability. There should be a community for how decisions made. I do not think the programs should be folder into each. And the WG structures we need to be tighter on. 

(RU: Also see voting discussion on the Community Handbook)

Saori: I agree with Frank. My comment is more about FINOS programs and how they are scope ... for example the VOICE program. Do we separate specifications and implementations into different programs? Or same program like Voice?

JT: Division of work – multiple programs, one that is specification, multiple others than implement;? Really agree with Frank about voting and governance. Don't know if we plan to go into 

Neil: Plexus is there and in existence ... also the pull request

Nick: There has been a lot of discussion about the PR

Tim: I have also considered Plexus an architectural pattern.

Johan: Non-engineering questions ... is there any work happening in the Plexus program (around standards?)

Nick: Saori is there standards work happening?

Saori: No, that is happening in FDC3. As part of grandfathering, standards work is to happen in FDC3.

Frank: this sounds mostly around the standard

Saori: Would like FINOS feedback on programs and structure; what about DB being on the FDC3 PMC – could that help?

Johan: Symphony also has their own program and also has their interop. 

Rob: Shared Peter Monks transition and there is active discussion about the program taxonomy; ultimately a key board responsibility is the program organization/taxonomy. 

1. FDC3 is not trying to define a feature complete system for interoperability.  FDC3 seeks to standardize the critical interfaces and touchpoints that will maximize the opportunities for interoperability across the industry.
2. We are coming to this process with a crowded field of many proprietary solutions providing a range of overlapping functionality.   Many of these are feature complete systems for interoperability - within their domains.  FDC3 seeks to provide what we don’t have today:  a standard that spans across these individual implementations.
3. This is not a perfect or clear cut process and we need to take the long view.  While under-specifying carries risk of fragmentation.  Because, given a vacuum, different proprietary approaches will fill the void left by light standards.  We are already living with fragmentation and it is always possible to unwind fragmentation.  Over-specifying, on the other hand carries a much greater risk of significant effort spent on a standard that will not and cannot gain traction because it runs counter to use cases, is too complicated to implement, or steps into areas of real competitive value for stakeholders.  For these reasons, the standards process is an inherently slow grind.
4. Criteria for a successful proposal is not just that it's a useful feature.  Proposals must, among other things, demonstrate that significant and mutual efficiencies would be gained and/or opportunities unlocked by the existence of the standard

1. 1. The proposal isn’t picking winners and losers among stakeholders.  
   2. The proposed standard doesn’t set an overly high cost of implementation and maintenance for the implementor.
   3. The proposal doesn’t run counter to accepted best practices.
   4. There is maximum reasonable flexibility around the requirement for implementors apply their own value.
2. Finally, in the interest of the actual success of FDC3 standards, it seems that the best approach may be to standardize the bare minimum, work on getting things working in the various platforms we represent.  Observe what works, what doesn’t, what the gaps are, then iterate on the standards, and repeat.