No update on reaching out to senior kdb developers from DB / RBC.

Alok is going to reach out to Nick Psaris at BAML since Nick is the author of a book about kdb.

Rob will try to work "top down" through the FINOS board members to identify potential collaborators for this WG.

Rob provided his update on reaching out to Kx/Kdb on their involvement, including the license.

Discussion around whether the WG will support integration builds of 32-bit vs 64-bit plugins on ODP.

• Will probably start with 32-bit to start since it's made available by Kx to attract new developers.
• Would be good if 64-bit were available on ODP.
  • At Morgan Stanley, the Kdb team don't choose their own compiler, the C++ team does.  Successful integration builds on ODP would ensure that it's easy to onboard.  Manually tweaking plugin code to comply with strict compilation flags eats up developer time.

Jason said he could send out information about namespace conventions that might be applicable.

Alvin to send out notes to the mailing list about conventions that get used for qualifying names.

Discussion of what could/should be the 1st project we should (effectively our first points on the board) which will building interest among others in participating in our program/WG.

Ryan agreed that developers in member firms are still a bit nervous about contributing code to the outside world.

Rob pointed out that the CCLA should provide the necessary protections.

Alvin opined that most developers do not know the contribution approval workflow end-to-end and are worried about hidden landmines.  That nervousness creates a barrier to developer involvement and exercising the correct processes.  Contributing to a coding standards document would be far less risky to the individual since nobody's ever been sued for having an opinion on how code looks.

Alok concurred that he is not 100% clear about the processes.

Ryan supportive of coding standards being a useful project for the WG.

Rob likened this (going after coding standards first) to a "canary in a coalmine".  Contributions to this will alert developers to potential issues to code contribution that can be sorted out with the help of FINOS if necessary.

Ryan suggested that coding standards might benefit from well-known kdb personalities endorsing them.  Suggested Nick Psaris and Jeff Borror.

Alvin will raise the topic with Jeff.

Ryan also pointed out that code contributed to FINOS will be more on the "industrial" side, which may have different standards.

Alvin suggested looking at C++ Core Guidelines for inspiration:

• https://github.com/isocpp/CppCoreGuidelines

Alok noted that Citi has "several" q coding standards.  We might want some alignment with Python standards since Kx is aligning themselves with that community.

Alvin remarked that one benefit of coding standards is that developers will be less likely to confuse "diff" tools.

Alok mentioned auto-documenting tools will impact coding standards.  Alvin will kick off a discussion on the mailing list about that.

Jason reiterated support for module loading since that would enable packaged tools.  No CPAN for q.

Alvin pointed out that an "industrial strength" dbmaint.q is something that could be among the first projects tackled.

• https://github.com/KxSystems/kdb/blob/master/utils/dbmaint.md

Alvin asked about how programs with multiple WGs organize things in GitHub.

Rob suggested looking at how FDC3 does things as they have multiple WGs.

GitHub terms of service indicate that a single human should only have a single account.  Some people like to partition their personal and work lives to the extent possible.

Alvin to look into this further.

See if FINOS has a collaborative document editing platform other than the Wiki.

Reminder that Google Group is public, which should satisfy the regulators as well as allowing non-members to see if they'd like to participate.